PC/GEOS | Hacker News Reader

PC/GEOS

github.com

115 pointsbeefhash76 comments

I'm really happy to see this. I wrote a story about PC/GEOS, also known as GeoWorks, a few years ago, and the end of the story was somewhat sad, as the death of one of the founders of BreadBox effectively left the future of the operating system in flux.

https://tedium.co/2016/04/28/geoworks-windows-3-1-competitor...

Hopefully open-sourcing it will keep this great operating system alive. It should have beat Windows 3.1.

Also here:

http://toastytech.com/guis/geos12.html

the "successor", i.e. Newdeal Office:

http://toastytech.com/guis/nd32.html

was not at all shaggy and later Breadbox Ensemble had also some nice feature (for the extremely low resources it used):

http://toastytech.com/guis/bbe.html

I gotta say, I like that interface. The idea of having multiple levels of interface complexity is also pretty interesting. Reminds me a lot of SuperMemo for better and worse. Very cool.

I really liked your post. I'd love to see more people making current articles about alternative approaches to operating systems and environments like that. It seems people forgot that just about 15 ago, there were many alternatives to the current stuff we're running.

These screenshots look so similar to the contemporary UNIX GUIs (Motif/VUE/CDE) that I'm surprised they never got sued over it.

I'm pretty sure it actually is Motif. That's how I remember it, and there's certainly enough text in the source to support that.

That's really interesting, seems like they licensed the Motif API and ported the whole thing over to DOS. Because the normal Motif is very much tied to UNIX and X.

X - sure; Unix - not do much; CDE desktop ran on OpenVMS.

It was similar to the Motif L&F but it was all implemented from scratch in the x86 assembly version.

What makes it great in 2018? Why keep alive?

It could function as a great alternative to Windows or FreeDOS for those of us who don't want to pay a Microsoft tax whenever we buy a new computer.

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

What makes an 80s/90s era 16-bit OS great in 2018? If you want free/open source, why not run Linux or FreeBSD or any if the many modern alternatives that have 64-bit support, preemptive multitasking, protected memory, modern VM, new software actively being developed for it, drivers for modern hardware, support for SSDs and USB 3.0 and nvidias, etc etc?

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.

GEOS would run on systems three orders of magnitude smaller than the ones you describe. It was intended to work well on machines with a single megabyte of RAM, and did.

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

Thanks for posting this. I used GeoWorks as well and marveled at how much OS/UI/app integration they packed into it. That the virtual memory and preemptive multitasking usably ran on a 286 juggling together fairly complex office style apps (word processor, drawing, spreadsheet) was jaw dropping.

Modern software is so bloated, it is insane.

PC/GEOS didn't have virtual memory the way people think about it--it was a handles based approach so that memory could be moved when it wasn't being actively used.

Windows and MacOS did something like this too. The memory APIs worked in terms of blocks of memory identified through 'handles' rather than pointers.

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

Actually, v1.0 of PC/GEOS ran on an original IBM PC with 512K RAM. Later versions required 1MB and more.

> GEOS would run on systems three orders of magnitude smaller than the ones you describe.

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

It seems like this OS has an interesting concept of beginner / intermediate / advanced user levels. That's not really something that's in today's systems. Looking back on earlier systems from time to time is a good way to see what we used to have, but don't anymore, and question if it's useful. Especially looking at alternates from the past that may have been overlooked in the past.

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.

Yeah, modern design would say that's too much choice, so design for permanent "beginner" mode

I think operating systems with historic value deserve protection and the decision to keep it in development ensures its value from an archival standpoint. The fact that this source code is out there keeps it alive.

It's not as simple as comparing it to the paradigm used by other operating platforms.

In college (2003), I took a 486-40 laptop for note-taking. It ran either a DOS+GEM setup or OS/2 3.0. This offered a no-distractions (no games, no wi-fi) experience and ran well on the available hardware.

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.

Weird question for a "Hacker" News forum.

The same reason that drives all interest in computing that isn't strictly for $work: because we can, and because we might find it fun.

The GP may just be wondering if this is purely for fun, or if the dev believes it has practical use.

Nothing wrong just-for-fun projects, of course. I loved GEOS on the C64, and it tickles me that someone's still maintaining it.

Keep in mind that PC/GEOS has almost nothing in common with GEOS on Commodore 8-bits or Apple II except the name. But I too am delighted to see this get open-sourced.

Why does this get downvoted? The parent did not violate any rules or code of conduct of HN. His question was on topic.

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.

It was probably downvoted because the phrasing sounded like they were dismissing the project as pointless. From their later post it sounds like that maybe wasn't what they meant, but it wasn't clear at the time.

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.

> please read the ruleset again.

There is only one written-down rule about downvotes, and your comment is breaking it.

That's true.

The source code for the C64 version is available here too:

https://github.com/mist64/geos

There is a Mega65 computer with a GUI based on GEOS at http://mega65.com that is a Commodore 65 clone. The 65 has a 64 mode and 65 mode for better color and sound.

I wrote the business plan for my Arizona based ISP on PC/GEOS back in '92 on a IBM PC AT.

https://www.dropbox.com/s/n78x5cp8na4iilq/InternetDirectIncP...

It looks really great! It's stylesetting is miles ahead of plain text, available elsewhere in msdos.

I was in college at the time. Wrote a /lot/ of technical papers with GeoWorks. The word processor and draw had great integration.

