Hacker News Reader

Comment by shadowgovt | Hacker News Reader

Traditionally, this is a significant philosophical difference between Apple and Microsoft that goes quite a ways towards explaining how Microsoft gained and held dominance for so long in the business sector.

Businesses don't want to be told that their working software needs to be updated to make a vendor's bottom-line cheaper. They recognize cost-shifting when they see it and respond by backing towards the exits. Microsoft maintained a philosophy for decades that it was their responsibility to, if at all possible, maintain backwards compatibility with older Windows software as a market differentiator. The primary times I remember them breaking this policy were security related.

(That having been said, I got out of active development of Windows software around Windows 8, so this may have changed).

View on HN

Again, I don't think people would have as much of an issue if it was clearly about deprecation.

Something like Google's minimum sdk version is annoying, but understandable. It's technical and concrete - you must link against version X because version X-1 is going to disappear.

This is not that. It's culling apps that are arbitrarily too old and arbitrarily not popular enough. They must be keeping around old sdk versions if those old but popular apps are allowed to continue on.

This is the single biggest reason why Microsoft continues to be dominant in the market of practicality. Microsoft will bend backwards 420 degrees and land a headshot to make sure something from 30 years ago will run (within reason) on the latest version of Windows.

That's the reputation, but it's far from true at the moment. For example, there are numerous games from the 2000s that don't work anymore (I mean crash at startup or soon after, not some soft "not working like before") in any compatibility mode on modern Windows. I'm more familiar with games, but I'm sure the same is true of various other kinds of software (though graphics drivers may well be an important part of the problem, so games may well be over-represented).

Games depend on more volatile elements like graphics drivers and APIs, like you said, so they aren't exactly representative of Microsoft's backwards compatibility efforts. That said, there are still quite a lot of games which owe their continued operation in modern Windows to Microsoft's veneration of old programs.

A better example is productivity software, like Photoshop and Illustrator or Paint Shop Pro. I can get Paint Shop Pro 5, a raster graphics editor from 1998, to run on Windows 11 just fine, for example. Another is Microsoft Office, in which Microsoft goes out of its way to make sure documents created long ago will load and work fine in modern Office, and ancient versions of Office itself will happily run mostly fine on modern Windows too (eg: I run Office XP on my Windows 7 machines).

Only things I've ever noticed that had issues in modern versions of Windows with is software reliant on old, specialized hardware (for example, dental imaging software) and games. Wouldn't really put the blame in these areas on Microsoft, as they don't provide the drivers nor the custom graphic API's (notice that most old DirectX software has no issues working) - and hell, you can still run your 40-or-so-year-old apps on a 32-bit version of Windows...

Games were among the worst offender in terms of writing on the disk outside of user space (including Program Files and the registry).

Old games were also quite often doing direct access to graphic cards outside of official APIs

And games are not business software. An old game that stops working is "too bad, move long", accounting software that stops working has real life consequences.

That's not the market they care about. What they care about is that the stupid labelmaking application my employer uses for its annual conference whose vendor went out of business in 2005 still runs today even though it was compiled for Windows 2000.

Games, especially in the 90s (and some early 2000s) did a ton of API abuse so they are among the harder types of software to keep running. Still, most do work out of the box and with 3rd party compatibility shims like dgVoodoo (for the older ones) and DXVK (for the more recent ones) stuff tend to work since the breakage is still very minimal.

More regular applications tend to be much easier to get working though. E.g. something like Delphi 2 or C++ Builder 1 work out of the box just fine. The biggest issue with older software is that they sometimes had 16bit installers who do not work with 64bit Windows. Windows comes with some updated stubs for some popular installers and it is possible to manually fiddle with some of the unsupported ones to run the 32bit engine directly, though something like odtvdm/winevdm that emulates 16bit code on 64bit would also work.

But in general you can get things working, depending on how well the application was written. In some cases (games, 16bit installers) you do need workarounds as they wont work out of the box, but even those workarounds are based on the 99.9% of the rest of the system preserving backwards compatibility.

I remember the old trick on MacOS of calling `getNextEvent()` instead of `waitNextEvent()` to make sure no other processes got CPU cycles.

Worked generally okay until the era of the Internet came along and after you quit the game, all manner of programs would crash when the network stack suddenly found itself teleported an hour or two into the future and couldn't cope.

https://www.joelonsoftware.com/2004/06/13/how-microsoft-lost...

> The most impressive things to read on Raymond’s weblog are the stories of the incredible efforts the Windows team has made over the years to support backwards compatibility ...

> I first heard about this from one of the developers of the hit game SimCity, who told me that there was a critical bug in his application: it used memory right after freeing it, a major no-no that happened to work OK on DOS but would not work under Windows where memory that is freed is likely to be snatched up by another running application right away. The testers on the Windows team were going through various popular applications, testing them to make sure they worked OK, but SimCity kept crashing. They reported this to the Windows developers, who disassembled SimCity, stepped through it in a debugger, found the bug, and added special code that checked if SimCity was running, and if it did, ran the memory allocator in a special mode in which you could still use memory after freeing it.

