Hacker News Reader

Comment by cshokie | Hacker News Reader

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.

View on HN

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.

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

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.

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

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

Reply on news.ycombinator.com