3 ms·

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 1

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.

wolfgang42 2y ago
>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! [1] https://steve-yegge.blogspot.com/2008/05/dynamic-languages-strike-back.html https://steve-yegge.blogspot.com/2008/05/dynamic-languages-s... Discussed at the time (34 comments) https://news.ycombinator.com/item?id=187365 https://news.ycombinator.com/item?id=187365 and in 2023 (45 comments) https://news.ycombinator.com/item?id=36571956 https://news.ycombinator.com/item?id=36571956
- wvenable 2y ago
  I was being charitable.
- ebcode 2y ago
  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. Here's the video of the talk: https://www.youtube.com/watch?v=tz-Bb-D6teE https://www.youtube.com/watch?v=tz-Bb-D6teE
johnm 2y ago
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.
skissane 2y ago
> 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.

wolfgang42 2y ago

>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! [1] https://steve-yegge.blogspot.com/2008/05/dynamic-languages-strike-back.html https://steve-yegge.blogspot.com/2008/05/dynamic-languages-s... Discussed at the time (34 comments) https://news.ycombinator.com/item?id=187365 https://news.ycombinator.com/item?id=187365 and in 2023 (45 comments) https://news.ycombinator.com/item?id=36571956 https://news.ycombinator.com/item?id=36571956

wvenable 2y ago
I was being charitable.
ebcode 2y ago
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. Here's the video of the talk: https://www.youtube.com/watch?v=tz-Bb-D6teE https://www.youtube.com/watch?v=tz-Bb-D6teE

johnm 2y ago

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.

skissane 2y ago

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