Hacker News Reader

> Microsoft breaking compatibility, more-so post Windows 7

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.

> The extent of user application backwards-compatibility is impressive, with only Windows 10 removing 16-bit application support (boo)

It's still supported on the 32-bit versions of win10! It has never been supported on a 64-bit version of windows though.

That raises several questions for my next team meeting...

Well, it does. I was told one thing and reality is different. I'm supposed to trust other members of my team rather than fact-check their input.

> Windows 10 removing 16-bit application support (boo).

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.

Not exactly true.

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.

There's also the option to transition to 32-bit protected mode and then go to virtual 8086 mode from there. Or to simply emulate the entire CPU. It was probably just a cost-benefit trade-off in the end.

Yeah

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)

So why is 16bit execution supported on Windows 10 32bit but not on Windows 10 64bit or even Windows XP 64bit?

It seems to be this:

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

Windows 95 still booted through DOS, pretty much any application that could run on 3.1/3.11 could run on 95, you could run Windows 3.11 from within 95 if you wanted too.

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.

IMHO, the single big break of backward compatibility was between windows XP and Vista 64.

What exactly did break? I can run 20 year old software on Windows 10 without resorting to emulation.

I would argue the most relevant example here would be Visual Fred (aka, Visual Basic .NET), the saga of Microsoft throwing people who had relied on Visual Basic 6 under the bus; for more on this topic as it relates to Python 3 and Ruby 1.9, I wrote a comment a month ago that contrasts.

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

> the saga of Microsoft throwing people who had relied on Visual Basic 6 under the bus

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.

[0] https://msdn.microsoft.com/en-us/vstudio/ms788708.aspx

The real reason why Microsoft had to drop VB6 is because its object model was fundamentally incompatible with .NET. VB6 was a very thin wrapper around COM, after all. That C# happens to be technically superior to VB6 in most (but not all) respects just provided Microsoft with a convenient excuse for deflecting criticism.

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.

It wasn't even just COM, it was specifically OLE Automation.

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

> 64-bit compatibility was never going to happen,

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

Given the macro engine in Excel is VBA (basically VB6) I suspect VB6 support will be around for a VERY long time.