Also had a Tetris that is still the nicest clone I've ever played. For years after, I'd load my GeoWorks onto an old PC just to play the Tetris. I probably have the GeoWorks disks in my garage still.

I'm 100% confident I've played that exact Tetris, but on Linux with Motif on X. So I think you'll find, if you poke around enough, that source code is alive and accessible.

I doubt it. Ours was written in our homegrown x86 assembly language for our own OS kernel.

We had some fun times playing heads up Tetris competitions in the office.

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

Wow, that's really interesting! I'd love to read a write-up of your experience starting that up.

https://www.youtube.com/watch?v=HVcGyxfbNYY

"Their newest PC/GEOS, 4.x, is now a full productivity and Internet suite, including Web Browser and Email"

https://en.wikipedia.org/wiki/GEOS_(16-bit_operating_system) has more history. I played with it around Windows 3.1 times.

There is still a (quiet) mailing list covering all things GEOS, NewDeal Office, Breadbox Ensemble etc. here: https://groups.yahoo.com/neo/groups/geos-talk/info

I remember running Geoworks on my 8086 panasonic desktop (as souped up an 8086 as their can be, vga card, 40MB hard disk (then doublespaced!). I remember it coming with the Pre-AOL AOL client.

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"

Actually, to be more clear... The original graphical AOL client for the PC was a PC/GEOS application. It booted GEOS and straight into the AOL GEOS application.

Interesting. Was there any carryover between that and QuantumLink/QLink (via Commodore GEOS). I'm assuming not...

Technologically, no. Business-wise, I don't recall.

Thanks... tbh, it was the technology that interested me more.

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

Commodore GEOS was created by the same company as PC/GEOS. I only worked on PC/GEOS.

I know, but this wasn't a separate aol app, this was part of geoworks ensemble.

There was a standalone version that was sold on disks as AOL. GEOS was completely hidden from the users. I.e., it was AOL's GUI.

woah. I posted my comment before I read any others. we had the same recollection about AOL (and had similar pc specs!)

Geoworks came packaged with my 386sx 16mhz magnavox pc. I also remember this software package called "America Online" that I could connect to with my 2400 baud modem but it was way too expensive so I didn't sign up.

I thought I was the only one with a Magnavox 386 PC. It was back when they had John Cleese as a spokesman, as I recall.

There was also the OmniGo 100, an HP LX series machine that had GEOS in ROM:

http://www.hpmuseum.net/display_item.php?hw=200

Now, there's a name I haven't heard in a long time...

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

Great insights!

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 [1]. I don't know how it compared to what GEOS did, though.

[1] https://blogs.msdn.microsoft.com/oldnewthing/20110316-00/?p=... and many other articles on that site can send you down a deep rabbit hole.

Nice testimonial.

Do you know of any documentation online that covers the loader and other good bits?

Also, what is/was Tao?

Tao was a UK OS company that produced operating systems call Taos and intent (emphasis theirs); their killer feature was binary portability and assymetric multiprocessing, so you could have multiprocessor machines built of several different random architectures and treat them all as a single message-passing system. Code was converted from bytecode to native machine code at load time. It was small, elegant and very cool.

Turns out people didn't want to buy that.

I loved GEOS and annoyed all my friends ranting about it in the early 90s. It really made me appreciate that with skill you can get orders of magnitude more functionality out of the resources at hand.

I had GeoWorks on a C64 and was amazed by what it could do. Felt much more cohesive than Windows 3.1 in terms of being a consistent desktop environment.

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

GEM predates GEOS by many years. It was a product of Digital Research, and was started in the early 80s by Lee Jay Lorenzen who had worked (or interned?) at Xerox on the Star and wanted to bring those concepts over to commodity x86 desktop machines.

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:

http://www.dadhacker.com/blog/?p=995

http://www.dadhacker.com/blog/?p=1000

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 recommend reading the entirety of the dadhacker site. It's amazing.

I don’t think GEM was related to GEOS

lol, back in the days I found GEOS on a disk for my C64.

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

GEOS-SC sounds interesting as a potentially more portable "modern" version - did MELCO wind up owning the rights to it? If not does the source for that still exist...?

I'll have to get this compiled and installed on my IBM AT, nice to see something compatible with my 286.

Now we need to make it compile with gcc (or clang) and run on a Unix-like OS.

...or at least wrap up the Impex and Nimbus parts so I can get a little more mileage out of the font and clipart disks I'm still holding on to (but probably can't read anymore).

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

Given the fact that it is mostly written in weird semi-custom x86 macro assembler it would entail significantly more work than you expect :)

Yah, the assembly language is going to be a bit of an issue. But I wonder if there wouldn't be some interested parties to turn it all into portable C code ..

You can always compile it to function calls that emulate x86 opcodes. Considering the difference in speed between a 386SX (which ran GEOS acceptably) and a Core i3, it'll probably be fast enough.

Besides, the whole environment can probably run from within the cache of a modern CPU.

That's a neat idea, and probably kind of feasible .. I wonder if anyone will take up the challenge and produce a clean C-portable version .. I'm guessing some of the folks around ContikiOS might be intrigued by this idea. Off to other forums to discuss it further ..

Was there any kind of emulator to run it on the Suns used as a development platform?

We cross-developed. The host machines were Sun workstations where the dev tools and Swat debugger ran and talked to the PC target (remember that we started with PC/GEOS running on an original IBM PC with 512K of RAM).

Reply on news.ycombinator.com