10 ms·

This makes no sense to me. Backward compatibility is a huge competitive advantage for Intel, and IMHO, it's royally messed up that vm86 mode doesn't work in 64

This makes no sense to me. Backward compatibility is a huge competitive advantage for Intel, and IMHO, it's royally messed up that vm86 mode doesn't work in 64-bit mode. One DOS application I use was hurt by this: "old DOS OrCAD". It works well in Windows-XP on a 32-bit machine, but does not work at all in 64-bit Windows. (It's actually a 32-bit DPMI program and has drivers to use Windows GDI so you don't have to mess around with drivers). More evidence: IBM 360 mainframe software still works in Z/OS. It might be worth it for non-generic computing devices like cell phones, but Intel missed the boat there already.

manuelabeledo 3y ago
Legacy systems and architectures can’t be around forever. How many people in the PC market still use 16-bit applications?
- jhallenworld 3y ago
  >Legacy systems and architectures can’t be around forever. Why not? The bits don't decay.. Yes, this leads to an architectural mess, but I'm talking about a competitive business advantage.
  - manuelabeledo 3y ago
    > Why not? > Yes, this leads to an architectural mess Right there. There's no notable advantage in supporting a very small minority of the applications out there, at the cost of keeping units useless for the 99%.
    - bear8642 3y ago
      > There's no notable advantage... Potentially one if a large customer's paying you for it. At work, I'm helping a client upgrade from a decade old version (v12) of our product and having to copy over the switches to keep the even older (v11 and previous) behaviours
      - manuelabeledo 3y ago
        Ten years ago was 14 years after the introduction of the x86 64-bit instruction set, and 28 years after x86-32. I’m quite sure we will be OK without support for 16-bit instructions.
- MrBuddyCasino 3y ago
  Question is, what is the cost of keeping the old cruft around?
  - userbinator 3y ago
    Essentially none. It's all make-work (or, since they're intent on breaking things more than fixing them, break-work.)
    - manuelabeledo 3y ago
      I wouldn’t say “none”. Real estate in CPUs is extremely expensive.
      - akira2501 3y ago
        My immediate sense is that the entire vector system easily dwarfs the 16bit system.. as I'm guessing most of the modern 16bit mode is entirely in microcode.
      - userbinator 3y ago
        ...and taken up mostly by cache and vector execution units. An 8086 has 29000 transistors. A modern CPU has several billion. The amount needed to implement the 16-bit subset of the ISA is an absolutely tiny fraction of the total area.
        FullyFunctional 3y ago
        Ah, I see you don't work in the field. A few of the cost of legacy: * exponential growth in verification space (each feature combines with all other features), * design complexity (effort that could be spent better), * area/power/cycle time overhead (all options require more ports to muxes, more wires to run, etc.) * and most importantly, opportunity costs: some optimization tricks can't be pursued because the assumptions would break for legacy code The legacy tax is real
        3y ago
TazeTSchnitzel 3y ago
16-bit x86 code is ancient enough that a software emulation solution can be fast, efficient, and perfectly compatible, so there's no need to keep support for it in hardware at this point. Microsoft could have used emulation to keep old 16-bit x86 apps working with Windows for AMD64 (in fact they had done this before for non-x86 architectures) but I guess they weren't interested. WINE and DOSBox did it though.
dathinab 3y ago
16 bit code is most times braking due to Windows being itself incompatible so you need to emulate it anyway. And if you have very old but important windows legacy software you either want to also run old hardware and windows OS anyway or run enumeration anyway. On linux this is somewhat already the case, most distroes are by now for OS 64bit only with at most 32bit application support but not always enabled by default.
PrimeMcFly 3y ago
Out of curiosity why are you still using a 16bit DOS CAD application?
glhaynes 3y ago
and has drivers to use Windows GDI so you don't have to mess around with drivers This was a thing? So, would it still run in the "MS-DOS Command Prompt" in Windows but talk directly to Windows for its screen drawing?
- jhallenworld 3y ago
  Yes, here is how to do it: https://airborn.com.au/layout/vddtest.html https://airborn.com.au/layout/vddtest.html A 16-bit DOS application using DirectX.. In the case of OrCAD this was very easy because it already had plug-in architecture for graphics. It had this because even the mouse was not standardized in the early days.
  - glhaynes 3y ago
    How interesting! Wasn’t aware such programs existed. Thanks.
