One crucial part of my role as my family's de facto IT support was making sure my mom's FreeCell score record (which was just a Windows registry value) made it from each computer to the next across countless upgrades. She hated the new version that came out somewhere along the way because the card decks changed. (Windows 7? Windows 10? I switched to Linux full time in the XP era so my memory is a little fuzzy.) So I made sure to keep a backup of the Win32 version she was used to, and loaded it onto every machine she ever owned. It wasn't quite the 33 years of its lifetime, but probably close to 30.
Mom passed earlier this year, so the FreeCell score record won't ever increment again, but I still made a point to back it up one last time when going through her desktop this summer.
Sorry for the loss, are you able to keep her high score saved too?
I wanted old school MS solitaire in windows 11 since the modern version has ads and extra useless features. I found that the Windows XP version works without hassle. Earlier versions aren't really different but I forget if I tried to run earlier versions. One quirk: however the winning animation is programmed, it takes almost 20 minutes to complete on a very wide monitor[1].
I deplore the day we lost the menu bar and replaced it with "mobile first" designs. The desktop UI was perfected around the time of Windows 95 and has gotten worse with every iteration since then. That, and the increased reliance on non-native frameworks and libraries instead of working with directly with the Windows API in C.
Long-press and the ••• menu in the overflow is a far superior UI paradigm than having a purpose built menu button.
90% of the time, even in Android that was pre-Honeycomb, the menu ended up just showing what would have been in the overflow anyways.
Android really did end up doing a lot better on the UX side that iOS with the contextual action bar and long-press to select. The idea of selection mode on iOS is still a weird process, and it's been mostly worked around since with higher PPI screens and touch sensors, instead doing a small area to "select" items on iOS
IMO, the old Android menu button wasn't great UX. It ended up just being a miscellaneous laundry list of random functions, and the users would just need to learn "spam the menu button randomly on every screen just in case the needed action is hiding in there."
So do I, but I don't think I'd blame mobile-first designs, and instead place the blame on Microsoft sucking at making decisions, sucking at design, and sucking at mobile. Every bad Windows UI has, imo, been the result of trying to be cool and likeable by dying their hair a different colour to get some attention and getting ahead of or catching up with Apple who was playing a different game the whole time.
Apple meanwhile has made some notable mistakes, but when they do, it's usually a thorough bad bet that's just missed the mark, but if they do, it's all throughout their OS in every corner. Even with their recent Liquid glass blunder, they're not really putting a veneer that looks like wood over a rotting corpse of a house, they're just picking bad materials to update an otherwise decent layout. Microsoft's whole track consumer UI/product record imo is trying and failing to bet small but intrusively on ideas that don't work, aren't cool, and have no longevity. You see it as soon as you open the control panel that still looks like the 90s; it's this uncomfortable amalgam of failed tepid temporary marketing pitches by some department that make no sense
Windows 95 was the last release that had serious user testing in controlled environments. (They were also cribbing lots of notes from NeXT, which helped.)
Something fundamentally switched around 1998-2002 in how interface design was viewed and approached. I started my career in software as a design summer intern at a company that made a Windows “groupware” application in 1997. They took pride in following the platform’s guidelines and actually testing their designs with real users being videotaped trying to use it. The company’s UI design department was tiny, but employed both an industrial designer and a cognitive scientist.
Five years later, everybody I met in UI design was a graphic designer who was drawing glossy website mockups in Photoshop. The elder lore of science-based UI design was completely lost when Web 2.0 happened and app designs became vibes-based. Even Apple couldn’t resist the tide. (Indeed Steve Jobs’s return to Apple in 1997 was a major contributor because he had developed a taste for user-hostile skeuomorphism like the brushed metal QuickTime Player.)
I was at Microsoft when they user-tested Windows 7 to death. Including installing eye tracking software during sessions so you could monitor where the user was looking at on the screen.
That data was in part used to justify the changes made in 8: "Users only click on the start menu 0.1% of the time and when they do they focus on a narrow portion of the screen."
Although I started with 98, I think Vista / 7 was the peak. It was user friendly enough for newbies but didn't sacrifice advanced controls. Just organized them better to bring focus to the more used parts.
In terms of aesthetic, I love Windows 7-era Aero glass design (and to a lesser extent, Vista), but I also love the classic Windows 9x/2000 look. If I had to choose between the two, I'd go with Aero simply because of the start menu search bar.
Maybe on the OS side. However, Vista coincided with the release of Office 2007. That release of Office introduced the dreaded Ribbon, which made functions much harder to find.
> Some apps eschew it, like browsers, but not because they are “mobile first”, but because they are trying to maximize screen space.
I don't think this is true. If anything, we see more oversized buttons and empty space nowadays. It's as if developers forgot that PC users have keyboards and mice. Remember, display resolutions and monitors were a lot smaller back then, and making space count was arguably more important 20 years ago than it is today.
Ironic to say on hackernews which shows massive whitespace in the margins-- and if I try to widen my tab sidebar it actually indents the margin rather than eating into it.
One can look across the computing space as a whole and see that, it is surely not the case that we're "maximizing screen space".
Oh really? I, sadly, use nearly none. Open on my desktop right now: Slack, Outlook, Zoom, Windows Terminal, Edge, Claude, Obsidian, whatever the Windows image viewer is called, Cursor, and VS Code.
Only the last 2 have menu bars. And I can’t be certain that I didn’t dig through the preferences of one or both of them when I first installed them to tell them to knock off the bullshit and give me back the menus. Once in a while, there is an option buried somewhere like that.
The Menu + quick access bar was good for developers but terrible for users, at least compared to the ribbon.
Ribbon is absolutely an improvement for users but is more work for the XML layout and learning how to organize it.
I'm rather convinced that Ribbon is still the best way to organize quick actions, show their shortcuts (Alt to see keyboard shortcuts), and also have enough text to describe all the buttons. But it'd be nice if it were easier to make good Ribbons.
Menu was braindead easy, albeit through ancient process of .rc files and whatnot
The alternative to ribbon is not menu+ quick access, it was easily customizable toolbars where you can simply drag and drop only the buttons you need in the toolbars you need at a fraction of screen space that the ribbon wastes. And no user is ever exposed to that XML garbage only a dev could love
I'm just not sure why it has to be one or the other. Look at NeXTStep. They had a menu bar (or I guess a menu panel) and a ribbon, although that term didn't exist yet, and it was definitely not 100% there yet.
I think it's the other way around. Well organised menus can help users discover what functions are available at quick glance without having to hover each icons with the mouse to know what they do. For power users, the ribbons mean you can click directly on the function you need without having to click through menus and sub-menus.
> The desktop UI was perfected around the time of Windows 95
There’s no need to be hyperbolic or blinded by nostalgia. Yes, user interfaces have suffered several setbacks in the years since, but even if we concede every change was for the worse (they weren’t) it was by no means “perfected” and there was still plenty of area for improvement.
> Well that can't be entirely true, the desktop experience on Windows 10 improved on Windows 8 by leaps and bounds.
In large part, windows 10's ui is more like that of windows 95 because it undid the changes away from the windows 95 paradigm that windows 8 did. Furthermore, those changes away from windows 95 in windows 8 were the exact kind of thing that might be called "mobile first".
95 feels kinda backwards tbh but 98SE/2000 is outrageously modern. A lot of the windows admin tools are unchanged from 2000 apart from the icons. I really think if you could run a modern browser on 2000 it could be a daily driver for most people
As computers, and smartphones got more popular, the audience got larger and the use scenarios got more and more distant from professional use. Dedicated professionals, like software engineers and stock brokers still prefer CLI and Bloomberg terminal even today. Ordinary office workers late 90s and early 00s window-based interfaces (the ones you're talking about). But smartphone users who just want to play their free games and scroll through facebook actually prefer the mobile-first UIs.
If you see this UI transition through the same lense as CLI-GUI one, a lot of things become more clear, in my opinion.
i agree. i love the 120hz responsiveness of the UI. how fast the app loads, the buttons click. No lazy loading , placeholders, layout re-renders. Open the task manager: half a meg ram used.
I agree with you generally but I don't think desktop UI is remotely close to perfected. Unless you mean the desktop as a skeumorphic concept than maybe.
I think we've actually completely stagnate on the human interaction side of OSes and only emacs has made any progress and then only for those willing to put the work in, not as a vanilla user ui.
The finished patch DLL ended up being a tour of the stuff that broke.
The game did launch on Windows 11 but the main issue was that the 8-bit pre-DirectDraw behaviour was broken - for 256 colour screens, Windows 11 resolvesld palette indices only once, but the game relies on being able to change the palette for fades etc. Most of the screeen ended up black, but you could see the animated parts just fine.
So most of fix ended up being to hook every draw call and implement a virtual GDI that acted like a graphics card of the day.
There was a 32-bit disc space check that overflowed, a couple of use-after-free crashes and some racey threading calls that can't have been tested on a machine with 2 CPUs.
Backwards compatibility from Microsoft was almost all there, and probably would have kept Orly running for a couple of subsequent Windows releases. But it relies on a developer meeting them half-way, it's not an emulation layer.
wine has more backwards compatibility options than Windows itself, but in this project also triggered some different buggy code paths in the original (see cousin comment).
So this game still needed its bugs fixing to run in a modernised Windows, or it would have been stuck in a hardware emulator running Windows 95.
Your project's readme suggests that you tested on Proton. How poorly does the unmodified game run in Proton and/or Wine when you limit it to a single CPU? Very? Somewhat?
But after it was working on Windows, I tried it on Crossover and found that MacOS doesn't allow you to pin to one CPU. So it needed a racey scheduler rewriting.
There was also a difference in the way wine provides printer drivers that caused a buggy code path to run in the game, which caused a crash on the Steam Deck too.
So those bugs would have been critical even if the display implementation had worked.
The patch also adds an OpenGL window & scaling filter as the game's primary output, so it doesn't rely on GDI for pixel output any more.
I like that we are amazed by this. And yet all of my books from 34 years ago open up just fine (without cheating, no book opening emulator required!). I can even open a book on my shelf from 1896 without emulation. Not trying to troll too hard but I do think it is shocking how accustomed we've gotten to zero backwards compatibility in the world of software.
I think the oldest cartridge that would still work in a modern firearm would be .22 Short, which is from 1857.[1] It was developed into .22 Long, which was developed into .22 Long Rifle, which new firearms are still chambered in today. It wouldn't cycle a semi-auto though. Another contender would be .38 Long Colt, which is from 1875 and will work in firearms chambered in .38 Special or .357 Magnum.
The main causes of incompatibility were the transition from ball-and-powder to rimfire cartridges, then the transition from rimfire to centerfire. It's surprising how little firearms have changed in the past century. 9mm Parabellum is 125 years old. The Browning short recoil action (used by most handguns today) is over a century old.
If you live in a country or region where the gauge didn't change, you can put a 1845 train on a modern track just fine. If the gauge did change, you'll need a train from another country. Standard Gauge was first applied in 1825 after all.
Many militaries are still buying rifles that chamber a cartridge introduced in 1891 (7.62x54mmR). I'd argue a cartridge initially developed for a long bolt action rifle (Mosin-Nagant) that can now be fired out of a variant of a AK-patten select-fire bull-pup (Vepr) fits the analogy.
The oldest web app code of my own that I still maintain/evolve turned 20 this year, so yours is older than mine. I think it's largely a Ship of Theseus at this point, though I did just remove some code the other day that was absolutely untouched since 2008.
Speaking of FreeCell, a couple weeks ago I was visiting my 95yr-old grandmother and noticed she still plays oldschool FreeCell, specifically a variant that's really hard to track down now called FreeCell Pro [https://cards.fandom.com/wiki/FreeCell_Pro]
It inspired a weekend project. I always liked that you could swap the card backs in OG FreeCell and play with different "themed" decks, so I vibecoded something a little more modern. I got carried away and added a roguelite mode too (yeah I know how "Roguelite FreeCell" sounds). Anyway, it's free to play on the web, no ads: [https://freecellworlds.com/]
Basically a 1992 rogue-lite where each room is a different solitaire game. eg: front parlor == clock solitaire, first bedroom == regular solitaire, upstairs is blocked by freecell, etc...
It's a fairly rich concept, you have a ton of different gameplay bound together by a very loose plot/quest mechanisms (eg: blue key == blue door ; boss == win 2 games of solitaire).
Definitely worth sharing if you've got some solitaire fans in your life!
Yeah classic FreeCell only lets you move one card at a time. No stacks. A lot of FreeCell implementations have a QoL feature that let you move stacks if there's enough free cells or empty columns to allow the move.
Along these lines, I'm always amused with the videos (e.g. https://www.youtube.com/watch?v=C8CIhCTVyqQ) showing you can update a [virtual] device from Windows 3.1 to Windows 11.
In 2026 does it still make sense to build new Windows app using Win32 API? I was building a simple image viewer similar to QuickLook on Mac using Win32. I found it's very responsive. The code is less readable compared to React. For me Win32 is a good option if the UI state machine is simple enough.
While Win32 tends to deliver the most resource-efficient and responsive apps if the complexity is not high, I have settled on the latest .NET + C# + Windows App SDK / WinUI 3. Making an app look good and fit into the modern Windows look is extremely hard with Win32 C/C++ and writing and maintaining it requires energy that I'd rather spend elsewhere. Besides, modern frameworks are making great strides in speed, efficiency and QoL features. .NET 11 is full of optimizations, for example.
I've tried this and found the WinUI deployment model frustrating and user hostile. There are like 5 open issues on GitHub where people seem deeply confused (I'm one of them) as to if it's possible to build a plain .NET .exe. Some people have tried it and it "works", others try it and get obscure errors, it's a real mess.
I think the sweet spot is WPF or actaully its FOSS version: AvaloniaUI. It is high level enough to be cross-platform and not stupidly verbose, however it is rather light pn resources. However, Win32 still wins in absolute minimalism.
yeah, it's still pretty good for a lot of things. I've found with AI it's now super easy to do native win32 apps really easily. It used to be doing all the plumbing was a PITA. There were wrappers to make it easier, but now you can do it directly. It means you get super performant, tiny binaries, that start instantly. Like windows should be. However, at home I've moved to linux a while back so way less useful to me now, though works fine with WINE. I still use it to make little utilities for work though.
Unless your name is Raymond Chen, you probably want to at least use ATL/MFC, which are frozen but still supported. Me, I'd take Qt any day, or wxWidgets if I wanted to go minimal.
Win32 API is great and responsive; ATL/WTL (and MFC) are still very useful abstractions with little cost. The biggest pain point is having to handle a lot of things manually, like DPI awareness (and themed controls). Even things like Emoji and other modern text features are not available through GDI and require DirectWrite iirc. Still, I'm surprised how useful it manages to be regardless how old it is.
When you say responsive, you mean like it reacts quickly, or it responds to screen size?
In web we refer to the latter but i feel you mean the former.
I built a toy project in .NET 2005[0] with WinForms and the experience was actually excellent, binding data to controls was dead simple, it felt surprisingly modern. But i can't imagine how I'd make the UI resizable lol
I wouldn't, because I do not think we should put up barriers in our application between OSs (Nor have to maintain separate UI code bases for each OS you think might use it). So I use cross-platform kits. There are compromises, but I don't care about the looks native qualification compared to works anywhere. Yes, the software looks like an EGUI app (etc. Substitute Qt), instead of Looks native, but I appreciate how I'm not setting up barriers between OSs or making extra work.
So instead you are creating a bad UI for all of your users. That’s very Java application (or perhaps Electron these days) of you, but seems like a poor trade-off to me.
These days, with LLM assisted development, with relatively simple GUIs, I would go towards platform native GUIs per platform. And then all the shared business logic goes in a shared "core", with the GUIs only serving as "dumb" inputs and outputs, with all business logic shared between them.
LLMs are quite good at tedious tasks such as keeping multiple GUIs in different languages in sync with each other.
I couldn’t disagree more, when it comes to UIs. They should match the platform they are being used on. Cross-platform always produces a very sub-par experience. But us developers tend to care primarily about what makes development easiest for us.
I also don't care how if things _look_ native, I care if the work like a native app. For example, on the rare occasions I touch Windows, I expect standard keyboard shortcuts to work. On macOS, I expect full integration with the accessibility frameworks and OS affordances like services.
A lowest common denominator idea of "everywhere" is just not that useful.
I mean, if I was building a windows app, I would. Microsoft always tries to convince people to stop using it, but Win32 keeps working.
If Microsoft ever makes something that actually meets all the needs that Win32 addresses, they'll probably build a compat layer and a) your win32 code will still work in compat mode, b) that new thing may be worth targeting.
> That is because, duh, my computer doesn’t have a CD-ROM drive. But you can use a small DLL (cdemu.dll) to emulate one with some fake audio data and actually get it to play audio
This makes me curious to know if CDPLAYER.EXE would still work (unmodified, without extra DLLs) with a real CD-ROM drive if you ran it on a Windows 11 machine with one installed.
Tried it. If I open it with a disc in, it shows the "No CDROM devices found" message. If I open it without a disc in, it shows the menu, then when I put in a disc in Windows shows a weird error: https://files.catbox.moe/6y3qpy.png
It acts generally weird (buy a £10 dvd drive from ebay and try it yourself if you want any more detail, useful thing to have anyway) and obviously I can't get it to play anything.
The RTM version gets a bit further, doesn't show that weird Explorer error, but I still can't get it to play anything and opening the playlist crashes it vs on the Beta version where it actually listed the tracks.
I suspect the cd player is trying to take control of the drive and fighting with Windows trying to be helpful, don't know if there's a way to turn it off.
I can't say for certain but recently having done some work on windows with CDROM drives, i strongly suspect it would. I bet you could mount a music CD BIN/CUE with ImgDrive and it would work... Shit i guess i have to go try it don't I
Edit: i meant ImgDrive as a suggestion for those without optical drives. I have several, I'll test em out
I remember having installed Win32s package to our Windows for Workgroups 3.11 machines at Osmangazi University in 1995. The idea was that Windows, as a 16-bit operating system, could run a subset of Win32 apps that were compatible with the Win32s API surface. However, the release of Windows 95 had almost immediately made it obsolete. I'm sure it was useful in certain scenarios, but our only win was Freecell. :)
> The idea was that Windows, as a 16-bit operating system, could run a subset of Win32 apps that were compatible with the Win32s API surface.
386 mode in Windows 2 (sold as Windows/386) and 3 was really a 32-bit operating system for 16-bit applications.
Win32s allowed some 32-bit apps to run on windows 3.1 and up. Including many versions of Internet Explorer (Microsoft also released ie as a 16-bit application, though).
I often think old GUIs have a nice, functional look to them. This one is no exception. I notice (what I assume is) the shuffle toggle looks unfamiliar. This is from way back before that UI became a convention! I see the repeat icon has stuck around. So interesting!
Microsoft (and Apple) poured a ton of money into usability research in the early 90s and it showed. I vaguely remember the story through how many versions of the trash icon Microsoft went for Windows 95 to get it right.
For me it was a bit sad to see the mad and creative UX world of the homecomputer era being bulldozed over with the minimalist uniform results of the scientific usability research.
Little did I know that a mere quarter century later we are back were we once started and everyone as clueless as we were in the 90s goes overboard everywhere as if there was no tomorrow.
Yeah, and it sadly makes me miss the nicely ordered and easily usable world - I'm gettin' old I guess.
Functionality isn't hidden and buttons looked like buttons (instead of the modern trend of having unstyled text or tiny icons having a 50-50 chance of being a button).
The flat design trend really confused me. It really took off when high resolution screens started getting popular too, really made no sense. Wish we'd bring back Skeuomorphic design. Bring back that wood grain and metal textures. Bring back the fun UI's and app themes. Bring back real buttons!
I can't even run a binary from one Linux distro to the other, let alone one from a random Unix from the 80s. If a rebuild from source is allowed (which would need to allow modifications to the build system) that's a completely different game.
From the article, the time to beat is November 16, 1992. This might be possible on one of the BSDs, as FreeBSD and NetBSD both document support for running a.out executables with the 4.3BSD ABI. I guess it would depend on whether anyone had ported X11 to run on a BSD on i386 before then. Alternatively, maybe you'd be able to get something running on SCO OpenServer (if you count that as a current OS, it IS still getting security patches). It documents support for XENIX x.out binaries ( https://www.scosales.com/ta/kb/126704.html ) so you might be able to run software compiled in the late 1980s for XENIX/386.
Yeah I was kind of on the fence with this, but since the last version of Windows that shipped with NTVDM was Windows 10 32bit, and Windows 11 doesn't have a 32bit edition, I decided that using 3rd party tools would be cheating
I was aiming for something you could double click on vanilla Windows and would just work out of the box
Wrote a few small utilities in Win32 in the early 90s; still use them today unmodified, but most recently in WINE. I have some slightly older DOS utilities that are also quite usable.
kudos to microsoft for enabling 40+ years of API support. Most companies are ending support after less than 10 years. some even a few years ( like those Nest thermostats getting killed )
Can you imagine the maze of a diagram that enables these old APIs to draw to the screen and render controls properly still?
> Sadly, Windows 11 can’t run 16-bit Windows programs by itself, because 64-bit Windows has no NTVDM, so we’re going to have to find something from the early NT era.
I remember a recent-ish post on here that really, I mean really, dived deep into this whole thing. It turns out that it was mostly a lack of willpower or maybe political that stopped Windows 64bit running 16 bit apps.
Somewhere in the kernel, with some obscure mechanism there is support for some kind of emulation that if implemented would allow it to run NTVDM and therefore these 16 bit apps.
The author of the post even had some kind of proof of concept of running a 16 bit DOS app directly under Windows 64 bit with this.
The details are blurry, but I believe that that had the Windows team really wanted to this emulation could have been built in and totally seamless.
I got the impression that this was actually a fairly new finding which is why I suppose no one has tried it.
Related: "Chain of Fools : Upgrading through every version of windows (HQ)" (2011), they upgrade Windows 1 through to Windows 7, and demonstrate Doom II and Monkey Island working still at the end. Would be interesting to extend it to Windows 11.
I can tell that the person making the video never actually tried to run Doom on a real Windows 2000 or XP machine, otherwise they would have noticed that the game has absolutely no sound. Sound support for DOS games in Windows 2000+ was not built into the operating system. You needed to install a third party tool called "VDMSound" if you wanted sound blaster emulation for DOS games.
I'm imagining a future where Microsoft's Copilot pops up in the corner, Clippy style, and gives you a message like, "Hey, I noticed you're running an app that looks like it was developed when Windows Vista was new. Want me to freshen that up for you?" Then it runs a decomp/recomp process that updates the app at the binary machine code level so that it looks and feels like a modern app without any translation layers or weird bugs. No more user complaints about Windows having an inconsistent GUI.
At one tine, Slackware Linux would not recompile binaries unless the program was patched. So there was a time you could find rather old binaries on Slackware, and maybe still on other distros.
I wonder what the oldest unchanged source/program running on Linux or BSD ? My vote goes to cat(1) :)
One crucial part of my role as my family's de facto IT support was making sure my mom's FreeCell score record (which was just a Windows registry value) made it from each computer to the next across countless upgrades. She hated the new version that came out somewhere along the way because the card decks changed. (Windows 7? Windows 10? I switched to Linux full time in the XP era so my memory is a little fuzzy.) So I made sure to keep a backup of the Win32 version she was used to, and loaded it onto every machine she ever owned. It wasn't quite the 33 years of its lifetime, but probably close to 30.
Mom passed earlier this year, so the FreeCell score record won't ever increment again, but I still made a point to back it up one last time when going through her desktop this summer.
Sorry for the loss, are you able to keep her high score saved too?
I wanted old school MS solitaire in windows 11 since the modern version has ads and extra useless features. I found that the Windows XP version works without hassle. Earlier versions aren't really different but I forget if I tried to run earlier versions. One quirk: however the winning animation is programmed, it takes almost 20 minutes to complete on a very wide monitor[1].
[1] https://www.youtube.com/watch?v=78z2zlwV-XQ
If you want to scratch your old-school solitaire itch, check out https://freesolitaire.win
I’m still installing the classic (Windows 7) calculator [0] on each new Windows setup.
[0] https://win7games.com/#calc
My condolences. Such a nice way to honor her memory with one more backup.
I’m sorry for your loss. That is a wonderful story.
Thank you for sharing this. It was heartwarming to read!
She was right, the modern freecell sucks
<3
I'm so sorry for your loss, but now you have to tell us her high score!
I deplore the day we lost the menu bar and replaced it with "mobile first" designs. The desktop UI was perfected around the time of Windows 95 and has gotten worse with every iteration since then. That, and the increased reliance on non-native frameworks and libraries instead of working with directly with the Windows API in C.
Android used to have a dedicated menu key that would always bring up a menu. It was removed to chase Apple's 100% screen design.
Long-press and the ••• menu in the overflow is a far superior UI paradigm than having a purpose built menu button.
90% of the time, even in Android that was pre-Honeycomb, the menu ended up just showing what would have been in the overflow anyways.
Android really did end up doing a lot better on the UX side that iOS with the contextual action bar and long-press to select. The idea of selection mode on iOS is still a weird process, and it's been mostly worked around since with higher PPI screens and touch sensors, instead doing a small area to "select" items on iOS
3 replies →
IMO, the old Android menu button wasn't great UX. It ended up just being a miscellaneous laundry list of random functions, and the users would just need to learn "spam the menu button randomly on every screen just in case the needed action is hiding in there."
And the world has been improved for it ever since. What a waste of screen real-estate these buttons were...
Just got nostalgic about the 4 hardware buttons on my Sony Xperia Play: back-home-context(option)-search.
Still the best navigable phone I had when coupled with the Nova Launcher gestures.
I am fairly bothered about that but the one that really gets to me is the inconsistency of user interfaces across applications.
This precisely coincides with the web developers being allowed to wrap stuff into "apps" in Electron and the like.
It's been that way forever, did you forget about the Borland buttons? Colorful icons on them, much bigger, different shading.
3 replies →
So do I, but I don't think I'd blame mobile-first designs, and instead place the blame on Microsoft sucking at making decisions, sucking at design, and sucking at mobile. Every bad Windows UI has, imo, been the result of trying to be cool and likeable by dying their hair a different colour to get some attention and getting ahead of or catching up with Apple who was playing a different game the whole time.
Apple meanwhile has made some notable mistakes, but when they do, it's usually a thorough bad bet that's just missed the mark, but if they do, it's all throughout their OS in every corner. Even with their recent Liquid glass blunder, they're not really putting a veneer that looks like wood over a rotting corpse of a house, they're just picking bad materials to update an otherwise decent layout. Microsoft's whole track consumer UI/product record imo is trying and failing to bet small but intrusively on ideas that don't work, aren't cool, and have no longevity. You see it as soon as you open the control panel that still looks like the 90s; it's this uncomfortable amalgam of failed tepid temporary marketing pitches by some department that make no sense
Windows 95 was the last release that had serious user testing in controlled environments. (They were also cribbing lots of notes from NeXT, which helped.)
Something fundamentally switched around 1998-2002 in how interface design was viewed and approached. I started my career in software as a design summer intern at a company that made a Windows “groupware” application in 1997. They took pride in following the platform’s guidelines and actually testing their designs with real users being videotaped trying to use it. The company’s UI design department was tiny, but employed both an industrial designer and a cognitive scientist.
Five years later, everybody I met in UI design was a graphic designer who was drawing glossy website mockups in Photoshop. The elder lore of science-based UI design was completely lost when Web 2.0 happened and app designs became vibes-based. Even Apple couldn’t resist the tide. (Indeed Steve Jobs’s return to Apple in 1997 was a major contributor because he had developed a taste for user-hostile skeuomorphism like the brushed metal QuickTime Player.)
I don't think that's true.
I was at Microsoft when they user-tested Windows 7 to death. Including installing eye tracking software during sessions so you could monitor where the user was looking at on the screen.
That data was in part used to justify the changes made in 8: "Users only click on the start menu 0.1% of the time and when they do they focus on a narrow portion of the screen."
Skeumorphism is the opposite of user hostile. Flat design. Now THAT is user hostile.
3 replies →
The Desktop GUI was perfected with NeXTStep in 1990. Though some might say Smalltalk in 1984 (modulo some nice artwork and colours).
We could even have unified desktop.mobile codebases, with different GUI layouts. 280 North's objective-J/Cappuccino proved this.
IDK what we're even doing anymore.
> IDK what we're even doing anymore.
I would say people are just disagreeing with you that the situation is actually so black and white.
The early Mac made huge functional improvements over the Smalltalk GUI, improvements still used today.
The war on scroll bars has gotten pretty senseless.
Always-on-screen scrollbars were useless. Now they appear only when needed.
10 replies →
Although I started with 98, I think Vista / 7 was the peak. It was user friendly enough for newbies but didn't sacrifice advanced controls. Just organized them better to bring focus to the more used parts.
In terms of aesthetic, I love Windows 7-era Aero glass design (and to a lesser extent, Vista), but I also love the classic Windows 9x/2000 look. If I had to choose between the two, I'd go with Aero simply because of the start menu search bar.
2 replies →
Maybe on the OS side. However, Vista coincided with the release of Office 2007. That release of Office introduced the dreaded Ribbon, which made functions much harder to find.
1 reply →
I loved Windows Aero and the flip 3D view - the latter mostly because it looked so cool for that time!
3 replies →
I used the Zune theme for windows XP which I really liked. I dreaded Vista because it was just a resource eater with all the effects turned on.
https://www.softpedia.com/get/Desktop-Enhancements/Themes/Mi...
1 reply →
Wasn't that Windows 8 ?
> we lost the menu bar and replaced it with "mobile first" designs
What does this mean? I use lots of apps that still have a menu bar.
Some apps eschew it, like browsers, but not because they are “mobile first”, but because they are trying to maximize screen space.
> Some apps eschew it, like browsers, but not because they are “mobile first”, but because they are trying to maximize screen space.
I don't think this is true. If anything, we see more oversized buttons and empty space nowadays. It's as if developers forgot that PC users have keyboards and mice. Remember, display resolutions and monitors were a lot smaller back then, and making space count was arguably more important 20 years ago than it is today.
3 replies →
> but because they are trying to maximize screen space
If that was the case they wouldn't put giant margins around every UI element and dead space everywhere.
1 reply →
> they are trying to maximize screen space.
Ironic to say on hackernews which shows massive whitespace in the margins-- and if I try to widen my tab sidebar it actually indents the margin rather than eating into it.
One can look across the computing space as a whole and see that, it is surely not the case that we're "maximizing screen space".
3 replies →
> I use lots
Oh really? I, sadly, use nearly none. Open on my desktop right now: Slack, Outlook, Zoom, Windows Terminal, Edge, Claude, Obsidian, whatever the Windows image viewer is called, Cursor, and VS Code.
Only the last 2 have menu bars. And I can’t be certain that I didn’t dig through the preferences of one or both of them when I first installed them to tell them to knock off the bullshit and give me back the menus. Once in a while, there is an option buried somewhere like that.
6 replies →
How can it be related to perfection to permanently waste a strip of space you rarely (and in some apps never) use?
Working directly with C API in Windows has not been a thing since Vista, as COM took the main role for API delivery.
The Windows SDK samples like Hilo make use of C++ with COM.
Windows95 still had failures of UI design, and those weren't fixed until XP.
The Menu + quick access bar was good for developers but terrible for users, at least compared to the ribbon.
Ribbon is absolutely an improvement for users but is more work for the XML layout and learning how to organize it.
I'm rather convinced that Ribbon is still the best way to organize quick actions, show their shortcuts (Alt to see keyboard shortcuts), and also have enough text to describe all the buttons. But it'd be nice if it were easier to make good Ribbons.
Menu was braindead easy, albeit through ancient process of .rc files and whatnot
The alternative to ribbon is not menu+ quick access, it was easily customizable toolbars where you can simply drag and drop only the buttons you need in the toolbars you need at a fraction of screen space that the ribbon wastes. And no user is ever exposed to that XML garbage only a dev could love
I'm just not sure why it has to be one or the other. Look at NeXTStep. They had a menu bar (or I guess a menu panel) and a ribbon, although that term didn't exist yet, and it was definitely not 100% there yet.
I think it's the other way around. Well organised menus can help users discover what functions are available at quick glance without having to hover each icons with the mouse to know what they do. For power users, the ribbons mean you can click directly on the function you need without having to click through menus and sub-menus.
1 reply →
> The desktop UI was perfected around the time of Windows 95
There’s no need to be hyperbolic or blinded by nostalgia. Yes, user interfaces have suffered several setbacks in the years since, but even if we concede every change was for the worse (they weren’t) it was by no means “perfected” and there was still plenty of area for improvement.
> The desktop UI was perfected around the time of Windows 95 and has gotten worse with every iteration since then.
Well that can't be entirely true, the desktop experience on Windows 10 improved on Windows 8 by leaps and bounds.
> Well that can't be entirely true, the desktop experience on Windows 10 improved on Windows 8 by leaps and bounds.
In large part, windows 10's ui is more like that of windows 95 because it undid the changes away from the windows 95 paradigm that windows 8 did. Furthermore, those changes away from windows 95 in windows 8 were the exact kind of thing that might be called "mobile first".
Haha, yes. It does not account for releases which made UX dramatically worse (win 8) which were then reverted to some extent.
Only because Windows 8 was such a dramatic step back. Windows 7 is still better than Windows 10 in terms of UI.
Not until they settle on one control panel.
I can't tell if this is sarcasm. Windows 8 is a very low bar in terms of desktop UI. It was universally panned as a regression.
Are you nuts? Or wait.. you must be Gen Z then, never really used Win95.. If so, you cant make any statements in the subject.
I still run Windows Classic GUI here, because its fast and confortable to use. Can you do better? Hmm, maybe. But im not conviced :)
8 replies →
95 feels kinda backwards tbh but 98SE/2000 is outrageously modern. A lot of the windows admin tools are unchanged from 2000 apart from the icons. I really think if you could run a modern browser on 2000 it could be a daily driver for most people
As computers, and smartphones got more popular, the audience got larger and the use scenarios got more and more distant from professional use. Dedicated professionals, like software engineers and stock brokers still prefer CLI and Bloomberg terminal even today. Ordinary office workers late 90s and early 00s window-based interfaces (the ones you're talking about). But smartphone users who just want to play their free games and scroll through facebook actually prefer the mobile-first UIs.
If you see this UI transition through the same lense as CLI-GUI one, a lot of things become more clear, in my opinion.
i agree. i love the 120hz responsiveness of the UI. how fast the app loads, the buttons click. No lazy loading , placeholders, layout re-renders. Open the task manager: half a meg ram used.
Insanely great performance.
I agree with you generally but I don't think desktop UI is remotely close to perfected. Unless you mean the desktop as a skeumorphic concept than maybe.
I think we've actually completely stagnate on the human interaction side of OSes and only emacs has made any progress and then only for those willing to put the work in, not as a vanilla user ui.
I just resurrected a 90s kids CD-ROM game that shipped for Windows 3.1 - https://github.com/matthewbloch/orlys-draw-a-story-fixes
The finished patch DLL ended up being a tour of the stuff that broke.
The game did launch on Windows 11 but the main issue was that the 8-bit pre-DirectDraw behaviour was broken - for 256 colour screens, Windows 11 resolvesld palette indices only once, but the game relies on being able to change the palette for fades etc. Most of the screeen ended up black, but you could see the animated parts just fine.
So most of fix ended up being to hook every draw call and implement a virtual GDI that acted like a graphics card of the day.
There was a 32-bit disc space check that overflowed, a couple of use-after-free crashes and some racey threading calls that can't have been tested on a machine with 2 CPUs.
Backwards compatibility from Microsoft was almost all there, and probably would have kept Orly running for a couple of subsequent Windows releases. But it relies on a developer meeting them half-way, it's not an emulation layer.
Makes me wonder if forking Wine to have a "Legacy Windows" compatibility layer... for... modern windows would be worth half a damn.
wine has more backwards compatibility options than Windows itself, but in this project also triggered some different buggy code paths in the original (see cousin comment).
So this game still needed its bugs fixing to run in a modernised Windows, or it would have been stuck in a hardware emulator running Windows 95.
Your project's readme suggests that you tested on Proton. How poorly does the unmodified game run in Proton and/or Wine when you limit it to a single CPU? Very? Somewhat?
Don't know actually!
But after it was working on Windows, I tried it on Crossover and found that MacOS doesn't allow you to pin to one CPU. So it needed a racey scheduler rewriting.
There was also a difference in the way wine provides printer drivers that caused a buggy code path to run in the game, which caused a crash on the Steam Deck too.
So those bugs would have been critical even if the display implementation had worked.
The patch also adds an OpenGL window & scaling filter as the game's primary output, so it doesn't rely on GDI for pixel output any more.
I like that we are amazed by this. And yet all of my books from 34 years ago open up just fine (without cheating, no book opening emulator required!). I can even open a book on my shelf from 1896 without emulation. Not trying to troll too hard but I do think it is shocking how accustomed we've gotten to zero backwards compatibility in the world of software.
a better example would be whether you could put a train from 1845 on a modern track, or fire a musketball from an M16
I think the oldest cartridge that would still work in a modern firearm would be .22 Short, which is from 1857.[1] It was developed into .22 Long, which was developed into .22 Long Rifle, which new firearms are still chambered in today. It wouldn't cycle a semi-auto though. Another contender would be .38 Long Colt, which is from 1875 and will work in firearms chambered in .38 Special or .357 Magnum.
The main causes of incompatibility were the transition from ball-and-powder to rimfire cartridges, then the transition from rimfire to centerfire. It's surprising how little firearms have changed in the past century. 9mm Parabellum is 125 years old. The Browning short recoil action (used by most handguns today) is over a century old.
1. https://en.wikipedia.org/wiki/.22_short
If you live in a country or region where the gauge didn't change, you can put a 1845 train on a modern track just fine. If the gauge did change, you'll need a train from another country. Standard Gauge was first applied in 1825 after all.
Many militaries are still buying rifles that chamber a cartridge introduced in 1891 (7.62x54mmR). I'd argue a cartridge initially developed for a long bolt action rifle (Mosin-Nagant) that can now be fired out of a variant of a AK-patten select-fire bull-pup (Vepr) fits the analogy.
>whether you could put a train from 1845 on a modern track
you can do that, in fact I know that Austria still has a mid 19th century train in regular operation (https://de.wikipedia.org/wiki/SB_alt_23)
if you're looking for commuter trains a lot of early 20th century ones still operate around the world.
Give it a few centuries of evolution and maybe we'll get there
I guess this is one of those proverbial “I had to create an account to comment” messages:
https://m.youtube.com/watch?v=pQHX-SjgQvQ
https://news.ycombinator.com/item?id=50250809
I'm reminded of this amusing and brilliant post: https://blog.hiler.eu/win32-the-only-stable-abi/
> At the time of this post, that’s a 33 years and 8 months old application,
Pointing this out without a trigger warning is just rude ;-)
Some of us are older than we think, yo.
I helped develop a web app used by major drug companies in 2001 that's still in use as far as I can tell. Marvel at the Dreamweaver-enabled design: https://resultview.q2labsolutions.com/resultview/logon/logon...
:-) Nice.
The oldest web app code of my own that I still maintain/evolve turned 20 this year, so yours is older than mine. I think it's largely a Ship of Theseus at this point, though I did just remove some code the other day that was absolutely untouched since 2008.
Speaking of FreeCell, a couple weeks ago I was visiting my 95yr-old grandmother and noticed she still plays oldschool FreeCell, specifically a variant that's really hard to track down now called FreeCell Pro [https://cards.fandom.com/wiki/FreeCell_Pro]
It inspired a weekend project. I always liked that you could swap the card backs in OG FreeCell and play with different "themed" decks, so I vibecoded something a little more modern. I got carried away and added a roguelite mode too (yeah I know how "Roguelite FreeCell" sounds). Anyway, it's free to play on the web, no ads: [https://freecellworlds.com/]
Solitaire's Journey: https://en.wikipedia.org/wiki/Solitaire%27s_Journey
Basically a 1992 rogue-lite where each room is a different solitaire game. eg: front parlor == clock solitaire, first bedroom == regular solitaire, upstairs is blocked by freecell, etc...
Screenshots: https://www.mobygames.com/game/1986/solitaires-journey/scree...
It's a fairly rich concept, you have a ton of different gameplay bound together by a very loose plot/quest mechanisms (eg: blue key == blue door ; boss == win 2 games of solitaire).
Definitely worth sharing if you've got some solitaire fans in your life!
Wow this is amazing! I love this bit from the Wikipedia article:
"In 1996, Computer Gaming World declared Solitaire's Journey the 72nd-best computer game ever released."
The bar has moved up a tad I think :D
1 reply →
Is there a but or maybe I don't know the rules. Sometimes I can't put a long sequence J 10 9 8 7 ... on a Q
Yeah classic FreeCell only lets you move one card at a time. No stacks. A lot of FreeCell implementations have a QoL feature that let you move stacks if there's enough free cells or empty columns to allow the move.
[dead]
Along these lines, I'm always amused with the videos (e.g. https://www.youtube.com/watch?v=C8CIhCTVyqQ) showing you can update a [virtual] device from Windows 3.1 to Windows 11.
In 2026 does it still make sense to build new Windows app using Win32 API? I was building a simple image viewer similar to QuickLook on Mac using Win32. I found it's very responsive. The code is less readable compared to React. For me Win32 is a good option if the UI state machine is simple enough.
While Win32 tends to deliver the most resource-efficient and responsive apps if the complexity is not high, I have settled on the latest .NET + C# + Windows App SDK / WinUI 3. Making an app look good and fit into the modern Windows look is extremely hard with Win32 C/C++ and writing and maintaining it requires energy that I'd rather spend elsewhere. Besides, modern frameworks are making great strides in speed, efficiency and QoL features. .NET 11 is full of optimizations, for example.
I've tried this and found the WinUI deployment model frustrating and user hostile. There are like 5 open issues on GitHub where people seem deeply confused (I'm one of them) as to if it's possible to build a plain .NET .exe. Some people have tried it and it "works", others try it and get obscure errors, it's a real mess.
I think the sweet spot is WPF or actaully its FOSS version: AvaloniaUI. It is high level enough to be cross-platform and not stupidly verbose, however it is rather light pn resources. However, Win32 still wins in absolute minimalism.
yeah, it's still pretty good for a lot of things. I've found with AI it's now super easy to do native win32 apps really easily. It used to be doing all the plumbing was a PITA. There were wrappers to make it easier, but now you can do it directly. It means you get super performant, tiny binaries, that start instantly. Like windows should be. However, at home I've moved to linux a while back so way less useful to me now, though works fine with WINE. I still use it to make little utilities for work though.
Unless your name is Raymond Chen, you probably want to at least use ATL/MFC, which are frozen but still supported. Me, I'd take Qt any day, or wxWidgets if I wanted to go minimal.
I would say WinForms in C# is still the best today.
Win32 API is great and responsive; ATL/WTL (and MFC) are still very useful abstractions with little cost. The biggest pain point is having to handle a lot of things manually, like DPI awareness (and themed controls). Even things like Emoji and other modern text features are not available through GDI and require DirectWrite iirc. Still, I'm surprised how useful it manages to be regardless how old it is.
When you say responsive, you mean like it reacts quickly, or it responds to screen size?
In web we refer to the latter but i feel you mean the former.
I built a toy project in .NET 2005[0] with WinForms and the experience was actually excellent, binding data to controls was dead simple, it felt surprisingly modern. But i can't imagine how I'd make the UI resizable lol
[0]https://github.com/queenkjuul/spotify97
1 reply →
I wouldn't, because I do not think we should put up barriers in our application between OSs (Nor have to maintain separate UI code bases for each OS you think might use it). So I use cross-platform kits. There are compromises, but I don't care about the looks native qualification compared to works anywhere. Yes, the software looks like an EGUI app (etc. Substitute Qt), instead of Looks native, but I appreciate how I'm not setting up barriers between OSs or making extra work.
So instead you are creating a bad UI for all of your users. That’s very Java application (or perhaps Electron these days) of you, but seems like a poor trade-off to me.
1 reply →
These days, with LLM assisted development, with relatively simple GUIs, I would go towards platform native GUIs per platform. And then all the shared business logic goes in a shared "core", with the GUIs only serving as "dumb" inputs and outputs, with all business logic shared between them.
LLMs are quite good at tedious tasks such as keeping multiple GUIs in different languages in sync with each other.
1 reply →
I couldn’t disagree more, when it comes to UIs. They should match the platform they are being used on. Cross-platform always produces a very sub-par experience. But us developers tend to care primarily about what makes development easiest for us.
5 replies →
I also don't care how if things _look_ native, I care if the work like a native app. For example, on the rare occasions I touch Windows, I expect standard keyboard shortcuts to work. On macOS, I expect full integration with the accessibility frameworks and OS affordances like services.
A lowest common denominator idea of "everywhere" is just not that useful.
2 replies →
I am having a blast with AI + C + WinAPI. The responsiveness of WinAPI is awesome
I mean, if I was building a windows app, I would. Microsoft always tries to convince people to stop using it, but Win32 keeps working.
If Microsoft ever makes something that actually meets all the needs that Win32 addresses, they'll probably build a compat layer and a) your win32 code will still work in compat mode, b) that new thing may be worth targeting.
"Can you believe it... Reversi" reminded me of the Steve Ballmer ad for Windows 1.0: https://www.youtube.com/watch?v=DgJS2tQPGKQ
> That is because, duh, my computer doesn’t have a CD-ROM drive. But you can use a small DLL (cdemu.dll) to emulate one with some fake audio data and actually get it to play audio
This makes me curious to know if CDPLAYER.EXE would still work (unmodified, without extra DLLs) with a real CD-ROM drive if you ran it on a Windows 11 machine with one installed.
Tried it. If I open it with a disc in, it shows the "No CDROM devices found" message. If I open it without a disc in, it shows the menu, then when I put in a disc in Windows shows a weird error: https://files.catbox.moe/6y3qpy.png
It acts generally weird (buy a £10 dvd drive from ebay and try it yourself if you want any more detail, useful thing to have anyway) and obviously I can't get it to play anything.
The RTM version gets a bit further, doesn't show that weird Explorer error, but I still can't get it to play anything and opening the playlist crashes it vs on the Beta version where it actually listed the tracks.
I suspect the cd player is trying to take control of the drive and fighting with Windows trying to be helpful, don't know if there's a way to turn it off.
I can't say for certain but recently having done some work on windows with CDROM drives, i strongly suspect it would. I bet you could mount a music CD BIN/CUE with ImgDrive and it would work... Shit i guess i have to go try it don't I
Edit: i meant ImgDrive as a suggestion for those without optical drives. I have several, I'll test em out
I remember having installed Win32s package to our Windows for Workgroups 3.11 machines at Osmangazi University in 1995. The idea was that Windows, as a 16-bit operating system, could run a subset of Win32 apps that were compatible with the Win32s API surface. However, the release of Windows 95 had almost immediately made it obsolete. I'm sure it was useful in certain scenarios, but our only win was Freecell. :)
> The idea was that Windows, as a 16-bit operating system, could run a subset of Win32 apps that were compatible with the Win32s API surface.
386 mode in Windows 2 (sold as Windows/386) and 3 was really a 32-bit operating system for 16-bit applications.
Win32s allowed some 32-bit apps to run on windows 3.1 and up. Including many versions of Internet Explorer (Microsoft also released ie as a 16-bit application, though).
I often think old GUIs have a nice, functional look to them. This one is no exception. I notice (what I assume is) the shuffle toggle looks unfamiliar. This is from way back before that UI became a convention! I see the repeat icon has stuck around. So interesting!
Microsoft (and Apple) poured a ton of money into usability research in the early 90s and it showed. I vaguely remember the story through how many versions of the trash icon Microsoft went for Windows 95 to get it right.
For me it was a bit sad to see the mad and creative UX world of the homecomputer era being bulldozed over with the minimalist uniform results of the scientific usability research.
Little did I know that a mere quarter century later we are back were we once started and everyone as clueless as we were in the 90s goes overboard everywhere as if there was no tomorrow.
Yeah, and it sadly makes me miss the nicely ordered and easily usable world - I'm gettin' old I guess.
Functionality isn't hidden and buttons looked like buttons (instead of the modern trend of having unstyled text or tiny icons having a 50-50 chance of being a button).
The flat design trend really confused me. It really took off when high resolution screens started getting popular too, really made no sense. Wish we'd bring back Skeuomorphic design. Bring back that wood grain and metal textures. Bring back the fun UI's and app themes. Bring back real buttons!
There are a couple versions of the Windows CD player here (along with other operating systems)
https://guidebookgallery.org/screenshots/cdplayer/
I always liked the look of the more complicated ones like this:
https://ctrl-alt-rees.com/2021-09-29-media-rack-download-win...
You don't even have to find old binaries. The ODBC manager is still shipped with Win11 and has Win3.0 / NT3.5 dialogs with 16-color icons.
EasyToon (from 1998, I believe, built for Windows 95) runs on Windows 11. One of my favorite pieces of software.
It's a thing for making little black and white animations. (With GIF export.)
It was popular in the early 2000s and there was a subculture around it on animation forums.
English version (hey, still online!):
https://www.superfundungeonrun.com/easytoon/
Original version (Japanese, w/ screenshots):
https://web.archive.org/web/20020111185602/http://www.radium...
There's also a forked version on a French website (also available in English) with some extra features. But I like to keep it simple :)
https://www.flat2d.com/easytoon.html
Microsoft is known for making Windows run older programs. Apple not so much.
https://solitairealonetogether.com/
There's probably an old X11 app from the 1980s that could be executed through xwayland somewhere.
I can't even run a binary from one Linux distro to the other, let alone one from a random Unix from the 80s. If a rebuild from source is allowed (which would need to allow modifications to the build system) that's a completely different game.
Is this actually a thing?
10 replies →
I've had static binaries on linux machines that worked across distributions for decades.
As an unmodified binary from the 1980s on current Linux/Unix? Highly unlikely.
From the article, the time to beat is November 16, 1992. This might be possible on one of the BSDs, as FreeBSD and NetBSD both document support for running a.out executables with the 4.3BSD ABI. I guess it would depend on whether anyone had ported X11 to run on a BSD on i386 before then. Alternatively, maybe you'd be able to get something running on SCO OpenServer (if you count that as a current OS, it IS still getting security patches). It documents support for XENIX x.out binaries ( https://www.scosales.com/ta/kb/126704.html ) so you might be able to run software compiled in the late 1980s for XENIX/386.
1 reply →
Just used xev today (bought new mouse few days ago and it wasn't responding in chrome so I wanted to be sure).
xwm from 1984 and twm from 1989 will still execute on Xorg today.
And if you want to run them on Wayland, Worg will do that for you. https://github.com/jmalcolm137/Worg
> And although using otvdm does feel like cheating, I thought it was cool enough to include in this post.
Honestly, if NTVDM was part of Windows then it seems fair to use it, even 3rd party clones.
Yeah I was kind of on the fence with this, but since the last version of Windows that shipped with NTVDM was Windows 10 32bit, and Windows 11 doesn't have a 32bit edition, I decided that using 3rd party tools would be cheating
I was aiming for something you could double click on vanilla Windows and would just work out of the box
Very nostalgic. I think UI today is too simplied, but I can't stop making kind of that, because many user are not a member of Hacker News.
Wrote a few small utilities in Win32 in the early 90s; still use them today unmodified, but most recently in WINE. I have some slightly older DOS utilities that are also quite usable.
Here I was thinking it would have been Kedit…
Does visual studio still package the Spy++ exe that looks like its from the early 90's
kudos to microsoft for enabling 40+ years of API support. Most companies are ending support after less than 10 years. some even a few years ( like those Nest thermostats getting killed )
Can you imagine the maze of a diagram that enables these old APIs to draw to the screen and render controls properly still?
If you tried this on Linux desktops you wouldn't get far
That's a year before the first PowerPC Mac even shipped.
> Sadly, Windows 11 can’t run 16-bit Windows programs by itself, because 64-bit Windows has no NTVDM, so we’re going to have to find something from the early NT era.
I remember a recent-ish post on here that really, I mean really, dived deep into this whole thing. It turns out that it was mostly a lack of willpower or maybe political that stopped Windows 64bit running 16 bit apps.
Somewhere in the kernel, with some obscure mechanism there is support for some kind of emulation that if implemented would allow it to run NTVDM and therefore these 16 bit apps.
The author of the post even had some kind of proof of concept of running a 16 bit DOS app directly under Windows 64 bit with this.
The details are blurry, but I believe that that had the Windows team really wanted to this emulation could have been built in and totally seamless.
I got the impression that this was actually a fairly new finding which is why I suppose no one has tried it.
https://felsqualle.com/posts/2022/12/16-bit-support-in-64-bi... is the full story.
but tl;dr is that ntvdm relied on the CPU running 16-bit code, so was naturally EOL on a 64-bit Windows, where that mode doesn't work.
winvdm adds it back via CPU emulation.
I remember the post I read being a black themed site but this is also interesting, thanks
Related: "Chain of Fools : Upgrading through every version of windows (HQ)" (2011), they upgrade Windows 1 through to Windows 7, and demonstrate Doom II and Monkey Island working still at the end. Would be interesting to extend it to Windows 11.
https://www.youtube.com/watch?v=vPnehDhGa14
I can tell that the person making the video never actually tried to run Doom on a real Windows 2000 or XP machine, otherwise they would have noticed that the game has absolutely no sound. Sound support for DOS games in Windows 2000+ was not built into the operating system. You needed to install a third party tool called "VDMSound" if you wanted sound blaster emulation for DOS games.
I'm imagining a future where Microsoft's Copilot pops up in the corner, Clippy style, and gives you a message like, "Hey, I noticed you're running an app that looks like it was developed when Windows Vista was new. Want me to freshen that up for you?" Then it runs a decomp/recomp process that updates the app at the binary machine code level so that it looks and feels like a modern app without any translation layers or weird bugs. No more user complaints about Windows having an inconsistent GUI.
Interesting.
At one tine, Slackware Linux would not recompile binaries unless the program was patched. So there was a time you could find rather old binaries on Slackware, and maybe still on other distros.
I wonder what the oldest unchanged source/program running on Linux or BSD ? My vote goes to cat(1) :)
FreeBSD /bin/cat has lots of recent changes of substance: https://github.com/freebsd/freebsd-src/commits/main/bin/cat/...
Otoh, /usr/bin/true has only minor changes since initial import (1994) https://github.com/freebsd/freebsd-src/commits/main/usr.bin/...
/usr/bin/false is similar
[dead]