Investigate Win32s support

[seritools]

• relocatable executable: https://doc.rust-lang.org/rustc/codegen-options/index.html#relocation-model

[malxau]

Note that Win32s has no console subsystem, no support for threads, and executes in a shared address space (requiring a relocatable executable.)

[mateli]

There are hacks to mimic win32 threads in win32s but that is ugly. To begin with Win 3.1 is a single core operating system that use co-operative multitasking which is in itself ugly.

This is a problem shared when running rust on bare metal embedded systems where there also is nothing external to provide threading and usually no hardware support for parallel execution. There is a difference between concurrency and actual parallel execution where the latter requires hardware that run more than one task at a time such as having hardware threads or multiple cores. The hardware that Win 3.1 can run on and many embedded systems have no hardware threads and a single core so no parallelism unless you actually add multiple processors to a system. There were 386 systems with multiple processors but they all ran some variant of Unix or other workstation/server operating system. Windows 3.1 or 9x never had any support for something like that but Windows NT could run on dual Pentium system which came in some workstations.

So technically Windows 9x have fake threads with slow preemptive multitasking. Windows NT (including up to Windows 11) has support for multiple processors and multiple cores meaning real threads.

To achieve concurrency it is best to either rely on non-threading concurrency model or some kind of virtual threads inside rust. Even on modern system it is unwise to start more OS threads than there are cores or hardware threads capabilities. On PC hardware threads means HyperThreading where one actual core show up as two different cores.

So if you have 4 real cores with hyperthreading you should never have more than 8 active threads in the entire operating system because that will have a significant negative impact on OS performance. And in many scenarios running 8 threads instead of four will have a serious impact. That is why many scientific applications like matlab is best run with hyperthreading inactive and one thread per physical core.

A bit of a rant but the point is that on Windows 3.1 and windows 9x you should not have more than one thread. Use other concurrency like async await that plays well on a single core processor.

The solution to is to make starting a new thread fail. Simple as that. There is no reason to have threads on Windows 3.1, or Windows 9x.

[mateli]

As for a console subsystem... just make a window and put text in it... we don't need a full ANSI terminal window. Sure if we are going to run a series of console application we may need a simple command interpreter but that is not difficult to implement.

[ssokolow]

As someone who lived and programmed through the Windows 9x to single-core Windows XP era, I'm calling [citation needed] on your blanket statement to steer away from threading with only one CPU core.

Yes, it's inefficient to have more than cores+1 CPU-bound threads (hence the classic advice to feed -j 3 to GNU Make if you've got 2 CPU cores so you've got two CPU-bound threads and one to take up the slack when the other two are switching to the next compilation unit), but arguing to just blanket avoid parallelism when you've got one CPU core is like arguing to avoid 3D rendering unless you've got VR/AR goggles.

A bit of a rant but the point is that on Windows 3.1 and windows 9x you should not have more than one thread. Use other concurrency like async await that plays well on a single core processor.

As someone who is now a retro-hobbyist, I'll say that one of the most noticeable ways Microsoft leap-frogged Apple with Windows 9x is that, even on Mac OS 9.2.2 on a 933MHz Power Mac G4 Quicksilver 2002, you can feel the UI struggling to remain responsive while something like the official Mac OS Finder file-copy dialog is running, thanks to the lack of preemption. By contrast, the UI remains snappy under Windows 98SE on my 133MHz Pentium 1.

Is implementing preemption for Windows 3.1 overkill? Sure... but threading was one of the big things that made Windows 9x great.

EDIT: TL;DR: Threading isn't just about CPU-bound parallelism. It's also akin to the "VLIW vs. runtime branch prediction" conundrum, where it turns out to be more difficult in practice than you expect to reliably and effectively pick yield points in I/O-bound tasks to ensure the the UI remains responsive.

[ssokolow]

As for a console subsystem... just make a window and put text in it... we don't need a full ANSI terminal window. Sure if we are going to run a series of console application we may need a simple command interpreter but that is not difficult to implement.

*nod* That's how Open Watcom C/C++ does it if you ask it to build a Win16 app with console APIs.

[mateli]

I am talking out of my own experience.

What I am saying is that running more than one ACTIVE thread/process at a time is less efficient than single-thread concurrency. GCC does not have single-thread concurrency but instead often becomes inactive waiting for IO operations etc. Unless we have a compiler that use async/await or any other thread-less concurrency to compare with we cannot use compilers to test my statement. There are compilers that are significantly faster than GCC such as Turbo Pascal however as that is proprietary code it is difficult to say why it is faster, but I doubt it is by spawning threads.

I have written quite extensive single-tread GUI:s in C# using async/await and they do not struggle to be responsive. The cooperative multitasking is handled every time an async function calls another async function because that always pushes control back to dotnet's task scheduler.

It is true that both windows 3.1 and MacOS had problems with stability due to tasks that becomes inactive without handing over control to the scheduler. Those are bugs and while they still can occur with async-await frameworks and similar they are a lot less frequent. It is similarly possible and frequently occurring that modern multi-threaded system grinds to a halt if software has bugs that the OS cannot handle. Which is why patterns that minimizes bugs are important no matter how fancy your OS is.

