Comment by leeter | Hacker News Reader

Comment by leeter | Hacker News Reader

Parent Full thread

> It was a political choice by Microsoft to drop 16 bit Windows support in 64 bit Windows. This is the limit of their famous backwards compatibility -- still impressive, though.

No... it wasn't political. It was a deliberate design decision for technical reasons ( https://docs.microsoft.com/en-us/windows/win32/winprog64/run... ) HANDLEs on 64bit windows have 32bits that are valid whereas HANDLES on 32bit windows only have 16bits that are valid. So unless Microsoft wanted to completely negate the value of going to 64bit in the first place, e.g. expanding the limits on programs to be less restrictive, it was always going to have something to give.

Because 32bit code often "thunked"^1 in 16bit code they couldn't really support it because even in 32bit mode HANDLEs still have 32bits of valid HANDLE. So a HANDLE passed to 16bit code wouldn't round trip correctly due to truncation.

Nor is it like MS could emulate this like the OPs code does, because that would require rewriting applications that had already shipped from ISVs that don't exist anymore or magically understanding when an application has 16bit code and needs to get fake HANDLEs neither of which is easy in reality. In the end it was easier to just ship a 32bit version of windows for those that still needed that support.

1^ This was only possible because FAR pointers in 16bit mode are still 32 bits and thus size of a pointer was in effect the same. So they could operate in the same address space. In 64bit mode this isn't the case because there are no FAR pointers and segmentation.

Fair enough, though it's still not a hardware reason.

You could have just given 16bit handles to all 32bit programs, with the con being harder 64<->32 interoperability (since sending a handle from 64 to 32/16 would require faking it), but then you would not break _existing_ applications at least. Guessing 32bit handles also broke quite some 32 bit applications.

In retrospective, I would not have made it the way I describe either way, since it looks like people could care less about old 16-bit compatibility, and on the other hand 32<->64 coexistence was common for quite a while.

So unfortunately people do care, it's why 32bit windows is still a thing. Most of the people that care however are large legacy enterprises that are running line of business applications that they don't have the source code for or require libraries they don't have the source code for. While they are migrating it's not a quick process in many cases.

As for 16bit HANDLEs for 32bit programs, it wouldn't have solved the issue as the HANDLEs are kernel tokens. The kernel doesn't actually care whether the user space application is 32 bit or 64bit in many cases. That's all handled via WoW64CPU.dll and friends. They proxy all kernel calls from 32bit code and then segment switch to a 64bit segment before calling the kernel. The same happens in reverse when coming back. So it would incur significant performance overhead in many cases to add that when it isn't really necessary and would negatively impact already memory constrained programs. Instead MS chose to let them get the best benefits they could from 64bit mode: all 4GB the 32bit address space can be used for 32bit things instead of just the bottom 2/3GB (depending on being flagged /LARGEADDRESSAWARE). In the end it's a lot more complicated than just telling people that aren't using very memory intensive apps in the first place to just run 32bit Windows which already works... and supports vm86 mode.

Technically, the kernel does not need to care, other than providing an API to create a 16-bit alias to a handle. An API which the 32/16-bit APIs will use transparently, as well as 64-bit programs explicitly whenever they want to send to a potentially 32/16-bit process.

HANDLEs on 64bit windows have 32bits that are valid whereas HANDLES on 32bit windows only have 16bits that are valid

...then use a translation table. If the system is 64-bit, there's certainly enough room and speed for one!

16-bit applications would not be able to handle more than 64k handles either way.

Not as simple as it sounds, HANDLEs are universal on windows. So it requires user mode code to both be in on the charade and to play nice, which it rarely ever does. The issue being things like GetWindowHandle, CreateMutex etc. Passing a Mutex or Event handle to another process is not uncommon on windows. Yes in theory you could just block off the lower 64k Handles as compat handles but it makes code complicated and that leads to unnecessary bugs in code that has to handle it. It's a lot simpler at the end of the day to just ask customers that need that support to just run 32bit windows which has NTVDM support for real mode code and simple 16bit protected mode support that's transparent and just works. So yes they could have done that... but the complication isn't worth it when they have something that works just fine already at no extra cost to development or client; and these apps are being phased out largely anyway. Long story short: the solution sounds simple but once you start plugging all the holes and corner cases it gets insanely complicated very quickly.

I thought that the specific primitives needed to make NTVDM work were removed from AMD64, specifically that you cant go to Virtual 8086 mode, directly from long mode, without another reset inducing mode change someplace else? I read an article about this like 5 years ago.

But you _can_ go into vm86 mode from long mode. Linux used to allow you to do that and there was even a patch floating around to restore this when it was removed from the kernel.

Mostly true, this would be protected mode 16bit code (286), not DOS code or real mode code. Protected mode 16bit code was rare and thus support was less needed.

Reply on news.ycombinator.com