Win7 64bit?

[dreamaco]

Hi,
recently got 64bit Windows 7, and so old DOS versions of NASM no longer worked so downloaded the window version.
So far sa good, but assembling with them does not produce same binary files. The produced binary did not any longer run in BOCHS.
I tried to assemble same code on XP using DOS version of NASM and transffered those files into Win 7 64bit and same BOCHS. Runs perfectly!
So its something with Windows NASM not producing same as the DOS? What am I missing?
the parameters used for NASM are simple as NASM.exe file.asm -o file.bin.

Any ideas what could make the NASM versions producing differently output?

Using 2.09.08

[the_mart]

Do you have a basic sample application showing what you’re trying to build? What type of executable are you trying to create, and for what platform? It’s possible that your output file is in the wrong format, but it’s hard to know exactly what’s wrong without those details.

I can confirm that NASM works perfectly well with Windows 7 x64.

[dreamaco]

I cannot show any code in its entirety but its nothing special really it does use BITS16 BITS32 and ORG directives.
I did some tests and found out the actual byte differences between what was produced DOS and WIN NASM:

There where 5 things so i simply show them all here:
A few bytes as they appeared became different by window NASM version:

bytes 7Dh became 81h
byte 7Eh became 82h
bytes 7Fh became 83h
and 7ch became 80h

And then the initial ORG 7C00h did the 5th thing which introduced 1024 initial zeros int he binary.
deleteing the ORG made away those 1K  of zeros. Of course every offset became wrong but,


So, those where the 5 things that 64bit Windows NASM did differently, does this make any sense?

[the_mart]

There’s not really enough information here. A simple “hello world” example is fine, as long as it demonstrates the behaviour you are describing.

Also, you didn’t mention what type of executable you are trying to create, and which platform it is for. It sounds like you might be trying to create an x86 boot sector.

[dreamaco]

The type of executable I mentioned before NASM.exe file.asm -o file.bin, which is a simple flat binary.
Yes it's indeed a bootsector, the strange behaviour comes with the first few lines actually so here they are they are:

ORG 7C00h ; oddity here is that this produces 1KB of zeros in Win64 using Windows version of NASM
BITS 16
JMP 0:$+5 ; here bytes starts to differ in DOS and Win NASM when used in Win64, more specifically a original 7C goes into a 80h

; These two above lines is my main problem, if I have more problems as the bytes changing mentioned above they are clearly related to the above.

Note that when used in Win7 32bit windows NASM version worked PERFECTLY and identical to DOS, but now on 64bit Win7 seem to be a different game alltogether?

Anyone knows what these 2 strange oddities is happening?

I want to stress again that if I bring a already compiled from an XP machine for example it will run perfecly in BOCHS on the Win7 64bit. Its just the
behaviour of NASM that seem to differ.

There’s not really enough information here. A simple “hello world” example is fine, as long as it demonstrates the behaviour you are describing.

Also, you didn’t mention what type of executable you are trying to create, and which platform it is for. It sounds like you might be trying to create an x86 boot sector.

[dreamaco]

I tries hard to find the root of the behaviour it shows up here:

ORG 7C00h

JMP 0:$+5

ALIGN 4 ; < This is what introduces 1KB of zero padding in Windows7 64bit but not DOS or Windows7 32bit

Solved partial problem where the bytes changing, this was due to this padding. one single problem left, but why does it pad 1kb?
 

[Rob Neff]

Read This Post as it may help you.

[dreamaco]

A SECTALIGN OFF at the beginning was all that was needed, its now identical to any binary, thanks!

[Keith Kanios]

A SECTALIGN OFF at the beginning was all that was needed, its now identical to any binary, thanks!

That is a temporary work-around, yes.

I've found that while the 2.10 (release candidate) branch is working correctly with respect to section alignment, the 2.09 branch still has some issues. I've also noticed that the binary output (-f bin) driver in both branches differ, with 2.10's version seemingly being the more correct one.

I'll have to raise this issue with the development list.

Thanks for your report.

[Cyrill Gorcunov]

So 2.10 series has a fix which were not fetched back into nasm-2.09.xx series. As Keith just pointed in @nasm-devel list there is a difference between the branches related to potential initialized memory usage, in result I think it become highly system dependant.

I'll fetch fix into nasm-2.09.xx, lets see how it goes. Thanks, and sorry for that.

[Cyrill Gorcunov]

Just pushed out nasm-2.09.09. It should be compiled and packaged soon. So please guys test it out, and report the results.
Thanks!

[dreamaco]

I can confirm its now fixed. Great work.

Just pushed out nasm-2.09.09. It should be compiled and packaged soon. So please guys test it out, and report the results.
Thanks!

[Cyrill Gorcunov]

I can confirm its now fixed. Great work.

Thanks a huge for report and testing!