andrewf
All the assembly code, and the C harness which loads the textures etc, was hand done by me, and period correct. That's where the fun is!
Outside of that, there are so many anachronisms. I actually built the test geometry as a quake map, and processed it using Quake's BSP/lightmap tools. That's 1996 vintage.. except I'm using a newer Quake editor (Trenchbroom, 2013) and modern forks of the tools. All natively on a modern system with a 4K monitor. Building and non-performance testing of the DOS code happens in a Windows XP (2001) VirtualBox (2007) using its' Shared Folder feature.
I might have time to pick this up again soon. My post-processing of the Quake .bsp presently only handles axis-aligned 64x64 surfaces with some hardcoded texturing assumptions. I'll want a full .bsp-to-isometric-data "renderer" - either written from scratch or somehow derived from Quake's source. But this is all just to enable the 286 assembly code noodling, which is what I want to spend time on!
So I'll probably use Claude to assist with the tooling side. By "assist" I mean "do as much as possible to produce the file format I specify". It doesn't seem much worse to me than all the other modernisms I'm already relying on outside of the core task.
I could still read the text! And it's useful to read texts and understand 95%, or 80%, or even 50%! IMO "fully understand what you're reading" versus "can't understand what you're reading" is a harmfully discouraging dichotomy. You can often gloss over such things rather than struggle with them.
I'm guessing dBase was itself built using Microsoft's compilers, so pulling in other code from the same compiler was plausible. Not a product choice re: the Turbo compilers, just a disjoint path dependency between two acquired product lines (Ashton-Tate's dBase, and Wizard C).
This is the reason that Clipper, a third-party dBase compiler, could only link against .OBJs from particular versions of Microsoft C. Clipper compiles to p-code whose interpreter is implemented in Microsoft C; "linking" a Clipper program is actually linking a Microsoft C program with a static array comprising the Clipper compiler's output. So you can mix in a .OBJ expecting that version of the Microsoft C runtime library. Not a .OBJ expecting the Turbo C++ runtime library.
Sometimes a "punch in the face" is useful. Makes you re-evaluate things. Being punched in the face all day, every day, is just tiring.
"Six paediatric health-care professionals were recruited to swallow a Lego head."
2. Separate entity spun up to focus on Thunderbird only. Now you can support Thunderbird development directly.
3. New separate entity is now in the business of extensible AI clients?
EDIT: I went back and read the launch announcement [1]. I'll concede it does say "will also allow us to explore offering our users products and services that were not possible under the Mozilla Foundation" which could mean anything, really. And this development was funded by a Mozilla grant, importantly not by Thunderbird donors. I'm still struggling to not see this as a distraction from the core mission. I wish they'd spun up a new entity instead.
[1] https://blog.thunderbird.net/2020/01/thunderbirds-new-home/
Conceivably LLMs might be good at answering questions from an unorganized mass of timestamped documents/tickets/chat logs. All the stuff that exists anyway without any extra continuous effort required to curate it - I think that's key.
Their stuff isn't running on top of Linux on the Pi.
What I've learned from visiting my own parents is, you can alleviate the energy concern, if you (1) get solar panels and (2) ban your spouse from running the dishwasher at night :P
Sounds like this is about making .OBJs that fit in the conventions set by Win32 and the Microsoft linker. If you were using Microsoft's LINK.EXE I'd look at https://learn.microsoft.com/en-us/cpp/build/reference/nodefa... (and /Zi for the Microsoft compiler)
More generally, a lot of compiler generated code (including from LLVM IR -> native) will rely on compiler-specific runtime library functions, which aren't necessarily considered part of the "C runtime". https://wiki.osdev.org/Libgcc occupies this role for GCC-compiled code. See https://godbolt.org/z/fb75PPobz for an example (64-bit division on 32-bit x86 generates a call to ___divdi3)
(One example: hit "Show" on the table header for Win11, then use the form at the top of the page to highlight syscall 8c)
To re-encode the content into H.264+AAC, rather than simply "muxing" the encoded bitstreams from the MP4 container into a new MOV container.
I'd guess there are fewer media/codec engineers around today than there were web developers in 2006. In 2006, Gmail existed, but today's client- and server-side frameworks did not. It was a major bespoke lift to do many things which are "hello world" demos with a modern framework in 2025.
It'd be nice to have more flexible, orthogonal and adaptable interfaces to a lot of this tech, but I don't think the demand for it reaches critical mass.