Hacker News Reader

Comment by azinman2 | Hacker News Reader

What makes an 80s/90s era 16-bit OS great in 2018? If you want free/open source, why not run Linux or FreeBSD or any if the many modern alternatives that have 64-bit support, preemptive multitasking, protected memory, modern VM, new software actively being developed for it, drivers for modern hardware, support for SSDs and USB 3.0 and nvidias, etc etc?

Similarly, there’s nothing about geos that’s appropriate for a mobile device. If you want to start with something existing, Android is already open source and has a ton of existing software. Or try fuschia if you want more bleeding edge.

Now if you say it’s for a hobby, or fun, or whatever then I can understand.

View on HN

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

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.

Modern software is so bloated, it is insane.

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.

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

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

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

It seems like this OS has an interesting concept of beginner / intermediate / advanced user levels. That's not really something that's in today's systems. Looking back on earlier systems from time to time is a good way to see what we used to have, but don't anymore, and question if it's useful. Especially looking at alternates from the past that may have been overlooked in the past.

The allure of using an old operating system as the basis for new work is that it would at least seem to be much simpler than a modern operating system; and it's a good thing to avoid unnecessary complexity. Of course, it may turn out that in order to work on a modern computer, you need most of the complexity.

Something that's reported to work well on a 386 should be likely to feel responsive and fluid on any modern computer.

Yeah, modern design would say that's too much choice, so design for permanent "beginner" mode

I think operating systems with historic value deserve protection and the decision to keep it in development ensures its value from an archival standpoint. The fact that this source code is out there keeps it alive.

It's not as simple as comparing it to the paradigm used by other operating platforms.

Reply on news.ycombinator.com