GeoWorks: The Other Windows (2019)

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!

[1] https://steve-yegge.blogspot.com/2008/05/dynamic-languages-s...

Discussed at the time (34 comments) https://news.ycombinator.com/item?id=187365 and in 2023 (45 comments) https://news.ycombinator.com/item?id=36571956

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.

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.

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.

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.

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.

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.

https://en.wikipedia.org/wiki/Adobe_Type_Manager

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.

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.

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.

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.

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

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.

GeoWorks Geos: The Other Windows - https://news.ycombinator.com/item?id=38961852 - Jan 2024 (4 comments)

GeoWorks: The Other “Windows” - https://news.ycombinator.com/item?id=29402609 - Dec 2021 (66 comments)

Geoworks and AOL (2019) - https://news.ycombinator.com/item?id=27275321 - May 2021 (6 comments)

The History of GeoWorks, Microsoft Windows’ Upstart ’90s Competitor (2016) - https://news.ycombinator.com/item?id=14748209 - July 2017 (64 comments)

I remember an article on that around that time which specifically mentioned it playing video --- on an 80186.

Difference of course, is Tron is still around and is one of the most installed/used OSs in existence.