16-bit Assembly on 64-bit Windows?

前端 未结 3 690
南旧
南旧 2021-01-29 03:35

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

相关标签:
3条回答
  • 2021-01-29 03:43

    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.

    0 讨论(0)
  • 2021-01-29 03:52

    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.

    0 讨论(0)
  • 2021-01-29 04:01

    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.

    0 讨论(0)
提交回复
热议问题