4 ms·

This is never, ever, ever going to happen, and the reason is enterprise compliance. Every year, technical auditors will approve security policies that require

by ink_13 5y ago

This is never, ever, ever going to happen, and the reason is enterprise compliance. Every year, technical auditors will approve security policies that require Windows in all kinds of scenarios and definitively rule out use of Linux for any purpose. Also, one of the promises of Windows is that they won't break backwards compatibility under any circumstance regardless of how buggy the behaviour (except number of bits, RIP 16-bit). Unmodified Windows 95 binaries will still run today as long as the appropriate DLLs are there.

cshokie 5y ago
I think 16-bit support is actually a limitation of x86 CPUs. They can only go into 16-but mode if they booted as 32-bit. A 64-bit CPU running in 64-bit mode is incapable of running 16-bit x86 code. It is not a software limitation. This can be demonstrated by installing 32-bit Windows and enabling 16-bit support.
- BBC-vs-neolibs 5y ago
  Yeah, but if they REALLY wanted to, they could have emulated an 80268, it would have been plenty fast even in interpreted emulation. The whole NTVDM machine would fit in L1 cache. http://www.columbia.edu/~em36/ntvdmx64.html http://www.columbia.edu/~em36/ntvdmx64.html https://github.com/leecher1337/ntvdmx64 https://github.com/leecher1337/ntvdmx64 http://www.columbia.edu/~em36/otvdm.html http://www.columbia.edu/~em36/otvdm.html https://en.wikipedia.org/wiki/SoftPC https://en.wikipedia.org/wiki/SoftPC
- leeter 5y ago
  You can support 16bit in long mode via compatibility mode (the bits are still in the Global descriptor table definition https://wiki.osdev.org/GDT https://wiki.osdev.org/GDT as long as the long mode bit isn't set the, Sz bit can be used to indicate 16bit code), just not real mode without using virtualization extensions. The issue was more the way HANDLEs were managed and getting rid of 16bit limitations. (also getting programmers to stop assuming they could safely do things with the upper parts of handles)
- einr 5y ago
  No, it is possible to run 16 bit protected mode applications (i.e. Windows 3.x apps) under 64-bit "long mode". Microsoft explicitely chose to not support that -- with a few exceptions. In true Microsoft fashion, NTVDM on x86-64 is actually hardcoded to be able to run a couple of known InstallShield and Acme installer executables that are 16-bit but used to install 32-bit software. WINE on Linux x86-64 will run 16-bit Windows programs, by the way. However, you cannot do virtual 8086 mode without switching back to 32-bit mode, so you cannot run real mode MS-DOS programs. This would probably have broken a lot of 16-bit Windows software that still relied on real mode components, so it does make sense for this and other reasons that they dropped support for 16-bit software.
  - AshamedCaptain 5y ago
    > However, you cannot do virtual 8086 mode without switching back to 32-bit mode, so you cannot run real mode MS-DOS programs. You can switch to 32-bit mode, then enter vm86, and then switch back to long mode once you are done. There was a kernel module flying around that would do this and make syscalls such as vm86plus work in amd64 Linux. But yes, basically, it's a political more than technical choice to drop support for 16-bit programs on 64-bit Windows; same for >4GiB RAM support in 32-bit Windows.
    - leeter 5y ago
      I saw that module, looked at the code, and wondered if at that point it wouldn't be easier to just run a thin wrapper around the virtual 8086 code while just using standard virtualization extensions. That way it's just another KVM and not yet more kernel code to maintain. Because honestly QEMU already supports that target. This is of course ignoring the many issues caused by faster CPUs or things the target program is expecting but no longer exist or act differently on modern CPUs.
      - AshamedCaptain 5y ago
        Well, there is a rather straightforward explanation: virtualization extensions did not exist, and in fact would not exist for another 5 years at least. Actually, now that I think of it, having KVM capable of running real mode DOS is a rather recent development. Looking at you, AMD, but even early Intel VT-x didn't get it right until 2010ish (Westmere). Anyway, dosemu2 does exactly that (use KVM to run a lightweight kernel that just enters vm86).
Daishiman 5y ago
This is solved by making Windows a subsystem of a Linux-based operating system. Much like Wine, but actually maintained by Microsoft, providing a completely isolated and bug-compatible environment for legacy apps, and a leaner implementation for future win32 APIs that map more closely to Linux primitives.
- Eric_WVGG 5y ago
  Pretty much the same way that early versions of Mac OS X could run “Classic” apps. (It’s kind of remarkable how Apple was able to push their entire user base into a transition, and backward compatibility with that era is neither practical nor really desired. Not the case with Windows!) Anyway, yeah, there are really no technical reasons why this couldn’t be done or even difficult, the reasons why this would never happen are all strategic and enterprisey.
- TheRealDunkirk 5y ago
  Hilarious. Then they'd have to deal with the fact that they deliberately made their API calls to screw with Wine, and things like Crossover, during the late 90's and early 2000's.
  - giomasce 5y ago
    Reference for this?
  - Daishiman 5y ago
    Not really. They had a ton of programs that needed bug-for-bug compatibility. Caring about getting SimCity2000 to run is a much more reasonable explanation than trying to protect themselves from Wine, which in the early 2000s was barely on anyone's radar.
- loeg 5y ago
  Yes. But the idea that creating this from the ground up is easier than maintaining Windows is baffling.
  - 5y ago
gordaco 5y ago
For a LOT of us, at least in certain circles of power users, this is the only thing tying us to Windows. I have a fuckton of software that I know almost for sure that will run under the newest Windows... in Linux, yeah, maybe Wine likes it, or maye I'm out of luck. For some of this software there are reasonable alternatives (emulators, for example. I care about the ROMs, and they are not tied to any operating system). Others, not so much (like my Winamp with 20+ input plugins, some of which can play audio files that I haven't found how to play in Linux, at least using a single player for all the formats). Admittedly, Windows' bullshit is making it harder and harder to justify compliance. I assume that at some time in the future I will finally switch and eschew all the bullshit of aggressively anti-user behaviour (ads, forced updates, changes in UI or in the default applications because of said forced updates, and so on) that Windows seems to love since 8 or so. I know I'm not alone. If Windows gets rid of all this compatibility, there is no fucking way that users are going to accept it. Let Windows be Windows and Linux be Linux.

