6 ms·

Microsoft's willingness to maintain backward compatibility has been key to their success over the years. With the importance of Adobe's products on their platfo

by pc2g4d 9y ago

Microsoft's willingness to maintain backward compatibility has been key to their success over the years. With the importance of Adobe's products on their platform, it makes sense that they would go out of their way to ensure their continued functioning.

guitarbill 9y ago
For enterprise customers, sure. For many consumers, now that they use more modern OS and browsers daily (iOS/Android), it's painfully obvious how terrible this strategy has been - even if they can only articulate that on a subconscious level. Honestly I'd love to see what Microsoft could do if they ditched backwards compatibility completely, except in the server OSes. While hardly revolutionary, Surface Pad Pro is a good indicator/example that there's at least potential there.
- 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.
- SCHiM 9y ago
  Those 'more modern' operating systems have roots and parts in their codebase that are just as old, if not older, than Windows. All platforms are continously adding new pieces and sometimes rewriting old. But I know for a fact that there are parts under Android's hood that a computer scientist from the 1970 would've found familiar. There is no reason to ditch the backwards compatibility in my opinion. All components can be kept functional alongside each other (like how UWA can function next to Win32) with some extra effort. I love the fact that there's a host of applications that target Win32 that I've been using since windows 2000 and still work on windows 10.
  - mirsadm 9y ago
    It's amazing how much technical debt Android has accrued given how much newer it is than Windows.
    - wtallis 9y ago
      I'm not too surprised. During Android's early years it was chasing a moving target as the standard mobile computing paradigm shifted from Blackberry/Treo type devices to iPhone clones. Then tablets got added to the mix and mobile SoCs outpaced Moore's Law for a while. The higher-level elements of the platform were inevitably going to be subjected to a degree of churn that Windows hasn't needed to deal with in about 20 years. (Of course, Windows has opted in to some churn with the revolving door of UI frameworks, but that's entirely self-inflicted.)
      - digi_owl 9y ago
        Not helped by Google thinking they could apply Chrome/web methodology to device firmware. Sorry, but there is a reason why MS do year long public betas etc. Apple can get away with being different because they control the whole stack, from the chips to the online services. Right now Google is where Palm was with PalmOS.
- digi_owl 9y ago
  MS would crash and burn virtually over night. With no backwards compatibility there is little to no reason for customers (business or consumer) to stick with the brand.
agumonkey 9y ago
Yeah, it doesn't makes me less sad but I can't blame MS to try to keep their position and backward compatibility. Also there were many other partners that didn't want to change their code, so MS had to keep many deprecated or even non public API in early windows 3/95 releases
Pxtl 9y ago
God damn. If I were in that situation as a dev, I'd be tempted to break the latest releases of Adobe products on the day of launch, while still keeping the old ones supported. If I have to keep supporting your old broken garbage, you can't release new garbage.
- wand3r 9y ago
  Thats the nature of the beast; everyone wants to release new garbage; which itself was clean until it had to put just a few bits of old rubbish in until it became trash. Can't find it now but someone posted a Linux mailing list where Torvalds ripped a Dev for breaking something that impacted a user. The dev responded something like the parent: It's a 3rd party app/not Linux responsibility. The OS has to be stable and the users experience is Paramount. Even a technical crowd (based on the thread) is 50/50 split on this being a Microsoft issue. A non-technical users response: "this software is shit, these idiots broke X in [this version] Microsoft sucks"
  - z1mm32m4n 9y ago
    I believe the thread you're looking for is this one, about never breaking user space: https://lkml.org/lkml/2012/12/23/75 https://lkml.org/lkml/2012/12/23/75
    - wand3r 9y ago
      exactly that. thank you.
      - cpeterso 9y ago
        And Linus taking glibc devs to task for them breaking Adobe Flash Player, due to a bug in Flash's use of memcpy(): https://lwn.net/Articles/414467/ https://lwn.net/Articles/414467/
        danielbarla 9y ago
        That was an interesting read; he wasn't even very confrontational there. The point was also solid - they had an internal performance optimization change which was unproven, yet broke things in the real world. That, and the lack of guidelines or tests for what kind of usage results in the behaviour, it's a de-facto "feature" of the interface that they should not break.
ced 9y ago
Raymond Chen from Microsoft on maintaining backward compatibility from Windows 95 to Windows XP: Look at the scenario from the customer's standpoint. You bought programs X, Y and Z. You then upgraded to Windows XP. Your computer now crashes randomly, and program Z doesn't work at all. You're going to tell your friends, "Don't upgrade to Windows XP. It crashes randomly, and it's not compatible with program Z." Are you going to debug your system to determine that program X is causing the crashes, and that program Z doesn't work because it is using undocumented window messages? Of course not. You're going to return the Windows XP box for a refund. (You bought programs X, Y, and Z some months ago. The 30-day return policy no longer applies to them. The only thing you can return is Windows XP.) ... This is just the tip of the iceberg with respect to application compatibility. I could probably write for months solely about bad things apps do and what we had to do to get them to work again (often in spite of themselves). Which is why I get particularly furious when people accuse Microsoft of maliciously breaking applications during OS upgrades. If any application failed to run on Windows 95, I took it as a personal failure. I spent many sleepless nights fixing bugs in third-party programs just so they could keep running on Windows 95. (Games were the worst. Often the game vendor didn't even care that their program didn't run on Windows 95!)

by pc2g4d 9y ago

guitarbill 9y ago

For enterprise customers, sure. For many consumers, now that they use more modern OS and browsers daily (iOS/Android), it's painfully obvious how terrible this strategy has been - even if they can only articulate that on a subconscious level. Honestly I'd love to see what Microsoft could do if they ditched backwards compatibility completely, except in the server OSes. While hardly revolutionary, Surface Pad Pro is a good indicator/example that there's at least potential there.

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.
SCHiM 9y ago
Those 'more modern' operating systems have roots and parts in their codebase that are just as old, if not older, than Windows. All platforms are continously adding new pieces and sometimes rewriting old. But I know for a fact that there are parts under Android's hood that a computer scientist from the 1970 would've found familiar. There is no reason to ditch the backwards compatibility in my opinion. All components can be kept functional alongside each other (like how UWA can function next to Win32) with some extra effort. I love the fact that there's a host of applications that target Win32 that I've been using since windows 2000 and still work on windows 10.
- mirsadm 9y ago
  It's amazing how much technical debt Android has accrued given how much newer it is than Windows.
  - wtallis 9y ago
    I'm not too surprised. During Android's early years it was chasing a moving target as the standard mobile computing paradigm shifted from Blackberry/Treo type devices to iPhone clones. Then tablets got added to the mix and mobile SoCs outpaced Moore's Law for a while. The higher-level elements of the platform were inevitably going to be subjected to a degree of churn that Windows hasn't needed to deal with in about 20 years. (Of course, Windows has opted in to some churn with the revolving door of UI frameworks, but that's entirely self-inflicted.)
    - digi_owl 9y ago
      Not helped by Google thinking they could apply Chrome/web methodology to device firmware. Sorry, but there is a reason why MS do year long public betas etc. Apple can get away with being different because they control the whole stack, from the chips to the online services. Right now Google is where Palm was with PalmOS.
digi_owl 9y ago
MS would crash and burn virtually over night. With no backwards compatibility there is little to no reason for customers (business or consumer) to stick with the brand.

agumonkey 9y ago

Yeah, it doesn't makes me less sad but I can't blame MS to try to keep their position and backward compatibility. Also there were many other partners that didn't want to change their code, so MS had to keep many deprecated or even non public API in early windows 3/95 releases

Pxtl 9y ago

God damn. If I were in that situation as a dev, I'd be tempted to break the latest releases of Adobe products on the day of launch, while still keeping the old ones supported. If I have to keep supporting your old broken garbage, you can't release new garbage.

wand3r 9y ago
Thats the nature of the beast; everyone wants to release new garbage; which itself was clean until it had to put just a few bits of old rubbish in until it became trash. Can't find it now but someone posted a Linux mailing list where Torvalds ripped a Dev for breaking something that impacted a user. The dev responded something like the parent: It's a 3rd party app/not Linux responsibility. The OS has to be stable and the users experience is Paramount. Even a technical crowd (based on the thread) is 50/50 split on this being a Microsoft issue. A non-technical users response: "this software is shit, these idiots broke X in [this version] Microsoft sucks"
- z1mm32m4n 9y ago
  I believe the thread you're looking for is this one, about never breaking user space: https://lkml.org/lkml/2012/12/23/75 https://lkml.org/lkml/2012/12/23/75
  - wand3r 9y ago
    exactly that. thank you.
    - cpeterso 9y ago
      And Linus taking glibc devs to task for them breaking Adobe Flash Player, due to a bug in Flash's use of memcpy(): https://lwn.net/Articles/414467/ https://lwn.net/Articles/414467/
      - danielbarla 9y ago
        That was an interesting read; he wasn't even very confrontational there. The point was also solid - they had an internal performance optimization change which was unproven, yet broke things in the real world. That, and the lack of guidelines or tests for what kind of usage results in the behaviour, it's a de-facto "feature" of the interface that they should not break.

ced 9y ago

Raymond Chen from Microsoft on maintaining backward compatibility from Windows 95 to Windows XP: Look at the scenario from the customer's standpoint. You bought programs X, Y and Z. You then upgraded to Windows XP. Your computer now crashes randomly, and program Z doesn't work at all. You're going to tell your friends, "Don't upgrade to Windows XP. It crashes randomly, and it's not compatible with program Z." Are you going to debug your system to determine that program X is causing the crashes, and that program Z doesn't work because it is using undocumented window messages? Of course not. You're going to return the Windows XP box for a refund. (You bought programs X, Y, and Z some months ago. The 30-day return policy no longer applies to them. The only thing you can return is Windows XP.) ... This is just the tip of the iceberg with respect to application compatibility. I could probably write for months solely about bad things apps do and what we had to do to get them to work again (often in spite of themselves). Which is why I get particularly furious when people accuse Microsoft of maliciously breaking applications during OS upgrades. If any application failed to run on Windows 95, I took it as a personal failure. I spent many sleepless nights fixing bugs in third-party programs just so they could keep running on Windows 95. (Games were the worst. Often the game vendor didn't even care that their program didn't run on Windows 95!)