16-bit Assembly on 64-bit Windows?_问答_开发者

I decided to start learning assembly a while ago, and so I started with 16-bit assembly, using FASMW. HOwever, I recently got a really new computer running Windows 7 64-bit, and now none of the compiled .COM files that the program assembles work anymore. they give an error message saying that the .COM is not compatible with 64-bit windows. 32-bit assemblies still work, however i'd rather start with 16 and work my way up... Is it possible to run a 16-bit program on windows 7? or is there a spec开发者_如何学JAVAific way to compile them? or should i give up and skip to 32-bit instead?

The reason you can't use 16-bit assembly is because the 16-bit subsystem has been removed from all 64-bit versions of Windows.

The only way to remedy this is to install something like DOSBox, or a virtual machine package such as VirtualBox and then install FreeDOS into that. That way, you get true DOS anyway. (NTVDM is not true DOS)

Personally, would I encourage writing 16-bit assembly for DOS? No. I'd use 32- or even 64-bit assembly - the reason being there are a different set of function calls for different operating systems (called the ABI). So, the ABI for 64-bit linux apps is different to 32-bit ones. Not sure if that's the case with Windows. However, I guarantee that the meaning of interrupts is probably different.

Also, you've got all sorts of things to consider with 16-bit assembly, like the memory-model in use. I might be wrong, but I believe DOS gives you 64K memory to play with "and that's it". Everything, your entire heap and stack along with code must fit into this space, as I understand it, which makes you wonder how anything ever worked, really.

My advice would be to just write 32-bit code. While it might initially seem like it would make sense to learn how to write 16-bit code, then "graduate" to 32-bit code, I'd say in reality rather the opposite is true: writing 32-bit code is actually easier because quite a few arbitrary architectural constraints (e.g., on what you can use as a base register) are basically gone in 32-bit code.

For that matter, I'd consider it open to substantial question whether there's ever a real reason to write 16-bit x86 code at all. For most practical purposes, it's a dead platform -- for desktop machines it's seriously obsolete, and for embedded machines, you're more likely to see things like ARMs or Microchip PICs. Unless you have a specific target in mind and know for sure that it's going to be a 16-bit x86, I'd probably forget that it existed, just like most of the rest of the world has.

32-bit Windows 7 and older include / enable NTVDM by default. On 32-bit Win8+, you can enable it in Windows Features.

On 64-bit Windows (or any other 64-bit OS), you need an emulator or full virtualization.

A kernel in long mode can't use vm86 mode to provide a virtual 8086 real-mode environment. This is a limitation of the AMD64 / x86-64 architecture.

With a 64-bit kernel running, the only way for your CPU to natively run in 16-bit mode is 16-bit protected mode (yes this exists; no, nobody uses it, and AFAIK mainstream OSes don't provide a way to use it). Or for the kernel to switch the CPU out of long mode back to legacy mode, but 64-bit kernels don't do that.

But actually, with hardware virtualization (VirtualBox, Hyper-V or whatever using Intel VT-x or AMD SVM), a 64-bit kernel can be the hypervisor for an entire virtual machine, whether that VM is running in 16-bit real mode or running a 32-bit OS (like Windows 98 or 2000) which can in turn use vm86 mode to run 16-bit real-mode executables.

Especially on a 64-bit kernel, it's usually easier to just emulate a 16-bit PC entirely (like DOSBOX does), instead of using HW virtualization to running normal instructions natively but trap direct hardware access (in / out, loads/stores to VGA memory, etc.) and int instructions that make DOS system calls / BIOS calls / whatever.