Was Acorn's RISC OS an under-appreciated pearl of OS design?
liam-on-linux.livejournal.com
liam-on-linux.livejournal.com
... we had one of the machines that we just could not get this thing to boot reliably. You could boot it, turn it off, reboot it and sometimes it would work and sometimes it wouldn't. It turned out, it would boot fine if you left it long enough, but if you didn't turn it off for very long then it didn't reset properly, and this was because the fan on the board was still spinning and the back EMF on the fan was enough power to keep the ARM running. And that's why you've got an ARM in your phone today, it would take no power to keep a 3 micron ARM with 25000 transistors would run for 30 seconds off the energy stored in the fan.
Generally fans are a very effective way of dumping energy, not storing it. They're literally used for this purpose in exercise bikes.
1. Task bar / dock thing. This was well before Windows 95 and Mac OS X both adopted the feature.
2. There was a dedicated menu button on the mouse. This was the only way to get a menu, there no menu bars anywhere, freeing screen real estate. The other two mouse buttons were select, which behaved like a normal mouse button, and adjust, which did the sort of things you need to resort to shift-click on other platforms.
3. There was no file open dialog. You just double clicked a file to open it, or dragged it to the app that you wanted to open it with if you wanted to open in not the default. To save you would be presented with an icon which you could change the name of, and then drag to a finder window. No duplication of the folder system structure in a finder and in every app that handles files.
If AmigaOS had the UX of RiscOS, or RiscOS had the multitasking of AmigaOS, it would have been a beautiful thing.
[on edit] Other people have mentioned the Basic implementation, and it was very impressive - far and beyond most versions, and very much a useful programming language with an accessible syntax.
https://docs.microsoft.com/pt-br/archive/msdn-magazine/2009/...
No, not really.
Remember that Windows 1.0 was a primitive sort of tiling window system, because Microsoft was afraid of being sued by Apple and did not dare implement overlapping windows.
What you are seeing is a strip of the desktop background, which contains icons representing running programs. The tiling algorithm leaves a strip of "desktop" visible so that you can get to the program icons. This is how you switched between programs.
Windows 2 reintroduced tiling windows, but had no desktop icons as such -- again, it was afraid of being too like classic MacOS. This meant that you could rearrange windows, and so see the desktop. That in turn made it clearer that programs minimized to the desktop, as nothing else could be on the desktop.
This can be seen clearly if you look at screenshots of the work-in-progress test versions of "Windows Chicago", e.g. https://sites.google.com/site/chicagowin95/index -- this is what was to be Windows 4.0 but was renamed Windows 95.
For instance, in this one: https://sites.google.com/site/chicagowin95/index/chicago40
... you can see some running program's icons sitting _on top of_ the prototype taskbar.
There was no separate container for program icons. The taskbar was invented _de novo_ in Windows 95, and subsequent to the invention of the taskbar, icons representing running programs were moved into it.
While Windows 1 tiles might have been due to wanting to avoid upsetting Apple (though in terms of APIs and resource management it was mostly a copy) there were those who preferred tiles like With's Oberon (which I also used at the time, along with GEM and Geos).
It was really quite a lovely system (very few installer programs, install/uninstall very clean with minimal dependencies), but it managed as well as it did mainly because nearly everything was statically linked and did its own thing for config. So centralised management of preferences was difficult, and what shared code there was (like the C library) broke the model a bit by needing to be kept in a separate '!System' directory.
As systems got more complex and ended up on the Internet, there was a greater concern for shared state between applications and security. Consequently the amount of stuff that started from disc on startup, the number of shared libraries and config files etc. went up, and some of the advantages of booting from ROM and the minimal 'copy to install' model went away a bit.
The chief difference between the Windows task bar and a MacOS dock is that some subset of icons on the dock are present even if the application hasn't been started.
You could not pin icons to the taskbar in Windows 98, no.
Windows 98 integrated IE4, which contained a feature called "Active Desktop".
This was not a Win98 innovation -- if you installed IE4 onto Windows 95 or NT 4, you got the same features.
Active Desktop included dockable "toolbars" that could be pinned to the desktop or to any edge of the screen. One of these became part of the taskbar, and was called the "quick launch" bar.
It's a separate area for program icons. If you launch an app, you end up with _two_ icons: one in the quick launch bar, _plus_ an icon in the taskbar as well.
The Quick Launch toolbar is still present in Windows 10 today, in 2020, and can be turned back on very easily: https://mywindowshub.com/add-quick-launch-toolbar-windows-10...
Pinning launcher icons directly to the taskbar was a new feature in Windows 7 and was not possible before that: https://social.technet.microsoft.com/Forums/SharePoint/en-US...
Plus I have a soft spot for co-operative multitasking.
Seems like a pain when working in a program and want to open a file
I was surprised when I switched from RISCOS to Windows just how much windows wants you to work in a 'single task' mode.
Not only is there no easy way to compose application chains, the UX discourages you from thinking that applications chains might be possible.
Automation incredibly difficult - it's impossible for most people, and not easy even if you have developer-level skills. But worse, your data is locked into these monolithic applications. Project interchange isn't usually a thing at all, and data interchange formats tend to be lossy and/or unreliably implemented.
Pipes in a command line shell are a poor substitute for the wonders that would be possible with a common and easy to use composable and automatable UI/API framework and data interchange system.
Nothing to do with "conditioning". I had no experience of any other desktop environment at the time.
- A dedicated menu button on mouse is hard to discover. Mac's brilliance is that you can start exploring the UX right away without any prior knowledge of which button does what. It also prevents you from examining your options without needing to click anything. I don't think saved screen real estate is worth it. Mac & Windows did away with always-visible menu bars just fine. Remember how Windows 8 tried to hide the start menu and how it had turned into the worst UX experience in the last decade ever. Visibility is important for discoverability.
- "Drag & drop" has too much user friction. It's hard to discover, it's hard to apply properly (many beginner users think that leaving button mid-drag is okay for a short little while). It's impractical because you usually use your apps maximized (for the maximum real estate, remember?). It requires you to have the file visible and easily accessible (consider cluttered desktop icons). I stopped using drag&drop a long time ago, and resort to Copy/Paste function of Windows Explorer for copying files, which works brilliant.
"Drag & drop to open" has other issues too. For one, there is no orthogonality between open & close. Do I drag away the icon to close the file or is there a standalone "close" option without an open?
They might be novel ideas for their time, but I don't think they provide good UX.
For what it's worth, it really wasn't. The meaning of at least the left and menu buttons was literally the first thing you would find out when being shown how to use the machine, and was on the intro sheet in the (extensive and excellent) printed guides.
The difficult-to-discover part was the right button ('adjust'), defined as doing whatever the left button did but a bit differently. So the left button might select a file, while the right button might add a file to the existing selection. Or a left click on the scroll bar 'down' arrow scrolls down, while a right click scrolls up (which was actually quite useful in pre-scroll wheel days as it saved a lot of precision mouse movements when searching documents etc.)
This is really analogous to the discoverability problems that guis have with modifier keys - the right button is basically a sort of ctrl-click without needing to put your hands on the keyboard.
But the menu button was just how you used menus. It was available and worked the same in essentially all applications and was really pleasant to use.
is this sarcasm? it appears disjointed from your comment and disagrees with your thesis.
> Remember how Windows 8 tried to hide the start menu and how it had turned into the worst UX experience in the last decade ever.
part of that is surely that trigger start in windows 8/8.1 closed (hid/whatever) you were working on before, forcing an unnecessary context switch. i can't print or save documents in office anymore for the same reason - if you choose “File”, it closes your current file.
note that mac os, windows, and to a much greater extent iOS and Android have abandoned the visibility principle. having a dedicated button vs a “force click” feature? i'd prefer the button.
your objections to dnd depend on it not being well implemented. but when it's core, it is well implemented. i use dnd, even sometimes to copy/paste on windows.
° "Drag & drop to open" has other issues too. For one, there is no orthogonality between open & close. Do I drag away the icon to close the file or is there a standalone "close" option without an open?
i don't understand your objection here. is there orthoganality between open/close on other systems? i have never thought so. i close by clicking x (windows, gnome) or just going back home (android). but i open by doubling click the file (linux) or doing something ad hoc (windows, android)
Not sure how it contradicts with my points. Can you clarify?
> is there orthoganality between open/close on other systems? i have never thought so.
Yes, there is always a "Close" menu option right in the same menu with the "Open". The close "X" is for closing windows, not opening them, and it also has orthogonality. You open the window by clicking on an icon, and you close it by clicking on another icon.
Going back isn't "closing" on Android. It's just the opposite of navigating forward which also makes sense in a navigational context.
But it bundles selection-specific and system-general commands up in a remote menu bar that requires a lot of to and fro to operate. The beauty of right-click is that it gives a contextual menu specific to the object right there. I'd argue that it's fantastic UX.
> "Drag & drop" has too much user friction
Yet it's universally used for moving windows around the UI; click-drag on the title bar.
e.g. both Windows and Mac OS came to the same "icon bar" design that RISC OS had in 1990. It had "magic" application directories for self-contained installation from floppies & downloads. It had a pretty nice vector drawing engine built in, sprite plotters etc. The OS was documented really comprehensively in a £80 set of programmers reference manuals. They wrote a really clear style guide, and (eventually) a well-understood higher-level GUI toolkit which produced great results with little code.
The most heinous part os the OS was the lack of shared libraries in userspace. If you wanted to share code between apps, you wrote it as a kernel extension module and made up new system calls! So this very common facility became a risky, advanced topic for programmers. (also because BASIC + assembler were free, and the C compiler was not, loads of popular libraries were hand-written in assembler).
RISC OS used cooperative multitasking and it lacked virtual memory protection. By 1995 linux or BSD were better platforms. MS released Windows 95 and preemptive multitasking arrived to millions of homes.
I still have a 2002 PACE based RISC OS in the basement. It boots with bootp+NFS. It was part of a kiosk that was replaced by a BSD box. No booting or runtime issues anymore. We even designed a serial watchdog to ensure a reboot if the STB hanged, because riscos hanged even booting. No issues with the BSD.
In my humble opinion by the mid 1990s preemptive multitasking and memory protection was mandatory in a general purpose OS and RISC OS lacked it.
I think the author is making the mistake of comparing it with what I would call "new world" OSs.
Very broadly I would categorize most OSs of the 90s into old-world and new-world, common traits of the old-world being:
- Minimal or no memory protection
- Minimal or no real user separation
- Usually desktop-focussed
- Cooperative multitasking at best
- Heavily reliant on assembly and hardware specifics
As an old-world OS, in 1991, I do still think that RISC OS did a pretty good job from a user's perspective. My memories are of it being fast, attractive (anti-aliased fonts?!) and intuitive (often ingenious). With an extremely powerful inbuilt BASIC implementation, to add.
The more I've looked in to RISC OS more recently, the more I've realized how many compromises had to be made to achieve this, and I'm sure they were running out of headroom to evolve it towards a new-world OS. But really this was true for most old-world OSs I can think of. (again, cue exceptions)
I used a RISC OS machine as my primary computer all the way through to 2004, but it was seven or so years past its best by then, and probably twelve since RISC OS was even a potential world-beater.
Virtual memory was undermined by large portions of the OS being implemented as, effectively kernel modules. That is because this was the provided mechanism for 'shared' libraries; there's no dynamic linker, as such, just syscalls. So perhaps it can be attributed more not to lack of virtual memory, but lack of a mechanism for shared libraries (and IPC)
It is certainly true that as features from multi-user systems began to make an appearance on PC desktops, RISC OS starts to get left behind in this area.
But also recall that wasn't the focus (for a self-selected user base, of course.) An OS geared to productivity, with features like consistent widgets (and style guide), drag and drop between apps, consistent filesystem interaction throughout and standardised anti-aliased font and vector graphic rendering as part of the OS. It's 2020 and it doesn't feel like any of the OSes I use today have anything like the same cohesion (let alone web apps)
They were, however, the early victories of RISC OS. It does look like in the latter years 'easy' stuff was worked on; things like new window decor and textured backgrounds; perhaps diverting attention (either the RISC OS developers, or users) from the core.
I'm rather interested what Acorn's take was on the porting of NetBSD to Acorn hardware (which I first saw at a show in about 1995). With the benefit of hindsight, perhaps RISC OS could have been layered atop of this. A BSD kernel with a RISC OS syscall interface, windowing system and BASIC interpreter to provide compatibility for the wealth of existing software, and a transition to a 'modern' OS. Was this considered at the time? Was anyone at Acorn paying attention to BSD? Was there enough people-power to make it feasible? Was Acorn already in trouble by then? The world could have been a very different place.
Acorn sold BSD derived RISC iX workstations (the hardware was just rebadged Archimedes) from 1988.
Please note I used the word 'also', I did not mean to imply the R-series weren't full UNIX workstations, but they came quite a few years after the Unicorn.
A later version called the Triple-X ran System V and came with a GUI on the native processor.
Edit: found a link with a better description of the Unicorn:
http://chrisacorns.computinghistory.org.uk/docs/Torch/Torch_...
One more with some pics:
http://chrisacorns.computinghistory.org.uk/docs/Mags/AU/AU_S...
There was some memory protection to make pages read-only for user code, notably page zero (to trap null pointer dereferences, and to protect the interrupt vectors) but my memory is that the system heap (containing the OS modules) was either directly writable from userspace, or it was trivial to make a system call to get write access.
RISC OS was a terrifically fun environment in which to learn programming. Of course it lacked lots of the fundamentals of 'proper' operating systems (memory protection, preemptive task switching, multiple users etc etc) but the compromises they made were cleverly chosen and lots of parts of the design were very elegant. The user interface was great and there was lots of other very sophisticated features that were ahead of their time, discussed elsewhere in these comments (outline fonts, vector graphics, fast native video compression/decompression, the list goes on). The operating system was very easy to extend, so it was easy and fun to write little utilities, and this led to a vibrant hobbyist/'freeware' scene as I suppose it was called in those days.
The fact that the OS was all implemented in assembler was reflected in the API, and (coupled with the inherent pleasure of working with the ARM instruction set of those days) led to the majority of third party apps being written in assembler too, often with bits of the very efficient built-in BASIC to bind it all together. This made the whole user experience very fast and slick.
The documentation was also superb, though expensive for a youngster! I can't bring myself to get rid of the Programmer's Reference Manuals as they're so good and were such a holy text back in the day.
I still have "BASIC WIMP programming on the Acorn" by Alan Senior on my bookshelf for no good reason. I can't even find any cover photos online for it.
One day we had a visitation from Acorn trying to get us to write Archimedes software. They asked us what they could do to make their platform more appealing to us as developers and to users.
We said we liked their CPU performance, but didn't like the Archimedes graphics hardware which was too low res and low depth, and could not be upgraded. For example, the Risc OS system did anti-aliased fonts (which they were very proud of), but at such a horribly low resolution that the result managed to be blurry and blocky at the same time.
They didn't really get our complaints, didn't think the bad graphics were important. They had no intention of ever making a machine with enough video memory to do a better job.
We said their system UI was odd, for example unlike Mac and Windows there was no copy and paste. We gave other examples of the UI being weird just for the sake of it, but I can't remember the details after all these years.
They said all their UI was fine, and copy and paste was stupid.
That department never did publish anything for the Archimedes.
I'm surprised about that! Looking at https://en.wikipedia.org/wiki/Acorn_Archimedes it says the machine could do 640 × 512 with 2, 4, 16 or 256 possible colours, or 800 × 600 with 2, 4 or 16 possible colours. That's pretty spectacular for the late eighties; far superior to the Amiga (previously considered the king of graphics) and even superior to VGA, let alone the Mac.
What am I missing?
OK, I concede, I gave in to a tiny trollette there.
I've been using *nix professionally since 1989. I work for a Linux vendor. I know my way around.
But for the last 25 years, I've mainly worked with Linux. I quite like Linux, although it's getting a bit long in the tooth and bloated these days.
But what strikes me every time that I try any of the BSDs is how little they have learned from Linux and what has made Linux so successful.
Linux natively uses PC partitioning. BSD doesn't; you have to install into special BSD "disk slices" which must be in a primary partition. (I confess I have not tried on a UEFI box yet. I am sure GPT changes this, but I don't know how.)
Linux natively uses the PC keyboard and framebuffer. It adapts to my screen size. It uses colours. BSD doesn't. I still see '80s nonsense like ^H sometimes.
Linux usually detects and uses all my hardware. Even on quite recent kit, I've had BSD not recognise my network card, or my wifi adaptor, or whatever.
Linux feels like a native OS on PCs and handles PC hardware gracefully. BSD, to me, doesn't - it feels like a 1970s minicomputer OS, reluctantly running on an alien platform.
I started out on SCO Xenix 286 on an IBM PC-AT, when that was still fairly modern kit. FreeBSD doesn't feel much more advanced than that, and NetBSD and OpenBSD are worse.
That is what I am getting at.
There have been multiple efforts to incorporate some of the nice bits of OS X over the years, notably NeXTBSD. They failed completely. It seems to me that the BSD folks don't want nasty new tech. If it worked 50 years ago, it's still good enough.
It was a joy to program, but it got killed (in my industry) because customers had been screwed over by vendors locking them into specific hardware, then raising prices once the customer had no way out. So the contracts always specified COTS hardware ... "Commercial Off-the-Shelf". This was always, always interpreted as meaning PC hardware.
We transitioned because we had to, but the lamented the loss of the elegant, simple, clean designs we could use on RISC OS.
I still do.
Rox-Filer had a panel, a pinboard with shortcuts, a Python-Gtk2 API with Rox-Lib with lots of Drag and Drop applets.
Beyond XFCE, it was a nice alternative to Gnome. It's even lighter than XFCE and probably when used with Fluxbox it would be faster and snappier than LXDE.
Dave Jaggar has some interesting comments on the history around DEC, StrongARM and the Austin ARM team.
I would mention that that video was _wildly_ contentious over in the RISC OS world. :-D
Also RISC OS was a desktop OS and Thumb etc was all about getting into mobile devices and so in effect abandoning that legacy.
In fairness though without Thumb ARM would be unlikely to have reached its market position today so credit due I think to all those who contributed to the evolution of the architecture (including the team that developed A64).
Plus seems like the GBA was paused for a while in the 1990s too.
Why and how do you think it would have fit?
Btw: they were used to generate live on screen graphics for the BBC for quite a few shows https://www.youtube.com/watch?v=exW-LbLRJV0
The two major flies in the ointment are that RISC OS has never had a wifi stack (use ethernet or an external wireless access point) and that some of the old software hasn't survived the shift from the ARM2/3's 26-bit addressing mode to the more modern 32-bit standard. But if you don't have old games you want to be nostalgic about, that's less of a problem!
RISC OS recently changed ownership and it is now fully open-source. The new owners have sponsored an improved version with more bundled software, called RISC OS Direct: https://www.riscosdev.com/direct/
Now that would be interesting, a ~$200 laptop running RISC OS!
[0] https://www.techradar.com/uk/news/arms-original-operating-sy...
I had an Amiga at home and was so frustrated at not having access to x86 PCs.
In hindsight I realise how fortunate I was to learn programming and be exposed to these different very forward thinking OSes very early.
RISC OS began my experience of hacking software by being able to click into the application and edit stuff. Trying to bypass the security to do more on them also honed early development and explorative techniques too.
I had hours of fun on the school computers making weird stuff happen whenever anyone tried to open an application or access their documents folder.
Being able to drop into a BASIC shell at any point by hitting F12 was cool too.
Kept the old Arthur ROM chips for years afterwards as a sort of prize.
I remember being extremely disappointed by the OS: firstly, storing the system on ROM made obvious sense to me but it also nagged me because this wasn’t an embedded system and the ideology of downloading frequent updates from the internet to patch the deluge of security vulnerabilities and other assorted bugs being discovered on a regular basis was already developing.
Secondly, as the article points out, it actually struck me as a rather rudimentary OS with a fairly ugly (and foreign) GUI. It lacked preemptive multitasking, memory protection, and the notion of multiuser. It felt technically on the level of Windows 3.11 but loaded from ROM, on an (admittedly very fascinating) exotic architecture.
And yes, the OS was starting to show its age (both graphically and with its cooperative multitasking) by the time Acorn was broken up, but at its peak it was miles ahead of the competition, and was definitely an under-appreciated pearl.
In reality it was still loading all its OS patches from disc.
That along with clever use of 16 colours (8 greyscale) and antialiased fonts really gave the impression of a much more advanced machine for the time.
Really loved that machine. :D
Well, that was sort of my point. If you follow the link to the ROUGOL talk on its history, it explains some of the reasons why.
It's important to consider that the history of RISC OS has an important commonality with the history of AmigaOS: in both cases, the companies were planning something far more sophisticated and clever -- CAOS for Commodore, ARX for Acorn -- but the projects over-ran and under-delivered. So, they fell back on almost-skunkworks projects that used existing tech to get something good enough out the door when the hardware was ready to ship.
In Commodore's case, they used the existing TRIPOS OS, written in BCPL: https://en.wikipedia.org/wiki/TRIPOS ... and the existing Rexx language: https://en.wikipedia.org/wiki/Rexx
The result was AmigaDOS (as it was originally called, before it was renamed to AmigaOS).
In Acorn's case, there had already been a 16-bit port of the BBC Micro MOS and BASIC, for the ill-fated Acorn Communicator, based on the same 65C816 CPU as the Apple ][GS: http://chrisacorns.computinghistory.org.uk/Computers/Communi...
So Acorn ported its existing OS and language to ARM, and wrote a fairly basic desktop GUI in BASIC. The result was Arthur: https://everything2.com/title/Arthur+OS
Once it had shipped, it was finished and renamed RISC OS. Allegedly the name change is because of the Dudley Moore film which had just taken the name "Arthur 2": https://en.wikipedia.org/wiki/Arthur_2:_On_the_Rocks
So, yes, it was a hasty, last-minute exercise, based on an outdated core, an early-1980s, single-user, single-tasking command-line OS for a low-end machine -- just like Windows 3 and DOS.
On the other hand, it worked and worked very well -- arguably far better than Windows 3, I'd say.
I aspired to an Amiga as a student in 1986 or so, but by the time I could afford such a thing, I had the option of something much faster... ;-)
My main (non-tech) blog is on there too and it's 18 years old now. I have just been too lazy to move so far.
>Any headline that ends in a question mark can be answered by the word no.
https://en.wikipedia.org/wiki/Betteridge%27s_law_of_headline...
Yes, that was entirely intentional. :-) I used to be the staff technical writer at PC Pro magazine. Ian Betteridge was a colleague on the staff of our sister magazine, MacUser, for which I also wrote sometimes. We're still in touch today.