How far can you get, application development-wise, by using only the original APIs from Windows 1.0, and only whatever came included by default with Windows 1.0?
I finally decided to write an application for the very first version of Windows and see how different the modern WinAPI really is from its earliest versions. Windows 1.0 came out back in the mid-1980s – the era of 16-bit processors, MS-DOS, and cooperative multitasking. At first glance, you might think it has almost nothing in common with modern Windows, but when you look specifically at the application API, that’s where things get interesting.
I wanted to see how far it would be possible to go using only the capabilities of the first version of Windows. I didn’t want to just make a minimal example with a window and a menu, but a small, complete application with graphics, keyboard input, timers, and constant redrawing. For this experiment, I chose Xonix – a simple yet surprisingly addictive game.
↫ Stanislav Safronov
It turns out that surprisingly, despite the 40 years and massive changes since Windows 1.0, there’s still a lot that feels recognisable. It’s also remarkable that the code Safronov ended up with ran on every version of Windows from 1.0 to 10, but sine it’s a 16 bit application it no longer works on Windows 11. It also had a hiccup on Windows 95, but he suspects that’s an issue in the 16 bit subsystem in Windows 95, and not in his code.
The code’s available on GitHub.
Yeah, win16 won’t work on x64 Windows. Not just Windows 11 but also all x64 versions of Windows.
Win16 is one of the things “XP Mode” did for you on x64 Windows (n addition to DOS apps and 32-bit device drivers), before Microsoft decided that we don’t need compatibility anymore and dropped “XP Mode” from Windows 8 onwards.
As an aside, Microsoft could have made win16 work natively on x64 WIndows (like they did for win32), they just couldn’t be bothered.
kurkosdr,
I agree the article should be more explicit about this. Binary compatibility doesn’t really work unless you go out of your way to install a 32bit OS. AMD designed this limitation into “AMD64” at the very beginning. Unless your ok with running a 32bit OS, the hardware stopped supporting 16bit native modes decades ago.
Microsoft could emulate 16bit software, but it was AMD that dropped native support 16bit in hardware from 64bit operating systems, which is what all major operating systems are these days.
Alfman,
Yes, people skip this part, but AMD basically said: “you can have 64/32 bits or 32/16 bits but not both”
Just for this reason Microsoft had to go to great lengths to emulate 16 bit installers on 64 bit system. They basically had a specialized parser for Install Shield and others and swap them out for something that works without the user realizing.
The term “16-bit” is ambiguous when it comes to x86. There are “real-mode” DOS apps (which of course don’t work on AMD64 without emulation of virtualization), and there are win16 apps which have been working in protected mode (virtual memory and all) since “386 Enhanced Mode” in Windows 3.1 (and maybe earlier, don’t remember).
Microsoft could have enabled win16 apps to run on x64 Windows, but they’d have to do more work to create another WoW (Windows on Windows), and they didn’t.
kurkosdr,
You’ve got it backwards. Genuine real mode works but VM86 mode (ie running real mode software under a protected mode supervisor) does not work.
https://en.wikipedia.org/wiki/Virtual_8086_mode
This means that VM86 mode can only be used by a 32bit OS.
A 64bit OS cannot use VM86 mode, these were made mutually exclusive by AMD. The reason “XP Mode” worked is because the x86-64 host OS is not using VM86, but rather VMX which can run a 32bit guest OS. That guest OS is allowed to use VM86 inside the VM.
kurkosdr,
On re-reading your post, I see you are not talking about real mode or VM86 mode, but 286 protected mode, which still used segmentation. Although as far as I can tell those 286 protected mode segments were 24bit and could address up to 16MB, so it would be inappropriate to call them “16-bit” IMHO. Regardless, I think we’re on the same page now.
Apparently 286 protected mode segmented memory did keep working with 386, with some changes…
https://en.wikipedia.org/wiki/X86_memory_segmentation
My understanding is that this has not carried over into x86_64…
It seems to me that AMD closed the door to running all segmented code from 64bit long mode, but let me know if you find anything that says otherwise.
I’m learning a lot of 286 trivia 🙂
I didn’t know this about win3.x software. The userspace software could have 16MB segments, but the windows API still relied on 64k segments. This is bizarre to me, but it seems to mirror the situation with 32bit DOS DPMI programs having to interact with 16bit BIOS+OS. I wasn’t aware that early versions of windows had a similar divide.
I only started computing when things were already 32bit and only experienced 16bit via DOS. I was familiar with both real and protected modes, and though I was aware that 286 protected mode existed, it had long since been abandoned by everybody.
kurkosdr,
I think at one point they would think
“Shall we maintain 3 versions of Windows installations, with their dependencies, updates, and of course additional disk usage?”
They already had pretty good backwards compatibility. But everything has a cost.
Obligatory windevdm : https://github.com/otya128/winevdm
How to use it : https://github.com/Kochise/win_portable/blob/master/Game/castlotw/CASTLE1.BAT
Kochise,
That is nice
I would not be surprised Microsoft themselves would switch to Wine/Proton at one point for backwards compatibility.
(I still remember Wine 1.0 being launched. It was a huge milestone)