A lot of 'real' (cough) hackers like to look down at MS, but Raymond Chen is one of those guys I'd hate to get into a technical argument with: he has experience, is extremely sharp, and very sarcastic. Those three attributes make Old New Thing my favorite MS blog even if I don't write Win32 anymore.
If anything, Windows' level of backward compatibility is a giant cautionary tale: enable poor behavior from devs, and it will proliferate. You cannot trust app devs to do the right thing, they need to be forced to; whether by gatekeepers at app stores, or OS restrictions. It is a tragedy of the commons. Whether it's inane programs inserting themselves into the systray, 'preloaders' for bloated apps (which slow startup), browser extensions, Explorer add-ons, or other garbage, app devs still seem to do a fantastic job of gunking up a Windows install.
This is why it's a bit of a blessing that webapps can't do much; because the more powerful they become, the more annoying and inane they will be.
I'm really amazed that Windows has maintained substantial binary compatibility for so long. To be honest, when I see "one way they could've done it was by squeezing the flag into the one byte of padding between widgetLevel and needs_more_time" I think nooope, nonstandard, can't do it, not my problem. Worrying about such things constantly throughout huge projects like MSVC over decades of time must add a whole new level to the difficulty of those engineers' jobs.
On the other hand, it's a service to the user that old software keeps running. People who once invested in a copy of photoshop don't have to pay for upgrades they don't need. Or, in my case, i still use ecco pro to outline ideas, which saw its last update in 1997, is orphaned without source, and for which i've found no alternative that matches my exact flow.
That's Windows strength as well as its weakness. For example, I've heard that Windows Shell (whose proud team member is Raymond Chen) has to carry the baggage of backward compatibility, heritage code base and stuff like that simply because some forsaken customer might be using a particular feature. It's really hard to innovate in the environment like that.
Yea, you can't simultaneously say "Developer, don't do this!" and then "Well, to maintain backwards compatibility with developers who did it, we're going to let you do it. BUT DON'T DO IT!"
MS is in a tight spot. They have this maintanance mess because of their otherwise admirable dedication to backwards compatibility.
Microsoft's dedication to backward compatibility is why Windows ruled the desktop world for several decades.
Apple's utter contempt for backward compatibility is why people who care about their sanity hate developing products for OSX. Which API is Apple going to deprecate and screw me over with today?
Microsoft always went above and beyond the call of duty to support hardware and software (with runtime code modification and more). This allows programs should have failed epically to run flawlessly on everything from Windows 95 to Windows 7.
If Android even attempted a fraction of what Windows did, fragmentation would not be a problem. Android is a perverse mix of Apple and Microsoft though. It's a pain in the ass to maintain products for Android and it's even worse for iOS.
> This allows programs should have failed epically to run flawlessly on everything from Windows 95 to Windows 7.
The "upgrade through every version of Windows" videos show Reversi and MS-DOS Executive running on Windows 8. You do have to run 32-bit Windows, though, to get 16-bit compatibility.
I know there were a couple of pretty significant glibc upgrades, and IIRC the binary format changed at some point from something earlier to ELF. Hrm. "something earlier" seems to have been the a.out format, based on Eric Youngdale's 1995 Linux Journal article:
While the kernel developers never break compat, userland developers are much happier to, which leads to all sorts of issues. Even if your a.out file is statically linked, it might depend on a service that's since been replaced.
This is why when it comes to old (2000 era) Linux games, it's much easier to just run the Windows version in wine than to go through all the hoops to gather old libraries and get the sounds working.
Old Linux games use OSS, which you may get to run. They may also require obsolete Xfree extensions for direct framebuffer access, which the modern hardware will not allow though.
If you are extra unlucky, they may require direct console framebuffer access and unless you have also the old hardware with old drivers, you are going to get it on modern system.
>Apple's utter contempt for backward compatibility is why people who care about their sanity hate developing products for OSX. Which API is Apple going to deprecate and screw me over with today?
You mean like they countless new API versions and frameworks that MS introduces year over year as "THE" way to write Windows programs?
Sure, they might retain binary compatibility, but if you want future-proof your stuff and continue to get updates and changes you have to jump to the new shiny.
This is compounded by the strange fact that Microsoft's own development tools produce programs which you cannot give to other people to run on a standard Windows install.
If I compile on Linux, I link against libstdc++ version du jour and the binary will just run on a recent distro. If it doesn't you end up in the same spot - you need to install the appropriate .so version, but most of the time things just work.
So Microsoft's stuff links against a system DLL, but I'm not allowed to do that because they can't guarantee full backwards compatibility, so they give me explicitly-numbered DLLs to link against. So why aren't those part of the standard install? It comes on a DVD! It has gigabytes of stuff, surely a few megabytes more won't hurt. It even comes with the .Net runtime and you'll get the latest one pushed to you by Windows Update. It's almost as if they want to push people towards writing C# instead of C++, which due to being a managed language doesn't end up in the situation where you're writing to strange private struct fields... oh...
Just imagine you're linking against the MSVC10 runtime and want to distribute your program to people who run Vista. How could the runtime even be part of the system? It didn't exist back then.
So you have to bundle your dependencies anyway and you need to do that with everything else you use as well. The OS does nothing else: It ships with the dependencies it needs. If there was no program in a standard Windows install that used the C++ runtime (very unlikely, I know), there probably wouldn't be a C++ runtime distributed with it (well, apart for that pesky problem Raymond acknowledges where people link against DLLs included in the system that are not system DLLs – probably the same reason why the VB6 runtime is still part of Windows).
So why do I need to distribute it? Why can't it be part of the standard install machinery "oh btw my program needs MSVCR10.DLL be a dear and fetch it from Windows Update"? Heck, this could be embedded in a manifest inside the .exe - "I need these MS libs with these versions" and when you double-click Explorer could parse that, check that those are installed and if not launch a "this program requires additional components installed from Windows Update, please wait".
And I don't want them to ship future versions of the runtime that don't exist yet, just the current ones. So when I build a .exe and give it to someone on the same OS they can run it.
What's bizarre is that it's easier to create a .NET program that runs on every supported version of Windows without having to worry about installing the prerequisites.
Simply compile to .NET 3.0. You can do this even on Visual Studio 2013. The resulting program will run on Windows Vista and Windows 7 without any install. It will also run on Windows 8 and 8.1, which bundle .NET 4, because Windows will automatically install .NET 3.5 when your program attempts to run.
This scenario doesn't work for Visual C++ programs. Each new version of Visual C++ ships with a new runtime library, and it's neither bundled nor automatically installed by Windows.
In other words, .NET executables are more portable than Visual C++ executables! Talk about bizarre.
They could set up Visual Studio to not compile code that does X, so that current binaries that do X still work, but you can't ship any new versions of your product until you stop doing X in it.
This is why I'm against the commonly praised "Be conservative in what you send, be liberal in what you accept" principle. Being liberal in what you accept only gives you compatibility nightmares in the future. Another perfect example of this is html and is the reason why every browser has to reimplement all the bugs of internet explorer 6 in order to not "break the internet". Really, why should a browser try to correct a corrupt document with trailing tags and open attributes. Beginner developers/designers will simply think "looks good on my machine, deploy and forget" and then we are stuck supporting that kind of corruptness forever.
"But, of course, if that had happened, maybe the web would never have taken off like it did, and maybe instead, we’d all be using a gigantic Lotus Notes network operated by AT&T. Shudder."
I'd even go as far as to suggest the opposite "be liberal in what you send [1], be conservative in what you accept (and fail as noisily as possible)".
[1]: by this I mean that it's ok if your "liberal" output (by "liberal" I usually mean "assuming newer features not yet widely adopted in other apps it needs to talk with") forces the user to upgrade other components to the latest versions in order to use yours, because if you're in a choice of "f_g the downstream guys" or "making trouble for the upstream guys", you should always choose "f_g the downstream guys", because here "f_g" them only means the minor inconvenience of forcing them to upgrade to decent versions and moves everything forward in the process, and has the added side effect of forcing them to also do their damn security upgrades :)
You must be my doppelganger, because I've been saying exactly this for some time. Internet Explorer caused so much trouble partly because it accepted so much bad HTML. It would close tags for you, even.
IE didn't start that, it had to accept that shit because everything else did long before it. I'm not even sure what browser started it. I'm positive that the first graphical browser I used (Cello) did, though.
I'm not even sure it was really considered a bad thing at the time.
P: Paragraph mark
The empty P element indicates a paragraph break.
The exact rendering of this (indentation,
leading, etc) is not defined here, and may be a
function of other tags, style sheets etc.
To whit, the well-formed, "good" example:
<h1>What to do</h1>
This is a one paragraph.< p >This is a second.
< P >
This is a third.
Yes, with spaces and alternating case. This was the standard before
IE6 came out, so it's not that crazy that they closed up some bold and
italics tags -- I'm not entirely sure if there were (are?) any other
SGML dialects that were quite as loosely defined as early "HTML" was.
I think IE6 did a lot of awful things, but the only real "damage" done
was in borking the CSS implementation (especially the box model). The
fact that it rendered crap HTML sort-of-ok wasn't all that bad.
It was the crazy things it did with, lets say.... specially crafted
HTML that led to a lot of problems. And MS FrontPage's insisting on
adding COLOUR="#000000" (black) to all documents, and assuming
BACKGROUND was set to white did a lot to break semantic mark-up.
Oh yeah, I'm not saying IE6 didn't do a lot wrong, just that this wasn't one of them.
But I also think it's worth remembering that IE5/6 also featured a lot of early experiments in things that are now considered essential components in the web. XMLHttpRequest was a huge advancement, and while ActiveX was obviously crappy it was at least part of an attempt at creating a more dynamic web.
The automatic tag closing behaviour is even specified now.
But look at it another way: imagine browsers accepted only valid HTML and every browser had some bugs in what they consider valid. Writing a document in a way that it displays at all might be a challenge already then. Add to that that not everyone is on the latest browser version (that was probably more true in the 90s as well) and you get all the current pains just with worse symptoms. I'm not really sure that's better.
I may be wrong here, but isn't implicit tag closing consequence of html deriving from sgml? mandatory tag closing is something that came with xml AFAIK
Yes, but then nobody implemented the SGML definition of HTML correctly. According to the standard, browsers should have parsed
<a href=foo/bar/baz>qux</a>
as
<a href="foo">bar</a>baz>qux</a>
since it did not only include optional closing tags, but also short tags. (This is incidentally why several SGML-based HTML validators used to complain about "end tag for element A which is not open" in the presence of href attributes without quotes.)
IETF groups continue to perpetuate this junk, too. It opens up security holes, as you can end up with a "confused deputy" situation. A proxy might read certain header fields one way because the spec encourages the proxy to "infer" the "meaning" of creative headers. But a server behind the proxy might interpret things differently.
I love Raymond Chen's old new thing, also Mark Russinovich's SysInternals - because of these two (and real job involving Windows) - I actually enjoy it when I can solve the next "weird" windows problems some of my coworkers would have (but then again I don't know as much as I wish - but it's fun time overall).
And while I disagree with Raymond on the MSVCRT.DLL topic, I can also see his point (and I might've took it, if I was working for Microsoft)
This is why it's a bit of a blessing that webapps can't do much; because the more powerful they become, the more annoying and inane they will be.
They can already do enough. My browser could be "my agent on the internet" but instead it's become "in control of the enemy, something I must neuter" to stop some website owner from ruining my computer's context menus, clipboard, playing unwanted sound, downloading and playing/displaying unwanted noise or adverts, taking me away from pages I was looking at, intercepting my mouse clicks and neutering them.
None of these things should ever have been at the control of the website.
This is part of what's driving the rise of feudal app store models. Users like them too-- at least most users who aren't concerned with (or don't understand) things like openness and freedom. They prune the ecosystem of shitware to at least some extent.
Personally I think OSes need to evolve toward a model where apps are more strictly containerized, something like Docker (Linux) but for everything. The user should still be able to admin their own machine, but this permission should be forbidden to apps without explicit user approval (and a big red warning).
That's the way OSX is RIGHT NOW. As a User I can run any program I want and mucky-muck my crap up. But Apps from the Mac App Store live in neat little bundles and are forbidden to do the mucking around in OS bits. So the OS is an "appliance" that I can just replace at a whim. If I go off the tracks to load apps that NEED to overwrite OS space, then I know who did it.
Personally, I but App Store versions whenever possible and I have next to zero problems with my Macs an order of magnitude less than my locked down PC at work even. VERY few apps need to color outside the lines and I like the push for them to explain themselves or get blasted by the next OS update.
I wonder if we will see app stores move more towards the package manager model we see in most Linux distros, where users can easily add third party repositories, remove first party repositories, and have dependencies handled automatically.
If anything, Windows' level of backward compatibility is a giant cautionary tale: enable poor behavior from devs, and it will proliferate. You cannot trust app devs to do the right thing, they need to be forced to; whether by gatekeepers at app stores, or OS restrictions. It is a tragedy of the commons. Whether it's inane programs inserting themselves into the systray, 'preloaders' for bloated apps (which slow startup), browser extensions, Explorer add-ons, or other garbage, app devs still seem to do a fantastic job of gunking up a Windows install.
This is why it's a bit of a blessing that webapps can't do much; because the more powerful they become, the more annoying and inane they will be.