Hacker News Reader

Comment by ryandrake | Hacker News Reader

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.

View on HN

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.

You can still run honest-to-goodness PC DOS 1.0 .com files from 1981 designed to run on the original PC out of the box in 32 bit windows 8.

You can run a.out files from 1992 on Linux too, so what.

Without recompiling or hunting for old libs?

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:

The ELF Object File Format: Introduction

http://www.linuxjournal.com/article/1059

Yes, without recompiling. That's the point, a.out is a binary format and if you recompile with current toolchain, you will get ELF.

You will need the original shared libraries and linker, though. They will run.

Thanks.

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.

AFAIK, Android has never broken it's public API.

If you hacked it and used internal APIs, you were warned - it is all over the documentation and mailing lists, that these are going to change.

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

Reply on news.ycombinator.com