Attached is a test file and trm.dll, along with the fasm.exe's that I tested with. TRM is the Tsunami Record Manager, a freely distributed, non-open sourced "data base" package--no longer supported.

When using 1.69.20 and .22 the program assembles and runs fine. When using .24 or .25, the program assembles but won't properly initialize the dll. In Olly 2 it seems to enter the dll at the wrong place, but I'm not sure. One thing about the dll, it is compressed or protected in such a way that Olly 1 would give a message that the entry point was outside the memory space, or something like that.

This had me scratching my head for a few hours.

Thanks in advance,

farrier

There appears to be new flags set:

IMAGE_DLLCHARACTERISTICS_NX_COMPAT 0x0100 (offset PE_Header:0x5e)

and

IMAGE_FILE_RELOCS_STRIPPED 0x0001 (offset PE_Header:0x16)

Both introduced in 1.69.23

My guess is that the DEP is the problem. Perhaps the DLL writes some code to the stack?

Try either/both 1) manually flipping the NX bit in the exe 2) turning off DEP in your OS for the test exe.

Programs using this DLL and the "Pro" version have been running on OS's from Win 95 thru Win 7 without a hiccup for 9 years now. So it is something that the fasm is doing to the .exe file that makes my Win Vista 64 unhappy.

I'll try the NX bit this evening! Thanks.

farrier

I did add the "NX-aware" setting since with fasm you specify "executable" flag for sections, which really makes full sense only when you have NX enabled. However if that code tries to execute some code on stack, that would really be a problem, since there is no way of defining PE stack as "executable".
Maybe I should add "NX" as another flag for "format PE" declaration.

Yes. I think it is needed.

farrier: Was the NX bit the problem for you?

Tomasz & revolution,

It does indeed appear to be DEP. Things changed for me with 1.69.24 & .25 and the only differences in the .exe's were:

Time and Date: makes sense
Characteristics: .24 & .25 have IMAGE_FILE_RELOCS_STRIPPED set ??
Checksum: again, makes sense
DllCharacteristics: word at 0xDE, 0xDF in the .exe, .24 & .25 are set to
IMAGE_DLLCHARACTERISTICS_NX_COMPAT - 0x0100 which is
"The image is compatible with data execution prevention (DEP)."

Changing 0x0100 to 0x0000 allowed the program to run without problems, the IMAGE_FILE_RELOCS_STRIPPED bit being set or cleared didn't seem to make a difference. I haven't figured out what this does!!

So for now, I'll continue to use the latest version of the fasm and clear "The bit that makes a difference!"

Thanks again for your help!

farrier

farrier,

editbin /nxcompat:no can be used to automate bit reset.

IMAGE_FILE_RELOCS_STRIPPED indicates that base relocations (usually .reloc section, pointed by DataDirectory[IMAGE_DIRECTORY_ENTRY_BASERELOC] element of optional header field) are absent. Such PE can't be relocated and can be loaded only at its preferred image base. Actually loader ignores this flag and looks for valid DataDirectory[IMAGE_DIRECTORY_ENTRY_BASERELOC] entry.

baldr,

I'll study, learn, and use!

Thanks,

farrier

Is this flag in the planning for a future release?

Any update on the NZ flag?

farrier

I have added the "NX" flag in 1.69.32 release. Sorry for delay, I just forgot about it until now.

Tomasz,

Thank you for your continued, excellent efforts for us!!!

farrier

I'm having a similar problem with using the "LoadLibrary" function with an fasm dll (which the latest fasmw version [1.69.32] doesn't seem to fix.). It seems to be trying to initialize the dll in the wrong place. Some Examples are below, the one in 2008 runs good, the later one gives me an error.

Hmmmm, appears no one else is having this problem?