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].
it was fun until the end which was a temu ad. Before that there was an emoji that said end automatically, which was no fun. and then there was no cool card shuffling at the end.
Don't visit the link, unless you like feeling let down.
> I wanted old school MS solitaire in windows 11 since the modern version has ads and extra useless features.
> All LG televisions are maintaining a dossier on you and transcribing everything you watch and everything spoken within earshot
These things seem like something we should be responding to with such an extreme disgust response that it's denominated in drone strikes.
Like having a shower liner installed that comes with A Guy With A Peephole who permanently lives in your bathroom now, and that's just something people tolerate. "Switch to tile if you don't like it", they say. No. Sometimes the appropriate response to audacity is to choose violence. It is an implied deterrent against sufficiently offensive antifeatures that nobody has bothered banning them. I shouldn't have to specify that I don't want it, the operating system is just not supposed to be in the business of pushing ads on me, the television is not supposed to be in the business of wiretapping me. These would have been banned long ago if they were known and if we had a functional government.
That guy living in the shower liner is getting disassembled with a Sawzall with extreme prejudice, and frankly that is not sufficient.
The score is a value stored in the Windows registry, the poster probably re-created (or imported from a previous export) the registry entry upon each Windows installation.
One of the first proper jobs I had, I ended up doing unofficial support for the Windows 3.1 machines that they had. I can't remember exactly what I had to do, probably just cleaning temp dirs or something, but I got regularly called to one of my friend's machines.
He liked to play minesweeper and I found that the high scores were just stored in minesweeper.ini or something. I didn't know very much about computers at the time but I could manage that [1].
So, whenever I was on his machine I would edit the file and add my own name with a score that was one second quicker than his.
He got some really good times so I feel it was definitely an encouragement to excellence!
[1] When I was in my 20s I was immortal and knew everything. Now I'm in my 50s, with decades of experience, I am very much mortal and know practically nothing. Strange how life turns out.
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.
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."
Isn't that the same as a win95-style menu? Whenever you want to do an action you have to look for it in the top menu and try right-clicking related objects on-screen.
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
> Long-press and the ••• menu in the overflow is a far superior UI paradigm than having a purpose built menu button.
I disagree - long-press isn't intuitive or discoverable, and it's slow.
You could make a case that they're a good fit for mobile, but they're truly horrible on desktop.
For me, long-press is one of the most infuriating UX features of mobile.
Probably the top on the offenders list for me is the copy-paste with the handles (which of course relies on long-press to trigger).
Hard buttons beat soft buttons for UX any time. You can use them with a glove, you can feel where the are located and you don't accidentally click because your finger was close enough for the capacitive touch sensor to trigger.
God, I hate copy/paste on android. tbh, I hate the whole 'gestures' thing where there never seems to be an actual 'instruction sheet' of what gestures are available. I wish they would make new apps provide a 'manifest' of gestures they support so your phone could have an up to date list based on which apps you have installed.
Worse, when I try to select text from whatever note with important data I have, the first option is "Cut", which means losing data (i.e., data is deleted from the source). "Copy" is hidden behind a hamburger menu. Who was the stupid person at Google who thought this would be good UX??
I’ve replaced the android headunit with a buttons and segmented display one (kenwood) because it was just horrendous. Now, it’s easy to switch sources, skip back and forth, and adjust volume with minimal looking. Tactical feedback and location memory is great UX.
I find that HP/Palm Pre with WebOS was best even if we ignore the physical keyboard (sliding left/right on the touch area below the screen or on the screen with a button pressed really made it easy to select text easily and precisely). Nokia N9 with Maemo/Meego was second best but it excelled in the cards interface for multi-tasking.
Some of those were taken into other OSes but nowhere were they implemented so smoothly.
Agreed. Note the increased spacing to separate the generic "Help" button from the others that are specific to the dialog box. Aligning the buttons to the text input fields would break this separation and it could also give the false impression that the buttons were related to the input fields.
They had a different look, but usage and UI conventions including keyboard navigation worked basically the same. Since the mixing of mobile and desktop with web technology, it’s the Wild West.
- Internet Explorer (frequently introduced new toolbar designs not available to apps via API until later)
- Encarta (custom dark mode-ish theme)
- Netscape Communicator (custom toolbars)
- RealPlayer
- QuickTime
- MSN Messenger (custom theme)
- Every video game ever
... UI inconsistency didn't arrive with the web. Even macOS has always been a patchwork. Apple couldn't stop introducing new themes over time and there were always apps that didn't quite follow. Brushed metal!
Kai's Power Tools / Power Goo / Bryce took the custom interface stuff to the most extreme lengths - people genuinely loved it at the time but I think most would be horrified if anything went that far today.
Ha! I forgot about those. Man I loved playing with Bryce back in the day, what a magical program that was. And yeah the UI was gorgeous for its time. Heck it still looks great even today, tbh.
But they were not too far removed from how the standard Windows buttons looked. Office had its own look in a lot of ways back then, e.g. with the extra handles on the toolbars.
Now, if I take a couple of current applications, the differences are much bigger: from the top of my head, Explorer, Settings, Edge, Office, Steam, Spotify all have much more unique UIs.
There was a short period of time around Windows 95-XP where application developers really wanted to try to use the "latest and greatest" because if they didn't they really stood out as being "last year's tech".
Then XP kind of broke that as so many started not bothering and then it all went sideways.
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."
A couple of the UX people who worked on Win8 told me that some of the UX study results were faked to give the desired results that justified the new Win8 design changes.
Def the sort of stories you hear at at a bar after work.
> therefore we need to make this menu as large as possible
shouldn't the conclusion have been "the start menu is so great the user doesn't even need to focus on using it". it feels like desperately trying to make the data fit the predefined conclusion, despite the data screaming and kicking.
That's really the big problem with the telemetry-driven designs today - the same raw data can be interpreted in whatever way you want so designers still end up doing what they feel like but can shut down any counter arguments (including complaints from real users) with "the data says otherwise".
Yes, I'm glad somebody's pointed that out. I read that post, "Users only click on the start menu 0.1% of the time...", and thought, well yes, what do you think the start menu's for? The user will use it to load something from time to time, then spend all their time in that application.
I've seen similar before - people not understanding that certain things are at their most successful if they're unobtrusive.
You’re not wrong that they aren’t directly correlated. I can see the argument though that making Notes look exactly like a yellow legal pad was not an automatic gain for usability compared to say, wordpad.exe with its super simple toolbar that showed you every option.
I think a fair take is that going full skeuomorphic may take some options off the table for you because they would conflict too much with the metaphor you’re leaning hard into.
I’m still 100% Team Forstall though, considering the massive violence that ios7 and its copycats have wrought on usability.
Some skeuomorphism is user-friendly, like buttons that animate like they're clicked when pressed down. Other skeuomorphism was user-hostile, like the various mouse-only interfaces where everything had to be dragged around to work.
Scroll bars have always been both control (press here to move around) and indicator (how much of this document is there, and how far through it am I?).
Always-on-screen scrollbars are only useless if you think that indication is useless. Many people find it quite valuable.
I'm constantly searching for the scroll bar position on mobile FF because its barely visible. And that's at least on a device where you can make the argument that horizontal screen real estate is limited, unlike a desktop PC where hiding scoll bars to save space makes zero sense at all.
More to the point, the indicator doesn’t need to always be visible to be useful. Appearing only when the viewport is noving works fine on the iPhone, for instance, because slighly moving the viewpoint to reveal it is a convenient action, and less well on desktop PCs where your hands are less likely to remain near movement controls at all times.
It’s also applicaction specific: I care a lot more about relative viewport size and position when reading a long document than I do when I’m entering commands at the bottom of a terminal’s scrollback buffer.
I don't disagree with your overall point. However, I don't find wiggling the scroll wheel on my mouse or a quick two finger swipe on a good touchpad any less convenient than using my thumb to do the same jiggle on my phone.
I do, possibly because I rarely use laptops and tend to lean back away from my desk when reading material on my desktop with its 55” display.
No matter, this is exactly the sort of thing that can and should be implemented as a systemwide user option, possibly with app- or even app-profile level overrides for cases like terminal emulators where users are less likely to prefer full-time scrollbars.
I think elements like scrollbars remaining visible serve a useful purpose of their own. I don't just mean scrollbars in this case depicting the location in the scroll, either, but instead offering a fully predictable interface that looks the same and doesn't depend on state. Elements like scrollbars only appearing when needed- expanding when you hover near them, for example, removes some of the predictability of the interface. If you have elements all over a UI that only appear "when needed" it starts to become a bit of a circus show, IMO; ribbons or toolbars or menus that only appear when you press alt or hover near the top of a window; scrollbars that only appear when you either scroll or move the mouse near the scroll elevator area, etc.
It's some of the same push that has removed titlebars from desktop UI. Programs like Chrome spearheaded effectively taking over that area, because it's a "waste of screen space", But it's not, that screen space was used for a predictable, known UI element that used to be fully expected on all desktop UI Window elements. It's sort of like how we have with writing a predictable convention of words on a page to have margins on the left and right. If that followed the way UX has gone we'd have dismissed page margins as "wasted space" and all text would have 0" margins and run all the way to the edges of the page and we'd pat ourselves on the back for "using page real estate" more effectively.
I do think hiding things can be over done, but it's rare that I have found the lack of a title bar problematic. Most apps don't actually remove it, they just decorate it to match their UI. It still has the standard buttons and can be clicked to drag the app around.
No they don't, they appear every time you scroll even if you never use the bar. And flashing of ui elements is in many cases worse than wasting that space permanently.
It's a tragedy decades of UI research/design can't get any of the fundamental design elements right
I hate when magically appearing scrollbars cause the screen to redraw - I especially hate it when the content needs a scrollbar if NOT present, so it appears, which makes the content reflow so it doesn't need it, and it keeps swapping back and forth.
There has been a bug in Apple's Quicklook on macOS for as long as I can remember, where the right side of a document is slightly cropped when Always Show Scrollbars is enabled. It appears to expect that the scroll bars should only appear intermittently and renders over the content.
Very frustrating when one is scanning documents and photos, and verifying them through Finder shows phantom cropping.
I personally like the scroll bars to always be visible as they serve as both an indicator and a control.
Schrödinger's button - you go to click it, a scroll bar appears, the button moves. You go to the new button location, the scroll bar disappears, the button returns.
They are handy on a tablet. At the same time they are not since dynamic content might be loaded so the true size of the page is not shown to me by the scroll bar.
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.
In both Windows 7 and Vista you could change the theme engine to Windows Classic, which gave you the Windows 9x/2000 look AND the start menu search bar.
Exactly. Windows 7 plus the windows 2000 "classic" option was pretty awesome.
Win10 LTSC with the right options and limiting search to local only is pretty good also though. Insanely snappy on even crap systems (with really any SSD)
I found the transparency of windows in Vista and 7 to be a useless distraction. Found Windows 8.1 to be refreshing in that respect, although the menuless apps were poor.
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.
I actually like Ribbon and I disagree. It made functions easier to find, for people who didn't have a muscle memory of those functions. It actually taught them how to use the program and exposed conditional menus like picture options better than the toolbars that appear and disappear.
Of course people who got used to traversing 3-level menus got annoyed but they still have all the same keyboard shortcuts. However, spending enough time, you also get used to Ribbon and it usually requires fewer clicks not more.
I still find a tastefully done Ribbon is better than a menu and a toolbar combination. The problem is, not everybody has put the same effort that Microsoft did which created monstrosities like Solidworks Ribbon.
I actually find it difficult to scan for a specific function since the most of the text in the ribbon is centered and may have multiple lines. With the current design, I am expected to look up top to check what tab I am on, then look down bottom to find the container that might have my desired functionality, and then finally scan the middle text (which may be one or two lines) for the button.
When Office 2007 was released, they made a lot of noise about how the ribbon was easy to use. One of the key functionality was Preview - that when the mouse cursor moves inside a button, the change is immediately applied to the content and when the cursor moves outside a button, the change was undone.
They never bothered to implement this Preview functionality on the Web version of office, and I bet only a few ever noticed this inconsistency.
I just learned that X Window System came out a year before the first Windows release. Interesting. Thanks for pointing out the compiz ripoff. It spurred me to look up the original release dates.
> 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.
Two things can both be true. An app can create more space around controls and get rid of the menu bar to save space.
The space also really has nothing to do with “mobile first”. It’s for touch screens (and also modern aesthetic that avoids crowded controls).
To be clear, I am not saying that all apps are optimizing for saving screen space. I was specifically talking about browsers, which are broadly optimized to give as much area as possible to the content.
You’re getting closer… “crowded” and “cluttered” are the most taboo words in the “UX” charlatans’ holy book. It’s so scary to them that they’ll sacrifice anything to avoid even a possible accusation of “crowdedness.”
It was a mildly useful point of view when they were designing things meant to be the first computer program someone might ever use. Like Microsoft Bob or Apple “At Ease.” But it’s idiotic to have things following that dogma as the only interface to tools that people need to use daily and will become expert users of.
To think some of us nerds complained about the Luna theme of XP as too “Fisher Price.” Fisher Price products look like industrial control panels compared to today’s contemporary operating systems and apps.
Smaller screen also means your menu bar has to be larger relative to the total screen size to be readable though. Assuming something like the standard going from 15" or 17" CRT to 24" LCD
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".
Totally agree. But this does not take away from his point that maximizing screen space is the motivation in Firefox. In fact, all you have done is demonstrate why they are driven to do so.
It should have said maximizing screen height, not space (on desktop not mobile), in these modern days of widescreen monitors. If we have title bars, menu bars, toolbars etc, while using the full screen width, we're peering through a letterbox. (Fixed headers on websites contribute too.) Line length needs to be kept shorter for readability, leading to wasted space at the sides.
Perhaps, if you're not using a sidebar for bookmarks or vertical tabs or whatever, it suggests something ought to have changed in UI design back when widescreen monitors became the norm?
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.
In fairness I did not do a full inventory of all the apps I use. I see Word and VS Code. It may be less than I thought if I inventoried every app I regularly use.
I see some have gone the “browser” direction with tabs folded into the title bar and the menu bar dropped. Windows Terminal, File Explorer, and Notepad are all that style now.
Edit: Actually Notepad has the tabs in the titlebar thing but retained the menu bar and folded it into the command bar.
I personally am pretty disgusted by ‘tabs in the title bar’ since really what that means is deleting the title bar. You can’t grab and move the freaking window because most of it is made out of a bunch of tabs or other widgets. I presume this is done because somebody’s research found that many people just do everything in maximized windows or the Apple “full screen mode.” As long as you don’t mind sacrificing the people who do use window managers to manage windows, likely the most sophisticated users, this seems like a great move. But I would argue it’s still stupid because I have plenty of screen real estate. Being able to read one additional line of text in my browser window or Slack conversation does literally nothing for me.
I love it. I can grab either end of the title bar just fine. I don't need to waste the entire middle. And if I have multiple windows I'm sacrificing more like 3 lines and it does start to matter.
It’s a tradeoff. I spend most of my time on a laptop screen (even when using an external monitor, the external is my secondary screen) and appreciate the reduction in screen waste. I don’t need or want a huge click area just for moving the window.
My favorite is 3:2 for laptops. 4:3 is a bit tall (screen is fine, but it makes the base much deeper as well). 16:9 is kind of crappy, especially if it’s a smaller screen.
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
This is the part I don't really understand - was the development experience and iteration speed really that much faster moving away from low level languages / APIs? It's in the critical path, it should be stupid fast.
I have some hope that thanks to hardware shortages and AI helping people write software they will rewrite some things back to faster languages. But this is all gut feeling, gut feeling that a lot of modern-day developers are afraid of optimized code.
(I fully acknowledge the hypocrisy, given my bread and butter is JS/TS front-end and I don't like C. But in my defense, there's no market demand for native developers either, barely any Go even, even though a few years ago it looked like a lot of Java backends were getting rewritten)
Yes, it was really that much better. Win32 was an atrocious API even by the standards of the time, and nobody uses it anymore for good reasons. You can't get the kind of UX modern users expect with plain Win32 - even implementing dark mode is a pain in the rear.
But! Something hardly anyone realizes is that you can get native old-school performance with modern frameworks if you do things right. The best example of this I've seen is what happens if you AOT compile JavaFX apps with GraalVM. They start instantly, every bit as fast as a classic Windows 95 era app running on a modern Win11 machine would.
JavaFX is the replacement for Swing in Java world. As GUI frameworks go I actually really like the API - it's not a ReactJS based paradigm that never really gelled for me, the closest JS equivalent might be something like Vue where reactivity is done at the property level instead of via vdom diffing. It is vaguely HTML inspired, so there's an XML based way to define UIs and you can style them with a dialect of CSS, but the whole thing is designed for GUIs from the ground up. Rendering uses the 3D pipeline on each OS (Direct3D, Metal, Vulkan or OpenGL), it's multi-threaded, there are sophisticated widgets for things like rich text editing and table views, properly parallel composited animation APIs etc. When it first came out it was quite futuristic, nowadays I'd say it's just standard.
Anyway, you can make apps with it that feel completely modern to end users, and yet, they start fast and use relatively little memory when AOT compiled. The JVM startup time disappears entirely.
Part of why it's fast is that GraalVM lets you initialize parts of the app statically at build time, so data structures like GUI widgets derived from XML or CSS can be frozen into a heap snapshot and just mmapped in. No startup time computation needed.
So it's possible and we don't have to go back to using legacy APIs to get this kind of performance. A sufficiently smart compiler can work wonders.
> even implementing dark mode is a pain in the rear
You don't need to implement dark mode when all the controls already follow the users system color scheme. Dark mode is a signficiant regression compared to user-adjustable color schemes and another example of designers wanting to enforce their vision over the desires of the user.
They don't follow the user's color scheme properly though. Win32 has been hardly maintained and it's riddled with compatibility problems, so you need to go through a complicated opt-in dance and test thoroughly for any idea introduced in the past 20 years or so. For instance, hidpi support isn't 'free' like it is in any modern toolkit.
Using a library that wraps the native system is also good - eg. wxWidgets. I find it very nice to work with compared to attempting to learn any of the myriad UI attempts Microsoft introduced later.
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
i'm planning to vibe-port some modern software I need to Windows XP. I'm done with the web browser, I'll just vibe native software for the sites I want
> 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 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
Menubars/toolbars were not n00b-friendly but great for anyone that used a computer for technical reasons.
Old Photoshop, any CAD software, Excel. Smaller buttons and more of them is a steeper learning curve but results in far superior day-to-day usability. You can still hold down [Alt] and see hotkeys, that wasn't unique to the Ribbon UI.
it's all very much an example of the "Look at what they need to mimic a fraction of our power" meme.
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.
Menus from Win95 are uniform. All buttons took up one row and a full width of the submenu. (Even if you don't have a shortcut key assigned, the space is taken up and wasted)
It's well acknowledged that modern designers and users benefit from large vs small, and other varying styles of organization.
Menus only had top menus vs submenu vs sub-sub-menu (and so forth). Yes a good menu is useful but...
A ribbon offers many more tradeoffs. It's harder to design a good ribbon, but the best ribbons are always better than even the best menu. The important features will be physically larger with more text and space. The less important or niche features might just be an icon with tooltip, possibly hidden behind a subcategory of the ribbon.
In theory, you can use the modern Ribbon to make old school menus. But why bother? If you made the switch to that XML design language, you might as well take all the benefits of the Ribbon
Or hell, if you like old school menus, you can still make them today. Those .RC editors still work in modern Windows 11. But give it a shot and you'll see how restrictive and bulky old school menus are in practice.
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.
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 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.
> 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".
The thing is one could argue most of the improvements were regressions to previous paradigms. Windows 10 was improved by being less like Windows 8 and more like the classic desktops of the 90s.
In other words, change for the sake of change does not an improvement make.
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.
The software analogies to books (documents of various types like PDF, HTML) don't have pathological obsolescence problems, either. Binary executable code is such a different animal that the comparison isn't instructive at all, or else I suppose you would also complain that you can't fit modern Ford parts onto a Model T because you can still read old books?
> The software analogies to books (documents of various types like PDF, HTML) don't have pathological obsolescence problems, either.
It kind of depends on the document format. PDF tends to display well over time (but there can be issues with complex documents and/or missing fonts), spreadsheets and word processor files are likely to be openable, but they may not display as they originally did. HTML is likely to look rather different than it did when written, but it'll probably be legible.
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.
> It's surprising how little firearms have changed in the past century.
Isn't that a function of constraints in the deployment model, which are fundamentally unchanged? A soldier needs <something> with him to hit enemies and <something else> to reload it - and the simpler the better, to facilitate difficult deployments and keep costs down. I mean, the venerable Kalashnikov is still around, despite its well-known shortcomings...
I guess we would see major developments only if we discovered/engineered materials that can perform the function in a significantly better way.
Modern metallurgy does allow for significantly higher chamber pressures, and this has been done in firearms such as the M7 with its 80,000psi .277 Fury.[1] Pistol cartridges can also be made smaller for the same effectiveness (allowing higher capacity in the same form factor), as has been done with .30 Super Carry.[2] But your guess is correct: They don't really catch on because a small improvement in capacity or effectiveness isn't worth changing all the manufacturing and logistics for new cartridges. 5.56mm and 9mm are good enough, and they're cheap due to their large volume of manufacturing. Any replacement would have to be much better to be worth the cost of changing over.
Most improvements have been in things like modularity, sighting systems, and standardization for mounting accessories such as lights and laser aiming modules. Better metallurgy does mean that modern firearms tend to last longer than older ones, but even a firearm from WWI can fire thousands of rounds before the bore erodes enough to hurt accuracy. I doubt we'll see any significant change in small arms unless something revolutionary comes along, such as portable energy weapons or mass drivers.
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.
Although on modern railways whilst the locomotive might fit, the train might not be allowed to operate in normal mainline traffic or need modifications to be considered safe. A steam train on the British main lines needs to be retrofitted with an alphabet soup of AWS, TPWS and GSM-R, and the glacial rollout of ERTMS and in cab signalling will mean figuring out how to add a HMI display to a steam engine cab.
And Apple might find software that doesn't get their magical signature to be unsafe and insecure, but the old executables will run if you ignore all those constraints.
> whether you could put a train from 1845 on a modern track
This quite literally happens all the time in the UK. There are heritage railways, and steam rolling stock regularly shows up on various routes as part of heritage rides.
On the other hand, I ride almost daily on a track bed that was laid almost 180 years ago, and through tunnels and on viaducts that are equally as old. The rails, sleepers, signals, and rolling stock have all changed, no doubt, but the base infrastructure is old hat.
The oldest bits of the London Underground are from 1863. The tunnels are exactly the same, the stations and stairways, and even some of the sign boards completely unchanged from then.
Railways are the epitome of forever infrastructure.
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.
I think the point made here is that the application runs as if it were a modern application, even though the OS is completely unrecognizable when compared to the OS it was written for. There are other ways to run old applications on modern hardware with modern OSs, which the author would consider cheating for the purpose of TFA. Heck, I can run ancient DOS and gaming console applications on my phone if I wanted to.
Veering off a bit more: books written in 1896 may not be readable any longer. Not because the ink faded, or the paper got stuck, but because the spelling and vocabulary changed, or the type font has been relegated to the dust bin (think Fraktur).
It is amazing, though. Wintel is basically a Matryoshka doll (Russian nesting dolls), where each version contains all the previous versions. (Just look at how a PC boots up!)
The dedication to compatibility is commendable, and you don't really see it on the other OS's. On that note, this is one of my favorite articles:
I was the system tester for "a modern Internet-based application" in 1996 used by a global logistics company. Fast forward 25 years and I went to local logistic branch to ship out some packages. Out of curiosity, I peeked over the desk to look at what software they were using. It was the same 25-year old "modern Internet-based application".
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!
I played a lot of FCPro back in the 1990s. As noted at the link, it had more possible games, automated stack movement if you had enough free spaces, had unlimited undo/redo, and had solvers (that could either solve it for you, or just tell you that a solution was still possible - the latter was immensely helpful in letting me get better at the game).
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.
One of the few things you can’t fault MS for is backwards compatibility. My GP has an absolute archaic..err..ERP? (sorry, I have no idea how to refer to these apps) for managing patient records that seemingly “just works” on Windows 11. As a many-decade Linux user, hats off to MS.
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.
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.
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.
It's definitely possible to build a self-contained EXE. It's not easy or the default for a number of reasons, including the fact that going back even to DOS the PC application deployment model for applications is folders full of shared library DLLs and a smaller EXE that makes use of them. (The Win32 page model was built on it.) Modern .NET excels in that, including in the classic DOS installer model of "just copy the files, no installer required (but you'll probably build one anyway for extra branding opportunities and a few bonuses)".
Some .NET versions <= 4 installed a lot of their DLLs globally in Windows and if you were exact version tolerant enough (and GAC binding magic lucky enough) you could distribute a single EXE without an installer and expect some number of Windows users it would "just work" with only the EXE (and other users you would get complex dances of Windows Updates and .NET Installers to debug). Modern .NET decided on the classic DOS style "folder of DLLs" model over "global DLL cache and DLL Hell". You can no longer assume that the output EXE can "just work" on some supported Windows machines, but can better assume that the output folder of DLLs and EXE will work as intended generally on every supported Windows machine.
Not everything is flowers and sunshine (got a couple of open issues myself... in .NET MAUI too), but whether one can build a single, compact, self-contained exe does not define the hostility of a framework or platform, IMO. .NET was conceived as an enterprise-friendly development framework and that's where it shines the most. Quick-and-dirty/mean-and-lean/distribute-and-forget development was never its forte. I would appreciate that feature too, but it's largely a non-issue.
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.
In 2026 with WINE, Win32 is a surprisingly handy cross-platform GUI toolkit with surprisingly relaxed licensing restrictions. WINE even helps maintain the cross-platform support for modern .NET's (.NET 6+) System.Windows.Forms which allows you to write Win32 in a modern language stack with relatively modern conveniences.
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.
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
WinForms provided some responsive control patterns like "anchors" and "dock" properties [0] and other sorts of relative positioning. Some third party component libraries included even more advanced layout controls. A lot of applications would add in imperative code to make up for more complex scenarios that anchors/dock didn't handle well enough. WinForms was still built on the back of pixel-perfect positioning assumptions, so there was always people doing it manually with handwritten/hand-tuned math.
It is something I appreciate about WPF and other successors is that responsive layouts became the default and low level building blocks with "pixel perfect" harder to do and less of an "after thought" on top of pixel perfect WYSIWYG that's easy to get responsive wrong, but even with WinForms people were building responsive apps back in the day.
Windows apps always had to be able to respond to dynamically changing screen dimensions since the user could change from one screen resolution to another while an app was still running. Apps would get a WM_DISPLAYCHANGE message in their top-level windows message processing loop. Docs say WM_DISPLAYCHANGE was introduced in Win95.
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.
As someone who does raw Win32 API based UI... no. The Win32 UI system has been neglected for many years and is missing very basic functionality by modern standards, including dark mode support, antialiased rendering, hardware accelerated image stretching, and wide color gamut / HDR support. You're going to be working around a lot of ancient restrictions compared to a more modern UI and rendering layers on top of it.
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.
You still need to test all of those separate GUIs though so it's still costing more.
You also generally don't want them to actually be in sync because there are actual UX differences between platforms that you need to align with to really be native. If you don't follow that then what's the point?
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.
What does this mean in practice for software you write? What OSes to you build it for, and what OS or GUI-specific conventions to you follow which don't apply to others?
edit: Link software you wrote's installation instructions.
- You have made the choice to make software only run on MacOS, excluding the (majority) of users who are not using that. This is balanced against the upside of native look and feel.
- I agree that web and mobile have many differences when comparing them to each other, or to PC software. The differences and conventions which relate to application development between Windows, MacOs, and Linux are much smaller than those. (The only concrete example mentioned in this broader discussion was Home and End keys can have different behavior). I see this as a matter of degree, not kind.
I keep coming back to "So, we are deliberately limiting our software to a single OS because... (Vaguely articulated reasons about native look and feel? About cross-platform applications having "bad UIs" and "subpar results"? I can't do anything with that because it's too vague, and doesn't match my experience. Home and End keys or other keyboard shortcuts which are easy to feature-gate if the GUI kit doesn't handle it which it probably does?) When weighing pros and cons, I need to see the cons.
What specifically to you about cross-platform UI means bad job? I.e. what functionality does Windows specifically support that must work when running the application on Windows that Gnome, for example doesn't? (Or any other GUI/OS comparison)
A lot of it boils down to native widget look and feel. It's pretty silly in reality because there are multiple possible options for what is native on Windows (Win32/WinForms, WPF, UWP, WinUI, ...) and Linux (Qt, GTK, ...), so native apps will still be inconsistent. It's probably just an Apple thing really, because every other platform is already a big mix of different UI styles.
The way you worded this message could mean either a) people should focus on a single platform using native frameworks, or b) people should use a cross-platform framework instead of spreading themselves too thin. Maybe even both?
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.
How do you handle this for your own software? Could you please link me to one of your project's websites and install instructions? What specifically do you find that one OS has that's mandatory for a good/native UIs that others don't?
I hear you on the native UI is better all things considered. I'm trying to figure out how that works in practice. I.e., to accompany a "cross-platform UIs are inferior to native ones", you would be effective to also include the workflows you use. In a realm where you choose options, eliminating one should come with illuminating another, as one must choose a path, and others could be eliminated for their drawbacks as well, leaving none available. What is your path here?
No - almost all of the software I work on is at least one of:
- proprietary,
- command line tooling,
- single-platform.
A good example of what I consider to be a great approach (not mine) is Ghostty, which has fully native UI per platform and a shared core between platforms. JetBrains tools also go out of their way to integrate with platform conventions everywhere.
An example that cross-platform toolkits usually get wrong: cursor navigation in text fields. Home and End do different things on different platforms, and on macOS, basic emacs/readline bindings are supposed to work in all text entry fields.
It’s worth noting that this extends beyond GUIs - command line tools written in Go tend to use “package flag” which is native nowhere. The standards between Windows (which has two, in cmd and powershell), GNU-style and “legacy” Unix style are just not reconcilable without implementing platform-specific behaviour.
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.
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 big win of Win32S was getting developers to build Win32 apps ahead of the Windows 95 launch. Especially Win32S was one of the necessary building blocks to convincing some game developers that Windows was finally a good platform for game development rather than just assuming Windows could be exited and returned to DOS. Windows 95's launch would have been a lot less smooth if Win32S hadn't paved a lot of the way.
> 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!
This is one of those moments you are surprised to learn when someone has discovered something you just knew.
Freecell was the demo app in Win32s for Windows 3. It is thus several years older than NT as a retail OS.
I have downloaded Win32s and extracted Freecell from it, just to play the game on Win10 LTSC and Win11. Probably more than once in fact.
The default Freecell in 21st century Windows is an ugly blinged-out mess, and in minimal installations, there are no games at all. This is the quick easy way around it.
Win32s was concurrent with NT 3.1 (1993), and requires Windows 3.1 (1992) as 3.0 doesn’t know how to load PE EXEs. However it also appeared in Microsoft Entertainment Pack 2 in 1991, so a Win16 version that will run on 3.0 and predates NT does exist.
I was not really active in computing back then, so I don't know how widely distributed these releases were, but NT was clearly gestating longer than Win32s.
> 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
Is browser compatibility that durable? I would think that both java-script and CSS would be subject to some level of compatibility rot against a browser from 2056
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.
I had to run a Linux binary compiled for Ubuntu 10.something a few years ago. I couldn't get the drivers to work properly in libvirt and getting the binary to run on modern Linux was practically impossible, even with 32 bit support installed.
The downside of dynamically linked binaries: every tool of medium complexity needs a close-enough version of a common library, and once those get upgraded, the tool dies.
Most statically compiled version should work with a compatible enough libc, but I haven't seen many old programs like that.
Wine, on the other hand, runs tools from the 90s just fine, as long as they're 32 bit.
You don't need to go full static linking. Just bundle every library that doesn't have string backwards guarantees or rather bundle everything except base system libraires. The same is also how things work on Windows (and thus Wine really). Wine won't be able to run a binary that links to some random libpng or whatever that the compiler found in your System32. The only difference is that Microsoft makes an SDK that gives your some idea of whats a system library you can rely on as well as the ability to target older versions than the system you are building on. The latter can be done on Linux as well but there is no-pre made SDK so the easiest solution ends up being a VM or chroot with older libraries.
> Just bundle [...] everything except base system libraires
That means everything above libc. There are no "base system libraries" in the Linux world for GUI. Not even libX11, that has been deprecated in favour of libxcb, which has been deprecated in favour of not having X11 and running Wayland. Some days I am amazed that the ELF binary format hasn't been deprecated yet...
LibX11 is still alive and kicking. It is however possible to bundle libX11 and/or libxcb (libX11 today sits on top of libxcb) because the wire protocol between them and the X server is also backwards compatible.
And of course Wayland has XWayland to continue compatibility. This doesn't give you access to new toys but neither does restricting yourself to a 30-year old Win32 API.
And beyond libc/libX11/libxcb, libasound has also provided good backwards compatibility with newer systems implementing shims to make it work. You can also use libpulse directly if you don't care about old/opinionated systems though.
Many programs are dynamically linked to at the very least, libc. If the system libc is older than what the binary was developed for, it will often fail. Failures going the other direction are less common, but can and do still happen. If the binary was statically linked with everything it needs, you've got a pretty good chance it'll work, but that's a bit harder to do with GUI programs that need to interact with X or Wayland.
It depends. I've found for example, if i compile on Ubuntu or Debian, it will probably work on any Ubuntu, Debian, or Debian-based distro released at or newer than the one I compiled it on. There are other cross-compatible examples.
More broadly, there are things like manylinux and MUSL which allow cross-distro applications.
I agree - the model I use for why containers (Docker etc) exist is to abstract over Linux ABI incompatibility. I don't think they're a great solution, as it complicates software distribution. I should be able to distribute an executable and have it just work.
Linux isn't the source of the incompatibility. The kernel itself is very strict about not breaking userspace. Your userspace is breaking compatibility on its own, containers fix it by shipping the userspace components within the container, which only works because the kernel maintained compatibility. If the kernel broke compatibility you would need to use a VM so you can run a different kernel version.
Hah well yes for Windows. This is a mercy, but my mindset is still "Works on Windows, Linux and Mac". (The last being dropped for anything that requires Cuda...)
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.
NetBSD has excellent binary compatible with 80s "unix", the problem is most (all?) of the 80s unix platforms it supports aren't x86.
Current NetBSD still has good support for running SunOS binaries, though, including graphical ones. I'm certain you could get a SunOS 4.x binary from pre-1992 to run on NetBSD/SPARC. I've no idea how far back you could potentially go on NetBSD/m68k -- probably quite a ways, especially if the binaries are statically linked. SunOS pre-1988 was all static linking!
(Running "real" 4.3BSD binaries might be hard -- I think NetBSD/VAX defaults to ULTRIX compat, which is an either/or thing versus strict Berkeley Unix compatibility. Same binary format, similar but incompatible syscalls/data structures.)
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.
Perhaps even more interesting winfile.exe the original Windows 3 File Manager was even updated (including a few open source contributions) with a few modern conveniences. There's not a lot of reason for launching progman.exe in Windows 11, but you might be surprised what you can do with winfile.exe still to this day, when you want a break from File Explorer.
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) :)
Source compatibility is surprisingly good, binary compatibility is surprisingly awful, even with Slack.
I have some old Linux CDROM games from ~2000 that are nigh impossible to run, and even a lot of really old software fails to run on old (2.x) kernels without recompilation. But Slackware 4.x wasn't particularly good at this in my testing (i started on a slackware-based retro computing distro[0] but my HDD died with no backup before i finished it)
I mean, other than installing an old distro in old hardware, which i do enjoy. I got a CD copy of Mandrake Gaming Edition on eBay with a bundled port of SimCity 3000 that's very good at running old commercial Linux games.
I think there's people shipping ancient glibc with flatpaks to accomplish this today
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
it was fun until the end which was a temu ad. Before that there was an emoji that said end automatically, which was no fun. and then there was no cool card shuffling at the end.
Don't visit the link, unless you like feeling let down.
Better use
https://cards.jlogical.com/
Its way nicer and open source:
https://github.com/JLogical-Apps/cards
very bad performance :/
Note, this is not FreeCell[1], it is Klondike.
[1]: https://en.wikipedia.org/wiki/FreeCell
wrong solitaire
> I wanted old school MS solitaire in windows 11 since the modern version has ads and extra useless features.
> All LG televisions are maintaining a dossier on you and transcribing everything you watch and everything spoken within earshot
These things seem like something we should be responding to with such an extreme disgust response that it's denominated in drone strikes.
Like having a shower liner installed that comes with A Guy With A Peephole who permanently lives in your bathroom now, and that's just something people tolerate. "Switch to tile if you don't like it", they say. No. Sometimes the appropriate response to audacity is to choose violence. It is an implied deterrent against sufficiently offensive antifeatures that nobody has bothered banning them. I shouldn't have to specify that I don't want it, the operating system is just not supposed to be in the business of pushing ads on me, the television is not supposed to be in the business of wiretapping me. These would have been banned long ago if they were known and if we had a functional government.
That guy living in the shower liner is getting disassembled with a Sawzall with extreme prejudice, and frankly that is not sufficient.
> are you able to keep her high score saved too?
The score is a value stored in the Windows registry, the poster probably re-created (or imported from a previous export) the registry entry upon each Windows installation.
I’m still installing the classic (Windows 7) calculator [0] on each new Windows setup.
[0] https://win7games.com/#calc
One of the first proper jobs I had, I ended up doing unofficial support for the Windows 3.1 machines that they had. I can't remember exactly what I had to do, probably just cleaning temp dirs or something, but I got regularly called to one of my friend's machines.
He liked to play minesweeper and I found that the high scores were just stored in minesweeper.ini or something. I didn't know very much about computers at the time but I could manage that [1].
So, whenever I was on his machine I would edit the file and add my own name with a score that was one second quicker than his.
He got some really good times so I feel it was definitely an encouragement to excellence!
[1] When I was in my 20s I was immortal and knew everything. Now I'm in my 50s, with decades of experience, I am very much mortal and know practically nothing. Strange how life turns out.
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.
This is what posting is all about
She was right, the modern freecell sucks
Thank you for sharing this. It was heartwarming to read!
Bless. You’re a good egg.
<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.
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."
Isn't that the same as a win95-style menu? Whenever you want to do an action you have to look for it in the top menu and try right-clicking related objects on-screen.
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
> Long-press and the ••• menu in the overflow is a far superior UI paradigm than having a purpose built menu button.
I disagree - long-press isn't intuitive or discoverable, and it's slow. You could make a case that they're a good fit for mobile, but they're truly horrible on desktop.
For me, long-press is one of the most infuriating UX features of mobile. Probably the top on the offenders list for me is the copy-paste with the handles (which of course relies on long-press to trigger).
Hard buttons beat soft buttons for UX any time. You can use them with a glove, you can feel where the are located and you don't accidentally click because your finger was close enough for the capacitive touch sensor to trigger.
God, I hate copy/paste on android. tbh, I hate the whole 'gestures' thing where there never seems to be an actual 'instruction sheet' of what gestures are available. I wish they would make new apps provide a 'manifest' of gestures they support so your phone could have an up to date list based on which apps you have installed.
Worse, when I try to select text from whatever note with important data I have, the first option is "Cut", which means losing data (i.e., data is deleted from the source). "Copy" is hidden behind a hamburger menu. Who was the stupid person at Google who thought this would be good UX??
I’ve replaced the android headunit with a buttons and segmented display one (kenwood) because it was just horrendous. Now, it’s easy to switch sources, skip back and forth, and adjust volume with minimal looking. Tactical feedback and location memory is great UX.
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 find that HP/Palm Pre with WebOS was best even if we ignore the physical keyboard (sliding left/right on the touch area below the screen or on the screen with a button pressed really made it easy to select text easily and precisely). Nokia N9 with Maemo/Meego was second best but it excelled in the cards interface for multi-tasking.
Some of those were taken into other OSes but nowhere were they implemented so smoothly.
And the world has been improved for it ever since. What a waste of screen real-estate these buttons were...
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.
<cough>scanner drivers<cough>
It's been that way forever, did you forget about the Borland buttons? Colorful icons on them, much bigger, different shading.
> Borland buttons
Wow, you unlocked a memory. In case somebody doesn't remember, or doesn't know, the style of Borland buttons, here's a screenshot: https://sourceforge.net/p/owlnext/wiki/Replacing_usage_of_BW...
Some more screenshots on this page: https://www.drbob42.com/delphi/findmapc.htm
(Look at all those misaligned icons/labels in the Tool Options screenshot!)
On the contrary, they seem to be placed like that on purpose.
Agreed. Note the increased spacing to separate the generic "Help" button from the others that are specific to the dialog box. Aligning the buttons to the text input fields would break this separation and it could also give the false impression that the buttons were related to the input fields.
They had a different look, but usage and UI conventions including keyboard navigation worked basically the same. Since the mixing of mobile and desktop with web technology, it’s the Wild West.
It was always the wild west. Windows was full of "native" apps that reinvented their own UI. Off the top of my head:
- Office (custom widget toolkit, menus, toolbars, etc)
- Internet Explorer (frequently introduced new toolbar designs not available to apps via API until later)
- Encarta (custom dark mode-ish theme)
- Netscape Communicator (custom toolbars)
- RealPlayer
- QuickTime
- MSN Messenger (custom theme)
- Every video game ever
... UI inconsistency didn't arrive with the web. Even macOS has always been a patchwork. Apple couldn't stop introducing new themes over time and there were always apps that didn't quite follow. Brushed metal!
Kai's Power Tools / Power Goo / Bryce took the custom interface stuff to the most extreme lengths - people genuinely loved it at the time but I think most would be horrified if anything went that far today.
https://mprove.de/script/99/kai/index.html
Ha! I forgot about those. Man I loved playing with Bryce back in the day, what a magical program that was. And yeah the UI was gorgeous for its time. Heck it still looks great even today, tbh.
How is Winamp not on this list?!
For all those instances, at least keyboard navigation worked. Modern UIs are impossible to use with the keyboard.
But they were not too far removed from how the standard Windows buttons looked. Office had its own look in a lot of ways back then, e.g. with the extra handles on the toolbars.
Now, if I take a couple of current applications, the differences are much bigger: from the top of my head, Explorer, Settings, Edge, Office, Steam, Spotify all have much more unique UIs.
There was a short period of time around Windows 95-XP where application developers really wanted to try to use the "latest and greatest" because if they didn't they really stood out as being "last year's tech".
Then XP kind of broke that as so many started not bothering and then it all went sideways.
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."
A couple of the UX people who worked on Win8 told me that some of the UX study results were faked to give the desired results that justified the new Win8 design changes.
Def the sort of stories you hear at at a bar after work.
how do you go from
> the users don't focus on this menu much
to
> therefore we need to make this menu as large as possible
shouldn't the conclusion have been "the start menu is so great the user doesn't even need to focus on using it". it feels like desperately trying to make the data fit the predefined conclusion, despite the data screaming and kicking.
That's really the big problem with the telemetry-driven designs today - the same raw data can be interpreted in whatever way you want so designers still end up doing what they feel like but can shut down any counter arguments (including complaints from real users) with "the data says otherwise".
Yes, I'm glad somebody's pointed that out. I read that post, "Users only click on the start menu 0.1% of the time...", and thought, well yes, what do you think the start menu's for? The user will use it to load something from time to time, then spend all their time in that application.
I've seen similar before - people not understanding that certain things are at their most successful if they're unobtrusive.
Skeumorphism is the opposite of user hostile. Flat design. Now THAT is user hostile.
You’re not wrong that they aren’t directly correlated. I can see the argument though that making Notes look exactly like a yellow legal pad was not an automatic gain for usability compared to say, wordpad.exe with its super simple toolbar that showed you every option.
I think a fair take is that going full skeuomorphic may take some options off the table for you because they would conflict too much with the metaphor you’re leaning hard into.
I’m still 100% Team Forstall though, considering the massive violence that ios7 and its copycats have wrought on usability.
Skeumorphism where "things look like real things" can be fine. Complete skeumorphism where "things act like real things" is user hostile.
The poster boy for that is the old QuickTime Player, which had a volume wheel and a drawer for shortcuts. https://www.johnforde.com/teaching/shame/qtime.htm
Some skeuomorphism is user-friendly, like buttons that animate like they're clicked when pressed down. Other skeuomorphism was user-hostile, like the various mouse-only interfaces where everything had to be dragged around to work.
Extremes are usually wrong. Skeumorphism and flat design are both user hostile; Windows 95 is a very good compromise between the two.
But with Web 2.0 we got rounded corners for popups etc.
The war on scroll bars has gotten pretty senseless.
Always-on-screen scrollbars were useless. Now they appear only when needed.
Scroll bars have always been both control (press here to move around) and indicator (how much of this document is there, and how far through it am I?).
Always-on-screen scrollbars are only useless if you think that indication is useless. Many people find it quite valuable.
Correct, but you don't need the full thick scrollbar for the indicator function, some apps use a much smaller dot/guide
I'm constantly searching for the scroll bar position on mobile FF because its barely visible. And that's at least on a device where you can make the argument that horizontal screen real estate is limited, unlike a desktop PC where hiding scoll bars to save space makes zero sense at all.
More to the point, the indicator doesn’t need to always be visible to be useful. Appearing only when the viewport is noving works fine on the iPhone, for instance, because slighly moving the viewpoint to reveal it is a convenient action, and less well on desktop PCs where your hands are less likely to remain near movement controls at all times.
It’s also applicaction specific: I care a lot more about relative viewport size and position when reading a long document than I do when I’m entering commands at the bottom of a terminal’s scrollback buffer.
I don't disagree with your overall point. However, I don't find wiggling the scroll wheel on my mouse or a quick two finger swipe on a good touchpad any less convenient than using my thumb to do the same jiggle on my phone.
I do, possibly because I rarely use laptops and tend to lean back away from my desk when reading material on my desktop with its 55” display.
No matter, this is exactly the sort of thing that can and should be implemented as a systemwide user option, possibly with app- or even app-profile level overrides for cases like terminal emulators where users are less likely to prefer full-time scrollbars.
That would've been a much better argument when we were rocking 640x480 screens. 15 pixels out of 1,920 is hardly a sacrifice for the added utility.
I think elements like scrollbars remaining visible serve a useful purpose of their own. I don't just mean scrollbars in this case depicting the location in the scroll, either, but instead offering a fully predictable interface that looks the same and doesn't depend on state. Elements like scrollbars only appearing when needed- expanding when you hover near them, for example, removes some of the predictability of the interface. If you have elements all over a UI that only appear "when needed" it starts to become a bit of a circus show, IMO; ribbons or toolbars or menus that only appear when you press alt or hover near the top of a window; scrollbars that only appear when you either scroll or move the mouse near the scroll elevator area, etc. It's some of the same push that has removed titlebars from desktop UI. Programs like Chrome spearheaded effectively taking over that area, because it's a "waste of screen space", But it's not, that screen space was used for a predictable, known UI element that used to be fully expected on all desktop UI Window elements. It's sort of like how we have with writing a predictable convention of words on a page to have margins on the left and right. If that followed the way UX has gone we'd have dismissed page margins as "wasted space" and all text would have 0" margins and run all the way to the edges of the page and we'd pat ourselves on the back for "using page real estate" more effectively.
I do think hiding things can be over done, but it's rare that I have found the lack of a title bar problematic. Most apps don't actually remove it, they just decorate it to match their UI. It still has the standard buttons and can be clicked to drag the app around.
No they don't, they appear every time you scroll even if you never use the bar. And flashing of ui elements is in many cases worse than wasting that space permanently.
It's a tragedy decades of UI research/design can't get any of the fundamental design elements right
I restored them and made them fat again in FireFox. It was getting too thin and hard to find
I hate when magically appearing scrollbars cause the screen to redraw - I especially hate it when the content needs a scrollbar if NOT present, so it appears, which makes the content reflow so it doesn't need it, and it keeps swapping back and forth.
Good times.
There has been a bug in Apple's Quicklook on macOS for as long as I can remember, where the right side of a document is slightly cropped when Always Show Scrollbars is enabled. It appears to expect that the scroll bars should only appear intermittently and renders over the content.
Very frustrating when one is scanning documents and photos, and verifying them through Finder shows phantom cropping.
I personally like the scroll bars to always be visible as they serve as both an indicator and a control.
It's really annoying that you need to click on something that the scrollbar covers up or steals focus from.
Schrödinger's button - you go to click it, a scroll bar appears, the button moves. You go to the new button location, the scroll bar disappears, the button returns.
They are handy on a tablet. At the same time they are not since dynamic content might be loaded so the true size of the page is not shown to me by the scroll bar.
And fuck anyone that likes fullscreen programs and uses multiple monitors.
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.
The early Mac made huge functional improvements over the Smalltalk GUI, improvements still used today.
> 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.
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.
In both Windows 7 and Vista you could change the theme engine to Windows Classic, which gave you the Windows 9x/2000 look AND the start menu search bar.
Exactly. Windows 7 plus the windows 2000 "classic" option was pretty awesome.
Win10 LTSC with the right options and limiting search to local only is pretty good also though. Insanely snappy on even crap systems (with really any SSD)
I found the transparency of windows in Vista and 7 to be a useless distraction. Found Windows 8.1 to be refreshing in that respect, although the menuless apps were poor.
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.
I actually like Ribbon and I disagree. It made functions easier to find, for people who didn't have a muscle memory of those functions. It actually taught them how to use the program and exposed conditional menus like picture options better than the toolbars that appear and disappear.
Of course people who got used to traversing 3-level menus got annoyed but they still have all the same keyboard shortcuts. However, spending enough time, you also get used to Ribbon and it usually requires fewer clicks not more.
I still find a tastefully done Ribbon is better than a menu and a toolbar combination. The problem is, not everybody has put the same effort that Microsoft did which created monstrosities like Solidworks Ribbon.
> It made functions easier to find
I actually find it difficult to scan for a specific function since the most of the text in the ribbon is centered and may have multiple lines. With the current design, I am expected to look up top to check what tab I am on, then look down bottom to find the container that might have my desired functionality, and then finally scan the middle text (which may be one or two lines) for the button.
When Office 2007 was released, they made a lot of noise about how the ribbon was easy to use. One of the key functionality was Preview - that when the mouse cursor moves inside a button, the change is immediately applied to the content and when the cursor moves outside a button, the change was undone.
They never bothered to implement this Preview functionality on the Web version of office, and I bet only a few ever noticed this inconsistency.
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...
The zune theme is great, now on my XP machines i use a mod of the MCE theme called Royale Noir which is my absolute favorite.
https://images.sftcdn.net/images/t_optimized,f_auto/p/5c889a...
I loved Windows Aero and the flip 3D view - the latter mostly because it looked so cool for that time!
Oh you mean "ripping off compiz"?
I just learned that X Window System came out a year before the first Windows release. Interesting. Thanks for pointing out the compiz ripoff. It spurred me to look up the original release dates.
... which is "ripping off OSX". But you don't want to hear that, do you?
UX being copied by OSes from each other is a good thing.
Lol. Check when linux had multiple desktops and when osx had them.
If you're a tachyon I guess linux is ripping off osx :)
> 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.
Two things can both be true. An app can create more space around controls and get rid of the menu bar to save space.
The space also really has nothing to do with “mobile first”. It’s for touch screens (and also modern aesthetic that avoids crowded controls).
To be clear, I am not saying that all apps are optimizing for saving screen space. I was specifically talking about browsers, which are broadly optimized to give as much area as possible to the content.
You’re getting closer… “crowded” and “cluttered” are the most taboo words in the “UX” charlatans’ holy book. It’s so scary to them that they’ll sacrifice anything to avoid even a possible accusation of “crowdedness.”
It was a mildly useful point of view when they were designing things meant to be the first computer program someone might ever use. Like Microsoft Bob or Apple “At Ease.” But it’s idiotic to have things following that dogma as the only interface to tools that people need to use daily and will become expert users of.
To think some of us nerds complained about the Luna theme of XP as too “Fisher Price.” Fisher Price products look like industrial control panels compared to today’s contemporary operating systems and apps.
Smaller screen also means your menu bar has to be larger relative to the total screen size to be readable though. Assuming something like the standard going from 15" or 17" CRT to 24" LCD
> 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.
My browser doesn’t have a bunch of dead space. No footer. One line for controls. Tabs have been collapsed into the title bar.
Compare latest Chrome to version 30 or something and toolbars are almost double the height.
Use a different browser?
All modern browsers are the same in this regard.
I loathe mobile first design, seems to me it's "mobile matters, on other devices just deal with it.".
The Wells Fargo website screams this for me - it used to be dense and packed with info, now it's got large elements and wasted space.
> 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".
You think Hacker News’ design is new? It’s looked exactly the same since I started using it over a decade ago.
Totally agree. But this does not take away from his point that maximizing screen space is the motivation in Firefox. In fact, all you have done is demonstrate why they are driven to do so.
Maximized screen space doesn't really benefit this site.
The key element missing from this thread is that the Internet going from a text based to a multi-media (and increasingly video-centric) experience.
A lot of Internet users, at this point, do as much reading on their phone or laptop as I do reading on my TV (almost none).
It should have said maximizing screen height, not space (on desktop not mobile), in these modern days of widescreen monitors. If we have title bars, menu bars, toolbars etc, while using the full screen width, we're peering through a letterbox. (Fixed headers on websites contribute too.) Line length needs to be kept shorter for readability, leading to wasted space at the sides.
Perhaps, if you're not using a sidebar for bookmarks or vertical tabs or whatever, it suggests something ought to have changed in UI design back when widescreen monitors became the norm?
> 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.
In fairness I did not do a full inventory of all the apps I use. I see Word and VS Code. It may be less than I thought if I inventoried every app I regularly use.
I see some have gone the “browser” direction with tabs folded into the title bar and the menu bar dropped. Windows Terminal, File Explorer, and Notepad are all that style now.
Edit: Actually Notepad has the tabs in the titlebar thing but retained the menu bar and folded it into the command bar.
I personally am pretty disgusted by ‘tabs in the title bar’ since really what that means is deleting the title bar. You can’t grab and move the freaking window because most of it is made out of a bunch of tabs or other widgets. I presume this is done because somebody’s research found that many people just do everything in maximized windows or the Apple “full screen mode.” As long as you don’t mind sacrificing the people who do use window managers to manage windows, likely the most sophisticated users, this seems like a great move. But I would argue it’s still stupid because I have plenty of screen real estate. Being able to read one additional line of text in my browser window or Slack conversation does literally nothing for me.
I love it. I can grab either end of the title bar just fine. I don't need to waste the entire middle. And if I have multiple windows I'm sacrificing more like 3 lines and it does start to matter.
It’s a tradeoff. I spend most of my time on a laptop screen (even when using an external monitor, the external is my secondary screen) and appreciate the reduction in screen waste. I don’t need or want a huge click area just for moving the window.
Speaking of screen waste, I think 4:3 is way better than 16:9, especially for laptop screens.
My favorite is 3:2 for laptops. 4:3 is a bit tall (screen is fine, but it makes the base much deeper as well). 16:9 is kind of crappy, especially if it’s a smaller screen.
This is one thing I love about macOS: always a menu bar, always just one, in a consistent predictable place where Fitt's law makes it easy to access.
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
This is the part I don't really understand - was the development experience and iteration speed really that much faster moving away from low level languages / APIs? It's in the critical path, it should be stupid fast.
I have some hope that thanks to hardware shortages and AI helping people write software they will rewrite some things back to faster languages. But this is all gut feeling, gut feeling that a lot of modern-day developers are afraid of optimized code.
(I fully acknowledge the hypocrisy, given my bread and butter is JS/TS front-end and I don't like C. But in my defense, there's no market demand for native developers either, barely any Go even, even though a few years ago it looked like a lot of Java backends were getting rewritten)
Yes, it was really that much better. Win32 was an atrocious API even by the standards of the time, and nobody uses it anymore for good reasons. You can't get the kind of UX modern users expect with plain Win32 - even implementing dark mode is a pain in the rear.
But! Something hardly anyone realizes is that you can get native old-school performance with modern frameworks if you do things right. The best example of this I've seen is what happens if you AOT compile JavaFX apps with GraalVM. They start instantly, every bit as fast as a classic Windows 95 era app running on a modern Win11 machine would.
JavaFX is the replacement for Swing in Java world. As GUI frameworks go I actually really like the API - it's not a ReactJS based paradigm that never really gelled for me, the closest JS equivalent might be something like Vue where reactivity is done at the property level instead of via vdom diffing. It is vaguely HTML inspired, so there's an XML based way to define UIs and you can style them with a dialect of CSS, but the whole thing is designed for GUIs from the ground up. Rendering uses the 3D pipeline on each OS (Direct3D, Metal, Vulkan or OpenGL), it's multi-threaded, there are sophisticated widgets for things like rich text editing and table views, properly parallel composited animation APIs etc. When it first came out it was quite futuristic, nowadays I'd say it's just standard.
Anyway, you can make apps with it that feel completely modern to end users, and yet, they start fast and use relatively little memory when AOT compiled. The JVM startup time disappears entirely.
Part of why it's fast is that GraalVM lets you initialize parts of the app statically at build time, so data structures like GUI widgets derived from XML or CSS can be frozen into a heap snapshot and just mmapped in. No startup time computation needed.
So it's possible and we don't have to go back to using legacy APIs to get this kind of performance. A sufficiently smart compiler can work wonders.
> even implementing dark mode is a pain in the rear
You don't need to implement dark mode when all the controls already follow the users system color scheme. Dark mode is a signficiant regression compared to user-adjustable color schemes and another example of designers wanting to enforce their vision over the desires of the user.
They don't follow the user's color scheme properly though. Win32 has been hardly maintained and it's riddled with compatibility problems, so you need to go through a complicated opt-in dance and test thoroughly for any idea introduced in the past 20 years or so. For instance, hidpi support isn't 'free' like it is in any modern toolkit.
https://learn.microsoft.com/en-us/windows/apps/desktop/moder...
Using a library that wraps the native system is also good - eg. wxWidgets. I find it very nice to work with compared to attempting to learn any of the myriad UI attempts Microsoft introduced later.
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.
How can it be related to perfection to permanently waste a strip of space you rarely (and in some apps never) use?
Windows95 still had failures of UI design, and those weren't fixed until XP.
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
i'm planning to vibe-port some modern software I need to Windows XP. I'm done with the web browser, I'll just vibe native software for the sites I want
> 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.
Wasn't that Windows 8 ?
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
Menubars/toolbars were not n00b-friendly but great for anyone that used a computer for technical reasons.
Old Photoshop, any CAD software, Excel. Smaller buttons and more of them is a steeper learning curve but results in far superior day-to-day usability. You can still hold down [Alt] and see hotkeys, that wasn't unique to the Ribbon UI.
it's all very much an example of the "Look at what they need to mimic a fraction of our power" meme.
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.
Menus from Win95 are uniform. All buttons took up one row and a full width of the submenu. (Even if you don't have a shortcut key assigned, the space is taken up and wasted)
It's well acknowledged that modern designers and users benefit from large vs small, and other varying styles of organization.
Menus only had top menus vs submenu vs sub-sub-menu (and so forth). Yes a good menu is useful but...
A ribbon offers many more tradeoffs. It's harder to design a good ribbon, but the best ribbons are always better than even the best menu. The important features will be physically larger with more text and space. The less important or niche features might just be an icon with tooltip, possibly hidden behind a subcategory of the ribbon.
In theory, you can use the modern Ribbon to make old school menus. But why bother? If you made the switch to that XML design language, you might as well take all the benefits of the Ribbon
Or hell, if you like old school menus, you can still make them today. Those .RC editors still work in modern Windows 11. But give it a shot and you'll see how restrictive and bulky old school menus are in practice.
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.
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 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 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.
The thing is one could argue most of the improvements were regressions to previous paradigms. Windows 10 was improved by being less like Windows 8 and more like the classic desktops of the 90s.
In other words, change for the sake of change does not an improvement make.
Not until they settle on one control panel.
And make it actually work well. I'll take the old 9x era control panel over the new text-only, harder-to-navigate settings app.
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.
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.
The software analogies to books (documents of various types like PDF, HTML) don't have pathological obsolescence problems, either. Binary executable code is such a different animal that the comparison isn't instructive at all, or else I suppose you would also complain that you can't fit modern Ford parts onto a Model T because you can still read old books?
> The software analogies to books (documents of various types like PDF, HTML) don't have pathological obsolescence problems, either.
It kind of depends on the document format. PDF tends to display well over time (but there can be issues with complex documents and/or missing fonts), spreadsheets and word processor files are likely to be openable, but they may not display as they originally did. HTML is likely to look rather different than it did when written, but it'll probably be legible.
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
> It's surprising how little firearms have changed in the past century.
Isn't that a function of constraints in the deployment model, which are fundamentally unchanged? A soldier needs <something> with him to hit enemies and <something else> to reload it - and the simpler the better, to facilitate difficult deployments and keep costs down. I mean, the venerable Kalashnikov is still around, despite its well-known shortcomings...
I guess we would see major developments only if we discovered/engineered materials that can perform the function in a significantly better way.
Modern metallurgy does allow for significantly higher chamber pressures, and this has been done in firearms such as the M7 with its 80,000psi .277 Fury.[1] Pistol cartridges can also be made smaller for the same effectiveness (allowing higher capacity in the same form factor), as has been done with .30 Super Carry.[2] But your guess is correct: They don't really catch on because a small improvement in capacity or effectiveness isn't worth changing all the manufacturing and logistics for new cartridges. 5.56mm and 9mm are good enough, and they're cheap due to their large volume of manufacturing. Any replacement would have to be much better to be worth the cost of changing over.
Most improvements have been in things like modularity, sighting systems, and standardization for mounting accessories such as lights and laser aiming modules. Better metallurgy does mean that modern firearms tend to last longer than older ones, but even a firearm from WWI can fire thousands of rounds before the bore erodes enough to hurt accuracy. I doubt we'll see any significant change in small arms unless something revolutionary comes along, such as portable energy weapons or mass drivers.
1. https://en.wikipedia.org/wiki/.277_Fury
2. https://en.wikipedia.org/wiki/.30_Super_Carry
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.
Although on modern railways whilst the locomotive might fit, the train might not be allowed to operate in normal mainline traffic or need modifications to be considered safe. A steam train on the British main lines needs to be retrofitted with an alphabet soup of AWS, TPWS and GSM-R, and the glacial rollout of ERTMS and in cab signalling will mean figuring out how to add a HMI display to a steam engine cab.
And Apple might find software that doesn't get their magical signature to be unsafe and insecure, but the old executables will run if you ignore all those constraints.
> whether you could put a train from 1845 on a modern track
This quite literally happens all the time in the UK. There are heritage railways, and steam rolling stock regularly shows up on various routes as part of heritage rides.
On the other hand, I ride almost daily on a track bed that was laid almost 180 years ago, and through tunnels and on viaducts that are equally as old. The rails, sleepers, signals, and rolling stock have all changed, no doubt, but the base infrastructure is old hat.
The oldest bits of the London Underground are from 1863. The tunnels are exactly the same, the stations and stairways, and even some of the sign boards completely unchanged from then.
Railways are the epitome of forever infrastructure.
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.
you just put out the bat signal for two types of geeks & nerds
Why train when you can just walk? (yeah this a snarky remark to the grandparent comment)
>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.
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
I think the point made here is that the application runs as if it were a modern application, even though the OS is completely unrecognizable when compared to the OS it was written for. There are other ways to run old applications on modern hardware with modern OSs, which the author would consider cheating for the purpose of TFA. Heck, I can run ancient DOS and gaming console applications on my phone if I wanted to.
Veering off a bit more: books written in 1896 may not be readable any longer. Not because the ink faded, or the paper got stuck, but because the spelling and vocabulary changed, or the type font has been relegated to the dust bin (think Fraktur).
https://xkcd.com/1909/
It is amazing, though. Wintel is basically a Matryoshka doll (Russian nesting dolls), where each version contains all the previous versions. (Just look at how a PC boots up!)
The dedication to compatibility is commendable, and you don't really see it on the other OS's. On that note, this is one of my favorite articles:
Win32 is the only stable ABI on Linux
https://blog.hiler.eu/win32-the-only-stable-abi/
I think that's very funny. Speaking of which, EasyToon also runs in WINE, of course :)
https://news.ycombinator.com/item?id=50250809
Give it a few centuries of evolution and maybe we'll get there
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...
I was the system tester for "a modern Internet-based application" in 1996 used by a global logistics company. Fast forward 25 years and I went to local logistic branch to ship out some packages. Out of curiosity, I peeked over the desk to look at what software they were using. It was the same 25-year old "modern Internet-based application".
If it ain't broke I guess. Long live ELMO!
:-) 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
I played a lot of FCPro back in the 1990s. As noted at the link, it had more possible games, automated stack movement if you had enough free spaces, had unlimited undo/redo, and had solvers (that could either solve it for you, or just tell you that a solution was still possible - the latter was immensely helpful in letting me get better at the game).
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.
Ah I see, I get it now.
Not surprising in the least. You can even run 8-bit DOS that has GUI if you want to count mouse + ASCII as GUI.
Now show me your oldest working Linux Desktop apps.....
One of the few things you can’t fault MS for is backwards compatibility. My GP has an absolute archaic..err..ERP? (sorry, I have no idea how to refer to these apps) for managing patient records that seemingly “just works” on Windows 11. As a many-decade Linux user, hats off to MS.
Would probably be Emacs for me
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.
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.
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.
Why not use something like wxWidgets?
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.
It's definitely possible to build a self-contained EXE. It's not easy or the default for a number of reasons, including the fact that going back even to DOS the PC application deployment model for applications is folders full of shared library DLLs and a smaller EXE that makes use of them. (The Win32 page model was built on it.) Modern .NET excels in that, including in the classic DOS installer model of "just copy the files, no installer required (but you'll probably build one anyway for extra branding opportunities and a few bonuses)".
Some .NET versions <= 4 installed a lot of their DLLs globally in Windows and if you were exact version tolerant enough (and GAC binding magic lucky enough) you could distribute a single EXE without an installer and expect some number of Windows users it would "just work" with only the EXE (and other users you would get complex dances of Windows Updates and .NET Installers to debug). Modern .NET decided on the classic DOS style "folder of DLLs" model over "global DLL cache and DLL Hell". You can no longer assume that the output EXE can "just work" on some supported Windows machines, but can better assume that the output folder of DLLs and EXE will work as intended generally on every supported Windows machine.
Not everything is flowers and sunshine (got a couple of open issues myself... in .NET MAUI too), but whether one can build a single, compact, self-contained exe does not define the hostility of a framework or platform, IMO. .NET was conceived as an enterprise-friendly development framework and that's where it shines the most. Quick-and-dirty/mean-and-lean/distribute-and-forget development was never its forte. I would appreciate that feature too, but it's largely a non-issue.
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.
In 2026 with WINE, Win32 is a surprisingly handy cross-platform GUI toolkit with surprisingly relaxed licensing restrictions. WINE even helps maintain the cross-platform support for modern .NET's (.NET 6+) System.Windows.Forms which allows you to write Win32 in a modern language stack with relatively modern conveniences.
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.
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
WinForms provided some responsive control patterns like "anchors" and "dock" properties [0] and other sorts of relative positioning. Some third party component libraries included even more advanced layout controls. A lot of applications would add in imperative code to make up for more complex scenarios that anchors/dock didn't handle well enough. WinForms was still built on the back of pixel-perfect positioning assumptions, so there was always people doing it manually with handwritten/hand-tuned math.
It is something I appreciate about WPF and other successors is that responsive layouts became the default and low level building blocks with "pixel perfect" harder to do and less of an "after thought" on top of pixel perfect WYSIWYG that's easy to get responsive wrong, but even with WinForms people were building responsive apps back in the day.
[0] https://learn.microsoft.com/en-us/dotnet/desktop/winforms/co...
Probably more responsive.
Windows apps always had to be able to respond to dynamically changing screen dimensions since the user could change from one screen resolution to another while an app was still running. Apps would get a WM_DISPLAYCHANGE message in their top-level windows message processing loop. Docs say WM_DISPLAYCHANGE was introduced in Win95.
I would say WinForms in C# is still the best today.
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.
As someone who does raw Win32 API based UI... no. The Win32 UI system has been neglected for many years and is missing very basic functionality by modern standards, including dark mode support, antialiased rendering, hardware accelerated image stretching, and wide color gamut / HDR support. You're going to be working around a lot of ancient restrictions compared to a more modern UI and rendering layers on top of it.
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.
Could you please clarify why you think cross-platform means bad UI?
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.
You still need to test all of those separate GUIs though so it's still costing more.
You also generally don't want them to actually be in sync because there are actual UX differences between platforms that you need to align with to really be native. If you don't follow that then what's the point?
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.
What does this mean in practice for software you write? What OSes to you build it for, and what OS or GUI-specific conventions to you follow which don't apply to others?
edit: Link software you wrote's installation instructions.
You can just look at my profile and see some of it, or check out my website. I’ll have a new app to show soon, so stay tuned!
Those are web and mobile apps... Not PC software.
web and mobile are both platforms with their own special quirks, APIs, and behaviors. however, you missed that Logbook Ed also runs on macOS.
I will just throw this out there:
- You have made the choice to make software only run on MacOS, excluding the (majority) of users who are not using that. This is balanced against the upside of native look and feel.
- I agree that web and mobile have many differences when comparing them to each other, or to PC software. The differences and conventions which relate to application development between Windows, MacOs, and Linux are much smaller than those. (The only concrete example mentioned in this broader discussion was Home and End keys can have different behavior). I see this as a matter of degree, not kind.
I keep coming back to "So, we are deliberately limiting our software to a single OS because... (Vaguely articulated reasons about native look and feel? About cross-platform applications having "bad UIs" and "subpar results"? I can't do anything with that because it's too vague, and doesn't match my experience. Home and End keys or other keyboard shortcuts which are easy to feature-gate if the GUI kit doesn't handle it which it probably does?) When weighing pros and cons, I need to see the cons.
Not everyone has the resources to build five or six different UIs.
I think it’s better to do a good job once rather than five or six bad jobs, but we all have different priorities.
What specifically to you about cross-platform UI means bad job? I.e. what functionality does Windows specifically support that must work when running the application on Windows that Gnome, for example doesn't? (Or any other GUI/OS comparison)
A lot of it boils down to native widget look and feel. It's pretty silly in reality because there are multiple possible options for what is native on Windows (Win32/WinForms, WPF, UWP, WinUI, ...) and Linux (Qt, GTK, ...), so native apps will still be inconsistent. It's probably just an Apple thing really, because every other platform is already a big mix of different UI styles.
The way you worded this message could mean either a) people should focus on a single platform using native frameworks, or b) people should use a cross-platform framework instead of spreading themselves too thin. Maybe even both?
I suppose it’s hard to follow a thread across multiple comments, but like I said, cross platform UI toolkits give sub-par results.
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.
How do you handle this for your own software? Could you please link me to one of your project's websites and install instructions? What specifically do you find that one OS has that's mandatory for a good/native UIs that others don't?
I hear you on the native UI is better all things considered. I'm trying to figure out how that works in practice. I.e., to accompany a "cross-platform UIs are inferior to native ones", you would be effective to also include the workflows you use. In a realm where you choose options, eliminating one should come with illuminating another, as one must choose a path, and others could be eliminated for their drawbacks as well, leaving none available. What is your path here?
No - almost all of the software I work on is at least one of:
- proprietary,
- command line tooling,
- single-platform.
A good example of what I consider to be a great approach (not mine) is Ghostty, which has fully native UI per platform and a shared core between platforms. JetBrains tools also go out of their way to integrate with platform conventions everywhere.
An example that cross-platform toolkits usually get wrong: cursor navigation in text fields. Home and End do different things on different platforms, and on macOS, basic emacs/readline bindings are supposed to work in all text entry fields.
It’s worth noting that this extends beyond GUIs - command line tools written in Go tend to use “package flag” which is native nowhere. The standards between Windows (which has two, in cmd and powershell), GNU-style and “legacy” Unix style are just not reconcilable without implementing platform-specific behaviour.
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.
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 big win of Win32S was getting developers to build Win32 apps ahead of the Windows 95 launch. Especially Win32S was one of the necessary building blocks to convincing some game developers that Windows was finally a good platform for game development rather than just assuming Windows could be exited and returned to DOS. Windows 95's launch would have been a lot less smooth if Win32S hadn't paved a lot of the way.
> 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...
The ones that tried to look like a HiFi stack always got me
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
This is one of those moments you are surprised to learn when someone has discovered something you just knew.
Freecell was the demo app in Win32s for Windows 3. It is thus several years older than NT as a retail OS.
I have downloaded Win32s and extracted Freecell from it, just to play the game on Win10 LTSC and Win11. Probably more than once in fact.
The default Freecell in 21st century Windows is an ugly blinged-out mess, and in minimal installations, there are no games at all. This is the quick easy way around it.
Win32s was concurrent with NT 3.1 (1993), and requires Windows 3.1 (1992) as 3.0 doesn’t know how to load PE EXEs. However it also appeared in Microsoft Entertainment Pack 2 in 1991, so a Win16 version that will run on 3.0 and predates NT does exist.
The beta was the year before NT.
https://winworldpc.com/product/win32s/beta
Win32s beta: October 1992.
NT 3.1: July 1993.
That's long enough to gestate a human being. And back then, a year was a long time. :-)
NT prereleases started in 1991
https://winworldpc.com/product/windows-nt-3x/nt-os-2
I was not really active in computing back then, so I don't know how widely distributed these releases were, but NT was clearly gestating longer than Win32s.
Not hugely, and on the metred local call dialup in the UK it would have been phenomenally expensive to download it.
I was working in IT and I deployed NT 3.1 in production in 1993. I never saw the betas.
Win32s was a small floppy sized thing, and some installed it just for the game, I think.
Win32s was developed and released concurrently with Windows NT. It was a compatibility layer for Win32, which didn’t even exist prior to Windows NT.
As I note above, Win32s was around the year before NT 3.1.
> 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
https://solitairealonetogether.com/
Software rot is why I love the [Single-File Web App](https://gods.art/articles/single_file_web_apps) pattern so much
Is browser compatibility that durable? I would think that both java-script and CSS would be subject to some level of compatibility rot against a browser from 2056
"Can you believe it... Reversi" reminded me of the Steve Ballmer ad for Windows 1.0: https://www.youtube.com/watch?v=DgJS2tQPGKQ
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.
Yesterday I built a binary in an Ubuntu 24.04 Podman container and tried to run it on my Debian Bookworm system:
Because I have glibc 2.36, you see.The other way around works fine, though, and you can avoid it by statically linking the binary when you build it.
In the last week or two I was looking at the changelog of an app or driver, might have been one shown here, maybe even cross-platform.
One of the recent efforts completed was removal of support for Ubuntu 24.04. That part I remember exactly :\
I had to run a Linux binary compiled for Ubuntu 10.something a few years ago. I couldn't get the drivers to work properly in libvirt and getting the binary to run on modern Linux was practically impossible, even with 32 bit support installed.
The downside of dynamically linked binaries: every tool of medium complexity needs a close-enough version of a common library, and once those get upgraded, the tool dies.
Most statically compiled version should work with a compatible enough libc, but I haven't seen many old programs like that.
Wine, on the other hand, runs tools from the 90s just fine, as long as they're 32 bit.
You don't need to go full static linking. Just bundle every library that doesn't have string backwards guarantees or rather bundle everything except base system libraires. The same is also how things work on Windows (and thus Wine really). Wine won't be able to run a binary that links to some random libpng or whatever that the compiler found in your System32. The only difference is that Microsoft makes an SDK that gives your some idea of whats a system library you can rely on as well as the ability to target older versions than the system you are building on. The latter can be done on Linux as well but there is no-pre made SDK so the easiest solution ends up being a VM or chroot with older libraries.
> Just bundle [...] everything except base system libraires
That means everything above libc. There are no "base system libraries" in the Linux world for GUI. Not even libX11, that has been deprecated in favour of libxcb, which has been deprecated in favour of not having X11 and running Wayland. Some days I am amazed that the ELF binary format hasn't been deprecated yet...
LibX11 is still alive and kicking. It is however possible to bundle libX11 and/or libxcb (libX11 today sits on top of libxcb) because the wire protocol between them and the X server is also backwards compatible.
And of course Wayland has XWayland to continue compatibility. This doesn't give you access to new toys but neither does restricting yourself to a 30-year old Win32 API.
And beyond libc/libX11/libxcb, libasound has also provided good backwards compatibility with newer systems implementing shims to make it work. You can also use libpulse directly if you don't care about old/opinionated systems though.
AFAIK Wine will run 16-bit applications just fine now, through WoW64.
Many programs are dynamically linked to at the very least, libc. If the system libc is older than what the binary was developed for, it will often fail. Failures going the other direction are less common, but can and do still happen. If the binary was statically linked with everything it needs, you've got a pretty good chance it'll work, but that's a bit harder to do with GUI programs that need to interact with X or Wayland.
It depends. I've found for example, if i compile on Ubuntu or Debian, it will probably work on any Ubuntu, Debian, or Debian-based distro released at or newer than the one I compiled it on. There are other cross-compatible examples.
More broadly, there are things like manylinux and MUSL which allow cross-distro applications.
Containers fix this.
As long as the container bundles the right libc, the program should work.
I agree - the model I use for why containers (Docker etc) exist is to abstract over Linux ABI incompatibility. I don't think they're a great solution, as it complicates software distribution. I should be able to distribute an executable and have it just work.
Linux isn't the source of the incompatibility. The kernel itself is very strict about not breaking userspace. Your userspace is breaking compatibility on its own, containers fix it by shipping the userspace components within the container, which only works because the kernel maintained compatibility. If the kernel broke compatibility you would need to use a VM so you can run a different kernel version.
That's what win32 is for...
Hah well yes for Windows. This is a mercy, but my mindset is still "Works on Windows, Linux and Mac". (The last being dropped for anything that requires Cuda...)
Win32 is the stable ABI for Linux, too.
Just like Python venv, The system is too broken that it's the only real practical fix
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.
NetBSD has excellent binary compatible with 80s "unix", the problem is most (all?) of the 80s unix platforms it supports aren't x86.
Current NetBSD still has good support for running SunOS binaries, though, including graphical ones. I'm certain you could get a SunOS 4.x binary from pre-1992 to run on NetBSD/SPARC. I've no idea how far back you could potentially go on NetBSD/m68k -- probably quite a ways, especially if the binaries are statically linked. SunOS pre-1988 was all static linking!
(Running "real" 4.3BSD binaries might be hard -- I think NetBSD/VAX defaults to ULTRIX compat, which is an either/or thing versus strict Berkeley Unix compatibility. Same binary format, similar but incompatible syscalls/data structures.)
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
404
Either the repo doesn't exist or it's private
Microsoft is known for making Windows run older programs. Apple not so much.
> 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
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.
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.
Somewhere in Windows 11 23H2 (maybe newer - I haven't looked) is the Windows 3 program manager application.
Perhaps even more interesting winfile.exe the original Windows 3 File Manager was even updated (including a few open source contributions) with a few modern conveniences. There's not a lot of reason for launching progman.exe in Windows 11, but you might be surprised what you can do with winfile.exe still to this day, when you want a break from File Explorer.
It's archived again now, but: https://github.com/microsoft/winfile
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.
Meanwhile, my 9-year old ipad cannot display half the web anymore.
Does visual studio still package the Spy++ exe that looks like its from the early 90's
2022 has Spy++ v17, 2010 has Spy++ v10 with no visual differences, but yeah, still using the old MDI gui for both.
If you tried this on Linux desktops you wouldn't get far
That's a year before the first PowerPC Mac even shipped.
Is that a misguided dig at Apple? I can still run plenty of my old Mac apps, some of them from as far back as 2025 or 2026 /s
Here I was thinking it would have been Kedit…
Linux and Mac could never
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?
Wine can run 16-bit Windows programs so it has better backwards compatibility than Windows itself.
> 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.
google_play_hn
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
Source compatibility is surprisingly good, binary compatibility is surprisingly awful, even with Slack.
I have some old Linux CDROM games from ~2000 that are nigh impossible to run, and even a lot of really old software fails to run on old (2.x) kernels without recompilation. But Slackware 4.x wasn't particularly good at this in my testing (i started on a slackware-based retro computing distro[0] but my HDD died with no backup before i finished it)
I mean, other than installing an old distro in old hardware, which i do enjoy. I got a CD copy of Mandrake Gaming Edition on eBay with a bundled port of SimCity 3000 that's very good at running old commercial Linux games.
I think there's people shipping ancient glibc with flatpaks to accomplish this today
[0] https://github.com/queenkjuul/basiclinux-lcars