Maybe the technical politics have changed, but I feel like I remember there was some push in the late 2000s to rewrite libraries that were using Xlib to instead use XCB.
Regardless, that's sort of my point: having a lower level fiddly layer is a desirable quality, and Xlib being rebased on top of it isn't exactly a counterexample.
You don't have to make a complete alternative. You can add calls to ATK (accessibility toolkit) on Linux/Unix platforms. I'm not sure what needs to be done on Win32 platforms though.
The best example I can think of is the Win32 controls UI (user32/Create window/RegisterClass) in C. You likely can't read the source code for this but you can see how Wine did it or Wine alternatives (like NetBSD's PEACE runtime, now abandoned).
Actually the only toolkit that I know that sort of copied this style is Nakst's Luigi toolkit (also in C).
Neither really used inheritance and use composition with "message passing" sent to different controls.
Vibe coding in the 90s was probably like learning C and pointers for the first time and then deciphering strange errors when you couldn't figure out how scanf worked, so you added asterisks and ampersands to the code until it compiled.
I once spent a couple hours debugging a perl cgi script. Nothing worked. Called in my colleague. Looks fine. We both were tearing our hair out. Sent it to the line printer, ordered pizza, and one of us read the code while the other typed it in. Couple hours later we finished and it worked.
AFAIK Cosmopolitan is missing the sandboxing features of WASM runtimes which would allow to run untrusted code safely, and for x86 vs ARM it uses the universal binary approach (e.g. you'll either have the x86 or the ARM code as dead weight in the executable).
For some reason I pictured this software as a system for developing memory or CPU constrained software. Like granting only 1 mb of memory and maybe having functions executed in a certain number of "clock ticks"
> Less controversially, when you write C, you write for a virtual machine described by the C spec, not your actual hardware.
Isn't this true for most higher level languages as well? C++ for instance builds on top of C and many languages call into and out of C based libraries. Go might be slightly different as it is interacting with slightly less C code (especially if you avoid CGO).
reply