Ah, GEOS. I used it quite a bit when I was a kid -- wrote school reports in geoWrite, made labels in geoPaint, and wrote 6502 assembly code in geoProgrammer. (Well, technically, wrote assembly in geoWrite and then used geoProgrammer to assemble and link -- a very tedious process, indeed.) GEOS applications were always a bit of a dog compared to non-GEOS programs, at least for those of us without any RAM expansion.

I once wrote a letter to Berkeley Softworks asking for more information about programming in GEOS (API's, etc.), and was surprised when I got a huge binder in the mail with a printout of the Hitchhiker's Guide to GEOS. [1]

[1] http://freepdfs.net/the-hitchhikers-guide-to-geos-lyonlabsor...

I had a middle school shop teacher who used GEOS, but never used it personally. What I find interesting from the PDF you linked is that GEOS was developed on UNIX using a cross assembler and emulator. Never would have expected that.

It was quite common, specially in the big studios doing games for multiple home computers.

I knew dozens of people with the C64 and I didn't know anyone who used it after the initial buzz wore off. The floppy sat in my shoebox with a hundred other apps. The PAL assembler was a much better tool for writing 6502 assembler. It was one of my first software purchases as a teenager.

The C64 wasn't the best platform for running a GUI, and GEOS required a great deal of patience. I eventually went back to non-GEOS tools for most things (Word Writer 4, yay). GEOS was nonetheless an impressive technical accomplishment. It was amazing to see the sophistication delta between software from the early days of C64 (e.g., those educational programs ported from PET) to what was available towards the end on the exact same hardware.

It's weird but when I was a kid I thought GEOS was a toy - I inherently rejected the graphical presentation of "doing things" over the "command line" (which was just BASIC for the most part).

Of course, this could be due to not caring for most of the applications launchable from GEOS.

The lack of launcher support (like legacy DOS support in Windows) probably killed it. If you were using it, you were also often loading native programs instead of it.

Something as simple as a double-click instead of having to reset and "LOAD * ,8,1" would have encouraged the practice of launching into a GUI first.

And joysticks were much more apt to playing summergames than to move the mouse pointer.

Getting a 1351 mouse definitely improved the experience.

I think the most incredible thing about GEOS are the hobbyist programmers who continued to maintain/modify it well after its mainstream lifetime.

I once mentioned to my auto mechanic that I was a programmer, and he invited me into the back room of his garage full of old C64 stuff. He showed me a modified C128 with an IDE interface, running his custom modded version of GEOS (Wheels). He had an accelerator hooked up to the machine and could change the CPU speed from the original C64/128 speed to something that appeared to be 10 times faster. To top off the demo, he showed me the web browser he was working on, bringing up a roughly rendered version of Yahoo's page (it was 1999) on the screen.

It turned out my mechanic was the famous (or infamous) Maurice Randall. It's worth searching for his name to learn about his accomplishments in the C64 hobbyist scene (and his unfortunate unreliability).

An interesting discussion on this very topic):

http://www.lemon64.com/forum/viewtopic.php?t=39637&sid=b6a11...

I did a tonne of programming for PC GEOS, aka Geoworks. It was... very cool, in a retarded sort of way. It could do all kinds of awesome things; multithreading! Virtual memory! Vector fonts! Embedding applications in other applications! Pluggable look and feel! Long filenames! Ubiquitous databases everywhere! All on a 8086 with 640kB RAM.

But in order to do any of this you had to write programs in a custom C dialect called GOC, compile things with a ghastly mess of Perl and Borland C mangled together, and the architecture was inextricably entangled with the 8086 architecture so it was fundamentally non-portable. (Object-oriented machine code. shudder) There was a debugger. It required two PCs connected via a serial cable...

If anyone's interested, I've got some source code here:

http://cowlark.com/geos-software/index.html

(including an ELKS syscall translator which allows you to run Linux-86 binaries on GEOS! I think someone used it, once.)

Hey, you can still buy it!

http://www.breadbox.com/

A mere $69 (the copy of DOS required to run it on is not included).

After the Macintosh came out, it took them one year to write GEOS for the Commodore 64 to do some of the same things a $4000 Macintosh could do on a sub$500 Commodore 64 and 1541 drive.

