Building a Windows 1.0 game and testing 40 years of compatibility
Posted by FlatlinerSPb@reddit | retrobattlestations | View on Reddit | 20 comments
Instead of just reading about Windows 1.0, I decided to actually build something for it.
So I wrote a small Xonix-style game for Windows 1.0 and ran the same binary across different versions of Windows.
It turned out to be more surprising than I expected. The same compiled 16-bit EXE runs from Windows 1.x all the way to 32-bit Windows 10. On modern 64-bit Windows it no longer works, but only because 16-bit support has been removed, not because anything changed in the original model.
What surprised me most is how familiar the WinAPI already looks in Windows 1.0. Even back then, the core ideas were already there - message loops, window procedures, and GDI rendering. The structure hasn’t really changed as much as you’d expect in \~40 years.
I put together a write-up with details and source here.
Curious if anyone else has tried building software for the earliest Windows versions?
FozzTexx@reddit
I wonder if it will run on my HP150 with Windows 1.0
FlatlinerSPb@reddit (OP)
It should run on your HP150 with Windows 1.0
FlatlinerSPb@reddit (OP)
Actually, now I'm not so sure anymore. I don't know what video card your HP150 has. You need EGA or better. It might run on others, but some graphics may not be visible — no optimization was done for CGA.
FlatlinerSPb@reddit (OP)
It should run on your HP150
thelapoubelle@reddit
Do you think Windows 1 would have appealed to developers of the time compared to writing something similar for dos? Did it make your task significantly easier?
FlatlinerSPb@reddit (OP)
Yes, but only for a very specific type of developer.
As the comment about 125-line Hello World shows, Windows 1.0 was incredibly verbose compared to DOS or other GUIs of the time. For most developers, that made routine tasks harder, not easier. However, for those working on complex, event-driven applications (like drawing or spreadsheet programs), Windows offered consistent window management and input handling that DOS couldn't match. So yes, it appealed to a few — but no, it didn't make typical development significantly easier.
Scoth42@reddit
Not the OP, nor was I was developer at the time (or now) but I've read stories that suggested developers found the whole thing kind of hilariously verbose and long-winded for even basic stuff. The amount of code it took just to set up a basic window with some simple controls and text was significantly longer than for basically any other OS at the time. For example, the Hello World that came with the original 1.0 SDK was 125 lines long. For what would be a one-liner in lots of languages and not nearly that long even for other GUI systems.
https://casadevall.pro/articles/2020/05/examining-windows-1.0-hello.c-35-years-of-backwards-compatibility/
Dante268@reddit
Excellent! I had same idea, btw. There're not many games for Windows 1.0 (only "bigger" game I know about is "Balance of Power"). So it's quite a feat to make a game for that platform today. I hope I will get to it as well one day.
66659hi@reddit
Almost nobody bought Windows before 3.1. Windows was kind of a waste of time, being just a shell on top of MS-DOS. It just made all of your programs run slower, and didn't have many advantages.
Winodws 95 was a huge improvement over 3.1, too, though Windows didn't really get "good" until NT4. NT3.1 and 3.5 were good, but very primitive.
mittelwerk@reddit
Now I challenge anyone to do the same under Linux. No, no sandboxing: I mean natively running whatever app one builds.
Peetz0r@reddit
There's plenty of software that even predates Linux entirely (as in, was written for old Unixes against posix standards) which can still be built for modern Linux (and also BSD and MacOS).
I can just install
bsd-gamesin my package manager and directly play a collection of such games.Away_Experience_5843@reddit
But it won't be the same binary.
mittelwerk@reddit
Also: things that depend on libraries or anything more modern will not work because the libraries themselves had so many changes over the years that backwards compatibility is effectively broken. As an example: GTK breaks compatibility so often that, if one wants to use the version that comes bundled with modern distros, one can't. Also: try installing, say, Ubuntu Lucid, and try installing any modern software on it. You can't. Not to mention, the whole Xorg/Wayland shitshow.
Sorry but, backwards compatibility is an issue on Linux.
(and yes, I know the kernel team prioritizes backwards compatibility for whatever kernel version is in the 10-year support period, that's why the "never break userspace" rule exists, but that's not true for everything else. And an operating system is much more than the kernel)
Peetz0r@reddit
The trick is that having source available is very common, and that effectively solves the problem 😉
Yes, if you only have a binary, you might very well be out of luck.
Away_Experience_5843@reddit
In practice this is the way better approach. But for the sake of this experiment Windows does it best.
But what if you bundle in all the libraries? That should work, right? For something simple like for example a CLI game.
n1ghtbringer@reddit
The point is the binary compatibility not source.
Though having the source is better long term, of course ;)
CyberTacoX@reddit
>On modern 64-bit Windows it no longer works, but only because 16-bit support has been removed
Google "winevdm". It puts the 16 bit support back!
The-Tylenol-Jones@reddit
Try this and you can get it working on Windows 11: https://github.com/otya128/winevdm
FlatlinerSPb@reddit (OP)
Thanx
Commercial-Dare3506@reddit
Cool