[tomcam]

You would be surprised at how much cruft in Windows over the years has been directly due to Adobe. I had many bug triage sessions where Windows developers at Microsoft had to work around Adobe problems to keep Windows users happy. I always thought it was unfair and was quite impressed by Microsoft at their willingness to handle this so quietly.

[comex]

Not just Windows. Some choice strings from macOS system frameworks:

AppKit:

    NSSavePanelOverRetainToCompensateForAdobe
    NSShouldWorkAroundBadAdobeReleaseBug
    Adobe Invener Fusion opted out due to odd event processing

Foundation:

    com.adobe.Reader
    com.adobe.Acrobat
    com.adobe.Acrobat.Pro
    _allocWithZone:.do_adobe_hack

(Though they're hardly alone. AppKit contains a huge number of bundle IDs scattered through the strings list, presumably for various special cases…)

[brongondwana]

Everyone has hacks for the biggest products out there, it's a fact of life.

My DAV server has hacks for Microsoft bugs and misfeatures, hacks for older Apple clients, hacks for Konqueror of all things, because I tested against it.

And our current CalDAV code has just inherited two new hacks this week to work around weird bugs in shit that Google Calendar has been serving up:

* years with only two digits or two leading zeros rather than 20xx.

* unquoted TZNAMEs with :s in them.

At least events from year "0012" are allegedly legitimate parsable ISO8601 times, and the events from year "12" are at least legitimate VCALENDAR. The broken TZNAMES parse legitimately, but

DTSTART;TZNAME=GMT+10:00:20120101T01010101 needs to be fixed up pre-parse.

Welcome to interoperability, where liberal in what you accept is the only choice when your communication partner is much bigger.

[l-p]

Excerpt from the Radicale documentation:

> The Radicale Server does not and will not support the CalDAV and CardDAV standards. It supports the CalDAV and CardDAV implementations of different clients (Lightning, Evolution, Android, iPhone, iCal, and more).

[brongondwana]

Yeah, I bet. The standards are getting better, but there are so many vendor specific things that you need to support to have a good experience that just reading the standards in isolation won't help you much.

Contributing to devguide.calconnect.org on the other hand, helps everybody.

[gumby]

I wonder if someone has the energy to establish connectathons for "above layer 4". Most of our interoperability problems these days are virtual (thanks to brick and mortar connectathons squeeing out any of the old layer 1-4 bugs). These days we could do them online, and automate the detection of regressions.

I was actually astonished that connectathons are still running; I haven't been to one in decades: http://www.connectathon.info

[pc2g4d]

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.

[ced]

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!)

[Pxtl]

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]

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]

I believe the thread you're looking for is this one, about never breaking user space:

https://lkml.org/lkml/2012/12/23/75

[digi_owl]

And this is why the kernel is "everywhere" while "year of the desktop" never happens. Because Linux userspace is all to happy to break itself again and again and again...

[dTal]

Isn't this more of a social problem than a technical one? It seems to me like the main issue is a convention that a system only have a single version of a library installed, the anointed "system" version of that library. And often, binary releases of software are built against a particular cocktail of library versions from a particular distro at the time of release, each of which depends on its own cocktail of libraries, etc... In reality it's not complicated to get virtually any binary running on any system (in the worst case, just put the distro it expects into a chroot) - and there's no reason why applications couldn't just bundle all the libraries they need, right down to glibc - but it's just Not Done.

[wand3r]

exactly that. thank you.

[cpeterso]

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/

[agumonkey]

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

[guitarbill]

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.

[SCHiM]

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]

It's amazing how much technical debt Android has accrued given how much newer it is than Windows.

[wtallis]

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]

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.

[m1sta_]

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

[derefr]

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.

[ndespres]

Windows 7 included what you describe as a feature called "Windows XP Mode," which would launch applications inside a Windows XP virtual machine which was closely tied to the host OS. It worked really well for a lot of applications which weren't ready for Win 7 yet.