It was the Commodore 64C that came bundled with GEOS.

They had a Commodore 128 version and a Commodore 16/Plus4 version of GEOS as well.

They also ported it to the Apple II series.

https://en.wikipedia.org/wiki/GEOS_(8-bit_operating_system)

And in that same year you could get a sub-$600 machine that could do more than that C64 or Mac: the Atari 520ST! :)

of course the Amiga could do more than all 3 machines, but it cost even more than the ST (but nowhere near the cost of a Mac.)

Until in 1987 they made the Amiga 500 unit to compete with the 520ST, going back to the C64 the case is the keyboard design.

One thing about the Atari ST is that it was considered the real successor to the Commodore 64 because Jack Tremiel was behind it. Nicknamed the Jackintosh with the Magic Sack software it could run Mac software with a Mac ROM chip on a dongle.

Ah GEOS. It has special meaning to me because I was working on Windows / Mouse GUI desktop system for the C64 when news broke. When I finally saw it I stopped working on my own system because it was so much further ahead. In retrospect I did learn a lot and it was certainly my largest 6502 assembly project ever.

Funny, I was just watching the Computer Chronicles about Windows 3.0 release, where they mentioned GEOS https://www.youtube.com/watch?v=YewNEAIkbG4

Interesting episode.

GEOS had some bleeding edge disk handling in it for a C64. It had random access files with fast-loader and fast-saving. It could also use the 1541 as SWAP space IIRC, and had early support for C64/C128 RAM expansion modules.

The 1541 only has 2K of SRAM, so using it as swap seems a bit pointless, unless you mean it could page out to floppy?

GEOS did support a "SWAP FILE" on the floppy. It wasn't swap in the modern page fault / virtual memory sense, of course. When you loaded a "desk accessory" (Calculator, notepad, etc.) from within another application, it would carve out a piece of RAM large enough for the accessory, write the prior contents of the memory to "SWAP FILE", and load the accessory into the region.

Yes, I meant to a floppy.

Yikes. I had a C64 for years, but never used GEOS. My memories of the speed of the 1541 are not fond memories...

I remember a friend showing me GEOS in ~1996, It was a click and 10-30 seconds of waiting followed by another click and another 10-30 seconds of waiting. C64 simply had no memory for GUI OS.

there was a memory-extension card for the c64 with GEOS pre installed, made it ok-ish fast

Yes, you needed either the C128 or the ram-extension for the C64.

Didn't AOL for DOS run GEOS? I wondered why my 386SX-16MHz could run AOL's windowed and mouse driven GUI so fast but crawled with Microsoft Windows 3.1

AOL used a stripped down version called Geoworks: https://en.wikipedia.org/wiki/GEOS_(16-bit_operating_system)

They stopped using it when they stopped supporting DOS and switched to a Windows client. Older AOL for DOS 3.5" floppies can take the Geoworks files out and run them by themselves without the AOL client.

I loved Geoworks--it was how I got introduced to GEOS and how powerful a good GUI desktop could be. I was so disappointed when AOL dropped support of it. :(

Microsoft Windows kind of dominated the market once it got bundled with MS-DOS and was part of the OEM PC Tax.

Geoworks kind of fell to the side of the road, but it still exists in some form at Breadbox.com: http://www.breadbox.com/

Like GEM, OS/2, Vision, Desqview, Geoworks kind of got killed by Microsoft bundling DOS and Windows to make their monopoly. By the time Windows NT and Windows 95 made it to the market, people went crazy over Windows and forgot the alternatives to it.

My first computer had PC-GEOS! My uncle was super geeked out about setting us up with it! It was neat, but we still mostly used DOS and Windows 3.1.

It is interesting how different perception was 20 years ago.

My cousin had a Sinclair PC200 back then, that IIRC was Amstrad's poor attempt to get in to the PC market. That was a 8086 based PC with CGA card, and it came with DOS 3-something and GEOS (don't remember the version).

My cousin had a mouse and all, quite uncommon back then, and we tried and experimented with GEOS quite a lot, but we couldn't see the point really.

