The Windows Update Marathon in a VM: From Windows 1.01 to XP
winhistory.de
winhistory.de
Microsoft Office 2019 can open .doc files created in Microsoft Office 97 and upgrade them to a modern format, with zero loss (except for things like OLE objects, which are no longer supported for security reasons). My parent's computer has documents which haven't been touched in 20 years and they still open just fine.
Or applications written for Windows NT that still work - unmodified! - on Windows 10 thanks to layers of compatibility hacks. A true feat of engineering.
If you want to read more about the horrors of maintaining APIs that are backwards compatible with software written decades ago, I can heartily recommend Raymond Chen's blog: https://devblogs.microsoft.com/oldnewthing/
Sometimes, change is good, even if it's painful in the short term.
https://arstechnica.com/gadgets/2017/11/microsoft-patches-eq...
Shit! I was playing Stellaris meanwhile I was updating to Kubuntu 18.10
I have!
> Not only keeps working before the upgrade. It allows you to WORK meanwhile the whole OS is upgrading!
Yeah, and then it breaks and trashes my install after the upgrade. Happened to me many times.
Server upgrades are usually smooth (early versions of Ubuntu being an exception.)
The more immediate usability issues mean that I have a clear divide between the OSes I prefer to use for my daily driver (OSX/Windows) vs. the OSes I prefer to use for servers (Linux). With WSL2, the virtualization capabilities are good enough that I pretty much never need to explicitly boot Linux on my laptop/desktop anymore.
My limited experience with Windows dual boot, shitty Windows issues or Bios caused problems.
Do you have a good reason to blame Linux here?
Of course it's still possible that on my particular configuration it's actually Windows doing something dumb that makes grub.conf changes necessary. However, it's (1) well documented for years, (2) an issue that the Linux (distro) installer creates, and (3) an issue that still gets recreated on every update that mysteriously reverts my grub.conf changes, so Windows gets the benefit of the doubt and Linux doesn't.
That's been my experience in general with desktop Linux: I have never experienced a Linux distro where I didn't have to get into the weeds to fix up a clean install, even when Linux is the only OS on the system.
I only booted into Windows a couple of times (to keep it up to date) but I never ran into any problems with dual booting.
Ubuntu has its problems, especially Gnome works but I hate it's dumbdown, also high density screens work but have issues.
I still far prefer Linux to Windows.
Office 95 can run on Win10, with only a little difficulty:
As if that isn't already discussed to death around here or elsewhere. I see far more disdain for Microsoft than I do any praise at all. And while I'm not particularly happy with Microsoft either, I'm still able to appreciate the good things that they do.
(2) Microsoft Works (at least the version we had a license to) definitely does not run on modern Windows. My dad's business is forced to keep a Windows XP VM alive, in order to keep running Works Database, because as I mentioned, there's still not a migration path to anything for it.
I should be able to fire up a BASIC script from 1970 and have it still run. It shouldn't require me hours of hunting retro-computing websites for the right simulators - it should just be part of the OS.
I don't care how - whether that be emulation, or maintaining direct compatibility.
A set of emulators for all ancient computing platforms only comes in at a few megabytes, so there really isn't an excuse not to include it.
Why you say? Two reasons: 1. maintaining backwards compatibility isn't hard - you just switch to emulation every time you want to 'get rid of cruft', and then what happens inside the emulated container can be frozen in time and requires no maintanance. 2. Every time one breaks a legacy bit of code, all the users of that code have to do some work to re-invent it. It would be like shredding Leonardo da vinci's work just because we have better painters now.
I legit see more Microsoft stuff all around, Linux stuff close second.
Mac actually took great pains to be backwards compatible until relatively recently. PPC's could run 68k programs, OSX could run tradition MacOS programs, and x86 macs could even run PPC programs.
And Linux Desktop can't run programs not in its repo unless you want to compile it from source.
So what does that tell us? Well, there at least appears to be a pretty strong correlation between compatibility and success with desktop OSs.
In my opinion the biggest short term threat we have at the moment isn't the popular document file formats (though that is a long term threat) but content posted exclusively online. Web standards are constantly evolving and any given website would have a multitude of files -- many of which wouldn't even be hosted on the same domain as the HTML endpoint, which itself is most likely dynamically generated. Plus our local copies of web content is just a temporary cache that routinely gets flushed so once it disappears from the web it's likely gone for good (web archive aside).
I'll be more worried about classic file formats when computing undergoes it's next paradigm shift away from personal computing (arguably that's already started happening with smart phones and cloud computing).
> Being retro-compatible in a walled garden only doesn't make all that sense.
It makes perfect sense from the company's point of view.
> It makes perfect sense from the company's point of view.
Yeah, for sure, but I was criticizing OP that was praising MS for still being compatible with their own 20+ years old proprietary and hegemonic document format.
https://support.office.com/en-us/article/equation-editor-6ea...
https://arstechnica.com/gadgets/2017/11/microsoft-patches-eq...
Fast forward multiple upgrades of Office it still works to this very day! You just have to keep ignoring the scary self-signed certificate warnings. ;)
I'm a die-hard Linux guy, but credit where credit is due - Excel is awesome.
Windows can run the previous version of Office. But running the current version, alongside say, Office 2007, is a major pain in the ass.
Maybe you just need to run the old version of Outlook, because your IP phone system or ERP software has some plug-in that was never written for the next version and isn't compatible.
Maybe you need to run a version of Access that's so stinking old that you have to use Windows XP in a VM.
Now, to make things worse, the database connectors for that version of Access are so outdated, that it's holding the entire company back on MySQL 5.5 because if you upgraded, your Access application wouldn't work anymore.
Not to mention, all that code you wrote 20 years ago in VBA is insecure as all hell. Unencrypted connections, ripe for SQL injection, plus that version of Access can't work with large datasets or return large results. Dammit!
I'd rather have planned deprecation and make choices to (at some point) abandon certain APIs, features and formats. In the case of formats, a public release of some parser code would be nice, so that if someone really wants to get some old data, they can, but other than that, stagnation isn't as good as people make it out to be.
As for "...means it hasn't been maintained for 20 years..." - the OS did maintain the old API's and the way they behave to make sure old software that uses said APIs still works on new OS. Does not mean that the new APIs were not developed.
Some things don't need intensive maintenance, and it's a bad thing to force it for unnecessary reasons. Backwards compatibility can often be understood as 10 vendor engineers performing maintenance effort so 10,000 customer engineers don't have to. It's a massive productivity win for society.
I'm a software engineer. I hate working on ancient codebases as much as the next guy, and I personally benefit from the constant make-work of re-engineering. But, as a customer, I'd rather invest my time and money to solve new problems, rather than spend it re-solving old problems.
The code and APIs will never be "perfect," and many processes change little.
Also, it's a little ambiguous who's code you're talking about: the customer's or the platform's? If a platform that maintains backwards-compatibility is an achievement worth celebrating, because it saves loads of effort across society and give people access to software who might not otherwise be able to afford it. If a platform breaks its customer's code because it's chasing after API perfection, it's kinda abusing its customers.
The theory that a platform as 'backwards compatibility' is only good for lazy developers and lost source code. And yes, not doing maintenance saves time, but so does not upgrading your platform. I mean, if 8 inch floppies work for nuclear installations, OS/2 works for subway passenger systems, and Windows 3.1 for radio servers and other flight control systems, might as well not maintain anything at all. Heck, why not use relay logic in the subway control rooms.
I think the issue here is that you're viewing this as too all-or-nothing. If the OS/2 subway software is well-tested and does everything it needs to do, what's the benefit of spending $10 million rewriting it or paying a guy to keep up with platform changes? If IBM (or whoever owns it now) keeps maintaining OS/2 so the software can run with little to no modifications on new hardware (since hardware fails), good on them. There's probably 1,000 such systems, and that's $10 billion in savings for society.
That doesn't mean no software should actively be maintained, a lot of it should. It also doesn't mean that working old systems shouldn't sometimes be replaced or upgraded. But it does mean backwards compatibility is important and shouldn't be dismissed.
https://www.microsoft.com/en-us/download/details.aspx?id=542...
Cheap bullshit, not technical limitation, is at the heart of this level of "compatibility" issues.
The ability for an application (eg, Office) to install side-by-side with other versions of itself is entirely different than its Backwards Compatibility (eg: ability for current versions to open and/or save Office 2007 format). In fact, because of the latter, provided they did a good job at it, the former is arguably irrelevant.
I'm not familiar with Office/Outlook/Access's APIs and their history of backwards compatibility, but given that Microsoft usually does a good job with BC, I'd tend to suspect the other vendors (IP phone/ERP software) are at fault. In my experience, there's a good chance the only real incompatibility is with the vendor's installer or some version check that prevents it from working, as opposed to really not actually working, say, because Microsoft removed some API they used.
The rest of what you're talking about really points to some other disfunction, or bad or unlucky decision.
Did you buy an IP phone system expecting 20 years of use from it? Why can't you get updates -- is it because you don't want to pay for maintenance, or did they go out of business?
The cascade effect you're talking about here though highlights something else: So many companies do things they think are saving money, but actually cost them more.
For example, they can't go to the latest IP phone software, because they need to buy a hardware upgrade that will cost $x, so it means they have to use old version of Access that uses old MySQL which means other development team spends $y extra working with that version (or paying for custom dev for other products to work with it, etc). Did anyone actually evaluate which is larger? The decision to "save" $20k on a phone system upgrade could easily cost $50k or more for several months of a developer's time.
I am still somewhat surprised that Windows doesn't have a Docker-esque sandboxing system to solve this problem (I mean, it has Docker, but it's based on a full VM). I suppose in the third-party realm at the very least you have Sandboxie, but meh...
Starting with Office 2016 (maybe 2013) App-V from MS does precisely what you describe and it doesn't require any sort of classic virtualization component to be accessibly by the OS or hardware.
See: https://en.wikipedia.org/wiki/Microsoft_App-V
The tech is there. Usage is a different story.
I'd call that more "stable API" than anything else --- Win32 is Win32, and while they've added functionality over the years, the basic stuff remains the same.
A document file that can still be read decades later should be the norm though, and Office 2019 needing to 'upgrade' them is less than ideal.
At that time I think people already smelt that important docs would need to exported in something else (ex. PDF) just in case MS changed its mind about how text or layouts would work.
But I can see how the conflicting requirements to keep the upgrade treadmill rolling and never break any old apps have made certain versions of Windows into such unholy piles of kludges.
These are still used in the newer XLSB format[2].
[1] https://www.loc.gov/preservation/digital/formats/digformatsp... (Page 14)
[2] https://docs.microsoft.com/en-us/openspecs/office_file_forma...
It was far from bug-free though.
Pre-XML the .doc format was just the in-memory representation of the document serialised to disk and loading it was the converse. Conceptually you could imagine it like mmap(). It was different between versions because the code was different, not by any deliberate effort.
Another comment here points out that word emitted tags for forward compatibility reasons. That's still true - I've had reason to parse OOXML directly and see those tags. I guess it sometimes isn't enough.
They are now at a point where they have to base their browser on a rival’s engine, their developing a mobile device based on Android and their own cloud platform hosts fewer Windows instances than Linux instances.
Google supposedly didn't support windows phone, in part, because they were upset that they couldn't use the wince apps as a base.
IE's backwards compat method was to simply embed the old version of the engine, and use it as necessary. That's not really a factor in the many reasons people mostly use IE to download a better browser for personal browsing, but is a major factor in why it was the corporate browser of choice for decades: it is expected to be able to continue to work the same way on a long term basis.
Windows vs Linux usage rates on servers is mostly a statement of Linux is at least good enough, and a good enough solution with simpler (no) paid licensing is a clear win for ease of use. I haven't seen any Linux vs Windows server performance benchmarks in a long time; I'm assuming they're not that far apart, outside of whatever bits and pieces that either platform is truly bad at.
I was a WinCE developer - both .Net and MFC. Trust me, no one wanted to use WinCE for anything. Besides, MS abandoned WinCE with VS 2010.
I can’t speak for performance, but the resource requirements for Windows is huge compared to Linux and that really makes a difference in cloud environments when it comes to price (even excluding licensing cost) and startup time - that makes a difference when you need elasticity and to scale up and down fast.
You can do a lot with a 128MB/.25 vCPU Linux instance. You can barely get away with a 4GB RAM Windows instance with 1 vCPU.
Well, maybe nobody wanted to, but to support a new platform with unknown uptake, would you rather use your existing code, write something new on a less capable api[1], or just walk away?
[1] well, a lot of wince stuff was still there on wp7, if you were willing to do terrible things in order to get available features that weren't exposed.
They introduced a special mode for the memory (de)allocator that allowed a (disallowed) pattern that SimCity used and that no longer worked with a new change, and used this mode when SimCity was running.
Ironically, Google Docs (Which was, for obvious reasons, not my first choice for opening an old Word document) parsed it in exactly the intended format.
I totally agree that Microsoft maintained compatibility to the point of breaking good engineering practices. But shouldn’t gcc/jvm count as programs too? And code developed for those program still runs assuming same input. It’s much more impressive with Microsoft because they are GUIs but functionally I think they’re pretty much the same.
I believe that periodic clean installs of OSes are not necessary anymore and every modern OS install should survive hardware changes and upgrades to newer versions.
Servers, though, are a completely different story. Servers are like cattle, but personal computers are like pets.
Probably because I know I will reinstall not too long from any point in time I just install everything I think I need. I need to convert an IMG to ISO? Let me just try these 5 apps and forget about them. They will be cleaned after the fresh install anyway.
To go from the DOS based Windows (95, 98 and ME) to the NT based Windows versions (Windows NT 4, Windows 2000, Windows XP) required a fresh install.
Update: Actually, I was wrong: XP could update from ME - as seen in the OP.
In Win9x/Me, the core of the OS (the VMM) is 32-bit (which was true even in Windows 3.x in 386 Enhanced mode.) But, some other parts of the OS remained 16-bit code, and 32-bit apps will sometimes end up invoking 16-bit code via thunks when calling OS APIs.
By contrast, NT-based Windows, a 32-bit app will never invoke any 16-bit code. The only scenario in which 16-bit code would ever run would be when running a legacy 16-bit app.
(Someone please correct me if I'm remembering this wrong.)
However there were commonly used built-in dos utilities that were 16bit so if you called out to any of those then obviously you would invoke 16bit code.
By contrast, Windows NT doesn't support 32-bit processes loading 16-bit DLLs, although it does support the reverse (16-bit processes loading 32-bit DLLs – "general thunking")
http://rgmroman.narod.ru/flthunk.htm
I'm not sure how widely this facility, of loading 16-bit DLLs into 32-bit processes, was used. I thought, Microsoft actually used it internally in implementing parts of Win95, but I could be misremembering that.
I believe much of this was already in place with Windows 3.1(1)'s 386 enhanced mode and Win32s, although from memory Windows 95 moved far more device drivers into the 32-bit kernel. Presumably this was enabled by not having to be able to end the windowing session and quit back to DOS without rebooting.
[1] I seem to remember CD-ROM drive controller drivers being particularly common culprits in this regard, with virtual mode device drivers often being unavailable, so you had to use real mode drivers in config.sys even on Win9x. Yes, back in the day of single-, double-, and quad-speed CD-ROM drives, you typically had an ISA card with a custom controller that then connected to the CD-ROM drive via an "I can't believe it's not IDE" ribbon cable. Only later did we get ATAPI and hard drives and optical drives could use the same controller and bus. (Sound cards often had an on-board CD-ROM drive controller and ribbon cable connector around that time.)
The original "It's now safe to turn off your computer" screen after shutting down windows 95 is actually just a dos prompt.
You cannot see it, because the computer was left in a graphics mode, but if you can blindly type a command to switch graphics mode you're back at a normal DOS prompt.
IIRC it was more than just data structures and that other chunks of GDI were 16-bit, in part due to problems with 32-bit driver support for graphics hardware at the time.
True story, last week I tried to update Windows 10 v1803 (preinstalled) on my dinky ASUS VivoBook E12 to v1903. The result was a seemingly endless "Reverting changes" bootloop that I haven't gotten around to fix yet.
Deploying Windows 10 to users from Windows 7 has been a lot less hassle than XP to 7 in my environments, and I haven't heard different stories from other admins.
Apparently, according to Wikipedia: "Although Windows 9x features memory protection, it does not protect the first megabyte of memory from userland applications. This area of memory contains code critical to the functioning of the operating system, and by writing into this area of memory an application can crash or freeze the operating system. This was a source of instability as faulty applications could accidentally write into this region and with that halt the operating system"
As it was aimed exclusively at home users, various features aimed at enterprise (but often desirable to power users) were stripped out or broken.
I think you can probably get from ubuntu's release to current. But I also happen to know they 'supported' upgrading from Debian to warty warthog. And I've done a few Debian OS upgrades, so that's also doable. Possibly all the way back to 1.1 released in 1996. Can you upgrade from something else to Debian?
But not without pain, I've almost always needed to manually intervene and fix configuration files. So you need root shell.
Fun stuff. My first thought is the time I was installing Windows 9x from floppies and one of thirty-something were bad...
Considering how much I fresh install things, I really had no idea that you could upgrade all the way from 1 to XP.
Would be cool to produce some files in the first Windows like a picture in Paint 1.0 and then upgrade it again and again.
Yes, all Windows 10 editions are availables in 32 or 64bit.
https://www.groovypost.com/howto/enable-16-bit-application-s...
Getting 16-bit on 64-bit Windows takes a little more work:
https://medium.com/hackernoon/win3mu-part-1-why-im-writing-a...
https://github.com/otya128/winevdm
It can be installed systemwide to get almost seamless support for 16bit Windows apps.
I find it frustrating to not have an operating system that has the polish & coherency of macOS on non-Macs, and that’s one of the biggest reasons why these Mac people (myself included) doesn’t even consider moving out of macOS.
Microsoft might need to add something like a legacy control panel which only appears if you install an old app that adds something there. Users who don't use old apps wouldn't see it, so no harm done versus dropping support completely. And, I don't understand why Microsoft couldn't integrate those panels into the modern Settings UI, even if the underlying framework and visuals were different.
Yeah, and that means (at least for me) non-coherency of the platform. Why should there be two different settings on one OS, depending whether the user installed the app it or not?
> And even then, there's no reason Microsoft couldn't add a visual update and even integrate the UI into Settings.
FYI: the reason Microsoft can’t remove this control panel stuff is because some legacy apps (mostly designed for enterprise) installs DLLs that adds a control panel item. This is one of the examples where their backwards compatibility drags them to make a better OS.
Then don't install old apps and you'll get coherency. This is much better than outright blocking those old apps for everyone.
> FYI: the reason Microsoft can’t remove this control panel stuff is because some legacy apps (mostly designed for enterprise) installs DLLs that adds a control panel item
If I were Microsoft, I would remove the "Control Panel" as a program the user can open, but keep the underlying framework. Then, if a legacy program adds a control panel item, I'd place a shortcut to that item in modern Settings. It might not be 100% visually perfect, but you'd get most of the way there.
If there's some technical reason Microsoft can't do that (I don't understand how there could be—we're talking about shortcuts), at minimum the legacy Control Panel shouldn't appear until a 3rd party item is pushed to it, and it shouldn't contain any Microsoft settings. The current situation is completely unnecessary.
They did and people got upset. It's a "who moved my cheese" backward compatibility problem for people. People get upset if they can't find that thing they always used and worked just fine.
For a brief while Windows 10 the legacy Control Panel was entirely removed from Search, and there were so many complaints so they backed off and it's searchable again. That's about the only way to find it; at this point in Windows 10 it's not in the Start Menu, it's not File Explorer Quick Access. People have to intentionally find the Control Panel.
People still talk about the COM GUID to the legacy Control Panel as if it were some secret cheat code to Windows, making shortcuts to the Control Panel because it looks familiar and powerful and/or they don't want to relearn anything new, don't want to get used to the all the cheese that moved around in the modern Settings app.
That's literally what they've done, the problem is most of their own systems are legacy!
Fortunately for Microsoft this "issue" has historically resulted in some additional (if uneven) familiarity among Enterprise users, where MacOS is nowhere to be found, though I do concede it's been getting out of hand now with Windows 10
I would like a modernized Windows without all the cruft; one of the reasons Windows apps have such poor quality is that apps don’t need to update their internals, so they just can’t get advantage of the newer features. I’m not sure, but last time I saw the Windows land, win32-based apps HiDPI support is opt-in, not opt-out.
Apple has a great record on deprecating things in a fairly understandable speed, so apps in macOS generally have up-to-date internals with all of the features working consistently.
Most apps use the control-center (compared to Windows where every app reinvents notifications, even with the existence of the notification center added in Windows 10), use macOS tabs, users can define keybindings that work in every Cocoa TextField, etc...
As far as I'm concerned, LTSC is _perfect_. I want security updates, but I don't want the rest of my OS to change out from under me. And, because the security updates are much smaller, they download and install far more quickly.
I miss Windows Phone 10 every day still.
Sometimes I still miss Windows 8, when the Win32 desktop booted late and if you stayed entirely in UWP apps things were wildly clean and Windows ran like a dream. (I also know how many people hated that experience.)
Windows has the "flex" to do it, just not the developer nor the user buy-in.
There's an hope with "Windows 10X" they are trying to "flex" a bit, show people what Windows can do when allowed to limit the legacy cruft. The legacy cruft is all still there though, Microsoft has learned the hard way it's there for good, but maybe there's a small bit of hope that developers might be interested in enough in making first class "10X" applications, users enough interest in the magic of post-legacy Windows UI to try new experiences at least some of the time they aren't using the comfort food of the classic Win32 legacy. Maybe a little hope, we'll see.
> settings app and the control panel
After using Mac, I once decided to explore Win7's control panel on a friend's machine. I counted ten different kinds of windows in there, not including third-party additions. Some of the windows had controls that weren't used anywhere else in the system—iirc it was the side panel with navigation links.
Hearing that MS now made another entire app for the settings, in addition, was a knee-slapper.
Control panel is my litmus test for the quality of a desktop environment. E.g. you can easily see how Gnome 2 stole ideas from Mac, in the good sense.
I like the insane level of backwards compatibility.
When you can run a windows game from 1996 with only a few tweaks, it's beautiful. It's a worthless gimmick, but it makes me pop.