https://technet.microsoft.com/en-us/library/ee681616(v=ws.10...

[ygra]

It wasn't really that closely tied, if I remember. It simply used Terminal Services to run a single application on the server. You've long been able to open local documents with remote applications, and have the general experience very close to a local application.

[wvenable]

> 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.

I think Raymond Chen discussed this on this blog at one point. The answer is that users want a single integrated environment for all their apps and not a bunch of isolated sandboxes. They want to drag and drop, copy and paste, share files, inter-application communication, etc. They also want a single look and feel.

The other reason is that creating a new platform from scratch is a good way to lose features and alienate developers. The core of Windows NT doesn't look anything like Windows 3.1 but for developers the API they present is similar enough to get them on board.

[candiodari]

https://www.joelonsoftware.com/2000/04/06/things-you-should-...

MS tried to rewrite and get compatibility by using these sorts of features. It was looked at by the PMs and dismissed because it was completely broken.

Turns out most hacks are in the software for a reason. They actually solve a problem that needs solving. Who knew ?

[roblabla]

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

[1] : https://en.wikipedia.org/wiki/Rosetta_(software)

[2] : https://en.wikipedia.org/wiki/List_of_macOS_components#Class...

[douche]

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]

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.

[relevate]

This is partially the motivation behind MSR's Drawbridge project (which is the predecessor for Windows Subsystem for Linux), the idea being that the personality of the OS runs in user space and each application runs in a sandboxed picoprocess. All ~14,000 functions exposed by Windows DLLs could be implemented by a narrow ~45 ABI calls provided by the host.

https://www.microsoft.com/en-us/research/project/drawbridge/

[Kipters]

Technically they're already doing it via their subsystem mechanism. They're taking it "to the next level" with the Linux subsystem, where there's a kernel driver emulating a totally different kernel

[markrages]

> 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]

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.

[flomo]

Perhaps I'm missing something, but that sounds pretty much exactly how Win16 apps worked on 32-bit NT.

[kgc]

Early releases of OSX did this using "Rosetta"

[sorenjan]

I bet it would be a huge success.

[digi_owl]

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.

[frik]

File metadata is not cruft. It's a very good thing. Vista's/Win7 Explorer.exe with its metadata columns is GREAT.

Even better was Windows (Live) Photo Gallery. Sadly it's dead since Feb 2017, you can't even install it anymore, as only a now broken WebInstaller exists. Photo Gallery was hand down 1000 times better than Picasa/Lightroom/Photos/iPhotos for just browsing photos and videos. And it alo supported tags with hierarchy (eg "City/New York/Manhattan").

https://en.wikipedia.org/wiki/Windows_Photo_Gallery

Sadly WinFS failed, metadata is nowadays often misunderstood and persived by companies contra productive in the age of cloud service strategies. Flickr is probably the only well known photo service tht keeps metadata. Facebook made it popular to strip metadata and keep annotations internally (as vendor lockin) - now common also with other services.

I hope there will be a kind of come back of metadata. People need more education to understand the concept, that's all.

[mathw]

Sure it's not cruft when they're images in your image library and you need to find them and understand them using said metadata.

It's cruft when those assets are now embedded into your compiled, bundled, distributed software and such metadata now has no purpose whatsoever, as is the case for the examples cited in the article.

[daemin]

The article was talking about adobe image metadata embedded in the explorer.exe executable itself, as metadata inside some png images that explorer uses in its interface.

It isn't talking about the metadata columns for files.

[frik]

Read the Wikipedia article about XMP. It's a newer metadata format to Exif and IPTC. XMP comes from Adobe, it contains a lot of Adobe strings in the XML schema.

I wrote about the metadata handling in Explorer/shell32. It's a light version of what was tried out with WinFS.

[daemin]