> ... Raymond Chen writes, “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.”

> A lot of developers and engineers don’t agree with this way of working. If the application did something bad, or relied on some undocumented behavior, they think, it should just break when the OS gets upgraded. The developers of the Macintosh OS at Apple have always been in this camp. It’s why so few applications from the early days of the Macintosh still work. For example, a lot of developers used to try to make their Macintosh applications run faster by copying pointers out of the jump table and calling them directly instead of using the interrupt feature of the processor like they were supposed to. Even though somewhere in Inside Macintosh, Apple’s official Bible of Macintosh programming, there was a tech note saying “you can’t do this,” they did it, and it worked, and their programs ran faster… until the next version of the OS came out and they didn’t run at all. If the company that made the application went out of business (and most of them did), well, tough luck, bubby.

---

This really gets into a philosophical difference of how software should work and who should be maintaining it. As a user, I love Raymond Chen's approach. As a developer, trying to maintain bug for bug compatibility with older versions of the code is something that scales poorly and continues to consume more and more resources as more and more bugs need that bug for bug compatibility across versions.

Being dominant in the PC market is kind of a Pyrrhic victory.

Not anymore. That may once have been true but circa Windows 8.1/10 that changed substantially IME. It really came to a head when Windows 7 support was dropped but I spent several years consulting and helping people migrate really really old software (which should have been replaced) that was Win 3.11/DOS based from Win7 to either Dosbox or Wine on Linux systems because Windows 10 specifically couldn't actually support running them anymore. Compatibility was broken in a rough way with 10 for very old applications which were otherwise working.

It's fine to argue typical desktop applications need to be updated but purpose-built applications cost money, so when you have things like a POS terminal installed in thousands of fast-oil-change locations and it's from the Win3.11 era working perfectly fine for years but suddenly stops working after moving to 10, that's a sudden cost on a business (especially with no warning). Yes, you can argue that companies should be updating that kind of software, if only for reasons of security (I often did). The bottom line tends to be king, especially in smaller businesses, in my experience.

> The primary times I remember them breaking this policy were security related.

And they also went above and beyond to make it happen too. That time when they byte-patched a binary which they didn't have the source code anymore comes to mind.

https://blog.0patch.com/2017/11/did-microsoft-just-manually-...

https://news.ycombinator.com/item?id=15720923

it seems like that on a long enough timeline however, promising that legacy cruft will always keep crufting as it did before seems like a huge burden that leaks into your ability to deliver quality in your current offerings.

Sure there are old things that are good and "complete" but far more old stuff is just old and could well be burnt to the ground, except for the fact that you have some customer somewhere relying on its oddities and unintended behaviors as an essential feature of their integrations.

I feel you are arguing for real harm now, versus potential harm in the future.

There's no sign that being very-backward-compatible is holding Windows back that I can see.

In the other hand I have collected a set of utilities into my work-flow that are easily 20+ years old, and they all work fine.

The last major cull from Microsoft was that 16bit programs ceased to work on 64 bit platforms. Other than that I've never had an app fail.

Most of those utility supplies have long since disappeared, retired, or died. But I can still keep transferring those apps to the next machine and they keep running.

None of this impacts the quality of my current offerings. Ultimately all this costs me is some cheap disk space.

I have a couple camera apps from the mid 'aughts that were written for Windows XP that still function fine under Windows 10. Same thing with an old photo scanner, that just only recently failed. My last SCSI dependent peripheral. Ran fine on Windows 10, on ancient software, using ancient TWAIN SCSI drivers, until the scanner itself failed. As I moved from XP -> 7 -> 8.1 -> 10, the first thing I did was load up all my old photo software to be sure it would work.

My father has an ancient scanner from the XP era and the only thing that still works with it is a Windows XP VM he happens to have (I assume later windows could work too, but the XP exists for other reasons and so we continue to connect the scanner to it).

Maybe Linux could be beaten to work with it, but this works well enough.

Microsoft struggles to release new OS’s, move to new devices and it’s been trying to move to ARM and has seen little success.

Backwards compatibility is very much holding MS back

Windows ARM64 works great, with (similar to macOS) transparent support for x64 programs. Successful or not, I don't see any problem with the software.

Works great as long as you don’t care about the lack of performance, not getting great battery life, and the lack of native applications…

Which is the reason that Apple is never going to conquer "traditional" gaming. Traditional games (ones that are NOT perpetually updated live services) and rock-solid-stable development targets have always been very close -- game consoles would always be guaranteed to run any game that's ever been officially released for it, even if it's an unpatched launch-day game running on the final hardware revision of console 8 years after release.

Even if Mac hardware manages to vastly outrun the top end gaming PCs on raw performance, they'll never be seen as serious mainstream targets for this reason alone.

Reply on news.ycombinator.com