6 ms·

They could create a new version of Windows to mark this retry. Maybe they could call it Windows RT.

by m1sta_ 9y ago

sorenjan 9y ago
I bet it would be a huge success.
derefr 9y ago
Rather than dropping compatibility entirely, I've always wondered why no modern OS has gone the route of creating a "compatibility layer" that's actually a (very-tightly-sandboxed) VM containing a [stripped-down] older copy of the OS. This would be perfect to re-add Win16 support to W10, for example. Try to double-click a 16-bit app? It opens with its handler, "Windows 3.1 Hyper-V Association Background Launcher". As long as no W3.1 apps are running, it unloads, and the rest of the OS can be completely free of 3.1-era cruft. You could deprecate features from your latest OS at a breakneck pace if you really took this strategy to heart. WinRT really could have been just Metro/UWP + a "Desktop" that's actually a Windows 7 VM with a high-level paravirtualized shared filesystem. (And it's not like Microsoft didn't do this themselves before; this is essentially how DOS applications ran under Windows 3.1, in a [hypervised!] DOS VM.) --- EDIT: let me clarify the specific point I was getting at. If you ship $OldOS as a VM within $NewOS, very tightly sandboxed, then you never have to update $OldOS again, nor do you have to keep the code from $OldOS around in $NewOS. The $OldOS VM is now a "static artifact"—something that will never change, but will continue to run old software perfectly. So, if $OldOS gains more security flaws, you don't update $OldOS; you update the virtualization software to make the sandbox stricter. And when you find that your $NewOS is now, itself, old—well, you just do the whole thing again, writing an emulator for $NewOS within $EvenNewerOS, and then your $OldOS programs run by launching a VM-in-a-VM. If you like, you can port the $OldOS emulator to run on $EvenNewerOS—but you could also just consider it legacy software of exactly the type your $NewOS emulator is built to run. The point of this is to decrease maintenance burden, by freezing the previous OS, so that you never need to think of it again. This wasn't what was done with "XP Mode"; Windows XP continued to receive updates as a component of Windows 7. The point here would be to EOL the older OS, and then virtualize it.
- markrages 9y ago
  > I've always wondered why no modern OS has gone the route of creating a "compatibility layer" You could even hold down the Commodore key while booting to get a mode compatible with the previous system.
  - digi_owl 9y ago
    Yep. Many of their products stood or fell relevant to their C64 compatibility. Once a install base has been built up, compatibility (or lack there of) can make or break you.
- roblabla 9y ago
  OSX did this when they went from 68k to PPC [0], from PPC to x86[1], and also with Classic to support macos 9[2]. They maintained compatibility by emulated the previous architecture on the new one. [0] : https://en.wikipedia.org/wiki/Mac_68k_emulator https://en.wikipedia.org/wiki/Mac_68k_emulator [1] : https://en.wikipedia.org/wiki/Rosetta_(software) https://en.wikipedia.org/wiki/Rosetta_(software) [2] : https://en.wikipedia.org/wiki/List_of_macOS_components#Classic https://en.wikipedia.org/wiki/List_of_macOS_components#Class...
  - douche 9y ago
    Mac Classic was great. For some reason the G4s they issued us in high school didn't have the Classic compatibility mode locked down as tight as everything else useful (to a teenager), so I could play older Mac video games in study hall...
  - derefr 9y ago
    Ah, this is virtualization, though: the OS was trying to integrate the software from the old OS, letting it interact with all the older APIs of the modern OS as if it was running directly on it. Less like a VM, more like Wine. My point was less about compatibility, and more about security. If you took this approach, old software would still expose the new OS it was virtualized atop of, to its old security flaws. So you'd still have to move away from old software, eventually, for security reasons. But with proper VM isolation (and checkpointing, and a few other things), you could still have programs like IE6 around today, serving in its last purpose as the '90s-era Intranet web-services equivalent to the '80s 3270 mainframe terminal clients. Most any modern VM software can offer this level of isolation, but most have "host integrations" that turn them back into security holes. To be able to ship a static, EOLed copy of XP that could run IE6 indefinitely, without that causing problems, your compatibility layer would need to be a lot less like "Windows XP Mode" or Rosetta, and a lot more like DOSBox or qemu. There is one case where this already happens: many pieces of IBM z/OS software have been wrapped in layers of hard-isolated emulators for decades now, such that programs from the 70s are able to continue running without recompilation, atop a stack of VMs, where many of the intermediary pieces of VM software have themselves long been EOLed.

