Although I've been using ASM almost exclusively since 1992, I've been somewhat of a ghost as far as connecting with other developers of the same mindset. I've been developing a commercial product for 17 months, 60 to 80 hours per week. I'm on the verge of release, in testing under Win 7, and ONLY under 32-bit Windows 7, I've hit an anomaly (all my development was under Vista).

I've verified that when my .EXE loads my own .DLL, all variables inside the .DLL are fixed up to relocate under the base address of the .EXE, ignoring the .DLL's base address. Clearly this is a runtime issue with the Win 7 loader. The offsets are good but the pointers in the first .DLL function I call are going to (for example) 40F6CFh when the .DLL's base address is 10000000h so the pointer should be 1000F6CFh. Obviously they've changed the loader in Win 7.

So my question is, does FASM account for this or prevent it? Thanks in advance!

Maybe you forgot to add the fixups?

My existing version was compiled with MASM. I'm looking at switching to FASM now because of this problem.

If the relocs are present in all the DLLs (and I believe this is always the case with MASM, at least with default settings), then everything should be going fine. The base address you mention, is the one you specified at link time? Notice that if the address range is already occupied the DLL has to be, well, relocated and hence it is completely normal to have it re-based (and therefore the pointer to functions looking different). Now if because of this the pointers are going nowhere (memory not allocated), or to something that it shouldn't go to then something is seriously screwed up (hard coded pointers in your source that MASM is not identifying as relocatable pointers rather than plain immediates?)

In case you are looking that one DLL and your EXE are using overlapping addresses, make sure the EXE is actually loaded where you think it is, because if MASM included relocations in your EXE, then Win7 might be using them as part of the ASLR process.

OMG it's the embarrassment of the century. On par with calling tech support for a broken computer that isn't plugged in ...

I installed Win 7 on a new hard drive. Copied the whole development directory tree to the new Win7 drive off the old Vista drive. Had to rework all the batch files that do all the compiling because all the ML.EXE, LINK.EXE, etc. files are now in different location (8.3 naming has to be used in batch files). In the process of doing all this ... ahem ... I changed the /out: file name to something.dll ... but ...

... forgot the /DLL switch so it was compiling as an .EXE and being named as a .DLL.

Added the switch and it all worked.

There's a new linux-ish thing called PowerShell 2.0 in Windows 7, maybe you can break that 8.3 limitation with this shell.