2 ms·
In the absence of VM extensions, which the earliest AMD64 CPUs did not have, once the CPU is in long mode, the base address of segments other than FS and GS doe
by dfe 2y ago
In the absence of VM extensions, which the earliest AMD64 CPUs did not have, once the CPU is in long mode, the base address of segments other than FS and GS doesn't work, it must be 0.
That's not such a problem for 32-bit segments whose base is normally 0 anyway (flat 32), but most 16-bit protected mode Windows code expects the linear address of its code and data segments to be something other than 0, and even might expect to be able to use multiple data segments with different base addresses.
So, sure, you can run 16-bit protected mode code with a base address of 0, but that's not very useful.
Also there's no virtual 8086 mode when in long mode to support real mode code.
With VM extensions it's possible to virtualize the CPU in regular (not long) mode, at which point the virtualized CPU will indeed support non-zero segment base addresses and virtual 8086 mode.
In theory this can be done with an extremely light virtual machine layer, but the entry/exit to/from the 16-bit code, or even for that matter any code needing to use 16-bit data segments is going to require more than it would if the CPU weren't in long mode. And this is assuming you have virtual mode extensions. If you don't then you need a CPU emulator.
My guess is that Microsoft felt it just wasn't worth writing all of this extra code needed to do this. There's a big difference between technically possible and makes even remote economic sense to do it.
- rep_lodsb 2y agoWhen the manual says that the segment bases are ignored in long mode, it is only referring to 64-bit code. As far as I remember, the terminology goes like this: 64-bit OS, running 64-bit user code -> "long mode" 64-bit OS, 16/32-bit user code -> "compatibility mode" 16/32-bit OS -> "legacy mode" Also I've personally tested that it works, without any virtualization required (see sibling comment). Wine also does it in order to run 16-bit Windows programs, or at least it used to at one time - IIRC, there was some discussion on the Linux kernel mailing list about it.