They could create a new version of Windows to mark this retry. Maybe they could call it Windows RT.

by m1sta_ 9y ago

They could create a new version of Windows to mark this retry. Maybe they could call it Windows RT.

sorenjan 9y ago

I bet it would be a huge success.

derefr 9y ago

Rather than dropping compatibility entirely, I've always wondered why no modern OS has gone the route of creating a "compatibility layer" that's actually a (very-tightly-sandboxed) VM containing a [stripped-down] older copy of the OS. This would be perfect to re-add Win16 support to W10, for example. Try to double-click a 16-bit app? It opens with its handler, "Windows 3.1 Hyper-V Association Background Launcher". As long as no W3.1 apps are running, it unloads, and the rest of the OS can be completely free of 3.1-era cruft. You could deprecate features from your latest OS at a breakneck pace if you really took this strategy to heart. WinRT really could have been just Metro/UWP + a "Desktop" that's actually a Windows 7 VM with a high-level paravirtualized shared filesystem. (And it's not like Microsoft didn't do this themselves before; this is essentially how DOS applications ran under Windows 3.1, in a [hypervised!] DOS VM.) --- EDIT: let me clarify the specific point I was getting at. If you ship $OldOS as a VM within $NewOS, very tightly sandboxed, then you never have to update $OldOS again, nor do you have to keep the code from $OldOS around in $NewOS. The $OldOS VM is now a "static artifact"—something that will never change, but will continue to run old software perfectly. So, if $OldOS gains more security flaws, you don't update $OldOS; you update the virtualization software to make the sandbox stricter. And when you find that your $NewOS is now, itself, old—well, you just do the whole thing again, writing an emulator for $NewOS within $EvenNewerOS, and then your $OldOS programs run by launching a VM-in-a-VM. If you like, you can port the $OldOS emulator to run on $EvenNewerOS—but you could also just consider it legacy software of exactly the type your $NewOS emulator is built to run. The point of this is to decrease maintenance burden, by freezing the previous OS, so that you never need to think of it again. This wasn't what was done with "XP Mode"; Windows XP continued to receive updates as a component of Windows 7. The point here would be to EOL the older OS, and then virtualize it.

markrages 9y ago
> I've always wondered why no modern OS has gone the route of creating a "compatibility layer" You could even hold down the Commodore key while booting to get a mode compatible with the previous system.
- digi_owl 9y ago
  Yep. Many of their products stood or fell relevant to their C64 compatibility. Once a install base has been built up, compatibility (or lack there of) can make or break you.
roblabla 9y ago
OSX did this when they went from 68k to PPC [0], from PPC to x86[1], and also with Classic to support macos 9[2]. They maintained compatibility by emulated the previous architecture on the new one. [0] : https://en.wikipedia.org/wiki/Mac_68k_emulator https://en.wikipedia.org/wiki/Mac_68k_emulator [1] : https://en.wikipedia.org/wiki/Rosetta_(software) https://en.wikipedia.org/wiki/Rosetta_(software) [2] : https://en.wikipedia.org/wiki/List_of_macOS_components#Classic https://en.wikipedia.org/wiki/List_of_macOS_components#Class...
- douche 9y ago
  Mac Classic was great. For some reason the G4s they issued us in high school didn't have the Classic compatibility mode locked down as tight as everything else useful (to a teenager), so I could play older Mac video games in study hall...
- derefr 9y ago
  Ah, this is virtualization, though: the OS was trying to integrate the software from the old OS, letting it interact with all the older APIs of the modern OS as if it was running directly on it. Less like a VM, more like Wine. My point was less about compatibility, and more about security. If you took this approach, old software would still expose the new OS it was virtualized atop of, to its old security flaws. So you'd still have to move away from old software, eventually, for security reasons. But with proper VM isolation (and checkpointing, and a few other things), you could still have programs like IE6 around today, serving in its last purpose as the '90s-era Intranet web-services equivalent to the '80s 3270 mainframe terminal clients. Most any modern VM software can offer this level of isolation, but most have "host integrations" that turn them back into security holes. To be able to ship a static, EOLed copy of XP that could run IE6 indefinitely, without that causing problems, your compatibility layer would need to be a lot less like "Windows XP Mode" or Rosetta, and a lot more like DOSBox or qemu. There is one case where this already happens: many pieces of IBM z/OS software have been wrapped in layers of hard-isolated emulators for decades now, such that programs from the 70s are able to continue running without recompilation, atop a stack of VMs, where many of the intermediary pieces of VM software have themselves long been EOLed.