2 ms·

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 interope

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.

leeter 6y ago
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.
- AshamedCaptain 6y ago
  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.

leeter 6y ago

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.

AshamedCaptain 6y ago
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.