Now, there's a name I haven't heard in a long time...

Back before 2000 I did a tonne of stuff with GEOS; wrote a couple of terrible programming languages, some not-so-terrible games, a bunch of hacking, and even managed to write a Linux system call emulator allowing you to run Linux binaries under GEOS. (Well, ELKS. That still counts as Linux, right?) (In hindsight I should have gone for Minix binaries instead, as nobody back then had heard of ELKS, or now, and it would have let me run the Minix C compiler under GEOS.) See http://cowlark.com/geos-software.

It's an exceptionally elegant system, providing a multi-threaded, object-oriented system with outline fonts, full vector graphics support (based on things called GStrings), virtual memory (including virtual memory _files_, so disk I/O is done for you by the system), long filenames and symlinks, and a component-based architecture allowing for massive code reuse, all on a 640kB PC/XT running at 4.77MHz. On a faster machine it simply flew.

The core of it is a smart linker/loader which allows code and data segments to be loaded, patched together on the fly, and dropped on demand. All data is relocatable, allowing it to be rearranged or swapped out. The core language is 'object-oriented assembly' --- assembly with high-level features for message sending and deserialising objectes; the OO system has some very nice tricks up its sleeves, such as the specific/generic UI mechanism. Your app describes its UI in generic terms using classes like Trigger; these have holes in their inheritance tree. When your app gets loaded, the system fills in these holes with matching classes from the UI system. So a Trigger can turn into a Motif button, or an old-school GEOS button, or the Brother UI button, etc, depending on what it's loaded on.

You could also write in GOC, which is a proprietary preprocessed C not dissimilar from Objective C; it was, um, interesting. The code it generated had to be compiled with Borland C, which was expensive. The entire development environment wasn't great: there was a command-line debugger which had to run on a completely separate PC connected to your main machine with a serial cable. I rarely bothered with it.

Sadly the whole architecture is intrinsically tied to the i86 segmented architecture. Although, modern machines are so fast that I'm sure you could cross-assemble the i86 code to a modern architecture and just do the segmentation in software. The system's so well designed (and small and fast) that it'd probably still be an order of magnitude lighter than, say, LibreOffice. I still miss GeoDraw.

(I got a job offer from Geoworks once! I turned them down to stay with Tao, an equally doomed operating system startup...)

Great insights!

Your comment also made me wonder what actually happened to ELKS. Last I checked (many years ago, apparently), it seemed abandoned. But development has started again in 2014, and still seems ongoing: https://github.com/jbruchon/elks

Should play with it some time, maybe in an 8086 emulator.

EDIT: By the way:

I forgot to mention this in my other comment:

> The core of it is a smart linker/loader which allows code and data segments to be loaded, patched together on the fly, and dropped on demand. All data is relocatable, allowing it to be rearranged or swapped out.

Early Windows on early XTs did that, too! With all sorts of crazy hacks to make it happen [1]. I don't know how it compared to what GEOS did, though.

[1] https://blogs.msdn.microsoft.com/oldnewthing/20110316-00/?p=... and many other articles on that site can send you down a deep rabbit hole.