5 ms·

I think 16-bit support is actually a limitation of x86 CPUs. They can only go into 16-but mode if they booted as 32-bit. A 64-bit CPU running in 64-bit mode is

I think 16-bit support is actually a limitation of x86 CPUs. They can only go into 16-but mode if they booted as 32-bit. A 64-bit CPU running in 64-bit mode is incapable of running 16-bit x86 code. It is not a software limitation. This can be demonstrated by installing 32-bit Windows and enabling 16-bit support.

BBC-vs-neolibs 5y ago
Yeah, but if they REALLY wanted to, they could have emulated an 80268, it would have been plenty fast even in interpreted emulation. The whole NTVDM machine would fit in L1 cache. http://www.columbia.edu/~em36/ntvdmx64.html http://www.columbia.edu/~em36/ntvdmx64.html https://github.com/leecher1337/ntvdmx64 https://github.com/leecher1337/ntvdmx64 http://www.columbia.edu/~em36/otvdm.html http://www.columbia.edu/~em36/otvdm.html https://en.wikipedia.org/wiki/SoftPC https://en.wikipedia.org/wiki/SoftPC
leeter 5y ago
You can support 16bit in long mode via compatibility mode (the bits are still in the Global descriptor table definition https://wiki.osdev.org/GDT https://wiki.osdev.org/GDT as long as the long mode bit isn't set the, Sz bit can be used to indicate 16bit code), just not real mode without using virtualization extensions. The issue was more the way HANDLEs were managed and getting rid of 16bit limitations. (also getting programmers to stop assuming they could safely do things with the upper parts of handles)
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).

BBC-vs-neolibs 5y ago

Yeah, but if they REALLY wanted to, they could have emulated an 80268, it would have been plenty fast even in interpreted emulation. The whole NTVDM machine would fit in L1 cache. http://www.columbia.edu/~em36/ntvdmx64.html http://www.columbia.edu/~em36/ntvdmx64.html https://github.com/leecher1337/ntvdmx64 https://github.com/leecher1337/ntvdmx64 http://www.columbia.edu/~em36/otvdm.html http://www.columbia.edu/~em36/otvdm.html https://en.wikipedia.org/wiki/SoftPC https://en.wikipedia.org/wiki/SoftPC

leeter 5y ago

You can support 16bit in long mode via compatibility mode (the bits are still in the Global descriptor table definition https://wiki.osdev.org/GDT https://wiki.osdev.org/GDT as long as the long mode bit isn't set the, Sz bit can be used to indicate 16bit code), just not real mode without using virtualization extensions. The issue was more the way HANDLEs were managed and getting rid of 16bit limitations. (also getting programmers to stop assuming they could safely do things with the upper parts of handles)

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).