NASM on win7 64 bit

[blah32]

I am trying to get a hello world program to run on win7 64 bit. It compiles and starts to run, then gives me this error:
This version of .../nasm_test.com is not
 compatible with the version of Windows you're running. Check your computer's sy
stem information to see whether you need a x86 (32-bit) or x64 (64-bit) version
of the program, and then contact the software publisher.

Is there a way to get it to work?

Thanks

[Frank Kotler]

Should be.

The extension ".com" suggests you've got a 16-bit "hello", which will not run on 64-bit 'doze, I understand. MS has been threatening to drop 16-bit support for years, and apparently they finally pulled the trigger.

I *think* a 32-bit program should run on 64-bit Windows, and Nasm should assemble a 64-bit program. The code for the two would be quite different! I don't know much about 64-bit Windows (or 64-bit anything), but it appears to me that they've "thown us a curve ball". Even "just call printf" is different - not only different from 32-bit, but different for Windows and Linux! A complete mess, IMHO.

If you want to be able to run .com files on your system, look into "dosbox" or some similar emulator.

Best,
Frank

[michaeljreeves]

Windows 7 64-bit supports 32-bit programs under > Program Files(x86) < and has dropped support for 16-bit programs. This is documented on the Microsoft website if you want more info.

Even some 32-bit legacy programs don't work well under (x86), BUT MS offers an updated virtual machine program for Win7 Pro and above. (I think it's Pro+, but check). When you d/l and install, you get the same version of XP.  I am using Win7 Pro 64-bit myself, so, I was able to d/l and install XP Pro 64-bit.

Now, the Intel CPU's still support 16-bit programs and OS's for backwards compatibility of legacy programs. So, the fact that Microsoft no-longer supports 16-bit programs under Windows 7 was/is an arbitrary decision on their part.

I can boot and run MSDOS 6.22 and Windows 98 from an attached floppy disk. Unfortunately, these OS's will only install on HDD Drive[0] or can be installed on a floppy. I haven't tried it, but might be able to install on a ZIP drive if it registers as drive A:

As for your specific issue.... I have the same problem w/ 32-bit compilers. My solution was to install the XP-mode virtual machine and test under that OS. My IDE/Compilers seem to work okay w/ that arrangement. BUT XP-mode 64-bit does NOT support 16-bit programs either.

Another work-around I have implemented is to use an available PC loaded with a 32-bit OS that still supports 16-bit programs (debatable at best) such as XP Professional w/SP3 32-bit.

Wish I had better options to offer. I spent several weeks after I got my new system w/ Windows 7 Professional 64-bit pre-installed trying to set up other VM's such as Windows ME. Couldn't do it YET. LOL!!!

A final suggestion would be to open up the settings for NASM and make sure it always compiles source code as a 32-bit program.

[Frank Kotler]

Hi Michael,

Don't I "know" you from the HLA/aoaprogramming list? You expressed an interest in helping to upgrade HLA to 64-bits (thank you, if Randy doesn't). I think you'll find that there's a lot more to it than looking up new opcodes in the opcode table. See how it goes...

You also expressed an interest in "base assembly language", as opposed to the "high level" approach that HLA - as the name suggests - uses. Nasm is about the opposite end of the spectrum, in that regard. I'm glad you're taking a look at it. Hope you find it useful/interesting/educational... whatever.

Thanks for the suggestions on virtual machines - "dosbox" is merely one I've heard of... that "should" do it.

I don't think you'd want Nasm to "always" assemble 32-bit code - it'll do 16-32-64 bits, why cripple it? On a 64-bit system, "other tools" - compiler and linker - may expect to do 64-bit code by default, and may need a command line to advise it that we're doing 32-bit, if that's what we want. This is the case with Linux, anyway. Should be able to do both... either... all three... You need "appropriate" source code for each though!

Best,
Frank

[Keith Kanios]

MS has been threatening to drop 16-bit support for years, and apparently they finally pulled the trigger.

They had no choice, as Virtual 8086 Mode is not available/accessible from Long Mode.

NTVDM = Virtual 8086 Mode + some wrapper/monitor code.

WoW64 = Compatibility Mode + some wrapper/monitor code.

Same attempt to market an architectural feature as an internal innovation, different day

If you want to be able to run .com files on your system, look into "dosbox" or some similar emulator.

I second that recommendation of dosbox.

[Frank Kotler]

WoW64? They got a special 64-bit version of World of Warcraft?

Best,
Frank

[Logman]

If you install dosbox, does that mean you have to install the DOS version of NASM too? And will the DOS version of NASM install in Windows 7? Or do you have to put the DOS version of NASM on a floppy or something?

Logman

[Keith Kanios]

If you install dosbox, does that mean you have to install the DOS version of NASM too? And will the DOS version of NASM install in Windows 7? Or do you have to put the DOS version of NASM on a floppy or something?

No, but you can. Ideally, you want to make a directory on your C drive, probably called DOS, and instruct dosbox to mount that directory as its own C drive.

You can copy and paste into C:\DOS\ in Windows, and dosbox will see it relative to C:\

[Kaysoky]

I've had the same problem:
Every time I enter something along the lines of

Code: [Select]

nasm -o program.exe -f win64 program.asmand try to open it, I get the pop-up saying that this is an "Unsupported 16-bit Application".  It clearly uses 64-bit code, and ".exe" is supposedly a supported extension. 

The program itself is just a push + pop reg64, so code-wise there should be no problem.

Is there a better command line instruction I should use to fix this?

[Keith Kanios]

I've had the same problem:
Every time I enter something along the lines of

Code: [Select]

nasm -o program.exe -f win64 program.asmand try to open it, I get the pop-up saying that this is an "Unsupported 16-bit Application".  It clearly uses 64-bit code, and ".exe" is supposedly a supported extension.  

The program itself is just a push + pop reg64, so code-wise there should be no problem.

Is there a better command line instruction I should use to fix this?

Yes, link the Win64 object file to an executable by using a linker. NASM, with the exception of -f bin, produces object files expected to be handled by linkers.

Grab a copy of Jeremy Gordon's GoLink linker and have at it.

Also, the latest stable version of NASMX has Win64 demos demonstrating just that, how to assemble/build with NASM and link with GoASM. Take a look at one of the Win64 demo batch files and you'll see.

[Gary F]

I think the instruction code changed with the chip Architecture. I went to the Intel site and requested a manual on CD (free) for the specific chip. When I receive the CD, I will have more information to share.

Gary
 

[alexbarringer]

I think the instruction code changed with the chip Architecture. I went to the Intel site and requested a manual on CD (free) for the specific chip. When I receive the CD, I will have more information to share.

Gary
 

I think I should chime in here to make things a little bit easier to understand.  Not only does the mode change in the CPU and how it is addressed when it's in 64-bit mode but the BIOS itself, where the 32-bit BIOS will allow you to run .com files with minimum effort but in 64-bit mode the BIOS was completely rewritten.  Meaning that if you don't have a virtual machine
converting from 64-bit mode and 64-bit BIOS calls to a 32-bit mode and 32-bit BIOS call, you are out of luck, in other words the .com will not work.

However, should you feel the need to write 8 or 16-bit applications that are of the 64kb size and under and as a .com type file, you can get a nice little package that I use and it's free to use and download, it's called D-Fend-Reloaded version 1.3.2, comes as an auto installer as an .exe, just Google or DuckDuckGo it.  The D-Fend package emulates the older PCs and video cards to make it a pretty good alternative, even for those 16 and 32-bit protected mode games or applications.