The adventurous developer who recently released Linux for the Atari Jaguar (1993) has brewed up a version of the open-source OS for the Sega 32X (1994). If you can’t remember the 32X, it was Sega’s mid-gen answer to early fifth-generation challengers like the Jaguar, 3DO, and Amiga CD32. Sega’s solution added some potent processing power to a mushroom-like slot in an expansion to its popular Mega Drive/Genesis. Now cakehonolulu has got it running Linux, despite facing several major hurdles.

Compared to its Genesis host, the Sega 32X was incredibly muscular. The Genesis had relied on the capable but long-in-the-tooth Motorola 68000 (7 MHz) for years, but the 32X add-on boosted that with a pair of Hitachi SuperH SH2s (SH7604) CPUs (23 MHz). It also ramped up system RAM from the base 64KB by adding 256KB of its own. Sega’s expansion offered more than just speed; the console’s color palette was ramped up from 64 to 32,000 simultaneous colors on screen, and it was powerful enough to introduce hitherto unachievable 3D graphics elements to mainstream console gaming.

As with cakehonolulu’s tale of Linux wrangling on the old Jag, the above-linked blog talks through a long list of hurdles that needed to be leapt to get the Linux kernel booted and running BusyBox. This time around, particularly steely roadblocks included: the even more constrained RAM situation, the lack of hardware synchronization primitives, the desire to get SMP working across the pair of SH2 CPUs, no direct UART access from the 32X, and scheduler bugs, among other things.

On the positive side, smoothing the development process along were access to Chilly Willy’s 32X devkit, the linuxmd project, the Krikzz FPGA-based flash cart with ROM – RAM mapping tools, and existing SH2 documentation and sample projects. Please check through the linked blog for far more technical details from cakehonolulu.

As you can see, cakehonolulu was successful again. So, what’s the next stop for this adventurous dev – the Sega Saturn? Whatever the project may be, it was interesting to read that works like this are basically forming a portfolio for the Spanish dev, which they hope will help them with job hunting.

A set of updates for Sega Dreamcast hardware has been merged into the Linux 7.2-rc3 kernel this weekend. Dmitry Torokhov submitted updates addressing the legendary console’s input subsystem and Linus Torvalds merged them on Saturday. The updates even surprised Linux-focused site Phoronix, That’s probably due to context: the Dreamcast continues to enjoy support while admittedly older but real computing hardware like the i486, PowerPC 40x chips, DEC Alpha, and Itanium / IA‑64, have all been sidelined in recent times.

In brief, the updates should mean new versions of Linux will come with more stable mouse, keyboard, and joystick drivers for Dreamcast stalwarts. If you are one of the Dreamcast faithful, still satisfying your computing (and gaming) needs on the final original consumer gaming hardware from Sega, this is good news.

Reading the pull request we can see some details about the new drivers for the Dreamcast’s Maple‑bus peripherals (mouse, keyboard, controller). Specifically, there’s a “fix for a crash in Sega Dreamcast (Maple) mouse driver when opening the device, caused by missing driver data,” as well as “Fixes for Maple drivers (keyboard, mouse, joystick) to properly order setting driver data and device registration to avoid races.” In this context races refers to things happening in the wrong order to result in crashes: it’s a timing bug that’s now been quashed.

Dreamcast hangers-on will now be able to craft specialized Linux builds on CD-R for their machines. The maplemouse driver has had the now-fixed crash-inducing bug since 2017.

Phoronix also comments that Linux kernel fixes for the GD-ROM driver used by the Dreamcast and a proposal for the VMUFAT file-system driver were also seen this year.

The Sega Dreamcast launched at the end of 1998 (in Japan, and the following year in the U.S.). So, in some ways it isn’t that surprising that it is still getting Linux kernel updates when the Intel i486 (1989) has been retired from mainline support. But one might have expected stronger demand for supported Linux distributions among i486 desktop and laptop users.

Windows 95 worked out whether a setup program had run by reading the executable's name and checking it against a short list of hard-coded words, according to Microsoft engineer and semi-official Windows historian Raymond Chen, sharing the details via his Old New Thing blog. A filename containing "setup," "install," or "inst" flagged the program as an installer, which triggered the operating system's routine for repairing system files that installers had damaged. Three non-English entries appeared on the same list, which Chen identified as his own guesses at Italian, Turkish, and Hungarian.

The full match list ran to six terms: setup, install, inst, imposta, ayarla, and felrak. Chen wrote that "install" was redundant, because any name containing it already contains "inst," and speculated that the shorter entry was added later to catch installers named along the lines of "blahinst" without anyone deleting the original. A program whose own name produced no match got a second test, with Windows 95 checking whether the word "Setup" appeared anywhere in the path to the executable. A separate live check ran after any multimedia driver was installed through an INF file, added because those drivers frequently overwrote system DLLs.

This heuristic gated a recovery mechanism Chen described in March. Installers of the period overwrote system files without checking versions, disregarding Microsoft's rule that a file should only ever be replaced by a newer one. An installer carrying Windows 3.1 copies of shared DLLs, for example, would bury the newer Windows 95 versions underneath them, and every program that relied on the current files would break.

Windows 95 kept backup copies of commonly clobbered files in a hidden C:\Windows\SYSBCKUP directory. It would then let each installer finish, check its work, and restore the correct versions where the installer had downgraded them. This safety net depended entirely on correctly guessing that an installer had run, so a setup routine with an unusual name slipped past it, while an ordinary program named something like instant.exe tripped it for nothing.

The file check was often deferred until the next boot rather than run immediately, with Chen explaining that some installers, unable to replace a file already in use, would drop back to MS-DOS, run a batch file to swap the file, and restart Windows, so the cleanup pass had to wait for the reboot to catch anything the batch file had altered.

Windows 2000 debuted a new approach

Microsoft dropped this approach in Windows 2000, which introduced Windows File Protection. That system registers for file-change notifications through Winlogon restores protected files from a cache at %WinDir%\System32\dllcache, with no filename guessing and no waiting for a setup program to complete.

Then, Windows ME shipped a comparable System File Protection, and Vista onward moved to Windows Resource Protection, which guards files using access-control lists instead. The sfc /scannow command that Windows 11 users still run to repair system files descends directly from that work, having replaced a 1995 mechanism that decided when to act by scanning filenames for the word "setup."