10 ms·

The backwards compatibility though is one of the major features of windows as an OS. That fact that a company can still load some software made 20 years ago dev

The backwards compatibility though is one of the major features of windows as an OS. That fact that a company can still load some software made 20 years ago developed by a company that is no longer in business is pretty cool (and I've worked at such places using ancient software on some windows box, sometimes there's no time or money for alternatives)

sedatk 2y ago
That and it's 30+ years (NT was released in 1993). Backwards compatibility is certainly one of the greatest business value Microsoft provides to its customers.
- ozim 2y ago
  People tend to forget that it already is 2024.
  - xattt 2y ago
    Short of driver troubles at the jump from Win 9x to 2k/XP, and the shedding of Win16 compatibility layers at the time of release of Win XP x64, backwards compatibility had always been baked into Windows. I don’t know if there was any loss of compatibility during the MS-DOS days either. It’s just expected at this point.
    - anthk 2y ago
      On DOS, if you borrow ReactOS' NTVDM under XP/2003 and Maybe Vista/7 under 32 bit (IDK about 64 bit binaries), you can run DOS games in a much better way than Windows' counterpart.
      - rasz 2y ago
        Afaik due to POPF not trapping Reactos implemented NTVDM as a software emulator. https://web.archive.org/web/20170723164052/http://community.reactos.org/index.php/news/years-progress-ntvdm-part-1 https://web.archive.org/web/20170723164052/http://community.... https://web.archive.org/web/20151216085857/http://community.reactos.org/index.php/news/years-progress-ntvdm-part-2 https://web.archive.org/web/20151216085857/http://community.... At this point you might as well use DOSBOX. Intel Protected Mode POPF fail: https://docs.oracle.com/en/virtualization/virtualbox/6.0/admin/swvirt-details.html https://docs.oracle.com/en/virtualization/virtualbox/6.0/adm... https://devblogs.microsoft.com/oldnewthing/20160411-00/?p=93281 https://devblogs.microsoft.com/oldnewthing/20160411-00/?p=93...
        anthk 2y ago
        I think they recently improved NTVDM a lot.
  - ExoticPearTree 2y ago
    Not long ago, it was posted here a link to a job advert for the german railway looking for a Win 3.11 specialist. As I see it, the problem is the laziness/cheapness of companies when it comes to upgrades and vendor's reluctance to get rid of dead stuff for fear of losing business. APIs could be deprecated/updated at set intervals, like Current -2/-3 versions back and be done with it.
    - wongarsu 2y ago
      Lots of hardware is used for multiple decades, but has software that is built once and doesn't get continuous updates. That isn't necessarily laziness, it's a mindset thing. Traditional hardware companies are used to a mindset where they design something once, make and sell it for a decade, and the customer will replace it after 20 years of use. They have customer support for those 30 years, but software is treated as part of that design process. That makes a modern OS that can support the APIs of 30 year old software (so 40 year old APIs) valuable to businesses. If you only want to support 3 versions that's valid, but you will lose those customers to a competitor who has better backwards compatibility
- MarkSweep 2y ago
  If you include the ability of 32-bit versions of Windows to run 16-but Windows and DOS applications with NTVDM, it is more like 40+ years. https://en.wikipedia.org/wiki/Virtual_DOS_machine https://en.wikipedia.org/wiki/Virtual_DOS_machine (Math on the 40 years: windows 1.0 was released in 1985, the last consumer version of Windows 10 (which is the last Windows NT version to support 32-bit install and thus NTVDM) goes out of support in 2025. DOS was first released in 1981, more than 40 years ago. I don’t know when it was released, but I’ve used a pretty old 16-bit DOS app on Windows 10: a C compiler for the Intel 80186)
  - sedatk 2y ago
    True. I just assumed that 16-bit support got dropped since Windows 11 was 64-bit only.
    - EvanAnderson 2y ago
      Microsoft decided not to type "make" for NTVDM on 64-bit versions of Windows (I would argue arbitrarily). It has been unofficially built for 64-bit versions of Windows as a proof-of-concept: https://github.com/leecher1337/ntvdmx64 https://github.com/leecher1337/ntvdmx64
      - badgersnake 2y ago
        That’s okay, and if people want to test their specific use case on that and use it then great. It’s a pretty different amount of effort to Microsoft having to do a full 16 bit regression suite and make everything work and then support it for the fewer and fewer customers using it. And you can run a 32 bit windows in a VM pretty easily if you really want to.
        Timwi 2y ago
        Or you can run 16-bit Windows 3.1 in DOSBox.
        2y ago