by ink_13 5y ago

cshokie 5y ago

I think 16-bit support is actually a limitation of x86 CPUs. They can only go into 16-but mode if they booted as 32-bit. A 64-bit CPU running in 64-bit mode is incapable of running 16-bit x86 code. It is not a software limitation. This can be demonstrated by installing 32-bit Windows and enabling 16-bit support.

BBC-vs-neolibs 5y ago
Yeah, but if they REALLY wanted to, they could have emulated an 80268, it would have been plenty fast even in interpreted emulation. The whole NTVDM machine would fit in L1 cache. http://www.columbia.edu/~em36/ntvdmx64.html http://www.columbia.edu/~em36/ntvdmx64.html https://github.com/leecher1337/ntvdmx64 https://github.com/leecher1337/ntvdmx64 http://www.columbia.edu/~em36/otvdm.html http://www.columbia.edu/~em36/otvdm.html https://en.wikipedia.org/wiki/SoftPC https://en.wikipedia.org/wiki/SoftPC
leeter 5y ago
You can support 16bit in long mode via compatibility mode (the bits are still in the Global descriptor table definition https://wiki.osdev.org/GDT https://wiki.osdev.org/GDT as long as the long mode bit isn't set the, Sz bit can be used to indicate 16bit code), just not real mode without using virtualization extensions. The issue was more the way HANDLEs were managed and getting rid of 16bit limitations. (also getting programmers to stop assuming they could safely do things with the upper parts of handles)
einr 5y ago
No, it is possible to run 16 bit protected mode applications (i.e. Windows 3.x apps) under 64-bit "long mode". Microsoft explicitely chose to not support that -- with a few exceptions. In true Microsoft fashion, NTVDM on x86-64 is actually hardcoded to be able to run a couple of known InstallShield and Acme installer executables that are 16-bit but used to install 32-bit software. WINE on Linux x86-64 will run 16-bit Windows programs, by the way. However, you cannot do virtual 8086 mode without switching back to 32-bit mode, so you cannot run real mode MS-DOS programs. This would probably have broken a lot of 16-bit Windows software that still relied on real mode components, so it does make sense for this and other reasons that they dropped support for 16-bit software.
- AshamedCaptain 5y ago
  > However, you cannot do virtual 8086 mode without switching back to 32-bit mode, so you cannot run real mode MS-DOS programs. You can switch to 32-bit mode, then enter vm86, and then switch back to long mode once you are done. There was a kernel module flying around that would do this and make syscalls such as vm86plus work in amd64 Linux. But yes, basically, it's a political more than technical choice to drop support for 16-bit programs on 64-bit Windows; same for >4GiB RAM support in 32-bit Windows.
  - leeter 5y ago
    I saw that module, looked at the code, and wondered if at that point it wouldn't be easier to just run a thin wrapper around the virtual 8086 code while just using standard virtualization extensions. That way it's just another KVM and not yet more kernel code to maintain. Because honestly QEMU already supports that target. This is of course ignoring the many issues caused by faster CPUs or things the target program is expecting but no longer exist or act differently on modern CPUs.
    - AshamedCaptain 5y ago
      Well, there is a rather straightforward explanation: virtualization extensions did not exist, and in fact would not exist for another 5 years at least. Actually, now that I think of it, having KVM capable of running real mode DOS is a rather recent development. Looking at you, AMD, but even early Intel VT-x didn't get it right until 2010ish (Westmere). Anyway, dosemu2 does exactly that (use KVM to run a lightweight kernel that just enters vm86).

Daishiman 5y ago

This is solved by making Windows a subsystem of a Linux-based operating system. Much like Wine, but actually maintained by Microsoft, providing a completely isolated and bug-compatible environment for legacy apps, and a leaner implementation for future win32 APIs that map more closely to Linux primitives.

Eric_WVGG 5y ago
Pretty much the same way that early versions of Mac OS X could run “Classic” apps. (It’s kind of remarkable how Apple was able to push their entire user base into a transition, and backward compatibility with that era is neither practical nor really desired. Not the case with Windows!) Anyway, yeah, there are really no technical reasons why this couldn’t be done or even difficult, the reasons why this would never happen are all strategic and enterprisey.
TheRealDunkirk 5y ago
Hilarious. Then they'd have to deal with the fact that they deliberately made their API calls to screw with Wine, and things like Crossover, during the late 90's and early 2000's.
- giomasce 5y ago
  Reference for this?
- Daishiman 5y ago
  Not really. They had a ton of programs that needed bug-for-bug compatibility. Caring about getting SimCity2000 to run is a much more reasonable explanation than trying to protect themselves from Wine, which in the early 2000s was barely on anyone's radar.
loeg 5y ago
Yes. But the idea that creating this from the ground up is easier than maintaining Windows is baffling.
- 5y ago

gordaco 5y ago

For a LOT of us, at least in certain circles of power users, this is the only thing tying us to Windows. I have a fuckton of software that I know almost for sure that will run under the newest Windows... in Linux, yeah, maybe Wine likes it, or maye I'm out of luck. For some of this software there are reasonable alternatives (emulators, for example. I care about the ROMs, and they are not tied to any operating system). Others, not so much (like my Winamp with 20+ input plugins, some of which can play audio files that I haven't found how to play in Linux, at least using a single player for all the formats). Admittedly, Windows' bullshit is making it harder and harder to justify compliance. I assume that at some time in the future I will finally switch and eschew all the bullshit of aggressively anti-user behaviour (ads, forced updates, changes in UI or in the default applications because of said forced updates, and so on) that Windows seems to love since 8 or so. I know I'm not alone. If Windows gets rid of all this compatibility, there is no fucking way that users are going to accept it. Let Windows be Windows and Linux be Linux.