Read the article again, take a look at the code. The author is not complaining about Windows Explorer being able to parse and display metadata from PNG files. The author is complaining about how much embedded metadata there is inside PNG files inside the explorer executable file itself, as well as other DLL and EXE files in Windows.

The metadata that the author finds is actually inside resources inside the executable itself. It does not include any strings found in the executable which are used to parse the metadata from other files that you have on disk.

I'm not saying metadata is cruft. Metadata is very useful during production or for managing art assets. It is however superfluous once it is embedded in an executable or other code library or packed archive. This is simply because its purpose has already been served and it is no longer needed at that point, thus wasting space.

[VMG]

> Even better was Windows (Live) Photo Gallery. Sadly it's dead since Feb 2017, you can't even install it anymore, as only a now broken WebInstaller exists.

Slightly OT: is there any good photo organizer for windows? I would be happy with sth at the level of shotwell even https://wiki.gnome.org/Apps/Shotwell

[frik]

digiKam runs on Windows too, it's good, it's open source. But only photos.

Photo Gallery supports video too, and is s lot easier to use and has s polished UI and stable path-like-metadata support. DigiKam can read such metadata tags, even edit them but adding new ones is buggy (path like City/New York/Manhattan are then stored as three separate tags City, New York, Manhattan).

[i336_]

> Even better was Windows (Live) Photo Gallery. Sadly it's dead since Feb 2017, you can't even install it anymore, as only a now broken WebInstaller exists.

This sounds like a challenge. You're on.

- Do some scratching around; discover sites hosting "wlsetup-all.exe"

- Point the Web Archive at download.live.com

- After some trial and error with broken pages find http://web.archive.org/web/20161130174327/https://support.mi...

- Follow the "Download options" link

- Eventually land on http://web.archive.org/web/20161226002912/https://support.mi..., and disable JavaScript so the page doesn't kill itself (remember on Chrome you just click the (i) to the left of the URL)

- Ah, a "Download Now" link!

  $ curl -vv http://go.microsoft.com/fwlink/?LinkID=255475
  Location: http://g.live.com/1rewlive5-web/en/wlsetup-web.exe

  $ curl -vv http://g.live.com/1rewlive5-web/en/wlsetup-web.exe
  Location: http://wl.dlservice.microsoft.com/download/C/1/B/C1BA42D6-6A50-4A4A-90E5-FA9347E9360C/en/wlsetup-web.exe

Hmm...

  (note s/web/all/g)
  $ curl -vv http://g.live.com/1rewlive5-all/en/wlsetup-all.exe
  Location: http://wl.dlservice.microsoft.com/download/C/1/B/C1BA42D6-6A50-4A4A-90E5-FA9347E9360C/en/wlsetup-all.exe

Can I...?...

  $ curl -vv http://wl.dlservice.microsoft.com/download/C/1/B/C1BA42D6-6A50-4A4A-90E5-FA9347E9360C/en/wlsetup-all.exe
  < HTTP/1.1 404 Not Found
  (...)
  <div id="header"><h1>Server Error</h1></div>
  (...)
  <h2>404 - File or directory not found.</h2>
  <h3>The resource you are looking for might have been removed, had its name changed, or is temporarily unavailable.</h3>

Hmmm.

- Try and load wl.dlservice.microsoft.com/robots.txt in the Web Archive

- Get redirected to Microsoft homepage!!