userbinator 3y ago
and IMHO, it's royally messed up that vm86 mode doesn't work in 64-bit mode. You can blame AMD for that and the other dubious decisions in the design of amd64 in general.
AshamedCaptain 3y ago
> vm86 mode doesn't work in 64-bit mode. vm86 doesn't work in 64-bit mode, but you can simply temporarily switch down to 32-bit mode, and them vm86 works just fine. Early amd64 Linux would do this, and there was even a kernel module to do it after they dropped support for it. Microsoft had other reasons to drop 16-bit support in Windows 64.
- userbinator 3y ago
  Microsoft had other reasons to drop 16-bit support in Windows 64 Namely, planned obsolescence. They realised that forcing people to consume could squeeze a little more $$$ from them.

manuelabeledo 3y ago

Legacy systems and architectures can’t be around forever. How many people in the PC market still use 16-bit applications?

jhallenworld 3y ago
>Legacy systems and architectures can’t be around forever. Why not? The bits don't decay.. Yes, this leads to an architectural mess, but I'm talking about a competitive business advantage.
- manuelabeledo 3y ago
  > Why not? > Yes, this leads to an architectural mess Right there. There's no notable advantage in supporting a very small minority of the applications out there, at the cost of keeping units useless for the 99%.
  - bear8642 3y ago
    > There's no notable advantage... Potentially one if a large customer's paying you for it. At work, I'm helping a client upgrade from a decade old version (v12) of our product and having to copy over the switches to keep the even older (v11 and previous) behaviours
    - manuelabeledo 3y ago
      Ten years ago was 14 years after the introduction of the x86 64-bit instruction set, and 28 years after x86-32. I’m quite sure we will be OK without support for 16-bit instructions.
MrBuddyCasino 3y ago
Question is, what is the cost of keeping the old cruft around?
- userbinator 3y ago
  Essentially none. It's all make-work (or, since they're intent on breaking things more than fixing them, break-work.)
  - manuelabeledo 3y ago
    I wouldn’t say “none”. Real estate in CPUs is extremely expensive.
    - akira2501 3y ago
      My immediate sense is that the entire vector system easily dwarfs the 16bit system.. as I'm guessing most of the modern 16bit mode is entirely in microcode.
    - userbinator 3y ago
      ...and taken up mostly by cache and vector execution units. An 8086 has 29000 transistors. A modern CPU has several billion. The amount needed to implement the 16-bit subset of the ISA is an absolutely tiny fraction of the total area.
      - FullyFunctional 3y ago
        Ah, I see you don't work in the field. A few of the cost of legacy: * exponential growth in verification space (each feature combines with all other features), * design complexity (effort that could be spent better), * area/power/cycle time overhead (all options require more ports to muxes, more wires to run, etc.) * and most importantly, opportunity costs: some optimization tricks can't be pursued because the assumptions would break for legacy code The legacy tax is real
        3y ago

TazeTSchnitzel 3y ago

16-bit x86 code is ancient enough that a software emulation solution can be fast, efficient, and perfectly compatible, so there's no need to keep support for it in hardware at this point. Microsoft could have used emulation to keep old 16-bit x86 apps working with Windows for AMD64 (in fact they had done this before for non-x86 architectures) but I guess they weren't interested. WINE and DOSBox did it though.

dathinab 3y ago

16 bit code is most times braking due to Windows being itself incompatible so you need to emulate it anyway. And if you have very old but important windows legacy software you either want to also run old hardware and windows OS anyway or run enumeration anyway. On linux this is somewhat already the case, most distroes are by now for OS 64bit only with at most 32bit application support but not always enabled by default.

PrimeMcFly 3y ago

Out of curiosity why are you still using a 16bit DOS CAD application?

glhaynes 3y ago

and has drivers to use Windows GDI so you don't have to mess around with drivers This was a thing? So, would it still run in the "MS-DOS Command Prompt" in Windows but talk directly to Windows for its screen drawing?

jhallenworld 3y ago
Yes, here is how to do it: https://airborn.com.au/layout/vddtest.html https://airborn.com.au/layout/vddtest.html A 16-bit DOS application using DirectX.. In the case of OrCAD this was very easy because it already had plug-in architecture for graphics. It had this because even the mouse was not standardized in the early days.
- glhaynes 3y ago
  How interesting! Wasn’t aware such programs existed. Thanks.

userbinator 3y ago

and IMHO, it's royally messed up that vm86 mode doesn't work in 64-bit mode. You can blame AMD for that and the other dubious decisions in the design of amd64 in general.

AshamedCaptain 3y ago

> vm86 mode doesn't work in 64-bit mode. vm86 doesn't work in 64-bit mode, but you can simply temporarily switch down to 32-bit mode, and them vm86 works just fine. Early amd64 Linux would do this, and there was even a kernel module to do it after they dropped support for it. Microsoft had other reasons to drop 16-bit support in Windows 64.

userbinator 3y ago
Microsoft had other reasons to drop 16-bit support in Windows 64 Namely, planned obsolescence. They realised that forcing people to consume could squeeze a little more $$$ from them.