IIRC, there have been several instances of this between releases, less so from the user application perspective, but rather from the driver model.
Windows 3.1 to Windows 95 (16- to 32-bit), Windows ME to Windows 2000 (NT kernel), Windows XP to Vista (UAC etc.) each saw various issues with device drivers.
The extent of user application backwards-compatibility is impressive, with only Windows 10 removing 16-bit application support (boo). For example, even now it's possible to double-click on the application icon at the left-hand of the window title bar to close the application - à la Win 3.1.
> The only mistake Microsoft made was not doing rolling releases
I think they're 'fixing' that with Windows 10.
Windows ME did not evolve to Windows 2000, Windows ME was a consumer/home operating System based on the same branch as Windows 98.
Windows 2000 was a continuation of Windows NT(4) for the enterprise market.
Windows XP was the first OS that unified consumer and enterprise versions on the same branch and moved the consumer version to the NT kernel.
Windows 10 didn't drop support for 16bit applications, it still is supported on the 32bit version like most people said, Windows XP 64bit couldn't run 16bit application either.
This has to do with how the 64bit CPU's work and the lack of 16bit real and IIRC even protected mode.
As for general compatibility you can install Windows 3.11 on a machine and upgrade it all the way to Windows 10 and keep your data as long as you go through 95/98 and Windows XP in the middle.
There are videos on Youtube where people install 3.1, 3.11, 95, 98, 98SE, ME, XP, Vista, 7 and 10 and keep their data and some settings (computer name, user, my documents, and even a quite a few windows settings ;)) and that is actually quite impressive.
It's still supported on the 32-bit versions of win10! It has never been supported on a 64-bit version of windows though.
CPU's in 64bit mode don't support running code in 16bit mode -- Windows 10 (actually 7) didn't remove support, it never existed to begin with. This is also why 32bit versions of Windows can and do still run 16bit applications.
CPUs in long mode (aka 64 bit) do not have the virtual 8086 mode, so the cannot natively execute real mode code. However, the code segment selector can be configured in such a way as to allow 16 bit protected mode code to be executed, the same way 32 bit code can be executed.
Wasting silicon to emulate some 30+ y.o. architecture makes no sense
Intel/AMD could thing about doing a "pure" x64/x32 processor that starts in 32-bit mode mode and leaves everything else to an emulation layer (this could be present on the UEFI only for those customers that are interested in it)
https://msdn.microsoft.com/en-us/library/aa384249.aspx
"The primary reason is that handles have 32 significant bits on 64-bit Windows. Therefore, handles cannot be truncated and passed to 16-bit applications without loss of data."
Even though the IDE isn't supported, Microsoft still supports VB6 applications, and will throughout the lifetime of Windows 10 [0]. As an ex VB6 developer, I find this crazy. Just goes to show how much legacy VB6 must still be out there.
VB.NET got me to move to dot.NET, and then to C#. And I'm a better dev because of it. So you could say it fulfilled its role at least once. And let's not kid ourselves here, VB6 was always limited. E.g. subclassing was almost mandatory for advanced functionality, but would cause the debugger and program itself to crash when it hit a breakpoint. 64-bit compatibility was never going to happen, my understanding is the IDE includes some 16-bit programs which is why it's no longer supported. At some point, you've got to cut your losses. If anything, IMO, Microsoft's continued support of VB6 is sending the wrong message to managers and developers.
That being said, I don't mourn the loss of VB6. It was a truly horrible language, and the fact a whole generation of programmers preferred it over superior contemporary alternatives (e.g. Delphi) doesn't speak well of them. The only good thing about VB6 was its form editor, and that isn't even a language feature.
VB6 Variants were OLE VARIANTs. VB6 strings were BSTRs. VB6 arrays were SAFEARRAYs. Date, Decimal, Currency - you name it, it's all OLE.
And this went both ways, too - e.g. the reason why BSTR is called BSTR is because, well, it's a BASIC STRING... And if you want to add two OLE variants in a C++ Win32 app, with exact same semantics as in VB6, you can (to this day!) do this via VarAdd: https://msdn.microsoft.com/en-us/library/windows/desktop/ms2.... Ditto VarSub, VarCat etc. You can see that this family of functions is very VB-centric actually, because it has VarAdd and VarCat separately (corresponding to + and & in VB); it conflates binary and boolean operators just as VB did; and it has VarEqv and VarImp, corresponding to VB operators EQV and IMP. And yet, it lives in oleaut32.dll...
But it did, more or less. VBA and VB6 are essentially the same thing, and VBA 7 (still used in MS Office) added 64-bit support:
https://msdn.microsoft.com/en-us/library/office/gg264421.asp...
http://www.longpelaexpertise.com.au/ezine/IBMBackwardCompati... has a very good observation, though:
"The reality is that backward compatibility is only possible if there are enough users paying […] for it."
It is the same for Microsoft. If, for example, several big customers would want 16 bit support on x64, I'm sure they would provide it.
"reap the rewards of mature software"
It seems the better lesson is a) keep compatibility for a LONG time; there are finally some old Windows programs that Windows 10 no longer runs; and b) when you do break compatibility, don't make a big deal out of it.
Python 3 probably would've been better if it was just a feature-heavy incremental release that didn't break compatibility. 3.2 probably should've introduced a change that discouraged but still supported the old code style (maybe print a warning any time the file didn't contain a shebang-style header like #!allow_old_style, kind of a simpler reverse-version of the future module), and then maybe 3.8 could finally remove compatibility after the old method has been deprecated and difficult and annoying for 10 years or so. Making a hard delineation between compatibility, while on the surface appearing useful, seem to have a much stronger negative effect in encouraging users to stick with "their" version out of principle than it has the planned positive effect of giving users plenty of time and notice about compatibility breakages.
This seems gradual enough that most users won't notice and there won't be a hubbub, nor an insurrection among users to shun your new iteration for making them do extra work.
Dealing with people effectively, including end users, is very difficult. It takes a lot of patience.
One example is the original V8 dev team that went off to create Dart (AIUI). Nobody followed them and V8 got replacement developers. (But perhaps that was a particularly egregious case.)
Badly-engineered buildings get condemned, and we make it illegal to use them, even if it might benefit someone to use the building in exchange for the (likely not-very-well-considered) risk of the roof falling on them.
What sort of political/social infrastructure would it take to allow someone to condemn a codebase?
https://tech.slashdot.org/story/08/01/01/137257/office-2003-...
The old versions of Word is Word 2 for Windows, and Word 4 for Mac, and Excel 4....
The work around isn't complicated it's long because they gave you 3 methods of how to get the functionality back (the simplest way is to download 1 to 3 self installing hotfixes depending on what files you still need to access, I'm pretty sure they just didn't want to pay royalties anymore for supporting some of the non-MSFT formats nor did they really want to support nearly 20 year old binary formats) and that document has been revised as late as 2011, MSFT dropped support for Office 2003 in 2014, 11 years after release.
Yes MSFT does break backward compatibility once in awhile, but it's usually quite warranted, they offer supported workarounds or exemptions and they tend to break it once in 1-2 decades rather than once every 2 years.
Sorry but giving an example of MSFT dropping support for Word 2 or Excel 4 file formats that were designed probably in the late 80's in 2008 isn't exactly a good example of a company breaking backwards compatibility.
If your organization circa 2008 was still dependant on 2 decades old formats don't blame the vendor, you should have migrated that data, It's like complaining that verbatim stopped making floppy disks, oh noes what would you do?!
I bet archive.org has zillions of files that now aren't easily readable anymore. Do you think it is realistic to expect them to fetch every single copy from storage and convert it? I bet they cannot even find _all_ of them, given that documents may be embedded in mailbox files of various formats, in disk images, in usenet posts, in archives using various obsolete compression methods, embedded using OLE in other files, etc.
Even if they can find them, conversion in-place may not be possible. A file inside some archive file may grow in size, making the archive file larger than the archive file format allows.
For example, a few years after they declared conversion done, somebody could find an old CD and upload an old brochure or logo. A converted version may already be available, but how would that somebody know that that file looks the same? All they have are the files, and they are different.
Except for scale, archive.org isn't exceptional here. Large corporations face the same issue. They likely will bite the bullet, though, keep around some way to convert files for a few years after they declare to be 'done', and accept that some data will be lost after that.
Well, Apple is another very successful company, and follows the exact opposite model.
So, the empirical data support both approaches (if the goal is being a succesful company).
We weren't talking about MS satisfying that basic level of compatibility (that Apple usually satisfies as well), but much much increased levels (which Apple doesn't).
Many, many DOS programs would not run under Windows 3.1, necessitating users to boot into or exit out into DOS to run those programs, and of course Windows programs could not run under DOS.
Windows 95 generally did better at running DOS programs but it was far from flawless. Many programs required all kinds of workarounds and even patches.
Windows NT was originally a complete departure from DOS and Windows 3.1, 95, etc. only later on did Microsoft realize that they needed a compatibility layer for NT to ever go mainstream (along with a rebranding.)
Windows Vista broke tons of stuff too. Including everybody's printer drivers. When Vista was released you could buy a Vista computer along with a printer which had no drivers for Vista and which HP would tell you there's no Vista drivers ever coming.
Windows 8 may not have broken execution of Windows 7 apps but the entire UI was a complete shift from what users were accustomed to. Whether you liked it or not, that kind of major change is a big mistake when so many of your customers are tech novices who are not going to have an easy or enjoyable time learning how to use their computer from scratch.
This is just scratching the surface. My point is let's tell the truth here, Microsoft is not some hero of backward compatibility who has never made a mistake and always kept their users at heart.
The most accessible documentation of this is Raymond Chen's blog. For example here's a piece written in 2007 about Windows 95 and DOS: https://blogs.msdn.microsoft.com/oldnewthing/20071224-00/?p=...
While the herculean task of billion-device compatibility has not always gone off without a hitch, the idea that the past was all gaffes and trial and error at Microsoft does not ring true if you read the above blog from one of its more prolific public writers.
The only mention I made about devices was regarding the printer driver issue with Vista, which had nothing to do with the devices and everything to do with Microsoft totally redoing their printer driver implementation on the OS level. It necessitated all drivers be redone and some manufacturers (like HP) took the not very admirable path of telling customers they were up a creek.
I call that going the extra mile.
I remember the shuffling you had to do to make enough extended memory or expanded memory (depending on the program) available. It was no small feat to be backwards compatible with programs interacting more or less directly with the BIOS and with custom routines for individual makes of add-in cards. Successfully shifting that whole ecosystem to a fully protected mode, preemptive environment over the course of 6 years or so (from 95's first release to XP) was probably the most impressive software migration we've ever seen.
It'd be wonderful if their architects collected and codified these somewhere, ie "we did X because of Y, it didn't work, because Z ends up happening"
Mostly as a lesson for the rest of us not to fruitlessly repeat.
Software development is really all about finishing stories.
Edit: am I wrong? See https://en.wikipedia.org/wiki/Wine_(software)#Backward_compa...
As developers we know it is painful to maintain backwards compatibility, but it's incredibly valuable. It builds user confidence in your products, and most importantly it builds user trust that upgrading is safe and thus encourages adoption of newer versions of your software/libraries. The only mistake Microsoft made was not doing rolling releases. Major updates are slow and scary, so even though upgrading to a new version of Windows didn't mean loss of compatibility, it was never "easy" and always jarring.
Backwards compatibility, automated testing, rolling releases. That's the magic bullet to keeping everyone happy and on the latest updates. If your users have to think about version numbers, you're doing it wrong.
* Yes, there are instances of Microsoft breaking compatibility, more-so post Windows 7. The point is that they tend to focus on it, and they get it right 97% of the time which is a technological feat.
See the Rust programming language for a great example of this recipe.