- Lookup wl.dlservice.microsoft.com/* in Web Archive

- "805 URLs have been captured for this domain."

- Search for "c1ba..." - get hits!

http://web.archive.org/web/20170416220642/http://wl.dlservic...

137329840 bytes.

There are other sites that have copies of the file, but a) this one is from the Web Archive and b) I've verified using a mixture of WA and still-live Microsoft redirects that this is the latest-ever release.

[acemarke]

Just want to say I love it when people do stuff like this. :) I have no need for that app myself, but I appreciate that you took the time to grovel through the guts of several different pages, work around barriers, solve the problem, and document all the steps you took.

[frik]

Thanks!

I previously copy&pasted the folder to another PC, and manually patched the registry and copied some dlls to get it working.

[i336_]

Oh, nice. No problem ^^

[krylon]

> And it alo supported tags with hierarchy (eg "City/New York/Manhattan").

This is kind of OT, but F-Spot on Linux supported hierarchical tags, as well, and I loved it. Was really sad when it was discontinued and distros replaced it with Shotwell.

[wvenable]

Adobe effectively forced Apple to build the Carbon API for OS X delaying the release by a year or more.

[jomohke]

Apple used Carbon for a lot of its own built-in apps, such as Finder, didn't it? (edit: and iTunes)

(Almost?) all other other major vendors at the time used it heavily too: Microsoft Office until 2011, FileMaker until 2010.

If Apple released the OS a year earlier, but without any available third-party software (waiting for almost-rewrites to happen), would they really have been better off? At this time they were on life support and would have had difficulty convincing third-party vendors to invest heavily in their platform, or to convince users to adopt it without any major applications available.

In either case, Adobe's sway clearly declined over the years, as Apple cancelled the 64bit version of Carbon while Adobe was still heavily built around it, forcing Adobe to switch (and an awkward year or two when the Mac, but not Windows, versions were stuck with 32bit memory limitations)

[wtallis]

> Apple used Carbon on a lot of its own built-in apps (such as Finder), didn't it?

Apple wrote the Finder in Carbon as a dogfooding exercise, to prove to third party developers that Carbon was a first-class fully supported framework. The Finder has since been re-written in Cocoa.

[DerekL]

> Apple used Carbon for a lot of its own built-in apps, such as Finder, didn't it? (edit: and iTunes)

iTunes needed to support both Mac OS 9 and X, so Carbon made much more sense than writing all of the UI code twice. Also, it started as SoundJam MP, which was written for Mac OS 8, so Carbonization was much less work than a Cocoa rewrite.

[simonh]

Right, but the same logic applied to any popular app with users still on Mac Os.

[zubat]

Now imagine the world where Microsoft became Adobe's direct competitor and cut their oxygen supply.

[eon1]

I feel like you're implying that would be a bad thing when it could actually be preferable. I don't think MS is faultless or anything, but I'd be surprised if they could make themselves as much of a pain as Adobe does (especially given all the OS integration opportunity).

[goldfire]

This is exactly what Microsoft were accused of doing to Lotus 1-2-3 back in the day. See [0]. TL;DR: wasn't true.

[0] https://news.ycombinator.com/item?id=10432608

[santaclaus]

Didn't they try that with Expression back in the aughts and fail? Doesn't mean it couldn't work now, though!

[at-fates-hands]

I actually found out about Expression way after the fact and thought it was a viable alternative - but by then, MS was already in the process of sending it out to pasture.

It's like a co-worker said, "Adobe's software is bloated and cumbersome, but they have a top notch marketing team that keeps it afloat." But yes, if there is a company that is ripe to have some serious competitors it would be Adobe.

[aswanson]

I've heard that Adobe's poor software engineering has provided a huge malware/virus vulnerability surface for windows. Maybe MS should force them to break/rewrite.

[simonh]

And push a large chunk of Adobe users on to the Mac.

[batter]

Doesn't it makes you wonder why MS created that situation on the first place?

MS have no one to blame except themself and their 'legacy code'.

[commandar]

It's hard enough to get enterprise customers to stay current when they do provide legacy support. Fighting with IE version compatibility, for example, is still a daily, very real issue for enterprise size organizations.

Blame the customers. Microsoft never would have captured the marketshare they have if they didn't cater to them.

[DaiPlusPlus]

Microsoft does deserve some blame for deciding to support backwards-compatibility in-situ instead of introducing proper API versioning, packaging, isolation, and other proven techniques. Win32 wasn't versioned for processes until Windows 7 (using app.manifest) even though the need for such as system was blatantly obvious during the Windows 2000 days.

[commandar]

Sure, that's valid.

But most of the real nightmare scenarios I've heard related to backwards compatibility have more to do with third-parties doing things they were never supposed to do.

Things like hitting private, undocumented APIs. Or checking the Windows version with a "9x" wildcard, giving us the jump from W8 to W10 over a decade later.

Microsoft has made their own mistakes, but supporting the mistakes of third parties has been absolutely vital to them keeping their core customer base.

[DaiPlusPlus]

All of those scenarios you describe can be solved with appropriate application sandboxing and shimming.

I don't personally believe the "Windows 9" story - if a program is old enough to feel the need to check for Windows 95/98 then it should already be fine to run under Windows' own app-compat layer which spoofs the Windows version string anyway. I believe it's marketing-based out of fear consumers would see "MacOS 10 vs Windows 9" (like how it was PlayStation 3 vs Xbox 2 - hence "Xbox 360").

[nemothekid]

MacOS 10 wasn't rebranded from OS X until 2016, a full year after Windows 10 GA - and I doubt anyone outside a select few at Apple knew that the OS X line was going to be renamed.

In any case, your reasoning doesn't really make sense. I can run a program that was written for Windows XP on Windows 10 without the need from a app-compat layer. Given that a developer can hide/show all sorts of random functionality with an if-branch-on-version - the user will see a broken or strange app and it won't be clear (and MS probably didn't have the means to detect) that the app should run in compatibility mode.

I still believe that MS wanted to ship an OS that "just worked" and did so under 10, than trying to compete in version numbers with an OS that has had 10 in its name for last 18 years.

[carey]

Some of those programs would have been Java programs, where java.exe is modern, but the program is not. The definition of os.name in Java makes checking the string prefix particularly likely.

[ClassyJacket]

" Or checking the Windows version with a "9x" wildcard, giving us the jump from W8 to W10 over a decade later."

This is just a rumor made up on reddit. It's completely false. Windows returns its version number as a series of integers. And even if it was a string, they could've just called it "Windows Nine".

[WorldMaker]

Windows version APIs have always had a "name" string and bad developers do have a wild tendency to just use string manipulation instead of more obvious methods. The Windows version APIs now even "lie" by default since around Vista because they presume a developer isn't querying the version API for the right reasons and you now have to essentially tell Windows you are built for/have tested on the right version to get the right version response, but the right way to do things is capability checks rather than checking the version API so it shouldn't matter that you need to do a lot of work to get the actual current version information from the version API.

Also: https://news.ycombinator.com/item?id=14205899

[tremon]

Things like hitting private, undocumented APIs

That's entirely Microsoft's fault too: they made internal APIs accessible to applications, and did not provide comprehensive documentation on the full features of their public API.

The latter means that application developers were forced to just guess what a function could do. And since no API performs proper input validation, undocumented usage became the norm.

[ygra]

Of course internal APIs are accessible to applications. You can always call them somehow. Whether it's fishing "function #183" from a DLL, or reflecting on a managed type and calling stuff that way ... I wouldn't exactly blame MS here.

Public APIs are documented, guaranteed to work like documented (otherwise it's a bug and will be fixed) and intended for others to call. Internal APIs are none of these things. They are not documented because they're not supposed to be called. Anything not documented in an API it (to me at last) something that's not guaranteed to remain like that. Whether it's a complete function or just a side-effect of something that is public.

[UnoriginalGuy]

> Microsoft does deserve some blame for deciding to support backwards-compatibility in-situ instead of introducing proper API versioning, packaging, isolation, and other proven techniques.

They did, in Windows 8. It is called Metro/Modern/UWP. Everyone hates it.

[tjalfi]

My employer has an application that requires IE5 compatibility mode. We are a version behind and will be upgrading it this year. The sad thing is that the new version uses Silverlight.