- dartharva 2y ago
  But only to a degree, right? Only the last two decades of software is what the OS ideally needs to support, beyond that you can just use emulators.
  - NegativeLatency 2y ago
    Maybe, but your app could also be an interface to some super expensive scientific/industrial equipment that does weird IO or something.
  - badsectoracula 2y ago
    Software is written against APIs, not years, so the problem with this sort of thinking is that software written -say- 10 years ago might still be using APIs from more than 20 years ago, so if you decide to break/remove/whatever the more-than-20-year-ago APIs you not only break the more-than-20-year-ago software but also the 10 year old software that used those APIs - as well as any other software, older or newer, that did the same. (also i'm using "API" for convenience here, replace it with anything that can affect backwards compatibility) EDIT: simple example in practice: WinExec was deprecated when Windows switched from 16bit to 32bit several decades ago, yet programs are still using it to this day.
  - da_chicken 2y ago
    Pretty much the only 16-bit software that people commonly encounter is an old setup program. For a very long time those were all 16-bit because they didn't need the address space and they were typically smaller when compiled. This means that a lot of 32-bit software from the late 90s that would otherwise work fine is locked inside a 16-bit InstallShield box.
    - aleph_minus_one 2y ago
      > Pretty much the only 16-bit software that people commonly encounter is an old setup program. I know quite a lot of people who are still quite fond of some old 16-bit Windows games which - for this "bitness reason" - don't work on modern 64 bit versions of Windows anymore. People who grew up with these Windows versions are quite nostalgic about applications/games from "their" time, and still use/play them (similar to how C64/Amiga/Atari fans are about "their" system).
runjake 2y ago
> The backwards compatibility though is one of the major features of windows as an OS. It is. That's even been stated by MSFT leadership time and time again. But at what point does that become a liability? I'm arguing that point was about 15-20 years ago.
- dgfitz 2y ago
  New frameworks have vulnerabilities. Old OS flavors have vulnerabilities. OpenSSh keeps making the news for vulnerabilities. I’d argue that software is never finished, only abandoned, and I absolutely did not generate that quote. Stop. Just stop.
  - anthk 2y ago
    >OpenSSH Yes, just stop... with the bullshit. OpenBSD didn't make vulnerabilities. Foreign Linux distros (OpenSSH comes from OpenBSD, and they release a portable tgz too) adding non-core features and libraries did.
- efitz 2y ago
  There is another very active article on HN today about the launch of the new Apple iPhone 16 models. The top discussion thread on that post is about “my old iPhone $version is good enough, why would I upgrade”. It’s funny, if you ask tech people, a lot fall into the “I have to have the latest and greatest” but also a lot fall into the “I’ll upgrade when they pry the rusting hardware from my cold dead hands”. For Microsoft, the driver for backwards compatibility is economic: Microsoft wants people to buy new Windows, but in order to do that, they have to (1) convince customers that all their existing stuff is going to continue to work, and (2) convince developers that they don’t have to rewrite (or even recompile) all their stuff whenever there’s a new version of Windows. Objectively, it seems like Microsoft made the right decision, based on revenue over the decades. Full disclosure: I worked for Microsoft for 17 years, mostly in and around Windows, but left over a decade ago.
  - ruthmarx 2y ago
    > It’s funny, if you ask tech people, a lot fall into the “I have to have the latest and greatest” This is almost never a technical decision, but a 'showing off' decision IMO.
johannes1234321 2y ago
It is a great achievement. But the question is: Is it really relevant? Couldn't they move the compatibility for larger parts to a VM or other independent Subsystem? Of course even that isn't trivial, as one wants to share filesystem access (while I can imagine some overlay limiting access), might need COM and access to devices ... but I would assume they could push that a lot more actively. If they decided which GUI framework to focus on.
- 486sx33 2y ago
  I think that VM software like Parallels has shown us that we are just now at the point where VMs can handle it all and feel native. Certainly NT could use a re write to eliminate all the legacy stuff…but instead they focus on copilot and nagging me not to leave windows edge internet explorer
- wvenable 2y ago
  > Couldn't they move the compatibility for larger parts to a VM or other independent Subsystem? A huge amount of the compatibility stuff is already moved out into separate code that isn't loaded unless needed. The problem too, though, is users don't want independent subsystems -- they want their OS to operate as a singular environment. Raymond Chen has mentioned this a few times on his blog when this sort of thing comes up. Backwards compatibility also really isn't the issue that people seem to think it is.
  - dredmorbius 2y ago
    Independent subsystems need not be independent subsystems that the user must manage manually. The k8s / containers world on Linux ... approaches ... this. Right now that's still somewhat manual, but the idea that a given application might fire off with the environment it needs without layering the rest of the system with those compatibility requirements, and also, incidentally, sandboxing those apps from the rest of the system (specific interactions excepted) would permit both forward advance and backwards compatibility. A friend working at a virtualisation start-up back in the aughts told of one of the founders who'd worked for the guy who'd created BCPL, the programming language which preceded B, and later C. Turns out that when automotive engineers were starting to look into automated automobile controls, in the 1970s, C was considered too heavy-weight, and the systems were imploemented in BCPL. Some forty years later, the systems were still running, in BCPL, over multiple levels of emulation (at least two, possibly more, as I heard it). And, of course, faster than in the original bare-metal implementations. Emulation/virtualisation is actually a pretty good compatibility solution.
hnfong 2y ago
It's possible that wine is more "backwards compatible" than the latest version of Windows though. And while wine doesn't run everything, at least it doesn't circumvent security measures put in place by the OS...
- leftyspook 2y ago
  I've had more luck running games from 97-00 under wine than on modern Windows.
flohofwoe 2y ago
If you look at more recent Windows APIs, I'm really thankful that the traditional Win32 APIs still work. On average the older APIs are much nicer to work with.
- alt227 2y ago
  > On average the older APIs are much nicer to work with IMO this is because they are better written, by people who had deeper understanding of the entire OS picture and cared more about writing performant and maintainable code.
  - xeonmc 2y ago
    Well-illustrated in the article “How Microsoft Lost the API War”[0]: The Raymond Chen Camp believes in making things easy for developers by making it easy to write once and run anywhere (well, on any Windows box). The MSDN Magazine Camp believes in making things easy for developers by giving them really powerful chunks of code which they can leverage, if they are willing to pay the price of incredibly complicated deployment and installation headaches, not to mention the huge learning curve. The Raymond Chen camp is all about consolidation. Please, don’t make things any worse, let’s just keep making what we already have still work. The MSDN Magazine Camp needs to keep churning out new gigantic pieces of technology that nobody can keep up with. [0] https://www.joelonsoftware.com/2004/06/13/how-microsoft-lost-the-api-war/ https://www.joelonsoftware.com/2004/06/13/how-microsoft-lost...
    - jimbokun 2y ago
      > making things easy for developers by giving them really powerful chunks of code which they can leverage, if they are willing to pay the price of incredibly complicated deployment and installation headaches, not to mention the huge learning curve. I feel the same way about Spring development for Java. Also reminds me of: https://www.infoq.com/presentations/Simple-Made-Easy/ https://www.infoq.com/presentations/Simple-Made-Easy/
- bboygravity 2y ago
tippytippytango 2y ago
If 20 years is so ancient, why did they go by so fast....
- lproven 2y ago
  Bad news. NT wasn't 20 years ago. It was 31 years ago.
ksec 2y ago
My question is why cant M$ ship the old OS running as VM. And free themselves from Backward compatibility on a newer OS.
- galaxyLogic 2y ago
  Users will want to use applications that require features of the earlier OS version, and newer ones that require newer features. They don't want to have to switch to using a VM because old apps would only run on that VM.
  - wongogue 2y ago
    Putting apps from the VM on the primary desktop is something they have already done on WSLg. Launching Linux and X server is all taken care of when you click the app shortcut. Similar to the parent’s ask, WSL2/WSLg is a lightweight VM running Linux.
    - simonh 2y ago
      In many ways the old API layers are sandboxed much like a VM. The main problems are things like device drivers, software that wants direct access to external interfaces, and software that accesses undocumented APIs or implementation details of Windows. MS goes to huge lengths to keep trash like that still working with tricks like application specific shims.
- TowerTall 2y ago
  They did that with Windows 7. Win 7 had an optional feature called "Windows XP Mode" that was XP running inside of a normal VM. https://arstechnica.com/information-technology/2010/01/windows-xp-mode/ https://arstechnica.com/information-technology/2010/01/windo...
- mike_hearn 2y ago
  Backwards compatibility isn't their biggest problem to begin with, so that wouldn't be worth it. In effect they already did break it: the new Windows APIs (WinRT/UWP) are very different to Win32 but now people target cross platform runtimes like the browser, JVM, Flutter, etc. So it doesn't really matter that they broke backwards compatibility. The new tech isn't competitive.

sedatk 2y ago

That and it's 30+ years (NT was released in 1993). Backwards compatibility is certainly one of the greatest business value Microsoft provides to its customers.

ozim 2y ago
People tend to forget that it already is 2024.
- xattt 2y ago
  Short of driver troubles at the jump from Win 9x to 2k/XP, and the shedding of Win16 compatibility layers at the time of release of Win XP x64, backwards compatibility had always been baked into Windows. I don’t know if there was any loss of compatibility during the MS-DOS days either. It’s just expected at this point.
  - anthk 2y ago
    On DOS, if you borrow ReactOS' NTVDM under XP/2003 and Maybe Vista/7 under 32 bit (IDK about 64 bit binaries), you can run DOS games in a much better way than Windows' counterpart.
    - rasz 2y ago
      Afaik due to POPF not trapping Reactos implemented NTVDM as a software emulator. https://web.archive.org/web/20170723164052/http://community.reactos.org/index.php/news/years-progress-ntvdm-part-1 https://web.archive.org/web/20170723164052/http://community.... https://web.archive.org/web/20151216085857/http://community.reactos.org/index.php/news/years-progress-ntvdm-part-2 https://web.archive.org/web/20151216085857/http://community.... At this point you might as well use DOSBOX. Intel Protected Mode POPF fail: https://docs.oracle.com/en/virtualization/virtualbox/6.0/admin/swvirt-details.html https://docs.oracle.com/en/virtualization/virtualbox/6.0/adm... https://devblogs.microsoft.com/oldnewthing/20160411-00/?p=93281 https://devblogs.microsoft.com/oldnewthing/20160411-00/?p=93...
      - anthk 2y ago
        I think they recently improved NTVDM a lot.
- ExoticPearTree 2y ago
  Not long ago, it was posted here a link to a job advert for the german railway looking for a Win 3.11 specialist. As I see it, the problem is the laziness/cheapness of companies when it comes to upgrades and vendor's reluctance to get rid of dead stuff for fear of losing business. APIs could be deprecated/updated at set intervals, like Current -2/-3 versions back and be done with it.
  - wongarsu 2y ago
    Lots of hardware is used for multiple decades, but has software that is built once and doesn't get continuous updates. That isn't necessarily laziness, it's a mindset thing. Traditional hardware companies are used to a mindset where they design something once, make and sell it for a decade, and the customer will replace it after 20 years of use. They have customer support for those 30 years, but software is treated as part of that design process. That makes a modern OS that can support the APIs of 30 year old software (so 40 year old APIs) valuable to businesses. If you only want to support 3 versions that's valid, but you will lose those customers to a competitor who has better backwards compatibility
MarkSweep 2y ago
If you include the ability of 32-bit versions of Windows to run 16-but Windows and DOS applications with NTVDM, it is more like 40+ years. https://en.wikipedia.org/wiki/Virtual_DOS_machine https://en.wikipedia.org/wiki/Virtual_DOS_machine (Math on the 40 years: windows 1.0 was released in 1985, the last consumer version of Windows 10 (which is the last Windows NT version to support 32-bit install and thus NTVDM) goes out of support in 2025. DOS was first released in 1981, more than 40 years ago. I don’t know when it was released, but I’ve used a pretty old 16-bit DOS app on Windows 10: a C compiler for the Intel 80186)
- sedatk 2y ago
  True. I just assumed that 16-bit support got dropped since Windows 11 was 64-bit only.
  - EvanAnderson 2y ago
    Microsoft decided not to type "make" for NTVDM on 64-bit versions of Windows (I would argue arbitrarily). It has been unofficially built for 64-bit versions of Windows as a proof-of-concept: https://github.com/leecher1337/ntvdmx64 https://github.com/leecher1337/ntvdmx64
    - badgersnake 2y ago
      That’s okay, and if people want to test their specific use case on that and use it then great. It’s a pretty different amount of effort to Microsoft having to do a full 16 bit regression suite and make everything work and then support it for the fewer and fewer customers using it. And you can run a 32 bit windows in a VM pretty easily if you really want to.
      - Timwi 2y ago
        Or you can run 16-bit Windows 3.1 in DOSBox.
        2y ago
dartharva 2y ago
But only to a degree, right? Only the last two decades of software is what the OS ideally needs to support, beyond that you can just use emulators.
- NegativeLatency 2y ago
  Maybe, but your app could also be an interface to some super expensive scientific/industrial equipment that does weird IO or something.
- badsectoracula 2y ago
  Software is written against APIs, not years, so the problem with this sort of thinking is that software written -say- 10 years ago might still be using APIs from more than 20 years ago, so if you decide to break/remove/whatever the more-than-20-year-ago APIs you not only break the more-than-20-year-ago software but also the 10 year old software that used those APIs - as well as any other software, older or newer, that did the same. (also i'm using "API" for convenience here, replace it with anything that can affect backwards compatibility) EDIT: simple example in practice: WinExec was deprecated when Windows switched from 16bit to 32bit several decades ago, yet programs are still using it to this day.
- da_chicken 2y ago
  Pretty much the only 16-bit software that people commonly encounter is an old setup program. For a very long time those were all 16-bit because they didn't need the address space and they were typically smaller when compiled. This means that a lot of 32-bit software from the late 90s that would otherwise work fine is locked inside a 16-bit InstallShield box.
  - aleph_minus_one 2y ago
    > Pretty much the only 16-bit software that people commonly encounter is an old setup program. I know quite a lot of people who are still quite fond of some old 16-bit Windows games which - for this "bitness reason" - don't work on modern 64 bit versions of Windows anymore. People who grew up with these Windows versions are quite nostalgic about applications/games from "their" time, and still use/play them (similar to how C64/Amiga/Atari fans are about "their" system).

runjake 2y ago

> The backwards compatibility though is one of the major features of windows as an OS. It is. That's even been stated by MSFT leadership time and time again. But at what point does that become a liability? I'm arguing that point was about 15-20 years ago.

dgfitz 2y ago
New frameworks have vulnerabilities. Old OS flavors have vulnerabilities. OpenSSh keeps making the news for vulnerabilities. I’d argue that software is never finished, only abandoned, and I absolutely did not generate that quote. Stop. Just stop.
- anthk 2y ago
  >OpenSSH Yes, just stop... with the bullshit. OpenBSD didn't make vulnerabilities. Foreign Linux distros (OpenSSH comes from OpenBSD, and they release a portable tgz too) adding non-core features and libraries did.
efitz 2y ago
There is another very active article on HN today about the launch of the new Apple iPhone 16 models. The top discussion thread on that post is about “my old iPhone $version is good enough, why would I upgrade”. It’s funny, if you ask tech people, a lot fall into the “I have to have the latest and greatest” but also a lot fall into the “I’ll upgrade when they pry the rusting hardware from my cold dead hands”. For Microsoft, the driver for backwards compatibility is economic: Microsoft wants people to buy new Windows, but in order to do that, they have to (1) convince customers that all their existing stuff is going to continue to work, and (2) convince developers that they don’t have to rewrite (or even recompile) all their stuff whenever there’s a new version of Windows. Objectively, it seems like Microsoft made the right decision, based on revenue over the decades. Full disclosure: I worked for Microsoft for 17 years, mostly in and around Windows, but left over a decade ago.
- ruthmarx 2y ago
  > It’s funny, if you ask tech people, a lot fall into the “I have to have the latest and greatest” This is almost never a technical decision, but a 'showing off' decision IMO.

johannes1234321 2y ago

It is a great achievement. But the question is: Is it really relevant? Couldn't they move the compatibility for larger parts to a VM or other independent Subsystem? Of course even that isn't trivial, as one wants to share filesystem access (while I can imagine some overlay limiting access), might need COM and access to devices ... but I would assume they could push that a lot more actively. If they decided which GUI framework to focus on.

486sx33 2y ago
I think that VM software like Parallels has shown us that we are just now at the point where VMs can handle it all and feel native. Certainly NT could use a re write to eliminate all the legacy stuff…but instead they focus on copilot and nagging me not to leave windows edge internet explorer
wvenable 2y ago
> Couldn't they move the compatibility for larger parts to a VM or other independent Subsystem? A huge amount of the compatibility stuff is already moved out into separate code that isn't loaded unless needed. The problem too, though, is users don't want independent subsystems -- they want their OS to operate as a singular environment. Raymond Chen has mentioned this a few times on his blog when this sort of thing comes up. Backwards compatibility also really isn't the issue that people seem to think it is.
- dredmorbius 2y ago
  Independent subsystems need not be independent subsystems that the user must manage manually. The k8s / containers world on Linux ... approaches ... this. Right now that's still somewhat manual, but the idea that a given application might fire off with the environment it needs without layering the rest of the system with those compatibility requirements, and also, incidentally, sandboxing those apps from the rest of the system (specific interactions excepted) would permit both forward advance and backwards compatibility. A friend working at a virtualisation start-up back in the aughts told of one of the founders who'd worked for the guy who'd created BCPL, the programming language which preceded B, and later C. Turns out that when automotive engineers were starting to look into automated automobile controls, in the 1970s, C was considered too heavy-weight, and the systems were imploemented in BCPL. Some forty years later, the systems were still running, in BCPL, over multiple levels of emulation (at least two, possibly more, as I heard it). And, of course, faster than in the original bare-metal implementations. Emulation/virtualisation is actually a pretty good compatibility solution.

hnfong 2y ago

It's possible that wine is more "backwards compatible" than the latest version of Windows though. And while wine doesn't run everything, at least it doesn't circumvent security measures put in place by the OS...

leftyspook 2y ago
I've had more luck running games from 97-00 under wine than on modern Windows.

flohofwoe 2y ago

If you look at more recent Windows APIs, I'm really thankful that the traditional Win32 APIs still work. On average the older APIs are much nicer to work with.

alt227 2y ago
> On average the older APIs are much nicer to work with IMO this is because they are better written, by people who had deeper understanding of the entire OS picture and cared more about writing performant and maintainable code.
- xeonmc 2y ago
  Well-illustrated in the article “How Microsoft Lost the API War”[0]: The Raymond Chen Camp believes in making things easy for developers by making it easy to write once and run anywhere (well, on any Windows box). The MSDN Magazine Camp believes in making things easy for developers by giving them really powerful chunks of code which they can leverage, if they are willing to pay the price of incredibly complicated deployment and installation headaches, not to mention the huge learning curve. The Raymond Chen camp is all about consolidation. Please, don’t make things any worse, let’s just keep making what we already have still work. The MSDN Magazine Camp needs to keep churning out new gigantic pieces of technology that nobody can keep up with. [0] https://www.joelonsoftware.com/2004/06/13/how-microsoft-lost-the-api-war/ https://www.joelonsoftware.com/2004/06/13/how-microsoft-lost...
  - jimbokun 2y ago
    > making things easy for developers by giving them really powerful chunks of code which they can leverage, if they are willing to pay the price of incredibly complicated deployment and installation headaches, not to mention the huge learning curve. I feel the same way about Spring development for Java. Also reminds me of: https://www.infoq.com/presentations/Simple-Made-Easy/ https://www.infoq.com/presentations/Simple-Made-Easy/
bboygravity 2y ago

tippytippytango 2y ago

If 20 years is so ancient, why did they go by so fast....

lproven 2y ago
Bad news. NT wasn't 20 years ago. It was 31 years ago.

ksec 2y ago

My question is why cant M$ ship the old OS running as VM. And free themselves from Backward compatibility on a newer OS.

galaxyLogic 2y ago
Users will want to use applications that require features of the earlier OS version, and newer ones that require newer features. They don't want to have to switch to using a VM because old apps would only run on that VM.
- wongogue 2y ago
  Putting apps from the VM on the primary desktop is something they have already done on WSLg. Launching Linux and X server is all taken care of when you click the app shortcut. Similar to the parent’s ask, WSL2/WSLg is a lightweight VM running Linux.
  - simonh 2y ago
    In many ways the old API layers are sandboxed much like a VM. The main problems are things like device drivers, software that wants direct access to external interfaces, and software that accesses undocumented APIs or implementation details of Windows. MS goes to huge lengths to keep trash like that still working with tricks like application specific shims.
TowerTall 2y ago
They did that with Windows 7. Win 7 had an optional feature called "Windows XP Mode" that was XP running inside of a normal VM. https://arstechnica.com/information-technology/2010/01/windows-xp-mode/ https://arstechnica.com/information-technology/2010/01/windo...
mike_hearn 2y ago
Backwards compatibility isn't their biggest problem to begin with, so that wouldn't be worth it. In effect they already did break it: the new Windows APIs (WinRT/UWP) are very different to Win32 but now people target cross platform runtimes like the browser, JVM, Flutter, etc. So it doesn't really matter that they broke backwards compatibility. The new tech isn't competitive.