I can't say I'm wild about a world where Digital Research won. When they were dominant with CP/M, the tools and documentation were bad to the point where most machines had Z80 processors and DR only provided an 8080 assembler, so you had to DB significant bits of code to get the missing opcodes. Developing RSXs to access bank-switched memory under CP/M 3 could have been so much easier with a few examples and perhaps debugging tools. MS/DOS was just so much easier.
I remember using a Z80 assembler on a CP/M 1.x machine, way back when. If it wasn't by DRI could it possibly have been (shock, horror) Microsoft??? We did have a Microsoft Fortran compiler, which was crap, but that was mostly down to being floppy disk based.
Not trying to be funny, I used the assembler a lot, but I really can't remember who supplied it.
Oh, just had a thought - this was on Research Machines 380Zs, so perhaps it was Research Machines home-grown one?
Yes, there were one or two third party assemblers available. From memory, the issue was with the downstream tools - so for instance on CP/M 3.0, I think you had to use the DR one to be able to build an RSX (equivalent of a TSR under DOS. You could count the number of 8080 CP/M 3.0 machines on the fingers of one foot.
You've reminded me that I have a 380Z or 480Z in the loft - I must get it going again.
GEM on the PC was... ick... compared to on the Atari ST.
But the problem with GEM on the Atari ST is that in order to cram it into the 192KB ROM they ripped out some goodies like proportional font support which ended up being in an add-on called "GDOS" which was buggy, used up RAM, and most people didn't have it (it came with things like DTP software etc).
In general this was always the problem with the ST. The Tramiels shipped it early and cheap and awesome and I loved mine ... but then didn't pay enough attention to software updates until it was too late and the world had moved on. Jack Tramiel never really understood the value of a good software platform IMHO.
In the early 90s they seemed to learn the error of their ways, hired some talent, and released full multitasking re-entrant versions of TOS/GEM ... but too late.
GEM's architecture itself underneath actually was clearly built for a mulitasking architecture complete with message passing between applications (via AES application msg send / mailboxes) etc. It just came down to failure to iterate.
Also the article mentions DR "hiring some people from Xerox" but in fact fails to note that the actual original architect and author of GEM itself was hired from Xerox (Lee Lorenzen). He joined up with DR because he tried to pitch Xerox on porting their Star office concepts down to PC-class hardware and they didn't go for it. His pitch video can actually be seen here:
> But the bigger problem was software piracy. Piracy was common on the ST, and that made developers less enthusiastic to continue ST development
Not so sure about this. The Atari/GEM combination was very popular with musicians for MIDI, and I don't think there was so much piracy, or at least not compared with other platforms of the time.
The reasons I didn't develop anything much for Gem - a) It was quite difficult b) Not well documented c) I was too busy playing Dungeon Master.
Apple sued DRI, which resulted in the crippling of GEM, the glaring one I remember were static windows. You heard that right, windows were not resizable but had fixed screen locations in the PC version.
Thankfully Atari licensed GEM for their 68000 machines before the lawsuit, and wasn't affected by these changes. The Atari ST (Sixteen/Thirtytwo) was very Mac like at the time. It even ran the Mac OS from Apple ROMs (Spectre 128 and Aladin) on its much cheaper hardware.
I ran GEM on some of my early computers. Also bought both Windows 1 and Windows 2 to try. GEM was clearly superior from a user stand point. Windows 3 shipped and they just disappeared.
I was really interested in how they would respond to the challenge. IBM was working publicly with Microsoft on OS/2 so they had to know the market was going to change. The only real surprise was when Microsoft went all in on marketing Windows 3 and the rise of Office.
Borland tried to compete against Office and got killed. Perhaps with a competent GUI operating system it might have been different.
You do mention OpenGEM and FreeGEM, but not what's in them. They re-added all the features DR removed after the Apple lawsuit. They also added the features from GEM/4 and GEM/5 which John Elliot documented:
There were also other branches of GEM. DR did several...
• ViewMax, which was bundled with DR-DOS 5 and 6. This had Windows-style keyboard controls and could operate and manage DR-DOS's built-in multitasker, TaskMax.
• It also was working on GEM/XM which offered multitasking on plain old DOS.
• X/GEM ran on DR's RTOS, FlexOS. This was the realtime offshoot of DR Concurrent CP/M and Concurrent DOS: a family of full, native, protect-mode, multitasking DOS-compatible OSes for the PC, and 286s, and 386s. FlexOS is multitasking and so is X/GEM.
Some of the code from FreeGEM made its way back into ST GEM. There is a complete multitasking FOSS OS for the Atari ST and compatibles, called AFROS. It targets its own emulator, Aranym.
It originally had a minimal stub ROM replacement to boot the emulator: the OS is a native multitasking one so does not need much from Atari's ROM, which is not FOSS anyway. Atari's ROM is not just a BIOS: it contains the whole OS – the BIOS, and GEMDOS on top, and GEM on top of that.
But the community took that stub ROM and upgraded it to a fullly FOSS replacement for Atari TOS. In other words, with a replacement for GEMDOS and a replacement for GEM. That GEM replacement is partly built from FreeGEM code.
It's a lot of life for a long-dead desktop. I think some of this deserved a mention bigger than a single sentence.
My family's first computer in the 80s was an Amstrad PC1512 (an IBM XT clone). We received 4 nice colorful system floppies with it, and it included a GEM Desktop. I remember sometimes logging into GEM, because it looked awesome, but we never had a single program to run on it, so it was practically useless. https://www.youtube.com/watch?v=DlUTzydzLVI
I've been on a bit of a rabbit hole with Digital Research in the last few days, specifically because I am utterly fascinated with Concurrent DOS.
I played with Concurrent DOS (and later MultiUser DOS) in PCem and I was utterly amazed. I hadn't realized that there was a preemptive multitasking operating system available to consumers as early as the mid 80's outside of AmigaOS.
I read the Wikipedia and I kind of understand why it didn't catch on, but man I kind of wish DRI (and Gary Kildall) was still around. I suspect if they were, they would have continued to make stuff that was at least interesting.
> 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:
84 comments
Not trying to be funny, I used the assembler a lot, but I really can't remember who supplied it.
Oh, just had a thought - this was on Research Machines 380Zs, so perhaps it was Research Machines home-grown one?
You've reminded me that I have a 380Z or 480Z in the loft - I must get it going again.
But the problem with GEM on the Atari ST is that in order to cram it into the 192KB ROM they ripped out some goodies like proportional font support which ended up being in an add-on called "GDOS" which was buggy, used up RAM, and most people didn't have it (it came with things like DTP software etc).
In general this was always the problem with the ST. The Tramiels shipped it early and cheap and awesome and I loved mine ... but then didn't pay enough attention to software updates until it was too late and the world had moved on. Jack Tramiel never really understood the value of a good software platform IMHO.
In the early 90s they seemed to learn the error of their ways, hired some talent, and released full multitasking re-entrant versions of TOS/GEM ... but too late.
GEM's architecture itself underneath actually was clearly built for a mulitasking architecture complete with message passing between applications (via AES application msg send / mailboxes) etc. It just came down to failure to iterate.
Also the article mentions DR "hiring some people from Xerox" but in fact fails to note that the actual original architect and author of GEM itself was hired from Xerox (Lee Lorenzen). He joined up with DR because he tried to pitch Xerox on porting their Star office concepts down to PC-class hardware and they didn't go for it. His pitch video can actually be seen here:
https://www.youtube.com/watch?v=EMBGRZftS30
Lorzenen later left DR and created Ventura Publisher.
> But the bigger problem was software piracy. Piracy was common on the ST, and that made developers less enthusiastic to continue ST development
Not so sure about this. The Atari/GEM combination was very popular with musicians for MIDI, and I don't think there was so much piracy, or at least not compared with other platforms of the time.
The reasons I didn't develop anything much for Gem - a) It was quite difficult b) Not well documented c) I was too busy playing Dungeon Master.
I think many others may have similar thoughts.
It ran quite well on my 286.
https://en.wikipedia.org/wiki/Ventura_Publisher
Thankfully Atari licensed GEM for their 68000 machines before the lawsuit, and wasn't affected by these changes. The Atari ST (Sixteen/Thirtytwo) was very Mac like at the time. It even ran the Mac OS from Apple ROMs (Spectre 128 and Aladin) on its much cheaper hardware.
I was really interested in how they would respond to the challenge. IBM was working publicly with Microsoft on OS/2 so they had to know the market was going to change. The only real surprise was when Microsoft went all in on marketing Windows 3 and the rise of Office.
Borland tried to compete against Office and got killed. Perhaps with a competent GUI operating system it might have been different.
https://nemanjatrifunovic.substack.com/p/history-of-the-gem-...
He missed out on the recent history of the environment, and at the time, I wrote a blog post adding more info on what happened next:
https://liam-on-linux.dreamwidth.org/96552.html
You do mention OpenGEM and FreeGEM, but not what's in them. They re-added all the features DR removed after the Apple lawsuit. They also added the features from GEM/4 and GEM/5 which John Elliot documented:
https://www.seasip.info/Gem/
There were also other branches of GEM. DR did several...
• ViewMax, which was bundled with DR-DOS 5 and 6. This had Windows-style keyboard controls and could operate and manage DR-DOS's built-in multitasker, TaskMax.
• It also was working on GEM/XM which offered multitasking on plain old DOS.
• X/GEM ran on DR's RTOS, FlexOS. This was the realtime offshoot of DR Concurrent CP/M and Concurrent DOS: a family of full, native, protect-mode, multitasking DOS-compatible OSes for the PC, and 286s, and 386s. FlexOS is multitasking and so is X/GEM.
Some of the code from FreeGEM made its way back into ST GEM. There is a complete multitasking FOSS OS for the Atari ST and compatibles, called AFROS. It targets its own emulator, Aranym.
https://aranym.github.io/
It originally had a minimal stub ROM replacement to boot the emulator: the OS is a native multitasking one so does not need much from Atari's ROM, which is not FOSS anyway. Atari's ROM is not just a BIOS: it contains the whole OS – the BIOS, and GEMDOS on top, and GEM on top of that.
But the community took that stub ROM and upgraded it to a fullly FOSS replacement for Atari TOS. In other words, with a replacement for GEMDOS and a replacement for GEM. That GEM replacement is partly built from FreeGEM code.
It's a lot of life for a long-dead desktop. I think some of this deserved a mention bigger than a single sentence.
I played with Concurrent DOS (and later MultiUser DOS) in PCem and I was utterly amazed. I hadn't realized that there was a preemptive multitasking operating system available to consumers as early as the mid 80's outside of AmigaOS.
I read the Wikipedia and I kind of understand why it didn't catch on, but man I kind of wish DRI (and Gary Kildall) was still around. I suspect if they were, they would have continued to make stuff that was at least interesting.
> 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)