Apple sued DR and won, and DR had to cripple PC GEM. No overlapping windows, no icons on the desktop, drop-down menus instead of pull-down, and much more.
When it went GPL, all the removed functionality was put back, plus most of the stuff from the vendor-specific runtime-only versions 4 and 5.
I got the Amiga 1000 in 1985. I never did get into the Atari ST but I had friends who did. The next computer after the Amiga was a 386DX PC clone with VGA and a sound card.
It puts into perspective just what a spectacular amount of bloat we have in modern software.
A lot of it comes from diversity though.
GEOS was a tightly coupled system with one design, API, and programming paradigm. Same goes with classic macOS and other old school desktops. You had no more than two or three languages in use (usually ASM, C, and something like Pascal), one GUI library, one set of runtime libraries, etc.
Today your typical desktop hosts apps written in dozens of languages using dozens of graphics libraries and rendering layers. Since different apps use different versions of these things each app often ships the entire stack with it, meaning you may be running three or four versions of a dozen things. To make all that interoperable requires a Byzantine mess of APIs and interfaces and across the whole system. There are tons of shims and hacks and duplication of effort.
I remember a silent paradigm shift happening in the 2000s when we abandoned the question of what the “best” language or OS was and instead concluded “we’ll just run everything all at once.”
So now we need 16 gigabytes of RAM for a desktop.
I wonder sometimes if AI could get us out of this mess. Could future much more powerful coding models do things like reimplement the entire desktop environment in our language of choice at our command? Could they consolidate and refactor code at industrial scale? The thing that makes it impossible to get rid of all this cruft is the cost of doing so, something automation could cut.
If we could somehow make AI output deterministic and predictable, maybe. At the moment all it does for me is manage to make a 20GB GPU feel inadequate while every output is a loaded dice roll-- the opposite of what you're considering.
AI will mostly let us get into a (much) deeper mess by cheaply generating tons of mediocre code. By the time AI gets around to understand complex code, it'll be to fix it's own generated mess.
I also really like GEM (for the PC and Atari ST). It's nice to imagine Gem would have replaced windows in some alternate reality and then imagine where that would have taken us. Probably to a similar place, given the forces on the industry ...
I'm still longing (irrationally) for the simplicity of GEM on the monochrome Atari ST monitor...
The documentation and code clarity for older assembly projects is by a magnitude more pleasant than any modern source I’ve looked at during the last 20 years. We should be ashamed of what we’ve done in our profession.
Man, I'd forgotten about WriteNow. It was my favorite word processor on the Mac for years. (I'm pretty sure at one point -- long after it was defunct -- I acquired a copy of the very last released version, which crazily enough was published by WordStar.)
Somewhere I still have the StarOffice CD/s that I received (bought?) when it was a SUN microsystems product in the...maybe very early 2000s. And now I use LibreOffice...so, fairly successful software.
Some screenshot would make sense, at least in the readme.md on github. I recall GEOS on Commodore 64, 2 1541 floppy disks (speeddos?) it was a miracle, all running in 64kB: GUI, editor, calculator and other apps. Nowadays single static images are much larger than 64kB (at higher resolution though).
AOL became popular alongside the growth of Windows so most people think of them together. But they supported DOS-only customers with a GeoWorks client.
The irony of GEOS is that it was known for having low hardware requirements to run, but software development for it was done on Sun workstations. There wasn't a DOS SDK until well after Windows had won the desktop.
I grew up with a C64 when I was 5-6 years old. My “uncle” cracked games under the alias “THE SHADOW” and sent me boxes of 5-1/4 disks. When I was 7 and bored one summer I went digging in our basement boxes and found a disk organizer full of “business” software. When I got GEOS running I remember becoming so upset with my parents that they “hid” this from me. To me, GEOS made my toy a “real” computer. I played with GEOS all summer. Such good memories.
I very proudly ran Geoworks on DR DOS on my 486, just to avoid Microsoft as much as possible. It ran really well! But eventually I got lured in by OS/2.
This made my IBM 5150 like a new computer! The display and print postscript gave full wysiwyg and the output to my 9 pin dot matrix printer was second to none.
Can anybody explain to me where the meat of the application code is? For example, when I look at GeoDraw under Appl/GeoDraw I see .def files containing definitions, declarative looking .ui files in the UI subdirectory and some .asm files containing only a few very short functions. That surely can't be everything? I remember it being quite a complex application.
59 comments
[ 3.0 ms ] story [ 31.8 ms ] threadIt looked quite a lot like the Mac though the underlying API was nothing like the Mac.
The DOS version was dreadful.
Source: Amiga then Mac owner
Not at first, and not later.
Apple sued DR and won, and DR had to cripple PC GEM. No overlapping windows, no icons on the desktop, drop-down menus instead of pull-down, and much more.
When it went GPL, all the removed functionality was put back, plus most of the stuff from the vendor-specific runtime-only versions 4 and 5.
IMHO it looked great:
https://www.seasip.info/Gem/History/freegem2.html
Also, some of the GPL code went into EmuTOS, an all-FOSS TOS+GEM, so it wasn't wasted or lost.
My parents brought the family a Amiga 500 in 1990
A lot of it comes from diversity though.
GEOS was a tightly coupled system with one design, API, and programming paradigm. Same goes with classic macOS and other old school desktops. You had no more than two or three languages in use (usually ASM, C, and something like Pascal), one GUI library, one set of runtime libraries, etc.
Today your typical desktop hosts apps written in dozens of languages using dozens of graphics libraries and rendering layers. Since different apps use different versions of these things each app often ships the entire stack with it, meaning you may be running three or four versions of a dozen things. To make all that interoperable requires a Byzantine mess of APIs and interfaces and across the whole system. There are tons of shims and hacks and duplication of effort.
I remember a silent paradigm shift happening in the 2000s when we abandoned the question of what the “best” language or OS was and instead concluded “we’ll just run everything all at once.”
So now we need 16 gigabytes of RAM for a desktop.
I wonder sometimes if AI could get us out of this mess. Could future much more powerful coding models do things like reimplement the entire desktop environment in our language of choice at our command? Could they consolidate and refactor code at industrial scale? The thing that makes it impossible to get rid of all this cruft is the cost of doing so, something automation could cut.
Sure. They are trivially Googled -- if you know that this poor product was renamed multiple times.
GeoWorks 2.0:
https://guidebookgallery.org/screenshots/gwe2
https://winworldpc.com/screenshot/c28fc2a9-e280-ba01-2d6c-11...
BreadBox Ensemble Lite 4.0:
https://guidebookgallery.org/screenshots/bbel4
BreadBox Ensemble full (not Lite) version:
http://toastytech.com/guis/bbe.html
I'm still longing (irrationally) for the simplicity of GEM on the monochrome Atari ST monitor...
The original version, now FOSS: the PC port/rewrite of the C64 original.
LibreOffice < OpenOffice < StarOffice < StarWriter
https://www.cpcwiki.eu/index.php/Star-Writer
(Breadbox Ensemble is the most recent version)
Is it a coincidence that it resembles OS/2 Warp?
The irony of GEOS is that it was known for having low hardware requirements to run, but software development for it was done on Sun workstations. There wasn't a DOS SDK until well after Windows had won the desktop.
[*] https://tedium.co/2019/06/20/geoworks-geos-history/
https://www.techrepublic.com/article/how-pcgeos-found-a-5th-...
I _really_ wish someone would port this to the Raspberry Pi.
https://blog.bluewaysw.de/ensemble-on-raspberry-pi-with-ethe...
To turn this around --- what would be the most affordable new computer this could be run on?
If it could be run on a modern tablet w/ a stylus and handwriting recognition, I know what my next computer will be.
https://github.com/mist64/geos
https://csdb.dk/scener/?id=3324
https://csdb.dk/scener/?id=9467
https://csdb.dk/scener/?id=26172 (cracker)
https://csdb.dk/scener/?id=26838
https://csdb.dk/scener/?id=27327
https://csdb.dk/scener/?id=31327
https://csdb.dk/scener/?id=33379
https://csdb.dk/scener/?id=36183 (cracker)
https://csdb.dk/scener/?id=38598
Windows on a 386 was a step down in many ways.
OK fine. Someone create a docker image for this purpose: https://github.com/crempp/watcom-docker.
Will try it.
And it was programmed in a completely object oriented way so that it would suspend everything to disk.
You started the PC and all your applications, windows and documents were open like before, something that macOS only achieved 20 years later.