> One could argue DRI bowed out too soon. Then again, it’s questionable whether it would have won against Windows anyway. Microsoft was the larger company and had OEM agreements with all of the major PC makers.

Well, it is also that Windows even at version 1.0 was much more capable than GEM. Better documentation, better tools, better API and better functionality.

GEM was really just a shell over DOS and applications were actually DOS programs that called a special interrupt handler to make API calls. While this allowed any language that could make EXE files and call interrupts to be used to make GEM apps, it also meant that GEM inherited all the limitations from DOS, like the inability to run multiple applications at the same time (DR did eventually make GEM/XM that allowed switching between applications but it was still only one application active at any given time). Windows meanwhile not only could run multiple applications, but it also had a software-based virtual memory system that allowed applications to swap in/out both data and code to fit in the available memory (this required custom compiler support so, unlike GEM, you couldn't use any old compiler but on the other hand it you could make more complex applications).

The GEM API was also very barebones, you could create windows but all you could do with them was to draw inside. Dialog boxes were a completely separate thing that could take a tree of "objects" to draw inside them but even then the functionality was limited (the object types are hardcoded and while there is a "custom" type, all it does is provide a callback for drawing). You could work around some of the functionality by implementing some of it yourself - for example there is a call to draw an object tree (object trees are actually a flat array of fixed size structures where the first three fields define 16bit indices inside the tree for each object - this probably saved some bytes of memory at the cost of flexibility loss and TBH the extra bytes added for the code to work with the tree probably ate back those saved bytes, if not made things worse) so i think (never tried it) you could draw buttons, etc in a window when you receive the WM_REDRAW message but there is no event message propagation.

Meanwhile on Windows everything is a "window" in a window tree with a consistent approach to how things are handled. On GEM everything is a special case.

I get the impression that the GEM developers basically had some idea of what their desktop would look like and implement the functionality to do just that and nothing else with little room for flexibility or later expandability.

EDIT: also the graphics functionality was very limited, e.g. with hardcoded colors. Here are some GEM API docs in case anyone is interested:

https://www.seasip.info/Gem/vdi.html (low level API, draw graphics, input devices, etc)

https://www.seasip.info/Gem/aes.html (relatively high level API, make windows, define dialogs, messages, etc)

https://www.seasip.info/Gem/aestruct.html (some structures)

https://www.seasip.info/Gem/aesmsg.html (event message types)

I wrote a hypertext system that created dialog boxes on the fly and used the callback for the custom object type to implement links.

Atari ST user here. AES is as you say rather bare bones. In some ways it's more analogous to X windows "Xt" X intrinsics than it is to any "widget" toolkit -- in that it gives you the facilities for constructing trees of drawn objects, registering applications, communicating between applications, receiving events, opening windows, redrawing windows, etc. but for actual active widgets ... only provides premade alerts, dialogs, windows, menubars, and a file selector. But in fact those pieces are made from object trees like you say. So, yes, with your own event handling you absolutely could write your own widgets directly into the window by drawing an object tree, and more savy developers did that.

I suspect there was maybe an intent to eventually build something higher level above it, still. Just that never happened, or was never standardized. There are in fact some C-level libraries for the Atari ST that do, but they're more recent inventions.

It's not a bad architecture, just incomplete. It wasn't aiming for -- nor would they have had the budget to make -- the same space as MS Windows in that it wasn't a full and complete environment in that way. Even on the Atari ST where they controlled the whole stack instead of being hoisted over MS-DOS.