Note that on these old operative system cooperative multitasking were implemented by having tasks returning control by making a specific call into the kernel. With modern cooperative multitasking (my experience is mostly with C# so I will reference that although I know that rust has similar mechanisms) any call from an async function to another async function returns control back to the scheduler. Whenever a non-async function are used and an async is available this will produce a compiler warning.

That being said with cooperative multitasking you still of course need to know what you are doing and appropriately test your code.

And finally my point is that with non-NT Windows it is better to use async/await patterns than to use threading. Same for modern systems unless you are actually spreading calculations across cores then you need threads, but this is something non-NT windows has no support for.

Also not that there are a lot of embedded software that has a design similar to Windows 3.1 and old MacOS without having the problems that you pointed out with cooperative multitasking. The reason that they do not have these problems are testing, testing and more testing. With the testing frameworks the only cause for such a system to become unresponsive is if we take shortcuts with writing good tests, and of course running those tests regularly.

We should remember that the cooperative desktop systems from the 1980:s and their software were written over a short period of time and practices like extensive testing were simply just not seen as important. This is why even the software that were part of these operating systems had plenty of bugs that had performance and stability implications that simply would not be there in for example a robot control system of similar architecture and complexity.

What I am not claiming and isn't going to claim is that writing cooperative well-performing concurrent code is as easy as just spawning threads. But what I claim is that when you have such code and it contains no bugs that causes major inactivity, it performs a lot better than spawning threads. With the exception of when you actually need to offload to another hardware execution unit.

Finally as a tool to write Windows 3.1 applications, using rust with async-await is going to be the easiest way to write a stable Windows 3.1 application. Just make the internal scheduler regularly hand over control to the OS.

[ssokolow]

What I am not claiming and isn't going to claim is that writing cooperative well-performing concurrent code is as easy as just spawning threads. But what I claim is that when you have such code and it contains no bugs that causes major inactivity, it performs a lot better than spawning threads. With the exception of when you actually need to offload to another hardware execution unit.

That's basically my point. Telling people to just write correct cooperative multithreading on Windows 9x has a tone-deafness to it akin to saying that you only need Rust if you're working in a team and solo programmers should just write correct C++.

[mateli]

Well there is plenty of evidence that it is fully possible to do so. The difference between C++ and other languages are not between the possibility of writing correct code but about how much it costs. Writing correct cooperative multitasking using a modern framework like the one in C# and probably the one in Rust is going to cost a lot less than doing it using pretty much any compiler that were available for the discussed platforms in the era that they were popular.

On the other hand a lot of the cooperative multitasking that are in embedded systems is written in C and and works very well. The main reason for this is simply that embedded developer spend a lot of time making sure that their code is correct and this of course makes such projects expensive (when done right). Automated testing and frameworks helps keeping the cost down compared to something written before those tools were available but you still need to have a significant budget for testing. Although that being said a lot of the Windows 3.1 software were remarkable stable given the fact the only method for making it so were having a developer that wrote correct code.

So no I do not agree to this. There are to much code written in languages like C that use cooperative multitasking and works perfectly well without freezing and crashing. And no matter what compilers and tools you use in order to improve the development process no system are going to be fit for production use without appropriate testing.

[mateli]

As for a console subsystem... just make a window and put text in it... we don't need a full ANSI terminal window. Sure if we are going to run a series of console application we may need a simple command interpreter but that is not difficult to implement.

nod That's how Open Watcom C/C++ does it if you ask it to build a Win16 app with console APIs.

Ah I didn't know that. I actually have plans of porting a console game to Win16 and were thinking about writing something like that, but if Watcom already has it I don't need to.

[ssokolow]

Ah I didn't know that. I actually have plans of porting a console game to Win16 and were thinking about writing something like that, but if Watcom already has it I don't need to.

I don't know how rich an API it provides. I've only ever poked at it as a replacement for very basic use of CMD.EXE for output.

[ssokolow]

Well there is plenty of evidence that it is fully possible to do so. The difference between C++ and other languages are not between the possibility of writing correct code but about how much it costs. Writing correct cooperative multitasking using a modern framework like the one in C# and probably the one in Rust is going to cost a lot less than doing it using pretty much any compiler that were available for the discussed platforms in the era that they were popular.

You're still assuming that the users are willing to reinvent or use Rust versions of everything they need which would otherwise be blocking-API'd if they're looking at the period dependencies. There's a reason tokio has spawn_blocking.

[mateli]

No. I am saying that when you do development it is cheaper to write code that doesn't accidentally block cooperative multitasking using a language that has a mechanism for it rather than doing it in C. In C# all you need to do to make the risk minimal is to enable "warnings as errors" and code that use blocking api:s instead of async variants will not compile.

Reading trough spawn_blocking it is an example of bad code. The appropriate response to an async task that do not complete in time is to log it as a fatal error and throw an exception. To recover from bugs like that does not encourage code improvement and it may make tests pass when they shouldn't. Obviously blocking code that has no checks on runtime are bad code and must be fixed.

[ssokolow]

How nice for you that, despite being someone who cares about Windows 9x in this day and age, you don't have to deal with closed-source libraries.

I actually live in the real world, where ideological purity is not always feasible.

[mateli]

Not if those libraries contains bugs that causes the application to freeze no.

[ssokolow]

Listen to yourself. You're judging stuff based on a context its creators didn't intend and couldn't have anticipated.

At the time, everyone around them (the entire industry) was of the opinion that, outside of select()-y stuff in network servers, cooperative multitasking was a dead-end technology, made obsolete by finally having the correct solution... pre-emptive multitasking.

It's like faulting them for not anticipating the low refresh rates of ePaper screens and planning to support them when everything was trending toward higher refresh rates.

[mateli]

No everyone didn't. The embedded industry continued to use Win16 and many other cooperative solutions and are still using it. Win16 itself is rare these days as it's not available for licensing but there are plenty of other solutions. Microsofts themselves did reintroduce cooperative multitasking inside dotnet and there it's very common to use it.

Also before dotnet, Java had green threads that's also cooperative multitasking and now it's reintroduced as virtual threads.

[ssokolow]

I'm talking about the perspective of the people who wrote the kinds of libraries I'm referring to.

It's entirely legitimate for people to have been in that kind of bubble during the Windows 9x era and, if you dispute that, I'll take it as a sign that your perspective is not credible.

[mateli]

There are plenty of libraries from that era that are fully functional to todays standard. And plenty of shitty libraries being written right now.

No matter when it's written, if it's crap I replace it. I've reverse engineered printer drivers for being crap so a simple library isn't going to stop me.

However a far bigger problem with old libraries and drivers is that they're not available for Arm and other non-x86 hardware. Then I have no option but to replace them.

[ssokolow]

*shrug* I've burned out on chasing my perfectionism too many times.

These days, I've taken "make it work, make it right, make it fast" to heart because I've got too many ideas and too few decades left.

(In essence, if the user can't tell that it's bad (i.e. it's responsive, reliable, etc.), and it's maintainable
enough to satisfy my lazy ass, then it's good enough.)

Basically, the same psychology as Knuth called for on the topic of performance:

There is no doubt that the grail of efficiency leads to abuse. Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil.
Yet we should not pass up our opportunities in that critical 3%. A good programmer will not be lulled into complacency by such reasoning, he will be wise to look carefully at the critical code; but only after that code has been identified.

-- Donald Knuth, Structured Programming with go to Statements, ACM Computing Surveys, Vol 6, No. 4, Dec. 1974, p. 268

TL;DR: If you want to write libraries, that's fine. I actually want to write end-user programs... I'm just perfectionist enough that, when there truly are no suitable libraries (and not just none that don't offend my sense of aesthetics), I'll deign to write one. (And then give it a test suite with 100% branch coverage because I don't want to be responsible for QA testing it again and Python's ability to catch errors is pathetic, but there are no memory-safe Rust bindings for Qt QWidget short of using Python, PyO3, and PyQt as glue.)

[mateli]

Well I tend to be good at both and quite often I don't have to because there are high quality open source libraries around.

Premature optimization is when you optimize something that doesn't actually have a major impact of performance. Finding and fixing bugs that has a major impact on performance isn't premature optimization.

My experience is that on average the simplest way to fix a badly behaving library is to replicate the behaviour that I need. Sometimes that implies reverse engineering code. Sometimes it implies listening in on communication between a driver and a device to reverse engineer the protocol while completely ignoring the flawed implementation.

As for Python I absolutely hate it. Mostly I stick to C# and C while considering learning rust. C# is way better than Python when doing projects that are large enough to need structure. And C# code is often as fast as C code so no need to implement something like numpy using C. C on the other hand works on every processor and system that's worth using.

[ssokolow]

Well I tend to be good at both and quite often I don't have to because there are high quality open source libraries around.

It's not that I'm bad at libraries, it's that I see them as a chore to build and a chore to maintain when my goal is to build an end-user experience.

My experience is that on average the simplest way to fix a badly behaving library is to replicate the behaviour that I need.

It depends on what your needs are. From my perspective, shunning threading in Windows 9x because a library has blocking APIs if often a sign that I might have more principles than sense.

Hell, even in Rust, I've run into various situations where avoiding threads entirely is "going in for eye surgery via the rectum". For example, even if I'm doing it without parallelism to avoid thrashing a rotating hard drive, my experience has been that the cleanest way to both avoid thrashing and avoid having image block tokio's pool when doing on-demand thumbnailing in an actix-web app is to spin up a worker thread in the background, throw "work order" objects at it over a channel, and await the tokio::sync::oneshot that I put one end of in the work order to signal completion.

As for Python I absolutely hate it. Mostly I stick to C# and C while considering learning rust. C# is way better than Python when doing projects that are large enough to need structure. And C# code is often as fast as C code so no need to implement something like numpy using C. C on the other hand works on every processor and system that's worth using.

I'm not a big fan of Python compared to Rust, but I have 20+ years of experience with it and it has some bindings I've yet to find suitable replacements for, like PyQt, and libraries/frameworks in a similar position, like Django and its ecosystem of reusable "apps".

I never really got into C# because:

1. It may be good at Win32 API ergonomics, but it's inferior to Rust or Python for POSIX ergonomics in my experience and, if I'm developing for Windows and can't use Rust, I'm probably intending to develop something that's compatible back to at least Windows 95 RTM. (I basically have five OSes I either target or intend to target: Modern Linux, MS-DOS, Windows 3.1, Windows 95 RTM, and Macintosh System 6 or 7, with that last one being something I plan to choose based on whether I'm doing something that only makes sense in the context of APIs added with System 7.)
2. For many years, I was turned away from it by the uncertainty surrounding Microsoft's plans regarding software patents.

[mateli]

Also I don't really agree that premature optimization is bad. If you practice optimization it becomes a skill and you just automatically write code that is fast without spending extra time on it. Searching for performance bottlenecks in order to do optimization in a second phase that takes time.

Sure while you are building the skill premature optimization is going to take more time than just coding without care. But when your skill reach a certain level it's going to save you time. You will also create fewer bugs because when writing optimized code you need to know what it's doing.

[ssokolow]

It's a matter of mindset. Do I plan my architectures in consideration of likely performance impacts? Yes.

...but do I try to write my entire program in a zero-copy style that complicates refactoring before I even know how much of a performance impact each borrowed value is going to have? Probably not.

[mateli]

Oh and if you pull in Qt you can forget about memory safety. Unless you rewrite. Doesn't matter if your bindings in themselves are safe when the library isn't.

[ssokolow]

For my daily driver PC, I'm a KDE user and I find even the apps they're rewriting in Kirigami to be uncanny-valley UIs. The rationale is:

1. The QWidget UI is non-negotiable
2. The Ritual binding generator for Rust is a big wall of unsafe APIs and I'm only willing to take responsibility for debugging stuff I write against an API that won't catch my memory-safety mistakes for retro-hobby stuff in DOS and vintage Windows and Mac OS.
3. I use Rust so I can share implementations between my projects across various languages, which means that the C# and Java bindings to Qt are unappealing.
4. PySide (A.K.A. Qt for Python) is incomplete (eg. it's just missing a required API for certain QtDBus API calls to work)
5. Given that process of elimination leaves only PyQt, the question is whether the thing is complex enough for the added work of maintaining a frontend/backend split to justify pulling in Rust, given the added complexity for cross-building.

[mateli]

Well if you are unwilling to look at other toolkits than Qt that will limit you.

Rust have plenty of UI:s that are implemented in Rust. C# has Avalonia. When trying to maximize platform coverage however something game related such as SDL may be a valid choice.

Also don't dismiss the value of writing console applications. A console application written in C will work on everything from Commodore PET to a modern PC and this discussion established that Watcom will cover Windows 11. Even better you don't even need to compile for these platforms, a serial cable or network adapter and you can run a bbs, telnet or ssh server. I'm pretty sure that software for connecting to all three exists for win16 (Trumpet for example). It's difficult to find a retro computer without a terminal emulator and RS232.

[ssokolow]

Well if you are unwilling to look at other toolkits than Qt that will limit you.

Rust have plenty of UI:s that are implemented in Rust. C# has Avalonia. When trying to maximize platform coverage however something game related such as SDL may be a valid choice.

Call me an old-school Macintosh-style developer if you want, but I pick the user experience first and then choose my language and libraries based on what it will take to most efficiently get to that user experience.

For GUI applications, "toolkit X that I deem to be the ideal end-user experience for the situation" is non-negotiable... the implementation language is negotiable.

When trying to maximize platform coverage however something game related such as SDL may be a valid choice.

I have puttered around with the Rust bindings for SDL, but I decided to do my game dev in Godot. It definitely improves iteration time, but the decision-maker was my decision that my current hobby game project should have network multiplayer, and I do not want to be responsible for netcode from scratch.

Also don't dismiss the value of writing console applications.

I never said I was...but there's a difference between "I choose Rust because it's the best way to write a snappy CLI tool" and "I code in gVim because terminal emulators don't give console Vim the ability to draw wavy underlines".

Again, I pick the user experience, then go shopping for a tool to implement it.

[mateli]

Or here is another idea. If you must use Qt write the frontend in C++ and the backend in any language that has TCP. The bonus is that should the frontend crash it can just be restarted. And they can run on different computers.

[ssokolow]

You're half-right. I actually ported a Python module named gtkexcepthook to PyQt because, while a C++ bug can crash the whole program, it's incredibly rare for me to encounter a mistake that extends outside the Python runtime, so, if I write in Python, it's viable to have a design which throws up a "You should probably report this bug" dialog that stops at the edge of the event handler, allowing the user to continue to use the program safely.

You're also half-right in that I'm doing that... using PyQt. I've been puttering around with Stable Diffusion for kicks and the options there are Easy Diffusion (decent concept, but frustratingly buggy and under-manned), AUTOMATIC1111 (where the work goes... but horrendous UI), and ComfyUI (a graph-based thing that's not really in the same niche) an I'm working on a PyQt QWidget client for AUTOMATIC1111's HTTP API (and maybe later ComfyUI's HTTP API) to be "like Easy Diffusion, but better".

EDIT: Hell, I'd use Python just for how nicely C++ dependencies like Qt and OpenCV have been pseudo-static-linked into their Python bindings so I can use uv for a Cargo-like dependency/build-handling solution. Conan? vcpkg? No thanks.

[mateli]

Well you will also need to pick platform. I made some games where I just wanted to target everything and that enforced a combination of CC65, GCC and Watcom C. Going beyond text input simply wasn't reasonable given the very different graphics architectures. I would simply have to do several different frontends for different platforms.

With a narrower selection target platforms godot is an excellent choice. I don't like the lack of control when running on top of a game engine so I'm probably gonna go with SDL.

Although now I'm contemplating a bbs/telnet/ssh server because I'm working on something text based that needs a database backend. Lets say it's multiplayer but actually going to run on a single machine/server.

Unfortunately there are nothing that easy to use for graphical applications unless you go for something browser based. If we stick to most modern platforms that can run either Firefox and Chromium with GPU capabilities then that's not a bad solution. And one that godot supports by the way. Although I'm leaning towards blazor server side rendering right now.

[ssokolow]

Well you will also need to pick platform.

Fair. I see that as part of "pick the user experience first" or possibly a "step 0" before it.

Unfortunately there are nothing that easy to use for graphical applications unless you go for something browser based. If we stick to most modern platforms that can run either Firefox and Chromium with GPU capabilities then that's not a bad solution. And one that godot supports by the way. Although I'm leaning towards blazor server side rendering right now.

Up until the beginning of 2024, I was reasonably comfortably using an Athlon II X2 270 from 2011 by being carefuly to avoid web apps wherever possible. As for now, as I just mentioned, I'm working to write a replacement for a web UI in QWidget.

Hell, just having drag-and-drop which isn't janky and a rich-content list widget that allows multi-select drag-and-drop will be a huge bump. (My number-one issue with other people's web UIs is how they always reinvent just what their authors use and call it "good enough". My reason for generally avoiding them myself is to avoid being caught between being a hypocrite or re-implementing all 594 pages of Microsoft Windows User Experience (1999)... the Windows 95/98/ME/2000 HIG... and possibly the Windows XP and Windows 7 amendments they published for free download. Anything beyond that and desktop-mobile UI convergence starts to leak in and I can't stand that.)

[ssokolow]

Speaking of which, one of the projects I'm actually considering doing is sitting down with my copies of the 1999 Windows HIG, the Windows XP and 7 amendments, the 1992 Macintosh HIG, the Mac OS 8 and 9 amendment, some Mac OS X HIGs, the GNOME 2 HIG, the KDE 4, 5, and 6 HIGs, and possibly my copy of the OS/2 HIG and trying to codify an actual HIG for the common trends that were emerging in desktop UIs before this web and convergence nonsense broke everything. (So I have a document to point to in my CONTRIBUTING.md as what to read if you want to minimize the number of "please revise" cycles on your PRs.)

(Of course, I'll need to either prune or ignore the KDE 6 HIG, given their nods to the increasing use of Kirigami and its mobile-esque converged widgets and layouts.)

My placeholder name for it where I've been accumulating the PDFs and CHMs and the like is ~/src/2000s_universal_native_hig/. (You can find Apple's HIG PDFs for older Mac OSes on the Wayback Machine and I've got some MSDN Library CDs containing the CHMs for the Microsoft books... plus print copies of the OS/2, Windows 3.1, and Windows 9x HIGs. The 1992 Macintosh HIG is something I'd like to have in print as a classic and a collectable, but it's pricey.)

[mateli]

One of my currently idle projects is to replicate the experience of these old user interfaces in C# or something similar. A simulator rather than an emulator. Something that a user of old desktop environment would believe is real for quite some time. Perhaps a plugin system for adding applications. This is rather inspired by Java LaF and the Windows 98 simulator for Android.

[ssokolow]

My issue with that idea is that I'm very sensitive to "uncanny valley-ness" and I've yet to see, for example, a Qt or GTK theme that replicates the Windows 9x look and feel closely enough to not grate on me... let alone going the other direction where, for example, it still grates on me that Qt 4 made mouse interactions more sensitive than Qt 3 and it's still a problem.

(eg. The KDE 5 Save dialog is still prone to accidentally switching away from the default filename to the name of an existing file inside the folder I just double-clicked, at which point I copy the path of the current folder to the clipboard, cancel the save, and Ctrl+S again to get it back.)

[mateli]

I think that the future of the web is to use WebGPU and descendants to render user interfaces. This is currently mainly used by games and emulators but why not implemented a desktop environment that runs in the browser and renders using WebGPU.

[ssokolow]

I hope not. Even with stock Ungoogled Chromium to make sure it's not my Firefox privacy/anti-tracking/ad-blocking loadout and many suspended tabs bogging things down, I've found that in-browser apps (even WebAssembly-compiled C ones) are significanly heavier and more likely to be janky).

It's bad enough that modern Freetype in true native apps is apparently incapable of hinting fonts on non-HiDPI screens as crisply as Windows 98 SE or Mac OS 9.2.2.

[mateli]

Well to have any user experience the user must be able to run the application. Naturally very few use 8 bit computers like the C64 but I think that including it is fun. For people with limited budget I actually think that Raspberry Pi is far more widespread and while it can do graphics the earliest models are easily exhausted.

Targeting so many platform does limit what user experience that can be achieved. Ill be limited in what I can implement but look at what DOS BBS systems could do and add RAD development with C# and Entity Framework...

[ssokolow]

Fair... but an application that never reaches its first release version and, thus, never exists, is the worst user experience.

I have a couple of hand-me-down x86-based mini PCs which I maxed out to 8GiB of RAM and stuck 120GB mSATA SSDs into (where benchmarks say they're 1.1 times the speed of a Raspberry Pi 4) which I keep attached to the LAN and booting into a cut-down Debian for low-measurement-noise benchmarking which I can ssh -X into for "user-visible performance" testing and, when I get to that point, that's usually my target for minimum supported performance profile.

However, for stuff that can be operated in a batch mode... such as the chatlog parser I've been working on for an aid to compiling story bibles for writing fiction, I tend to just go overboard and see how much I can optimize the total wall clock time for parsing my test corpus of real-world input. (I managed to get the hyperfine runtime below 300ms on my old 2011 Athlon II X2 270.)

Beyond that, hardware that I might want to target becomes difficult to provision. I've got a Chinese Android TV box that I managed to get Armbian on... but I'm planning to use it to replace the Raspberry Pi 1 Model A in my mother's custom bedtime music player, then put the Pi 1 Model A into my USB4VC (I've got a KVM switch, so I only need one USB port) to free up the Pi 3 Model B to be used for something like an mt32-pi.

Outside of that, slow machines I have tend to be 32-bit devices assigned to run Windows XP or Windows 98 SE, where targeting a compatible version of Linux becomes inconvenient.

When I target hardware that slow, it tends to be more in the vein of "I'll use Open Watcom C/C++ to design this real-mode DOS application to be natively developable on a DPMI-capable DOS machine, and do my performance testing in a copy of DOSBox tuned to be in the vicinity of an IBM PC XT (because more true-to-reality emulators are more difficult to automate from a Makefile), but put the near and far behind ifdefs so I can also leverage Open Watcom C/C++'s support for building for modern Linux for convenience".

I have plans to do similar with Retro68's LaunchAPPL utility firing up a copy of Mini vMac and autoquit or autquit7 bringing it down again.

[mateli]

Which is why I currently are working on console application using standard C stdin/stdout handling and are considering moving towards something more like a BBS.

The biggest cost to using computers for me is not to purchase them but to pay for the power that they use. A bit more than 10 years ago I switched my home server from my old Phenom II to one of the low power Athlons with the same benchmarked performance. After three months the cut in my power billed had paid for the switch. That led me to a track where I now mostly use Arm-based computers because of cost and space efficiency. I have all variants of Raspberry Pi and a bunch of embedded boards you haven't heard of. And on my day job I work on equipment than can run for about 10 years on a low cost battery and a large part of that job has been to measure power consumption in various low power modes on a bunch of different embedded processors in order to find the longest possible battery life time.

Unfortunately the only Retro computers I have left are those of the Commodore brand, all the PC:s are gone so for me all usage of old PC software are for emulation. There are a lot of good software for DOS and old Windows version that will run better in an emulator than any similar native software will run on the same hardware. But I fully do understand the need for running software on old hardware.

Watcom is one of the best compilers for these targets, I wouldn't use it for Linux but for DOS and Windows it is very good. Another option that may be better especially when targeting really old stuff is FreePascal, Delphi and Turbo Pascal. They all compile a variant of the same language and it is possible to write code that will run on all three. Total commander for example is written in Delphi and exist for Win16 to 64-bit. Although I have not used pascal much so my experience with these are limited, I do recognize their value as compilers for legacy systems. Also if you really want a Retro experience the 1980's were all about Pascal, it was about 1989 that Watcom introduced decent 32 bit support with a dos extender the market shifted towards C++.

For those of us that want to target legacy systems it is a lot more about what output a compiler can produce and a lot less about what input it takes. LLVM-compilers targeting these systems are great news but unfortunately I think it will take a while until it they produce the quality output that watcom and borland compilers generate. Some predict that by then these legacy systems will no longer be relevant but I do not agree.

If they were supposed to lose relevancy they would have done so decades ago. The original hardware will fail one by one but emulators will always be around. And FPGA implementations of the old hardware. The C64 is already have all parts in production to build a complete machine. All the original chips have an FPGA implementation, there are several manufacturers of motherboards and boxes. The fact that you can buy replicas of all parts of a C64 means that it will probably never go away. As for retro PC:s you can buy sound and graphic cards but not yet full systems but give it a decade or two and all will have been fully replicated. From a financial perspective of course it makes more sense to buy something like Raspberry Pi and run an emulator so that is what most people will do.

Want a cheap computer? Well buy a Raspberry Pi Pico and flash it with a C64 emulator. It is capable of doing a lot more but that is what what is available off the shelf right now is a C64 emulator with VGA output.

To run DOSBox or similar you would want to attach an SPI RAM and patch DOSBox to cache RAM lines in the internal memory which is much larger than the cache memory of old PC processors. As a reference the 486 had 8 to 16 kb cache memory Pentium had 16 to 32 kb cache. PII had 32kb. Core 2 had 64 kb per core. L2 cache is about as slow as working with external SPI memory so it is irrelevant when comparing with something as modern as the Pico. Of course implementing a memory subsystem in software will come at a cost but I do think that you can get something at least as powerful as a PC AT with let's say 1MB of ram which opens up a lot of possibilities that a C64 doesn't have. Add a persistent F-RAM and you can write a PC emulator that can go down in a suspend mode that can run from battery for years and just resume running when you turn it on again. A 2mb f-ram costs about $50 . Volatile Ram of the same size is about $3 so non-volatility costs a lot extra but can be worth it depending on what you are building. Of course a SD Flash cards costs less than $50 and can also be used to persist state, but then you have to make a full copy of all RAM to the card when going into suspend mode while with F-RAM you just have to flush the cache and store state.

When using old compilers like watcom or turbo pascal ChatGPT can be very useful at translating modern C or even something like Java or C# into code that will compile on the most weird C compilers. I used it to translate modern C in to something that will compile with cc65, Watcom and of course modern compilers. In fact just writing a C# console application and then have ChatGPT translate it to the required subset of C may be a very useful solution.

The performance of a Raspberry Pi (any model) depends a lot about what you are doing. If you are running ssh -x combined with remotely showing a probably software-rendered X11 remote windows/display then you will cripple it's performance. If you are running something graphical on a Pi intending to view it on another machine well that is going to eat CPU cycles.

Also if you compile for Raspberry Pi 4 remember to use hardfloat all the way from the OS image to the program you are complying. If you use something generic that boots on softfloat systems then well you will obviously get softfloat binaries.

[ssokolow]

Which is why I currently are working on console application using standard C stdin/stdout handling and are considering moving towards something more like a BBS.

For me, outside of retro-hobby stuff (eg. I want to run a Gopher server on my LAN just for fun) it's all about "My time and psychological comfort/health is more valuable than electricity, so what UI would feel most comfortable for me for each use-case?" I certainly do do certain things in the CLI... but even there, I import readline for my Python REPL site customization and, for CLI tools that do their own interaction instead of just pipe-able stdin/stdout I tend to use something like rustyline (a readline-like library for Rust projects) to include support for command history and tab completion.

The biggest cost to using computers for me is not to purchase them but to pay for the power that they use.

I roll everything that isn't an "infrequently turned on" retro-hobby PC into the machine I'm sitting at right now, which has had a 65W TDP CPU since 2011 and has been running a Q1 2023 Ryzen since January 2024... partly because I didn't have air conditioning until last year and, even now, it's hard to get hot air out of this room. (I also use LCD monitors for my retro desktops because I grew up on my father's office laptops until 1997 and I never want to go back to the blurriness of the CRTs I was using from 1997 until the mid 2000s when I got DVI-attached LCD panels. It's bad enough that OSes after Windows XP and Mac OS 9 have forgotten what "full hinting" is supposed to mean for fonts.)

I do leave it running overnight, since it's the house media server and SMB/CIFS file drop and I don't use a mobile phone in the role of bedtime music player and log-taking talking clock (ATi Remote Wonder II next to the bed) but everything not necessary for bed (monitors, bias lighting, etc.) is on a switched power bar which is then plugged into an X10 module so that, if I'm already on the bed and out of willpower, I can shut them down using the remote.

Unfortunately the only Retro computers I have left are those of the Commodore brand, all the PC:s are gone so for me all usage of old PC software are for emulation. There are a lot of good software for DOS and old Windows version that will run better in an emulator than any similar native software will run on the same hardware. But I fully do understand the need for running software on old hardware.

Funny thing about that. I'd more or less gotten rid of old PCs too until an AST Adventure! 210 (~133MHz Pentium 1) showed up in a lot of ~3GHz P4s and Athlons years ago and rekindled my interest in actually having the hardware.

I also have emulators like DOSBox and 86Box but, for the most part, it's just the complete lack of "something isn't quite right"-ness of actually running real the real Windows Classic look and feel in the "Windows XP pretending to be Windows 98SE" on my hand-me-down Thinkpad T410 or genuine Windows 98 SE on the hand-me-down Thinkpad T42 I'm preparing to set up.

(Plus, I've found that the games I often want to play most, like Dungeon Keeper 2, are the ones that just work better on real hardware than in Wine.)

Watcom is one of the best compilers for these targets, I wouldn't use it for Linux but for DOS and Windows it is very good.

*nod* It's more that I like to have the option to make Linux binaries. (eg. I've got an on-hold project to write a DOS analogue to Inno Setup or NSIS, since the oldest full-featured freeware installer creators are for Win16, and I like the idea of having its build tooling be as amenable to cross-building as Watcom C itself.

Another option that may be better especially when targeting really old stuff is FreePascal, Delphi and Turbo Pascal.

Free Pascal is definitely the Python of DPMI programming, as far as "batteries included" goes. However, my biggest DOS hobby project has "Run in real mode, fit within 10K, contain a BASIC interpreter and unzip implementation, and be written in something more maintainable than assembly" as design goals, which means I've already had to write my own thin wrapper around int 10h using inline assembly to replace Watcom's graph.h (Something like a 35K size bump if you use it to position a "Hello, World!") with API wrappers for all the int 10h APIs I want that can produce an "exercise all the APIs" fancy "Hello, World!" demo in 1602 bytes. (996 bytes of that being the Watcom C runtime, based on how big a void main(void) {} COM file is.)

Aside from that, Free Pascal's Crt unit was very un-optimized compared to Turbo Pascal's last I checked and they've dropped support for Win9x-era Win32 for lack of interested maintainers.

I do have Delphi versions 1 through 5 in my collection, but, since I like to open-source my creations once they're sufficiently complete, I try to stick to toolchains that are equally freely redistributable for what I release, even if I'm willing to prototype in Delphi or Visual Basic.

(Right now, I'm torn over whether to use my collected Visual Studio 6 Enterprise set (took me a while to find a reasonable price on that aspect of what my father brought home when I was a kid) to follow along in my ATL-based books on Win32 COM programming and then rewrite my creations on the bare Win32 APIs in Watcom once it'd be less of a "jump in the deep end" experience.)

Also if you really want a Retro experience the 1980's were all about Pascal, it was about 1989 that Watcom introduced decent 32 bit support with a dos extender the market shifted towards C++.

To some extent, my approach to programming is an extension of how I do "rose-colored glasses builds" for retrocomputing. It's about compensating for stuff that has "aged poorly".

(eg. I was used to the limitations of COMMAND.COM as a kid but, to have a similar relationship with it as an adult who daily-drives zsh, I need to substitute 4DOS as my command interpreter. Likewise, I didn't have any kind of LAN until the mid to late 2000s, but I no longer see sneakernet as the norm, so I put a 100MBit NIC with DOS Packet Drivers in my DOS/Win31/Win98SE PC and offer up /srv/retro (read-only) and /srv/file_drop (read-write) over SMB/CIFS and AppleTalk and use network backup utilities such as Retrospect's FTP backup option.)

...it also helps that I'm not particularly nostalgic for anything PC that's older than MS-DOS 5.0 (I did use MS-DOS 3.2, 3.3, and PC-DOS 4, but I'm not nostalgic for edlin and friends), so my only potential nostalgia-appropriate uses of Pascal would be for the Macintosh SE I used System 6 and System 7 on around the same 1991 time period.

LLVM-compilers targeting these systems are great news but unfortunately I think it will take a while until it they produce the quality output that watcom and borland compilers generate. Some predict that by then these legacy systems will no longer be relevant but I do not agree.

I've been meaning to look into how well gcc-ia16 stacks up, given that it could potentially have better optimizers than Open Watcom.

And FPGA implementations of the old hardware. The C64 is already have all parts in production to build a complete machine.

*nod* I may not have much interest in playing with 8-bit micros (the rule of thumb seems to be "Is it designed around having a hard drive I can learn to write TSRs or Macintosh System INITs or batch file enhancer utilities or other persistent utility code for?") but I do watch retro-tech YouTube channels which do 8-bit micros.

From a financial perspective of course it makes more sense to buy something like Raspberry Pi and run an emulator so that is what most people will do.

*nod* One of my rainy-day project ideas is to take one of the mini PCs I have kicking around and see how much I can optimize Linux boot-up time from power-on to booting into a fullscreen copy of 86box.

When using old compilers like watcom or turbo pascal ChatGPT can be very useful at translating modern C or even something like Java or C# into code that will compile on the most weird C compilers.

I don't use GenAI for programming. In fact, the only chatbot I use is Perplexity and only when I'm having trouble crafting the right keywords to get what I want out of DuckDuckGo or Google. You need the cognitive exercise of solving problems yourself if you want to "build up that muscle and keep it toned" and, more generally, I refuse to become dependent on tech I can't self-host.

The performance of a Raspberry Pi (any model) depends a lot about what you are doing. If you are running ssh -x combined with remotely showing a probably software-rendered X11 remote windows/display then you will cripple it's performance. If you are running something graphical on a Pi intending to view it on another machine well that is going to eat CPU cycles.

Even better. After all, I use ssh -X with mini PCs as a way to ensure I'm keeping my minimum system requirements down, so erring on the side of the hardware seeming to underperform is good.

Also if you compile for Raspberry Pi 4 remember to use hardfloat all the way from the OS image to the program you are complying. If you use something generic that boots on softfloat systems then well you will obviously get softfloat binaries.

*nod* I've got an OpenPandora that I set up Rust to cross-compile for and it's a bit funny about hard vs. soft float because reasons. (It's been a while, but I think it might trace back to what the closed-source userland GPU driver blob TI provided was compiled for.)

[mateli]

I guess that depends a bit on electricity prices. While readline are useful for some use cases it's utility largely depend on what application you are writing. Also unfortunately it is not ported to all the platforms that I am currently targeting so I can't really use it. Some of my cli applications are non-interactive and would have no use for it, others are entirely menu-driven and have no use for it.

When I switched to flat screen it was more about space. And weight. Moving those things around were not fun. Back then power were cheap so I didn't mind using such equipment as a source of heat but there were just a point where I had to clean out CRT TV:s and computer monitors.

I usually keep things running, that's another reason I want stuff that are low power.

I don't really have space for the hardware that I want but in the future I may start collecting some of the good stuff especially if there are more stuff like Orpheus II coming out. New retro hardware is not the old one but it is not emulators either.

As I am more interested in running new software it is not as much of a problem to me that some old games will not run. But I think that eventually most of them will run. Some will also run because they are reverse engineered and ported to modern systems. I think that for example Diablo is fully reverse engineered and ported to other platforms. In other cases we will more likely have clones that are close enough to the original game.

FreePascal/Lazarus is one of those "close enough" clones but that obviously have some work that needs to be done before it is as good as Turbo Pascal/Delphi. I don't think that it is as good as OpenWatcom on 32 bit and if it support 16 bit it is probably not good. FreePascal for legacy windows versions are being improved upon although we will probably never see official support.

Command.com works for simple stuff but you are right that it get's annoying when more complex things has to be done.

I've played around with ChatGPT since it were first released but it is not until the newest o3 it has become somewhat useful. Translating source code between languages or fitting it to weird compilers like the cc65 is rather useful but when projects become larger it will fail. It speeds up development but you certainly can never rely on it.

It is not just about system requirements. Doing X11 over SSH adds a lot of latency due to the protocol being very badly designed and makes whatever you are rendering a lot slower. It is not necessarily that you run out of hardware capacity but more often X11 has a lot of roundtrips and stops in wait loops. VNC is better but only slightly.

[ssokolow]

I guess that depends a bit on electricity prices. While readline are useful for some use cases it's utility largely depend on what application you are writing. Also unfortunately it is not ported to all the platforms that I am currently targeting so I can't really use it. Some of my cli applications are non-interactive and would have no use for it, others are entirely menu-driven and have no use for it.

Naturally. I was more saying that I prioritize designing things to be as comfortable and convenient for me as possible and then fit the technology in around that.

When I switched to flat screen it was more about space. And weight. Moving those things around were not fun. Back then power were cheap so I didn't mind using such equipment as a source of heat but there were just a point where I had to clean out CRT TV:s and computer monitors.

I've got a few CRTs stored under the basement stairs in case I want to use them again... though I will admit that I like the compactness and lightness of the panels too.

I usually keep things running, that's another reason I want stuff that are low power.

*nod* Part of my reasoning for lumping everything into my daily driver Linux PC is so I only have one always-on, always-connected device to keep on top of security updates for and it's the one managed by the KDE update manager on my desktop.

As I am more interested in running new software it is not as much of a problem to me that some old games will not run. But I think that eventually most of them will run. Some will also run because they are reverse engineered and ported to modern systems. I think that for example Diablo is fully reverse engineered and ported to other platforms. In other cases we will more likely have clones that are close enough to the original game.

*nod* ...but, while I've got machines to play with for their OSes, I might as well take advantage of the low-hassle way to play the finicky games too.

FreePascal/Lazarus is one of those "close enough" clones but that obviously have some work that needs to be done before it is as good as Turbo Pascal/Delphi. I don't think that it is as good as OpenWatcom on 32 bit and if it support 16 bit it is probably not good. FreePascal for legacy windows versions are being improved upon although we will probably never see official support.

From what I remember, it's not the 32-bit that's the problem, but the A (ANSI Win9x) variants of the Win32 APIs as opposed to the W (Unicode WinNT) versions... which does make me wonder how far they are from being compatible via unicows.dll.

Last I checked for 16-bit, they'd just gotten to where https://wiki.freepascal.org/Win16 seems to be stuck at... but I think that wiki page has always had a problem with staleness.

It is not just about system requirements. Doing X11 over SSH adds a lot of latency due to the protocol being very badly designed and makes whatever you are rendering a lot slower. It is not necessarily that you run out of hardware capacity but more often X11 has a lot of roundtrips and stops in wait loops. VNC is better but only slightly.

The machines are side by side on the same gigabit switch. I didn't notice any latency when I was experimenting with remoting gVim using ssh -X. (The mini PCs are in a little stack below my central monitor.)