3 ms·

No, it is possible to run 16 bit protected mode applications (i.e. Windows 3.x apps) under 64-bit "long mode". Microsoft explicitely chose to not support that -

by einr 5y ago

No, it is possible to run 16 bit protected mode applications (i.e. Windows 3.x apps) under 64-bit "long mode". Microsoft explicitely chose to not support that -- with a few exceptions. In true Microsoft fashion, NTVDM on x86-64 is actually hardcoded to be able to run a couple of known InstallShield and Acme installer executables that are 16-bit but used to install 32-bit software. WINE on Linux x86-64 will run 16-bit Windows programs, by the way. However, you cannot do virtual 8086 mode without switching back to 32-bit mode, so you cannot run real mode MS-DOS programs. This would probably have broken a lot of 16-bit Windows software that still relied on real mode components, so it does make sense for this and other reasons that they dropped support for 16-bit software.

AshamedCaptain 5y ago
> However, you cannot do virtual 8086 mode without switching back to 32-bit mode, so you cannot run real mode MS-DOS programs. You can switch to 32-bit mode, then enter vm86, and then switch back to long mode once you are done. There was a kernel module flying around that would do this and make syscalls such as vm86plus work in amd64 Linux. But yes, basically, it's a political more than technical choice to drop support for 16-bit programs on 64-bit Windows; same for >4GiB RAM support in 32-bit Windows.
- leeter 5y ago
  I saw that module, looked at the code, and wondered if at that point it wouldn't be easier to just run a thin wrapper around the virtual 8086 code while just using standard virtualization extensions. That way it's just another KVM and not yet more kernel code to maintain. Because honestly QEMU already supports that target. This is of course ignoring the many issues caused by faster CPUs or things the target program is expecting but no longer exist or act differently on modern CPUs.
  - AshamedCaptain 5y ago
    Well, there is a rather straightforward explanation: virtualization extensions did not exist, and in fact would not exist for another 5 years at least. Actually, now that I think of it, having KVM capable of running real mode DOS is a rather recent development. Looking at you, AMD, but even early Intel VT-x didn't get it right until 2010ish (Westmere). Anyway, dosemu2 does exactly that (use KVM to run a lightweight kernel that just enters vm86).

by einr 5y ago

AshamedCaptain 5y ago

> However, you cannot do virtual 8086 mode without switching back to 32-bit mode, so you cannot run real mode MS-DOS programs. You can switch to 32-bit mode, then enter vm86, and then switch back to long mode once you are done. There was a kernel module flying around that would do this and make syscalls such as vm86plus work in amd64 Linux. But yes, basically, it's a political more than technical choice to drop support for 16-bit programs on 64-bit Windows; same for >4GiB RAM support in 32-bit Windows.

leeter 5y ago
I saw that module, looked at the code, and wondered if at that point it wouldn't be easier to just run a thin wrapper around the virtual 8086 code while just using standard virtualization extensions. That way it's just another KVM and not yet more kernel code to maintain. Because honestly QEMU already supports that target. This is of course ignoring the many issues caused by faster CPUs or things the target program is expecting but no longer exist or act differently on modern CPUs.
- AshamedCaptain 5y ago
  Well, there is a rather straightforward explanation: virtualization extensions did not exist, and in fact would not exist for another 5 years at least. Actually, now that I think of it, having KVM capable of running real mode DOS is a rather recent development. Looking at you, AMD, but even early Intel VT-x didn't get it right until 2010ish (Westmere). Anyway, dosemu2 does exactly that (use KVM to run a lightweight kernel that just enters vm86).