Retrowin32, a Win32 emulator
neugierig.org
neugierig.org
I'm reminded of FamiTracker, one of these traditional Win32 (MFC eew) apps which has managed to survive into the modern day with a technological stack largely unchanged, outside of newer compilers and me replacing DirectSound with WASAPI in Dn-FT. But even in simple apps there's a surprising amount of complexity, ranging from threading deadlocks from poor architecture, to a Wine bug causing the window to fail to redraw when resized (https://bugs.winehq.org/show_bug.cgi?id=52903, related https://bugs.winehq.org/show_bug.cgi?id=52515).
PuTTY, for example, uses MFC (I’d completely forgotten MFC was a thing until I had to write a custom port of PuTTY for a previous company ~5 years ago).
I'm not a Windows developer, and had to learn it while working on this upgrade. The MFC documentation has clearly atrophied, but has far as I can tell, there's also not blessed upgrade path for C++ applications.
There is C++/WinRT + WinUI 3, but looking at the screenshot that will pretty much require re-designing the whole UI so it's not going to be a simple upgrade.
Also, what counts as a single file? You can ship a (modern) C# app as a single-file executable. It will be hundreds of megabytes, but to the user, it's just a single file.
We really need open source, community-maintained versions of things like Rosetta so that old apps written for different architectures or even different operating systems can continue to run on modern operating systems. I applaud the author. We need more people like that interested in this stuff.
> There are other projects to run old Windows programs. WoW64 is the name of the system within 64-bit Windows that makes old 32-bit Windows programs run. Wine shims the Windows API onto your host system — see the great How Wine works for a deep dive on what that means. And system emulator projects like qemu emulate a full x86 machine such that you can install Windows onto them. But Wow64 requires running 64-bit Windows, Wine requires x86 hardware, and qemu requires installing the full Windows OS into the emulator to run a Windows program.
2) you do not need qemu (or any other emulation layer) to run wine
For example here is a video of using box86 on a Raspberry Pi 4 to run Windows games with Steam and Proton:
Maybe win32 will become the stable ABI for the browser too ;)
> Linux churns so much that a given program written today won't work in a year
I don't think that's true. It's more like "programs written 20 years ago (against glibc 1.x) don't work on recent Linux anymore"
> programs written in the Windows 95 32-bit era are guaranteed to never change again
Yeah, well, programs written for Linux 20 years ago also never change again. That's the whole point of closed-source binary-only programs...
> [windows executables are an] accumulation of cruft over literally decades.
Linux ELF file formats also contain ancient bits and pieces that are not used anymore. And the a.out "cruft" has only been finally removed this week
> Yeah, well, programs written for Linux 20 years ago also never change again. That's the whole point of closed-source binary-only programs...
This sentence is poorly phrased, but from the context it looks like they meant: programs written in the Windows 95 32-bit era are guaranteed to continue running without ever changing again
It'd be interesting if a company like Adobe open sourced everything at the 20 year mark.
Hobbyists and enthusiasts would love them for it.
This needs the caveat of how well written those programs were: even with all the compatibility features modern Windows have, some programs did abuse the underlying APIs and had memory issues.
Also some programs at the time used "thunking" to mix 16bit and 32bit code (via DLLs) or simply used some DOS-based programs for some tasks even though the "main" program was 32bit, so those wont work with 64bit Windows. AFAIK Borland C++ 5 is a case of an application doing both, even though the main IDE is 32bit (and works in modern Windows), some of the helper stuff relies on DOS and Win16 code that doesn't work.
Yes I can make it work as well, but that could likely have been the experience described
Technically Linux-the-kernel can run programms written 20 (and more) years just fine, it is the libraries that are the problem. However FWIW some libraries, like OpenGL, xlib and glibc do provide backwards compatibility - assuming no blatant abuse is done.
I made this test[0] in 2018 by compiling some binaries with a toolkit of mine in some ancient RedHat Linux from 1997 and they were working perfectly fine in 2018 Debian since it didn't rely on libraries that change their APIs/ABIs every time there is a new fashion. I haven't repeated it recently but i'm pretty sure a similar test with binaries from 1997 that only rely on libraries with stable ABIs will still work on my current openSUSE Tumbleweed installation, showing that more than two decades of backwards compatibility could be possible.
> I think I started thinking about this idea when I read the remark "win32 is the stable Linux userland ABI". That is, Linux churns so much that a given program written today won't work in a year; meanwhile, programs written in the Windows 95 32-bit era are guaranteed to never change again.
I think the point is that the Linux kernel ABI is super stable, but the Linux userland ABI (meaning, the system libraries your program uses) has breaking changes.
Traditionally, Linux binaries aren't distributed with their libraries; it's expected that the distro will place the libraries in the right version and in the correct place. Unfortunately distros rarely keep around old libraries indefinitely. This means that distributed binaries will eventually fail to run. (get any .deb from an old Debian and try to run on a new Debian, it likely won't work. Now, get any installer from Windows and try to run.. on Wine, it will probably work)
So, if you want stability, you need to use one of those package formats that bundle the application and all its libraries (like Snap, AppImage and Flatpak), that looks awfully like Windows installers :t except that Windows application don't need to bundle system libraries like the libc, because Windows extends their stability guarantees to dlls like user32.dll - that is, Windows has a _stable userland ABI_. Contrast this with Linux, where glibc is known to break from time to time.
So.. suppose you have a binary to run but doesn't have all of its libraries - the binary expects that system libraries are to be found at their well known places. Would you prefer this binary to be a Linux binary, or a Windows binary? Since Linux can run Windows programs just fine (or sometimes, better than Windows) with Wine, win32 might as well be the stable userland that Linux is missing
Linux also has a stable userland ABI, it is just that unlike Windows said stable ABI does way less. You can make very advanced programs with the stable APIs Windows provide, since they feature not only simple console stuff, I/O, etc but also user interfaces with widgets[0], 3D graphics, audio, video[1], etc.
Also glibc is stable if a program relies on public APIs, the breakage comes from programs relying on stuff they weren't meant to use. The biggest annoyance (not only with glibc but most libraries) is that you have to build your program on a system with the oldest libraries you plan on supporting (this is not a requirement on Windows) but with VMs, etc this should not be much of a problem in practice.
[0] X11 on Linux is also technically stable since the protocol is compatible even with machines from the early 90s and the libraries have a stable ABI, but by itself it doesn't provide much.
[1] Codecs notwithstanding, though Microsoft's own codecs should be fine to rely on
glibc has a very stable ABI, i.e. older binaries compiled against older versions of it should work fine on current versions (since the breaking libc6 transition which was several decades ago), they employ symbol versioning to ensure old binaries still find the symbols with the behavior they expect.
Of course, there are other "system libraries" that change ABI/SONAMEs more often, so what you are saying still generally applies, but I'd say glibc is not one of them.
> Windows application don't need to bundle system libraries like the libc
Linux follows the Windows model, where the stable interface is the kernel (Linux's syscalls, Windows's ntdll). This in turn implies that libc is a non-system runtime dependency, and a Linux application that wants to be portable across more than one release of Ubuntu (or whatever) should bundle its own copy.
Complaints of Linux ABI stability is mostly a story of old-timers trying to imitate how Unix worked in the '80s and '90s, with libc baked into the OS. Younger developers are more likely to use static linking or Docker/Flatpak/Snap.
They actually did end up fixing this with Windows 10. https://learn.microsoft.com/en-us/cpp/windows/universal-crt-... I think what finally pushed them in that direction was wanting to be in control of security updates for libc.
> Linux follows the Windows model, where the stable interface is the kernel (Linux's syscalls, Windows's ntdll).
ntdll isn't stable. They remove entypoints with just about every major release.
I haven't done low-level Windows programming since before the 64-bit transition, but I thought they kept the model of a DLL wrapper with a stable ABI.
It went the other way - Microsoft moved away from the "unstable C runtime" policy and introduced the Universal CRT (IIRC in 2015), officially being promoted to a Windows component, a guaranteed stable ABI, and shipped with Windows since W10.
>Linux follows the Windows model, where the stable interface is the kernel (Linux's syscalls, Windows's ntdll).
Ntdll is decidedly not guaranteed to be stable, and its direct use is explicitly discouraged by Microsoft. Win32 has always been the official and stable interface for NT-based OSes.
This makes upgrading the OS a heck of a lot easier too.
[1] https://www.destroyallsoftware.com/talks/the-birth-and-death...
That was not the case with defrag or regedit (or was it another register editor tool...). I remember using it without windows to backup and restore the register. This allowed me use windows as I wished and if it simply became slower because of the register, I could simply restore it.
The two demos seem to be broken right now, but I guess this is nowhere near being released and/or intended for public consumption yet.
Also (from "Taking a break" linked [1] in the post): does Figma not use email? Wut?
EDIT: Ah, probably not; looks like people are having success on Chrome too so it's probably just the site having a temporary issue
Highly inaccurate, hyperbole.
... or on an older slow Mac if it didn't have to go through a browser?