> 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)