Hopefully open-sourcing it will keep this great operating system alive. It should have beat Windows 3.1.
the "successor", i.e. Newdeal Office:
was not at all shaggy and later Breadbox Ensemble had also some nice feature (for the extremely low resources it used):
It might be useful as the basis of a new mobile-phone operating system.
It is certainly interesting to the archaic-computer users out there who are maintaining old systems as a means of consolidating computing culture, as we lean more and more towards homogenisation ...
Similarly, there’s nothing about geos that’s appropriate for a mobile device. If you want to start with something existing, Android is already open source and has a ton of existing software. Or try fuschia if you want more bleeding edge.
Now if you say it’s for a hobby, or fun, or whatever then I can understand.
I have an Android ADP1 phone on my desk at work; the first Android phone which was ever released (the G1 with the custom paint job on the back). It's a paperweight; there's nothing useful I can do with it, and it won't even talk to the Google servers any more. However, obsolete as it is, it's still staggeringly more powerful than anything GEOS ever ran on.
The biggest thing systems like GEOS do for the modern developer is to be an example: to demonstrate just what you can do with a tiny, tiny amount of code.
(Oh yeah, GEOS also had virtual memory and preemptive multitasking.)
To get a pointer, there were additional calls that would enable blocks (identified by handle) to be locked and unlocked. The lock calls provided pointers that were deemed valid until the block was unlocked.
The net of this is that the OS could do things like relocate and page blocks that weren't locked, and do it without hardware assistance.
It really was a nice, minimalistic way to approximate some 'big iron' features on modest hardware. (Although it's hard to imagine anyone wanting to go back. :-) )
Let's not get carried away... I remember running Linux on machines as small as 4MB.... not to mention embedded versions that were materially smaller still.
While it's true that PC/GEOS was small and efficient, it's also a product of its time (early 90's), as well as the fact it basically didn't follow any backwards compatibility constraints.
> demonstrate just what you can do with a tiny, tiny amount of code.... Oh yeah, GEOS also had virtual memory and preemptive multitasking.)
My first professional software job involved writing software on a custom OS that had at least the preemptive multitasking in four C source files. (Handle based VM would've been an easy addition.) It was also portable across X86 real and protected modes, and MC68K...
The allure of using an old operating system as the basis for new work is that it would at least seem to be much simpler than a modern operating system; and it's a good thing to avoid unnecessary complexity. Of course, it may turn out that in order to work on a modern computer, you need most of the complexity.
Something that's reported to work well on a 386 should be likely to feel responsive and fluid on any modern computer.
It's not as simple as comparing it to the paradigm used by other operating platforms.
Honestly, PC/GEOS would have been even better suited to task. Less resource intensive, but still with decent WYSIWYG tools. I may have to put together a bootable device with FreeDOS and GEOS this weekend.
Nothing wrong just-for-fun projects, of course. I loved GEOS on the C64, and it tickles me that someone's still maintaining it.
HN is also an experiment of community building. As far as I am concerned, the downvotes for the parent are a sign that the experiment is moving torwards fail.
If you are insecure as to when it is appropriate to downvote on HN, please read the ruleset again. Thanks.
We periodically get people on HN sneering at neat toy projects because they don't fill a business need, and we don't like that.
There is only one written-down rule about downvotes, and your comment is breaking it.
It was extra fun when one of the guys checked in a hacked version with some special keys to cheat that only he knew about. :-)
https://en.wikipedia.org/wiki/GEOS_(16-bit_operating_system) has more history. I played with it around Windows 3.1 times.
With that said, all the apps I had for it were the ones that came with it, so in a sense it was just a glorified version of micrsoft works + some games. It was cute and in a way gave a longer life to the 8086 machine than it deserved having, but, they missed the microsoft concept of "developers, developers, developers"
I remember pretty amazed at GEOS on the C64, but have never fully understood if there was a connection to the other GEOS implementations (or the nature of that connection if it existed).
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...)
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 . I don't know how it compared to what GEOS did, though.
 https://blogs.msdn.microsoft.com/oldnewthing/20110316-00/?p=... and many other articles on that site can send you down a deep rabbit hole.
Do you know of any documentation online that covers the loader and other good bits?
Also, what is/was Tao?
Turns out people didn't want to buy that.
Anyone remember KeyDraw? GEM-based vector graphics package for DOS, based on the GUI libraries from GEM Desktop which was the descendant of GEOS / GeoWorks, if I recall. Fantastically learnable program that introduced 5-year-old me into the world of vector art.
(On that front, anyone remember Aldus Intellidraw? Even better, _still_ a better UI than Illustrator, though held back by lack of antialiasing and weak postscript support).
Lorenzen went on to create the successful DTP program, Ventura Publisher, which itself used a bundled copy of GEM.
The wikipedia article on GEM has a good chunk of history: https://en.wikipedia.org/wiki/Graphics_Environment_Manager
A 68000 port of GEM and GEMDOS (which itself was a kind of fork of DR's own CPM/68k) were the basis of the Atari ST operating system "TOS". Some of the tales of how that all went down are documented by one of the participants here:
All of this an entirely separate effort from GEOS/GeoWorks, though in some respects the two efforts are similar in that they aimed to bring the full WIMP experience to fairly low-powered machines. But the philosophy was quite different. PC/GEOS was written in a lot of assembler, specifically for x86 (after they'd done something similar for the C64 in 6502 assembler in fact), specifically for commodity PCs. GEM was written in C with some amount of portability in mind (in theory), and ran on top of DOS, CP/M, or GEMDOS (I believe there was also attempts to get it to run on top of Unix). The first version of GEM was developed and ran on the Apple Lisa hardware.
I was blown away to see a desktop/gui for the first time in my life.
It felt like going back to the stone-age when I got a PC and it just had DOS and Norton Commander, haha
I think I'd love to have GeoWrite and GeoDraw back, but I'm afraid that the nice golden patina my nostalgia has applied to them probably isn't actually very thick. It might be better for me to just get the originals running in a DosBox or something...
Besides, the whole environment can probably run from within the cache of a modern CPU.