5 ms·

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,

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

icedchai 8y ago
Modern software is so bloated, it is insane.
kickingvegas 8y ago
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.
johnm 8y ago
Actually, v1.0 of PC/GEOS ran on an original IBM PC with 512K RAM. Later versions required 1MB and more.
johnm 8y ago
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.
- mschaef 8y ago
  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. :-) )
mschaef 8y ago
> 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...

icedchai 8y ago

Modern software is so bloated, it is insane.

kickingvegas 8y ago

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.

johnm 8y ago

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

johnm 8y ago

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.

mschaef 8y ago
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. :-) )

mschaef 8y ago

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