Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I can well believe that.

I moderated a talk between 4 of the original team members at Acorn that wrote RISC OS [explanation below] in the 1980s a few months ago. They're all of retirement age now.

Three of them were full of anecdotes and stories and details about the company, the machines, the buildings, etc. The other could barely remember anything about it; his former colleagues were prompting him for details of what he wrote about 35Y ago, but he had little idea. Too much other work since, he said, and too long ago, and he'd forgotten.

I hang out in various retrocomputing fora for fun, and it amazes me the utter nonsense that some people come up with from vaguely-remembered things they knew 30Y ago. They don't know that they've forgotten, so they free-associate stuff and just make it up, and then many get resentful when their wildly wrong answers are corrected.

RISC OS, for youngsters and Americans (where Acorn didn't sell much) is the original native OS for the ARM CPU, written by the company that developed the CPU and the machine it would power. It is still around today, it's FOSS now, and it runs on some modern ARM hardware such as the Raspberry Pi.

It is a multitasking GUI OS with a rich desktop, networking, internet support, and so on. It ran in from 512kB to 4MB of RAM. It was the first ever GUI computer to anti-alias screen fonts as standard, to move the whole window when it was dragged, rather than a dotted outline and then a redraw when the mouse button was released. The OS, its GUI, its core apps (text editor, image editor, console prompt, filer, etc.) fitted into and executed directly from ROM, that is, without being copied into RAM.

It was also the first GUI with a dedicated panel showing icons for running apps, plus a system control menu, a clock, and so on -- it inspired the Dock in NeXTstep (which came out 2Y later), which both inspired the taskbar in Windows 95 (which came out another 7Y after that).

And the whole OS was written by about 6-7 programmers, and the vast majority of it in hand-coded assembly language.



I seem to remember that having a mouse with a context menu click, what is now usually the right button click, was another RiscOS innovation.

Acorn ARM machines always came with a three button mouse and I think the context menu was the middle button. I think the third button was used for cancelling things but I can't quite remember.

I had a PC with Windows 2 around the same time and it always seemed weird that that the right button on my MS mouse did almost nothing (I think you could use it for column select in Word but that was about it). It was like the hardware and software teams were working separately, which was probably the case.

The Macs at the time had only one button and that at least seemed like a deliberate design choice. I wasn't a fan of it but I could see that someone had deliberately decided to make things simple with click, double click and long click on a single button.


You're right about the 3-button mouse.

However, this was not an Acorn innovation: several Unix vendors, including Sun, also used 3-button mice, with comparable functions.

I'd argue that Acorn's innovation was formalising the functions and providing a rich GUI to use them.

1. The left button is called Select. It does what a left-click does on most OSes: select an item, and so on. It terminates the action: e.g. click Select on a button in a dialog box, it closes the dialog.

2. The middle button is called Menu. It opens a context menu related to what you click on. These are the only menus in RISC OS. There is no menu bar, no hamburger menu, etc., only context menus. Each app's global menu is the context menu.

3. The right button is called Adjust. It changes what it's clicked on without terminating it. E.g. click Adjust on the OK or Save button in a dialog, it applies the changes without closing the dialog. So, no need for an Apply button. Adjust-click a scroll bar and it scrolls in the opposite direction from clicking with Select, so no need for a wheel mouse.

Lots of OSes have Select and Menu mice buttons now; nothing else has Adjust.

The good things: cleaner GUI (no visible menu bars or buttons, no Apply buttons, no file navigation in file dialogs because you drag and drop to save.) Richer control of that GUI with 1980s mice. (No scroll wheels or anything because they hadn't been invented yet.)

The bad things: a steeper learning curve. If it's your first GUI, it's harder to learn. Mouse controls are significantly more complex than GUIs with a 1- or 2-button mouse. But it's more powerful. If you already know a GUI, you have to unlearn stuff, which is harder still.

To use the classic computers/cars simile:

I do not have a car and don't drive much, but I would describe using a 3-button mouse in RISC OS as being like using a manual transmission. The Mac OS X/Windows model, with 2 buttons, is like using an automatic. It's easier to learn and easier to use, but you sacrifice a large degree of direct control. Scroll wheels are like flappy paddles on an automatic car's steering wheel: they try to restore a bit of control, but they only influence it a bit, you don't actually get the full native control back.


I tried RISC OS on a single-core Raspberry Pi and I was quite impressed at how well it ran. Significantly faster on this board than the stock Linux desktop environment based on LXDE.

Downsides are the usual, setting a native monitor resolution is not as easy or possible in the era of high resolution screens, the web browser cannot be used for the modern web.

I'm always impressed by those early brains that had no problem creating new things for the first time in assembler.


Yes, agreed.

And as someone who used RISC OS 2, I should point out that RO2 was significantly smaller, faster, and far more responsive than RO3 -- and that's on an 8MHz ARM2.

RO is much smaller and quicker than any other modern GUI OS. I believe, from faint memory, that the first Raspberry Pi version the ROOL organisation demoed to Raspberry Pi founder Eben Upton didn't have drivers to access the SD card yet, so it booted into RAM and then couldn't load anything else.

He asked how big it was: they told him, it's about 6MB, compressed.

He said, "no, not the kernel, the whole OS."

They said "that is the whole OS!"

6MB for kernel, filesystems, GUI, desktop, terminal emulator, core apps (text and image editors, BASIC interpreter, etc.)

I've only ever seen 3 OSes that compare at all to RO in terms of snappy responsiveness.

1. Psion EPOC16 (Psion 3, 3A, 3C, 3MX PDAs) and EPOC32 (Psion 5, 5MX, netBook PDAs).

2. The 1990s QNX Demo Disk showed that a desktop PC OS can rival RISC OS in compactness. It's the only one that could, though, and due to heavy compression it wasn't super fast.

3. BeOS was very close to as snappy and responsive, albeit ~2-3 orders of magnitude bigger. BeOS showed that PC hardware could compete: a PC in the hundreds-of-MHz class, with a 3-digit number of megabytes of RAM, could boot in seconds off a spinning rust HDD, and present a desktop with exceptional responsiveness.

Today, even a multi-core multi-gigahertz class machine running Windows or Linux or macOS feels like wading in molasses by comparison with RISC OS or BeOS.

Sadly, this includes Haiku and M1 Macs.

I've had no difficulty setting RISC OS on a Pi to whatever the native res of the connected screen was. Can't reproduce that one.

Modern browsers are coming; a WebKit-based browser is in testing now, as is a new TCP/IP stack with IPv6 and Wifi support.


> Significantly faster on this board than the stock Linux

You need to remember Linux, as did Unix before it, decouple the GUI from the OS (and the programs running on it) through multiple layers of abstraction, It was also designed to be ported to different CPU architectures, not for speed.


Unix as it was designed doesn't have any direct support for a GUI at all. Or networking, come to that.

They are not so much decoupled, as multiple separate trailers being pulled along behind on a tow-bar.

If you're on a Bash prompt on machine called "foo" logged in as user "bar", how do you look at the contents of a file called "readme" in folder "/usr/share/doc/" on a disk labelled "quux" on a machine called "baz"? Assume you have all necessary permissions to do this.

(Answer: you don't.)

If your terminal is on monitor #2 on machine F, how do you open a terminal on monitor #3 on machine B elsewhere in the lab, without knowing what desktop or display server it's running?

(Answer: you don't.)


And all those separate trailers impose a performance penalty. You can have a very fast Unix machine that doesn’t have a GUI and doesn’t understand a network, and you can have one where your home is an NFS mount halfway across the globe.


This is true, but it's not my point.

My point is that there are very fast OSes which remain portable and have this sort of thing built in and integrated right into the kernel, such as Oberon and A2, or Plan 9, or Inferno.

So when you originally said:

« ... decouple the GUI from the OS (and the programs running on it) through multiple layers of abstraction, It was also designed to be ported to different CPU architectures, not for speed. »

I think you are mixing up cause and effect, and trying to blame an accidental side-effect by making out that it's a core aspect of the design.

It's not that the Unix GUI layer is "decoupled" (as in, intentionally kept separate from) the kernel.

It wasn't. The kernel was designed without any thought of GUIs or consideration for them. There was no conscious layering or designing for portability here.

That's like saying... um... the new government after the French Revolution kept the railway system decoupled from government. It did not such thing. They had no conception or thought of railways; they're "decoupled" because one was bolted on a century later.

UNIX didn't decouple the GUI from networking, either. It never entered into the picture.

And yet, remember that the first lines of UNIX v1, long before C or anything, were written after Engelbart gave "the mother of all demos". This stuff _was_ happening, it was out there and it was on the radar.

Thompson and Richie realised their mistakes and they went on to fix them, in Plan 9, and then improve upon Plan 9 in Inferno.

But the Unix community had seized upon the older version by then and it wasn't AND STILL ISN'T interested in breaking what works in the interests of making it smaller, simpler, cleaner, faster and more efficient.


AmigaOS predates RISC OS by two years (1985 / 1987).

It was also a true preemptive multitasking OS (as you pointed out, Windows would only become preemptive with Windows 95), had the same move window behavior you describe (thanks to the Amiga's specialized chipsets, namely the Copper and the Blitter) and it also featured proportional scrollbars (another thing that would only land in Windows ten years later).


> “AmigaOS predates RISC OS by two years (1985 / 1987).” > [...] “had the same move window behavior you describe

Not the Workbench 1.3 we got with my family’s Amiga 2000, it used outlines:

https://www.youtube.com/watch?v=h4iR1RcdJTY&t=70s

I’m checking now and 2.0 also used outlines.

The 3.0 or 3.1 in the Amiga 1200 I got years later might have had that as an option in the Preferences, but I’m not sure. It used outlines by default in any case:

https://www.youtube.com/watch?v=DOOYSAHQURU&t=3490s

The rest of your post is, AFAIK, entirely correct.

I did see RiscOS at the time at an Amiga Party when the Acorn distributor in Spain was showing the RiscPC, and was amazed by it. I considered selling my 030/50+FPU accelerated A1200 and get a RiscPC but ended up not doing it. To this day I’m not sure that was the right call, the RiscPC did not have an FPU but otherwise it was much more adequate for the kind of applications I wanted to build.


I stand corrected.

I remember using MUI back then, maybe it added this behavior although even now, I'm no longer sure I can trust my memory on that.


See earlier comments about saying outrageous things and getting creative when called on it. 8)

Many of us mis-remember the past fondly. It’s not always a bad thing…


All AmigaOS versions (for original hardware) dragged only window outlines.

However, there were freeware "commodity" programs available that would patch the OS to drag the whole window. Various such desktop add-ons were quite popular.


AmigaOS, at least 1.x, does not redraw full windows while moving. It does the outline thing.


What retro computing forums are you on?


Me?

The ClassicCmp mailing lists, among others. Half a dozen subReddits and a dozen Facebook groups. A handful of Usenet groups.

I don't use web fora much so I won't count them.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: