Writing Windows 95 software in 2025
47 points by ralish
47 points by ralish
The problem is that the counter is a 32-bit integer, and the code was written by the ancients when 300MHz was a fast CPU. On anything modern (or an unthrottled emulator), the counter overflows almost immediately and produces garbage.
This happened on real computers too. the AMD K6-2 450 was too fast for it. There was a fixed boot disk supplied by Microsoft.
Recently, I developed an STM32 firmware in C. It has a 32-bit timer that overflows after 49.7 days, but with careful programming, everything works seamlessly if you use uint32_t and write overflow-safe code and don't use intervals larger than 24.8 days. It's a very classic problem (many millisecond timers, e.g. the one in SDL2, are 32-bit), you really don't want any bugs that pop up after 49.7 days. It was a fun thing to implement.
Amusingly 32 bit timer wraparound can also occur in the DNS, in SOA serial numbers (where the interval is controlled by the zone operator) and in DNSSEC signature validity periods (the y2k38 problem). The solution is called serial number arithmetic.
BTW, the code will be the same for modern Windows versions. Besides Unicode (-W functions), nothing has changed in Win32.
sixty-four megabytes of memory As God Intended.
Wowza, that was a LOT of memory back then. My Windows 95 computer had 8 MB. I did eventually up it as high as 96 at its peak in like 2003, but by then I had also changed to Windows 98!
But yeah, I read this win32.hlp file back in the day, downloaded it and read offline to learn Windows programming. Its title "Windows 95 Programmer's Manual". I kept being astonished at things like multiple desktops and named pipe mailboxes thinking that was the coolest secrets. Anyway, MOST of that stuff is not only still fairly relevant today (the concepts haven't changed much!), but most of it even still compiles and runs today!
I did hit one somewhat recently though where the old technique still compiles and runs.... but I wouldn't say it "works". The win95 style midi functions are still there, but since Windows 7, have so much latency they're not terribly usable for anything interesting. I hit this and was perplexed thinking I did it wrong, but compiled for Windows XP, dug out an old computer that still had it installed (need physical hardware to test midi latency effectively...) and it worked flawlessly. Turns out Microsoft put in some kind of permission check or translation layer or something and kept the function around, but never bothered to optimize it to work well, since it is considered obsolete and deprecated. I know there is new apis for the same functionality, but they're not as nice to use and takes effort from me to port, makes me sad.
Still, the win95 stuff remains useful to know. There was a period when people were saying this is all irrelevant, like who cares about WM_PAINT and InvalidateRect, just do it all all the time! But limiting the unnecessary work you do is useful to extend battery life even today so.... yeah the old ways are still valuable knowledge.
The win95 style midi functions are still there, but since Windows 7, have so much latency they're not terribly usable for anything interesting. I hit this and was perplexed thinking I did it wrong, but compiled for Windows XP, dug out an old computer that still had it installed (need physical hardware to test midi latency effectively...) and it worked flawlessly. Turns out Microsoft put in some kind of permission check or translation layer or something and kept the function around, but never bothered to optimize it to work well, since it is considered obsolete and deprecated. I know there is new apis for the same functionality, but they're not as nice to use and takes effort from me to port, makes me sad.
https://github.com/KeppySoftware/OmniMIDI/blob/master/DeveloperContent/KDMAPI.md can be used to fix that
I kept being astonished at things like multiple desktops and named pipe mailboxes thinking that was the coolest secrets. Anyway, MOST of that stuff is not only still fairly relevant today (the concepts haven't changed much!), but most of it even still compiles and runs today!
While a lot of stuff is still relevant, mailslots are pretty antiquated nowadays. Also named pipes over a network are more trouble than they're worth (BSD-like sockets tend to be superior). Local-only named pipes continue to have their uses though. But yes, even "antiquated" stuff can still run.
Yes, heck, all i've ever actually used named pipes for in real life since reading that was for running child processes with overlapped i/o on the pipe. I was just more wowed at this whole new world at the time, since I was pretty noob myself. Still, fun time to think about, it wasn't obvious back then when Windows 95 was new (though I didn't come to it personally until several years later) that tcp/ip and bsd sockets would win the way they did.
Why build using OpenWatcom? Wouldn't it be more fun to use an IDE like Visual C++ or Pelles C? Then you get a GUI builder too.
I am worried that using the current snapshot makes the process non-deterministic.
When I tried to make a program for Windows 95 I used regular mingw-w64. Not sure about compatibility but my program worked in Win95 in VM. As I see from CMakeLists for that project, there was no special configuration aside from -DWINVER=0x0400.
Have you tried using PCem or any of its forks to avoid the timing issue? I'd be curious to see if a similar deployment workflow could be made to work with them?
To everyone who insists software used to be simpler, how we've lost something along the way: here's your blank canvas, no Electron, no node_modules, no 200MB Hello World, just you, the Win32 API, and sixty-four megabytes of memory As God Intended.
I'll be waiting to see what you ship.
I don't think there's many people saying Windows 95 is the best balance between bloat and benefit.
Of course we've gained a lot over the years as well. The contention is that much of the loss wasn't necessary to pay for any of the gain (some of the loss wasn't necessary in practice, some in principle).
Not to mention, network effects often make it practically difficult to use far less bloated software over the alternatives.