I think another example was by joelonsoftware, where when MS moved to win 95, they actually ran popular software looking for bugs, and found the SimCity would use-after-free (which, before 95 wouldn't crash), so they modified their OS to leave that memory cell intact even after free.

They do this kind of stuff all the time[0], and it provides enormous value to users.

[0] https://blogs.msdn.microsoft.com/oldnewthing/

They do it to this day. Application compatibility assistant or whatever its called now runs on every single machine and hot patches loaded programs. Malware authors love it.

https://tzworks.net/prototype_page.php?proto_id=33

And now we're stuck with decades old software and API stacks while Metro/Modern UI/UWP struggles to take off since about 5 years.

The day MS depracates WinAPI, they're control of the desktop is over, as every company which develops huge codebases will switch to an environment where their programs doesn't have to be rewritten at MS's discretion.

Is there any platform an enterprise could switch to that would guarantee a slower rate-of-change than Windows? "One major rewrite-requiring breaking change in 20 years" sounds like—if not a good deal—the best one I could foresee getting anywhere.

Once you rewrite once, the red line is broken. I think joelonsoftware has an article about that.

IBM (Oracle, too, I would guess).

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.

What platform is that?

Sure they will rather change to a platform in the hands of Oracle,Apple or Google.

> stuck with decades old software

"reap the rewards of mature software"

The issue is that this is only of concern to application developers who don't want to use old APIs. Systems owners, managers, and users won't care if it gets the job done predictably and cost-effectively. And if the vendor is willing to keep that stack around and support it...

There was a great talk recently by Rich Hickey[0] about how change itself is breakage. Breaking early and often is catastrophically worse than python 2.7 in my opinion.

[0]: https://www.youtube.com/watch?v=oyLBGkS5ICk

Agreed. Hickey, in that talk, claimed if you really did break backward compatibility, you should just name it something else. So in real terms Python3 should have been renamed to Pythonidae or something like that. Eventually the last folks working in the 2.7.* branch would notice that nobody else was in the room and hopefully figure out where they went.

If you look at long-running, successful projects, they don't do this.

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

I feel like the only responsible thing to do in such cases—if you truly believe that the thing you're abandoning is just a plain-old failure of engineering, and it's effectively self-flagellation to be subjected to maintaining it—is to poison the well/salt the earth when you leave, so that people are at least forced to switch to something else, if not your replacement project.

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?

Google has begun building "time bombs" into Chrome that will start inconveniencing users once the binaries reach a certain age without being updated (I believe this is specifically related to certificate validation, but I'm not going to look up details because I don't want to be put on a watchlist for googling "chrome time bomb" :P ).

https://bugs.chromium.org/p/chromium/issues/detail?id=664177

Is the watchlist for googling it worse than the watchlist for writing it?

Nah, I was just on my phone and needed an excuse for my laziness. :P

I disagree. Python 2->Python 3 was not really a huge change. It seems that the Python 2 userbase is finally starting to dissolve but IMO the holdouts were mostly doing it for philosophical purposes. Renaming the project for Python 3 would've resulted in a massive decrease in useful searchability, history, etc, when really only a small handful of backward incompatible changes were at stake.

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.

It's hard to collect money for a rolling upgrade. This was the pre-cloud era and you sold products. With Windows 10 that's changed and it looks like they found a way to monetize user data also.

Here's an example of Microsoft Office killing off backwards compatibility for some older document formats:

https://tech.slashdot.org/story/08/01/01/137257/office-2003-...

They've dropped support for 15-16 year old file formats with a workaround in place....

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

Even assuming conversion works flawless, I don't think full migration is possible.

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.

That's true if you do the conversion after 20 years, but again what exactly are you advocating here that we should support 20 year old binary formats?

>Arguably one of the most successful companies in the world is Microsoft. The reasons for their success are many, but at least one is the focus on backwards compatibility.

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

Does this mean most OS X applications or drivers break when OS X is updated, and have to be recompiled or have is source code updated or re-written ?

No, it just means that Apple breaks backwards compatibility much more often (for PowerPC to Intel transition, for 32 to 64 bits, drops Carbon, changes APIs, etc). Though what you describe also happens to some apps using certain APIs that need code changes to run on a newer OS X.

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

Backwards compatibility can tie you to things that you need to get rid of though. At some point you have to decide to drop support for stuff and move on, otherwise something else that has will come in and eat your lunch.

I feel like you could make this argument about Apple just as well. It's got a larger market cap, so even more arguably successful. And they break compatibility (judiciously) in order to create a better product.

This isn't really true. If Microsoft of 2016 has a focus on backwards compatibility it is only because of their myriad mistakes in the past. I know people have this false impression because of fluff pieces that have been written about Microsoft having a focus on backward compatibility but anyone who has lived through the last 30 years of computing history knows this isn't really true. They have broken backward compatibility numerous times.

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.

Not really arguing with your points, but it seems Microsoft has a lot of lessons learnt from maintaining backwards compatibility.

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.

It's probably all there in their issue trackers. That's partly why software teams track issues, because somewhere there's a decision to be made and a story to be told, and that story is written in the issue before it's closed.

Software development is really all about finishing stories.

While it would be hard to call any kiloperson organization a hero, it is remarkable how people on the Windows team keep old software working even if it does not deserve to.

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.

Maintaining hardware compatibility with any PC hardware ever created is indeed nigh-impossible, so you'll note I didn't even mention that. I only talked about maintaining compatibility with applications written for their own operating system. Something that Microsoft does have pretty much universal control over.

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.

Windows 95 came with a way to configure shortcuts so that they would reboot back into DOS, just to run the program, and resume after you quit.

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.

In addition, I believe there is a large amount of Windows-native software that runs better under WINE than it does under Windows 10.

Edit: am I wrong? See https://en.wikipedia.org/wiki/Wine_(software)#Backward_compa...

I would be careful to trust wikipedia about this, especially if there are no citations.