PC GEOS had no future because it was written in object-oriented 8086 assembly language. This made it very small and efficient but effectively tied it to that 16bit platform. When PCs moved to 32bit and protected mode with the 386 there was no hope for GEOS.
It continued to find a niche in handheld PDAs running x86 processors (I had one, the HP OmniGo) but even those types of computers eventually moved to 32bit ARM.
>assembly language... made it very small and efficient
There’s an interesting post from someone who worked on the codebase and argues the opposite[1]—some relevant quotes:
> we wrote fifteen million lines of 8086 assembly language. We had really good tools, world class tools: trust me, you need 'em. But at some point, man...
> The problem is, picture an ant walking across your garage floor, trying to make a straight line of it. It ain't gonna make a straight line. And you know this because you have perspective. You can see the ant walking around, going hee hee hee, look at him locally optimize for that rock, and now he's going off this way, right?
> [...] I went in and found out that some title bar was getting rendered 140 times every time you refreshed the screen. It wasn't just the title bar. Everything was getting called multiple times.
> Because we couldn't see how the system worked anymore!
That is a great talk by Steve Yegge. And now I know why he's angry all the time. Not only did he work on GeoWorks, he also tried using Ruby at Google! Absolute legend.
> PC GEOS had no future because it was written in object-oriented 8086 assembly language. This made it very small and efficient but effectively tied it to that 16bit platform. When PCs moved to 32bit and protected mode with the 386 there was no hope for GEOS.
Microsoft faced a very similar problem with Windows - Windows was 16-bit code, a mixture of C and assembler. How did Microsoft handle it?
Firstly, it isn’t necessarily hard to port 16-bit real mode code to 16-bit protected mode. It really depends on how much segment manipulation you do. If you treat segments as opaque values and hide operations on them behind some API, all you have to do is change the implementation of that API.
Secondly, you can create a 32-bit protected mode kernel, and then run 16-bit code under it: you can run 16-bit code under it directly (just mark some code segments as 16-bit and others as 32-bit); if you really need to run 16-bit real mode code, you can use virtual 8086 mode. This is essentially what Windows did, back in Windows 2.x/3.x/9x/Me timeframe
You can use thunks to mix 16-bit and 32-bit code so they can call each other. That way you can write new code as 32-bit, rewrite performance-critical 16-bit code as 32-bit, but leave existing non-performance critical 16-bit code as-is.
You can even reassemble 16-bit assembly to run in a 32-bit code segment, the assembler just needs to stick 66 and/or 67 size overrides before (most) instructions. It will bloat the code, but it might be an option in some cases.
Another option, is write a transpiler from 16-bit assembly to C, and then compile that as 32-bit. DEC did something similar for the OpenVMS transition from VAX to Alpha - they wrote a compiler for VAX assembly language which compiled it to Alpha machine code; the same idea was carried forward in the Itanium and x86 ports. Similarly, in the early days of 8086, a lot of 8080 assembly code was ported to 8086 using tools that read in 8080 assembly and wrote out the 8086 equivalent (e.g. Intel’s CONV86, Tim Paterson’s TRANS86, Digital Research’s XLT86)
So I don’t think GEOS’ technical debt was insurmountable - Microsoft faced some similar issues with Windows (even if they didn’t have it quite as bad). Various options were available to address it. Rather, I think the real issue likely was that GEOS couldn’t attract sufficient investment to pursue them.
Lol. Migration of PC/GEOS to protected-mode 32-bit x86 was not some magical rubicon that wasn't foreseen.
Geoworks was doing well until its sales deals got utterly hosed by the Microsoft monopoly power play. That started a cascade of direct and indirect problems from both a technology and business perspective.
In the early 90s, Geoworks Ensemble filtered through my local teenager PC scene. The more curious among us tried it out. The experience was smooth and polished enough, and just different enough, that we went back a few times. Running Geoworks for weeks at a time.
But ultimately the system was relatively closed and limiting, there was nowhere to go with it once you got sick of the range it offered. From the perspective of young home enthusiasts at the time, anyway.
Meanwhile DOS (and even Windows) -based development was undergoing a period of extremely rapid iterative changes and extensions. It was impossible to stay away from that for long. It's where all the action was.
Yeah, it took way too long to prioritize and deliver a non-assembly development chain and opening that up to the public at large.
We cross-developed from Sun workstations to x86 PCs and quality of x86 native tooling wasn't nearly as good. But eventually building on x86 was actually quite a bit faster.
A belated note, from a bubbled-up memory (all on an "IIRC" basis!) :
Hard disk space was the killer, as much as anything. The average home PCs hard disk was 40-50MB in those days, and iirc a full Geoworks Ensemble install took almost half of it. And regardless of how one scrimped and made-do with what was left, it became an overwhelming disadvantage to have the whole system weighed down in that manner by such a heavy OS.
I can't edit the above post now (thus the folly of hastily commenting on HN, perhaps), but after actually looking into it by doing a DOSBox-X install, it seems that the Geoworks Ensemble 2.0 install size is only <10MB.
I suspect that my false memories of it taking more space were because, by 1993, DOS games and programs were requiring steadily more disk space (and there were more of them!). With Geoworks taking any sizeable portion our increasingly-meagre 40-52MB disks, we soon found ourselves desperately wanting those megabytes back to install this-or-that extra thing.
It was miraculous what you could do with GEOS on the Commodore 64. I did a lot of school projects, such as papers and newsletters. With lots of fonts and graphics.
The only environment that came close to having decent typography (apart from Windows and OS/2) was DesqviewX but I don't know if I knew anyone who ran it.
The GeoWorks typography engine was actually exceptional in that it offered fully scalable fonts (up to 792pt IIRC) when a lot of Windows fonts were still bitmapped and you had to get font cartridges for your LaserJet.
The fonts look a bit different from the Microsoft and Apple ones, but they were likely sourced from a different vendor (URW?), so there's an uncanny-valley aspect to it these days when "Times" means "Times New Roman".
I wonder if part of it was that when the earlier GUIs, like GEM and the Workbench, were architected before desktop publishing became the undeniable "killer app" for a GUI. They figured "here's some basic fonts to render the UI" and punted to the application software to handle anything else. Even with some of the early GUI word processors (GEM Write, for example), full WYSIWYG typography might have been above the expected target, considering the machine might be paired with a daisy-wheel or 9-pin dot-matrix printer.
Of course, all typography of the era looks a little odd by modern standards, running on a 640x480 screen with no antialiasing.
(This was also the OS with the first icon-based taskbar, before NeXTstep and its Dock; and also the first GUI where dragging a window to move it moved the window contents, not just a dotted outline. It's the original inspiration for the Windows 95 taskbar.)
I deployed and supported Windows 2.01 in production. IMHO, it's not really anything like a taskbar, though. It looks a bit like it if you only know Win2 from screenshots, but if you used it, it's not.
It's just an area of the desktop. Windows minimize to icons on the desktop. (The only icons on the desktop.) They zoom down into icons at the bottom of the screen, that's all. If you manage to keep Win2 running long enough to fill the bottom row, it starts a 2nd row above it. You can, if I recall, also pick them up and move them if you so wish.
In a tiny echo of the tiling windows in Windows 1.x, normal-sized windows avoid covering up that bottom area, but if you minimise all windows you can see: it's not a strip or bar or anything. It's not contained in any way. It's not a special region and nothing else goes there simply because Win2.x doesn't put anything else on the desktop itself.
NeXTSTEP was first shown in 1988, before RISC OS 2. I never used Arthur but it was a lot more primitive IIRC. Even the icon bar in RISC OS is less sophisticated than NeXT’s Dock.
It was, but the NeXTstep beta 0.8 was after Arthur 1.20, and the icon bar concept was in Arthur. RO's version is less sophisticated, yes, I agree. Highly functional, though.
I moderated a talk and discussion by the surviving members of the original RISC OS core team a couple of years ago. I wrote it up here:
The claim is from the team lead, Paul Fellows. To paraphrase him: One of the programmers got a job with NeXT, quit, went to California, and took his Archimedes. Lo, the next beta of NeXTstep had an icon bar!
I’ll give it a watch. I had the unusual experience of using RISC OS and NeXTSTEP at roughly the same time from 1991-1996. Until 1996 the only machine I really had that was my own was an Amstrad CPC 464 which had various add-ons and eventually an extra 3.5 inch disk drive attached which made transferring files much easier. For a while I had a cheap MS-DOS luggable and used a serial cable to transfer small text files from the CPC to the Toshiba T1000, eventually getting a slow modem for the CPC.
Yeah, PC/GEOS was built from the ground up to give that fully scalable "WYSIWYG" "Display Postscript" experience but the PC displays at the time weren't very good.
I remember learning about self-modifying assembly in the low level drawing code from JimDF.
System 6 pictured is from 1988, whereas AmigaOS pictured is from 1986.
AmigaOS 2 and 3 improved significantly in the fonts front. The system font "topaz" was redesigned for 2.0.
Even 1.3 (1987) came with the FF ("fastfonts") tool, introducing much faster font rendering as well as the ability to replace the system font with a better one.
System 6 isn’t substantially different from System 1 when it comes to type though, unless you install the Adobe Type Manager or TrueType extensions of course.
Because typography is _hard_ --- Dr. Donald E. Knuth thought he would write a typesetting system while on sabbatical --- 10 years later we had TeX.
Storage was also an issue --- back in the early days of personal computers, they took up so much space that I would often set up a networked CD-drive with the BitStream 500 font CD-ROM which fonts could then be copied from to be used.
Steve Jobs took a calligraphy class in college and thus knew a lot more about typography than typical techies. He insisted on insanely great typography on the Macintosh because of what he learned from that class.
Typography is hard and takes up a lot of cpu time. Even though AmigaOS had support for proportional fonts with bullet.library, I would still use Topaz, MicroKnight, p0t-n00dle or some other fixed 88 or 816 font for Workbench.
The example code for the Amiga with bullet.library seemed OK on the 8MHz cpu (7.xx MHz) and would be fast enough maybe with 1 bit plane, but when the Amiga is advertised as a colour computer people would complain why it's only 1bitplane, although the Amiga DTP program did that and in interlace as well.
Early 1980s Atari TOS/GEM had the windows aligned on 16 pixel boundaries (M68k word length) to make redrawing easier and faster, I don't know if early Macontish System 1.X had that as well to speed it up on 8Mhz M68K CPU.
> The only environment that came close to having decent typography (apart from Windows and OS/2) was DesqviewX but I don't know if I knew anyone who ran it.
DV/X included Adobe Type Manager as standard. ATM was initially a optional extra, and although very common on Classic MacOS it was rarely seen on Windows 3.x.
Quarterdeck was proud of it because DOS windows under DV/X could be resized to smaller than the original console size -- this is in the era of 72dpi monitors, remember, when 640x480 was a common resolution -- but remain readable.
I used GeoWorks on my used IBM PS/2 286 PC in like 1992. It ran off a single AOL floppy. It was honestly amazing to see my "ancient" DOS based computer suddenly displaying a Windows-like GUI. It really seemed like magic. It was also pretty much the only time I used a mouse on that machine, since everything else was DOS.
>But the best part of GeoWorks was the fact that it worked well without really strong hardware. Windows 3.1 really needed a 486 to shine, but GeoWorks could effectively run on a 286 or 386 without any problem.
My first install of Slackware 30 years ago was on 386DX33 with 2M RAM. The X felt fast and responsive, especially compare to the Windows. The only thing i saw missing then in Linux preventing me from pushing it to our customers is that typical business software of the day didn't work on it. Well, several years later, like Oracle release in 98, the things changed, and that seems to have sealed the fate of the high-tech world for the foreseeable future.
PC/GEOS v1.0 ran on an original IBM PC with 640K. The minimum for v1.2 was 1MB of RAM.
In terms of responsiveness, it was an interesting compare and contrast from the Sun workstations vs. the PCs running GEOS. Less mouse jitter is one memory (especially in comparison to those old Ultrix machines).
Also in the US. My family's first PC was a Magnavox-branded 386SX. Weirdly overengineered (motherboard with a lot of SMD components, almost tool-free case, CPU on a card so it could be sold as a 286 or 386SX) but janky in other ways (1M RAM/40M disc)
In retrospect it sort of made sense: Philips was an electronics company making a nice piece of electronics, rather than a computer company that was chasing benchmarks and features.
I distinctly remember a PC magazine article about a later release of GeoWorks. It gushed about how it could play full motion video (probably only 256 pixels wide, if that) while running other applications. The screenshot showed a clip from Star Trek IV. Kind of laughable by modern standards, but it was an impressive technical feat at the time.
It continued to find a niche in handheld PDAs running x86 processors (I had one, the HP OmniGo) but even those types of computers eventually moved to 32bit ARM.