| ▲ | deaddodo 8 hours ago |
| Nitpick: The author states that removal of 16-bit in Windows 64 was a design decision and not a technical one. That’s not quite true. When AMD64 is in one of the 64-bit modes, long mode (true 64-bit) or compatibility mode (64-bit with 32-bit compatibility), you can not execute 16-bit code. There are tricks to make it happen, but they all require switching the CPU mode, which is insecure and can cause problems in complex execution environments (such as an OS). If Microsoft (or Linux, Apple, etc) wanted to support 16-bit code in their 64-bit OSes, they would have had to create an emulator+VM (such as OTVDM/WineVDM) or make costly hacks to the OS. |
|
| ▲ | jcranmer 8 hours ago | parent | next [-] |
| I've written code to call 16-bit code from 64-bit code that works on Linux (because that's the only OS where I know the syscall to modify the LDT). It's actually no harder to call 16-bit code from 64-bit code than it is to call 32-bit code from 64-bit code... you just need to do a far return (the reverse direction is harder because of stack alignment issues). The main difference between 32-bit and 16-bit is that OS's support 32-bit code by having a GDT entry for 32-bit code, whereas you have to go and support an LDT to do 16-bit code, and from what I can tell, Windows decided to drop support for LDTs with the move to 64-bit. The other difficulty (if I've got my details correct) is that returning from an interrupt into 16-bit code is extremely difficult to do correctly and atomically, in a way that isn't a problem for 32-bit or 64-bit code. |
| |
| ▲ | deaddodo 7 hours ago | parent [-] | | Executing 16-bit code in Compatibility Mode (not Long Mode) is possible, that's not the problem. The problem is lack of V86 allowing legacy code to run. So Real Mode code is out wholesale (a sizable chunk of legacy software) and segmented memory is out in Protected Mode (nearly the totality of remaining 16-bit code). So yes, you can write/run 16-bit code in 64-bit Compatibility Mode. You can't execute existing 16-bit software in 64-bit Compatibility Mode. The former is a neat trick, the latter is what people actually expect "16-bit compatibility" to mean. | | |
| ▲ | jcranmer 6 hours ago | parent [-] | | > segmented memory is out in Protected Mode (nearly the totality of remaining 16-bit code). No, segmented memory is exactly what you can get working. You set up the segments via the LDT, which is still supported even in 64-bit mode; this is how Wine is able to execute Win16 code on 64-bit Linux. (Reading Wine code is how I figured out how to execute 16-bit code from 64-bit code in the first place!) What doesn't work, if my memory serves me correctly, is all the call gate and task gate stuff. Which is effectively building blocks for an OS kernel that everyone tossed out in the early 90s and instead went with kernel-mode and user-mode with the syscalls (first software interrupts and then the actual syscall instruction in x86-64). You don't need any of that stuff to run most 16-bit code, you just need to emulate the standard Windows DLLs like kernel, ntdll, and user. |
|
|
|
| ▲ | Animats 7 hours ago | parent | prev | next [-] |
| It's not so much running 16 bit code, but running something that wants to run on bare metal, i.e. DOS programs that access hardware directly. Maintaining the DOS virtualization box well into the 21st century probably wasn't worth it. > The 64-bit builds of Windows weren’t available immediately. There was a year or so between the release of AMD-64 and the first shipping Microsoft OS that supported it.[1] It was rumored that Intel didn't want Microsoft to support AMD-64 until Intel had compatible hardware. Anyone know?
Meanwhile, Linux for AMD-64 was shipping, which meant Linux was getting more market share in data centers.[1] |
|
| ▲ | EvanAnderson 8 hours ago | parent | prev [-] |
| Microsoft has just such an emulator. Via Windows source code leaks the NTVDM (Virtual DOS Machine) from 32-bit Windows versions has been built for 64-bit Windows targets[0]. I don't understand why Microsoft chose to kill it. That's not in their character re: backwards compatibility. [0] https://github.com/leecher1337/ntvdmx64 Edit: Some nice discussion about the NTVDMx64 when it was released: https://www.vogons.org/viewtopic.php?t=48443 |
| |
| ▲ | deaddodo 7 hours ago | parent | next [-] | | NTVDM requires Virtual 8086 mode in the processor. This doesn't exist in the 64-bit modes, requiring a software emulator. That is why OTVDM/WineVDM exist. You can see all of this explained in the README for the very project you linked: ``` How does it work? ================= I never thought that it would be possible at all, as NTVDM on Win32 uses V86
mode of the CPU for fast code execution which isn't available in x64 long
mode.
However I stumbled upon the leaked Windows NT 4 sourcecode and the guys from
OpenNT not only released the source but also patched it and included all
required build tools so that it can be compiled without installing anything
but their installation package.
The code was a pure goldmine and I was curious how the NTVDM works. It seems that Microsoft bought the SoftPC solution from Insignia, a company
that specialised in DOS-Emulators for UNIX-Systems. I found out that it also
existed on MIPS, PPC and ALPHA Builds of Windows NT 4 which obviously don't
have a V86 mode available like Intel x86 has. It turned out that Insignia
shipped SoftPC with a complete emulated C-CPU which also got used by Microsoft
for MIPS, PPC and ALPHA-Builds. ``` As to why they didn't continue with that solution, because they didn't want to rely on SoftPC anymore or take on development themselves for a minuscule portion of users who would probably just use 32-bit Windows anyways. | | |
| ▲ | EvanAnderson 6 hours ago | parent [-] | | Yeah. Like I said, Microsoft had the emulator. NTVDM on x64 is handled just like MIPS or Alpha, by using the SoftPC emulator. It's just a new CPU architecture. They had a proven and tested emulator yet they chose not to build it for the new x64 CPU architecture. It turns out that it wasn't too hard to build for the new architecture either. That's the crux of my confusion. It's not like SoftPC was new and unproven code. It doesn't feel like it would have been a major endeavor to keep supporting it. Obviously, I don't know Microsoft's telemetry told them re: the number of 16-bit application users. I know it impacted a number of my Customers (some of whom are running DOSBox today to keep old fit-for-purpose software working) and I don't support a ton of offices or people. It seems out of character for Microsoft to make their Customers throw away software. |
| |
| ▲ | cesarb 6 hours ago | parent | prev [-] | | > I don't understand why Microsoft chose to kill it. My personal suspicion: it's about handles. Several kinds of objects in the Windows API are identified by global handles (for instance, HWND for a window), and on 16-bit Windows, these handles are limited to 16 bits (though I vaguely recall reading somewhere that they're actually limited to 15 bits). Not having the possibility of a 16-bit Windows process would allow them to increase the global limit on the number of handles (keeping in mind that controls like buttons are actually nested windows, so it's not just one window handle for each top-level window). | | |
|