Perhaps was a limitation of the monitor and/or the CGA card (it didn't look to good in the high resolution mode of the CGA, with a very poor refresh rate) or the limitations of the 740 KB floppies, but the CLI that DOS provided was definitely better!

Ahh this brings back so many memories I completely forgot I had. I've spent ages trying to remember where I'd seen that upturned corner navigation before the Google Maps app did it...

Aargh, I'm now having bad flashbacks about writing for GEOS, they used a very weird preprocessor to bolt an OOP system onto C. Run, don't walk, away from .goc and .goh files...

Compared to coding in assembly, was it really worse? (I don't know. The only coding I did for C64/C128 was BASIC and assembly.)

.goc and .goh files was PC GEOS, not C64 GEOS.

Here's a fragment:

    @method MyProcessClass, MSG_META_EXPOSED
    {
            GStateHandle gstate = GrCreateState(win);
            GrBeginUpdate(gstate);
            @call GameView::MV_REDRAW(win, gstate);
            GrEndUpdate(gstate);
            GrDestroyState(gstate);
    }

The GOC files were preprocessed to produce very very manky C which was then compiled with Borland and linked with a custom linker. It was true OO with dynamic dispatch and a deeply strange system for allowing classes to have unspecified superclasses (that were then filled in at runtime programmatically). @call does a method call of MV_REDRAW on the object whose handle in GameView. (There was also @send which did an asynchronous call; if the object belonged to another thread a message would be sent rather than calling the code directly.)

That actually sounds very clever. It looks dense, and I'm not able to make much sense of the actual code, but it seems like some very bright folks were behind GEOS (obviously so, since they built so much interesting software for such limited machines). I was fascinated by PC GEOS when it was new, but I was using an Amiga during the era when it was a thing. I only had a brief stint on PCs when Windows 95 came out, and then soon after moved to Linux as my primary OS (usually with a dual booting Windows partition for gaming). The fact that it had multitasking long before Windows, and on XT/AT class machines was pretty damned cool. There were moments where I considered going that route after my C128D, instead of getting an Amiga.

Interestingly, there is still a company selling PC GEOS under the name Breadbox Ensemble, and their forum has posts from this year (not a lot of posts...but, still). I had no idea. It still looks about like it did in 1995. I am kinda baffled at who would still be buying and using this stuff...in a world with amazingly high quality Open Source tools to do everything GEOS ever did only better, and able to do it well on a very low powered machine (just like GEOS), it seems really strange to keep flogging that old horse.

It was clever --- far too clever, unfortunately. C and GOC was a bit of an afterthought; GEOS was originally programmed in object-oriented 8086 machine code, via a special assembler called ESP. GOC was a hack to make Borland produce all the same OO magic that ESP did. It was a reasonable object system, not actually that dissimilar from Objective C, but so, so proprietary.

The implementation didn't just rely on the 8086 architecture, it was inextricably intertwined with it. It worked like PalmOS where memory was referred to by object handle. To access memory, you'd lock it, then you'd get back a pointer. Once you'd finished, you'd unlock it again. This let the GEOS kernel page in your memory from swap. What it actually did was assign one of your segment descriptors to point at the locked block, which you'd dereference with ds:[offset] or es:[offset]. Very elegant, and totally using the 8086 segment infrastructure the way it was intended to be used... good porting to anything else, however!

Hey, I still have my old Geoworks SDK CD. (Which I scrounged free from someone. Useful tip: if you want your platform to be popular, don't make the SDK cost $1000.) I may have accidentally left the PDF of one of the manuals here. http://www.docdroid.net/vclb0s2/concepts.pdf.html

Totally ahead of its time. Totally doomed.

I attempted to write programs for C64 GEOS, and I found it worse than assembler! It may have been due to the programmer's manual being for an earlier version of GEOS than I was using (v2), but writing programs that didn't crash seemed to be impossible for me.

That said, I recall very little third-party programs appearing for C64 GEOS, so it may have been the case for most programmers who attempted to write for it.

Something similar that I've found for CPCs

http://www.symbos.de/

Totally amazing.

Thanks for the memories! Also reminds me of loading Frogger by audio tape on my Sinclair ZX81 https://en.wikipedia.org/wiki/ZX81