Fun fact: Microsoft has maintained backwards compatibility so effectively that the utilities that shipped with windows 1.0 (notepad, calc, etc) will work on recent versions (search for 'man upgrades windows 1.0 to windows 7) ... say what you want about Microsoft, but if you've ever worked on operating systems, this is absolutely incredible.
I thought Linux also had a very strict ABI compatibility policy also.
Executable formats have changed some, and I don't know if recent Linux systems would support the a.out format of early Linux. And shared libraries change too. But if you had a fully-statically-linked binary (and enabled a.out support if necessary), I think Linux should also support very old binaries.
Microsoft accomplished this with dynamically linked applications, which is a more difficult feat. It also led to 'DLL hell', but they have resolved this fairly effectively in modern versions of windows (at the cost of using gobs of hard drive space, mitigating the benefit of dynamic linking to some extent). In Windows 8 they've introduce a technology called 'page combining' which mitigates some of the problem in physical RAM. It does exactly what it sounds like - it searches RAM for identical pages, and when it finds them, it manipulates the page table to use one physical copy for all of the virtual copies. If some process tries to modify it, a copy-on-write operation is performed. This significantly reduces physical memory usage in Windows 8.
And Linux (and all Unices, as far as I know) have done the same thing without DLL Hell by using versioned share object files, the .so.0.1 and so.1 and so on you see on the end of binary libraries.
Windows 3.1 removed real mode support thus breaking compatibility with Windows 2 and Windows 1 apps.
What Microsoft did is replace various included applications completely with every upgrade. There's no compatibility. Things like notepad.exe for Windows 1 is simply replaced with a version made for Windows 3.1 when you upgrade. Likewise when you upgrade from 3.1 to 95.
You absolutely cannot run Windows 1 applications in modern day Windows. Heck the CPUs these days literally do not support real mode anymore. You can upgrade but that's really just a series of complete OS replacements in this case.
> Heck the CPUs these days literally do not support real mode anymore.
They do, actually; a brand new Core i7 still runs 16-bit real-mode and 32-bit real-mode.
Now, if you're running in 64-bit mode, there's no vm86 mode you can use to run 16-bit applications on a 64-bit kernel. However, the CPU still supports 16-bit real mode, and under a 32-bit kernel you can run 16-bit applications.
And indeed, Wine can run 16-bit Windows applications on 64-bit Linux. You could say that at this point Linux is more Windows-compatible than Windows itself :)
Nope, this is binary compatibility. The apps you see in the screenshot are binaries straight from Windows 1 install media. Literally every 16- or 32-bit version of Windows from 1 to 8 will run Windows 1 apps.
I'm sorry if I was unclear in my wording, I mean the modern Windows version must be 32-bit to be able to run 16-bit Windows apps.
Windows 3.1 removed real mode support thus breaking compatibility with Windows 2 and Windows 1 apps.
That's just not true. Windows 3.1 removed real-mode support in Windows itself -- in other words, the last version you can run on a 8086 CPU is Windows 3.0.
But pre-3.0 16-bit Windows apps certainly didn't stop working.
The trick there is that there is no such thing as "real-mode windows applications". The 16-bit ABI is essentially same regardless of whether windows run in real mode or protected mode.
Also, it is true that Windows Setup would replace old bundled applications with the upgraded versions (otherwise it wouldn't really be an upgrade,) but if you had older applications that didn't come with the new OS (REVERSI.EXE was no longer available in Windows 3.1, there was no CARDFILE.EXE in Windows 95, and so forth) Setup would just leave them alone, and they would run happily on the new OS.
There were some exceptions to this; I remember as a kid upgrading my 486 from Windows 3.1 to 95 for the first time, and being disappointed that Setup replaced Paintbrush and Write with Paint and Wordpad, because I liked Paintbrush better. It actually replaced PBRUSH.EXE and WRITE.EXE with dummy EXE:s that would just launch MSPAINT.EXE and WORDPAD.EXE instead. These dummy files are still in recent Windows versions for compatibility with stuff like ancient apps that create shortcuts to launch Write with their docs.
It was trivial to retrieve PBRUSH.EXE from Windows 3.1 install media, however, and it works fine on Windows 95 as well as every subsequent 32-bit Windows.
When you have the source code available to recompile software, that "compatibility" issue disappears (like for most tools on Linux). It's simply a different approach.
You know, ASM code can be hacked, and the older the ASM code, the less complex it is, because the compilers were not as aggressive as today's.
This has been done with abandoned games to fix bugs and compatibility issues, ex. Forgotten Empires (the mod)[1]
ASM code can also be ported between platforms (ex. from 16-bit DOS to 64-bit Linux), as long as you replace OS-specific calls, interrupts, IO access, etc., although the effort will be greater.
People should stop pretending that a compiled binary is a black box, because it isn't.
Still, the point that Windows makes backwards-compatibility as straightforward as possible prevails, since the cases where you need to do complicated maneuvers like hacking ASM code to fix compatibility issues are scarce.
I still get amazed that I can play some obscure games designed for Windows 95 and compiled using the DirectX 3 SDK. I can't say the same about Linux since I hadn't been able to recompile without fixing code old open source games, because X kernel version broke Y version of Z framework.
That's also quite common in virtual machines. You just need to trap the cursor in a corner. Then, as long as you keep the mouse inside the window, both will be synchronized.
I haven't had them be synchronised even after doing that, the cursor inside the VM moved faster the host cursor. That's ok though, it'd be an issue if the cursor in the VM moved slower.
Edit: Just pressing the Lock Mouse button works very well. esc will remove the lock.
I've ran Windows 3.1 in DOSBox before. I can't say it was a fun experience, it's not very stable. Trying to use The Way Things Work, a multimedia CD-ROM from Dorling Kindersley, would crash it occasionally.
If you want to run old Windows, I suggest a proper virtual machine.
It's hard to get networking functional inside DosBox, but works pretty well beyond that. I use this for some old Windows games (Castle of the Winds etc) and other nostalgiaware (Visual Basic, AmiPro etc). :)
