Liam on Linux

EDIT: this post has attracted discussion and comments on various places, and some people are disputing its accuracy. So, I've decided to make some edits to try to clarify things.

When Windows 2 was launched, there were two editions: Windows, and Windows/386.

The ordinary "base" edition of Windows 2.0x ran on an XT-class computer: that is, an Intel 8088 or 8086 CPU. These chips can only directly access a total of 1MB of memory, of which the highest 384kB was reserved for ROM and I/O: so, a maximum 640kB of RAM. That was not a lot for Windows, even then. But both DOS and Windows 2.x did support expanded memory (Lotus-Intel-Microsoft-specification EMS). I ran Windows 2 on 286s and 386s at work, and on 386 machines I used Quarterdeck's QEMM386 to turn the extended memory that Windows 2 couldn't see or use into expanded memory that it could.

The Intel 80286 could access up to 16MB of memory. But all except the first 640kB was basically invisible to DOS and DOS apps. Only native 16-bit programs could access it, and there barely were any — Lotus 1-2-3 r3 was one of the few, for instance.

There was one exception to this: due to a bug the first 64kB of memory above 1MB (less 16 bytes) could be accessed in DOS's Real Mode. This was called the High Memory Area (HMA). 64kB wasn't much even then, but still, it added 10% to the amount of usable memory on a 286. DOS 3 couldn't do anything with this – but Windows 2 could.

Windows 2 and 2.01 were not successful, but some companies did release applications for them – notably, Aldus' PageMaker desktop publishing (DTP) program. So, Microsoft put out some bug-fix releases: I've found traces of 2.01, 2.03, 2.11 and finally 2.12.

When Windows 2.1x was released, MICROS~1 did a little re-branding. The "base" edition of Windows 2.1 was renamed Windows/286. In some places, Microsoft itself claims that this was a special 286 edition of Windows 2 that ran in native 80286 mode and could access all 16MB of memory.

But some extra digging by people including Mal Smith has uncovered evidence that Windows/286 wasn't all it was cracked up to be. For one thing, without the HIMEM.SYS driver, it runs perfectly well on 8088/8086 PCs – it just can't access the 64kB HMA. Microsoft long ago erased the comments to Raymond Chen's blog post, but they are on the Wayback Machine.

So the truth seems to be that Windows/286 didn't really have what would later be called Standard Mode and didn't really run in the 286's protected mode. It just used the HMA for a little extra storage space, giving more room in conventional memory for the Windows real-mode kernel and apps.

So, what about Windows/386?

The new 80386 chip had an additional mode on top of 8/16-bit (8088/8086-compatible) and fully-16-bit (80286-compatible) modes. The '386 had a new 32-bit mode – now called x86-32 – which could access a vast 4GB of memory. (In 1985 or so, that would have cost hundreds of thousands of dollars, maybe even $millions.)

However, this was useless to DOS and DOS apps, which could still only access 640kB (plus EMS, of course).

But Intel learned from the mistake of the 286 design. The 286 needed new OSes to access all of its memory, and even they couldn't give DOS apps access to that RAM.

The 386 "fixed" this. It could emulate, in hardware, multiple 8086 chips at once and even multitask them. Each got its own 640kB of RAM. So if you had 4MB of RAM, you could run 6 separate full-sized DOS sessions and still have 0.4MB left over for a multitasking OS to manage them. DOS alone couldn't do this!

There were several replacement OSes to allow this. At least one of them is now FOSS -- it's called PC-MOS 386.

Most of these 386 DOS-compatible OSes were multiuser OSes — the idea was you could plug some dumb terminals into the RS-232 ports on the back of a 386 PC and users could run text-only DOS apps on the terminals.

But some were aimed at power users, who had a powerful 386 PC to themselves and wanted multitasking while keeping their existing DOS apps.

My personal favourite was Quarterdeck DESQview. It worked with the QEMM386 memory manager and let you multitask multiple DOS apps, side by side, either full-screen or in resizable windows. It ran on top of ordinary MS-DOS.

Microsoft knew that other companies were making money off this fairly small market for multitasking extensions to DOS. So, it made a third special edition of Windows 2, called Windows/386, which supported 80386 chips in 32-bit mode and could pre-emptively multitask DOS apps side-by-side with Windows apps.

Windows programs, including the Windows kernel itself, still ran in 8086-compatible Real Mode and couldn't use all this extra memory, even on Windows/386. All Windows/386 did was provide a loader that converted all the extra memory above 1MB in your high-end 386 PC – that is, extended (XMS) memory – into expanded (EMS) memory that both Windows and DOS programs could use.

The proof of this is that it's possible to launch Windows/386 on an 8086 computer, if you bypass the special loader. Later on, this loader became the basis of the EMM386 driver in MS-DOS 4, which allowed DOS to use the extra memory in a 386 as EMS.

TBH, Windows/386 wasn't very popular or very widely-used. If you wanted the power of a 386 with DOS apps, then you probably were fine with or even preferred text-mode stuff and didn't want a GUI. Bear in mind this is long before graphics accelerators had been invented. Sure you could tile several DOS apps side-by-side, but then you could only see a little bit of each one -- VGA cards and monitors only supported 640×480 pixels. Windows 2 wasn't really established enough to have special hi-res superVGA cards available for it yet.*

Windows/386 could also multitask DOS apps full-screen, and if you used graphical DOS apps, you had to run them full-screen. Windows/386 couldn't run graphical DOS apps inside windows.

But if you used full-screen multitasking, with hotkeys instead of a mouse, then why not use something like DESQview anyway? It used way less disk and memory than Windows, and it was quicker and had no driver issues, because it didn't support any additional drivers.

The big mistake MS and IBM made when they wrote OS/2 was that they should have targeted the 386 chip, instead of the 286.

Microsoft knew this – it even had a prototype OS/2 1 for 386, codenamed "Sizzle" and "Football" – but IBM refused because when it sold thousands of 286 PS/2 machines it had promised the customers OS/2 for them. The customers didn't care, they didn't want OS/2, and this mistake cost IBM the entire PC industry.

If OS/2 1 had been a 386 OS it could have multitasked DOS apps, and PC power users would have been all over it. But it wasn't, it was a 286 OS, and it could only run 1 DOS app at a time. For that, the expensive upgrade and extra RAM you needed wasn't worth it.

So OS/2 bombed. Windows 2 bombed too. But MS was so disheartened by IBM's intransigence, it went back to the dead Windows 2 product, gave it a facelift with the look-and-feel stolen from OS/2 1.2, and they used some very clever hacks to combine the separate Windows (i.e. 8086), Windows/286 and Windows/386 programs all into a single binary product. The WIN.COM loader looked at your system spec and decided whether to start the 8086 kernel (KERNEL.EXE), 286 kernel (DOSX.EXE) or the 386 kernel (WIN386.EXE).

If you ran Windows 3 on an 8086 or a machine with only 640kB (i.e. no XMS), you got a Real Mode 8086-only GUI on top of DOS.

If you ran Win3 on a 286 with 1MB-1¾MB of RAM then it launched in Standard Mode and magically became a 16-bit DOS extender, giving you access to up to 16MB of RAM (if you were rich and crazy eccentric).*

If you ran W3 on a 386 with 2MB of RAM or more, it launched in 386 Enhanced Mode and became a 32-bit multitasking DOS extender and could multitask DOS apps, give you virtual memory and a memory space of up to 4GB.

All in a single product on one set of disks.

This was revolutionary, and it was a huge hit...

And that about wrapped it up for OS/2.

Windows 3.0 was very unreliable and unstable. It often threw what it called an Unrecoverable Application Error (UAE) – which even led to a joke T-shirt that said "I thought UAE was a country in Arabia until I discovered Windows 3!"... but when it worked, what it did was amazing for 1990.

Microsoft eliminated UAEs in Windows 3.1, partly by a clever trick: it renamed the error to "General Protection Fault" (GPF) instead.

Me, personally, always the contrarian, I bought OS/2 2.0 with my own money and I loved it. It was much more stable than Windows 3, multitasked better, and could do way more... but Win3 had the key stuff people wanted.

Windows 3.1 bundled the separate Multimedia Extensions for Windows and made it a bit more stable. Then Windows for Workgroups bundled all that with networking, too!

Note — in the DOS era, all apps needed their own drivers. Every separate app needed its own printer drivers, graphics drivers (if it could display graphics in anything other than the standard CGA, EGA, VGA or Hercules modes), sound drivers, and so on.

One of WordPerfect's big selling points was that it had the biggest and best set of printer drivers in the business. If you had a fancy printer, WordPerfect could handle it and use all its special fonts and so on. Quite possibly other mainstream offerings couldn't, so if you ran WordStar or MultiMate or something, you only got monospaced Courier in bold, italic, underline and combinations thereof.

This included networking. Every network vendor had their own network stack with their own network card drivers.

And network stacks were big and each major vendor used their own protocol. MS used NetBEUI, Novell used IPX/SPX, Apple used AppleTalk, Digital Equipment Corporation's PATHWORKS used DECnet, etc. etc. Only weird, super-expensive Unix boxes that nobody could afford used TCP/IP.

You couldn't attach to a Microsoft server with a Novell network stack, or to an Apple server with a Microsoft stack. Every type of server needed its own unique special client.

This basically meant that a PC couldn't be on more than one type of network at once. The chance of getting two complete sets of drivers working together was next to nil, and if you did manage it, there'd be no RAM left to run any apps anyway.

Windows changed a lot of things, but shared drivers were a big one. You installed one printer driver and suddenly all your apps could print. One sound driver and all your apps could make noises, or play music (or if you had a fancy sound card, both!) and so on. For printing, Windows just sent your printer a bitmap — so any printer that could print graphics could suddenly print any font that came with Windows. If you had a crappy old 24-pin dot-matrix printer that only had one font, this was a big deal. It was slow and it was noisy but suddenly you could have fancy scalable fonts, outline and shadow effects!

But when Microsoft threw networking into this too, it was transformative. Windows for Workgroups broke up the monolithic network stacks. Windows drove the card, then Windows protocols spoke to the Windows driver for the card, then Windows clients spoke to the protocol.

So now, if your Netware server was configured for AppleTalk, say — OK, unlikely, but it could happen, because Macs only spoke AppleTalk — then Windows could happily access it over AppleTalk with no need for IPX.

The first big network I built with Windows for Workgroups, I built dual-stack: IPX/SPX and DECnet. The Netware server was invisible to the VAXen, and vice versa, but WfWg spoke to both at once. This was serious black magic stuff.

This is part of why, over the next few years, TCP/IP took off. Most DOS stuff never really used TCP/IP much — pre-WWW, very few of us were on the Internet. So, chaos reigned. WfWg ended that. It spoke to everything through one stack, and it was easy to configure: just point-and-click. Original WfWg 3.1 didn't even include TCP/IP as standard: it was an optional extra on the disk which you had to install separately. WfWg 3.11 included 16-bit TCP/IP but later Microsoft released a 32-bit TCP/IP stack, because by 1994 or so, people were rolling out PC LANs with pure IP.

---

* Disclaimer: this is a slight over-simplification for clarity, one of several in this post. A tiny handful of SVGA cards existed, most of which needed special drivers, and many of which only worked with a tiny handful of apps, such as one particular CAD program, or the GEM GUI, or something obscure. Some did work with Windows 2, but if they did, they were all-but unusable because Windows 2's core all had to run in the base 640kB of RAM and it very easily ran out of memory. Windows 3 was not much better, but Windows 3.1 finally fixed this a bit.

So if you had an SVGA card and Windows/286 or Windows/386 or even Windows 3.0, you could possibly set some super-hires mode like 1024×768 in 16 colours... and admire it for whole seconds, then launch a few apps and watch Windows crash and die. If you were in something insane like 24-bit colour, you might not even get as far as launching a second app before it died.

Clarification for the obsessive: when I said 1¾MB, that was also a simplification. The deal was this:

If you had a 286 & at least 1MB RAM, then all you got was Standard Mode, i.e. 286 mode. More RAM made things a little faster – not much, because Windows 2 didn't have a disk cache, relying on DOS to do that. If you had 2 MB or 4 or 8 or 16 (not that anyone sane would put 16MB in a 286, as it would cost $10,000 or something) it made no odds: Standard Mode was all a 286 could do.

If you had a 386 and 2MB or more RAM, you got 386 Enhanced Mode. This really flew if you had 4MB or more, but very few machines came with that much except some intended to be servers, running Unix of one brand or another. Ironically, the only budget 386 PC with 4MB was the Amstrad 2386, a machine now almost forgotten by history. Amstrad created the budget PC market in Europe with the PC1512 and PC1640, both 8086 machines with 5.25" disk drives.

It followed this with the futuristic 2000 series. The 2086 was an unusual PC – an ISA 8086 with VGA. The 2286 was a high-end 286 for 1988: 1MB RAM & a fast 12.5MHz CPU.

But the 2386 had 4MB as standard, which was an industry-best and amazing for 1988. When Windows 3.0 came out a couple of years later, this was the only PC already on the market that could do 386 Enhanced Mode justice, and easily multitask several DOS apps and big high-end Windows apps such as PageMaker and Omnis. Microsoft barely offered Windows apps yet – early, sketchy versions of Word and Excel, nothing else. I can't find a single page devoted to this remarkable machine – only its keyboard.

The Amstrad 2000 series bombed. They were premature: the market wasn't ready and few apps used DOS extenders yet. Only power users ran OS/2 or DOS multitaskers, and power users didn't buy Amstrads. Nor did people who wanted a server for multiuser OSes such as Digital Research's Concurrent DOS/386.

Its other bold design move was that Amstrad gambled on 5.25" floppies going away, replaced by 3.5" diskettes. They were right, of course – and so the 2000 series had no 5.25" bays, allowing for a sleek, almost aerodynamic-looking case. But Amstrad couldn't foresee that soon CD-ROM drives would be everywhere, then DVDs and CD burners, and the 5.25" bay would stick around for another few decades.

I am not a huge fan of the Windows-type desktop, but I will use it happily enough.

This is good, because there's a wide choice of them. However, I like my taskbar to be vertical, and most Windows-like desktops can't do that. When I say so, people often respond something like "but $desktop_x does vertical panels just fine!"

I get that a lot. So often I assembled an Imgur picture album to show what I mean.

The taskbar was an original invention in Windows 95. There is no prior art; I and others have looked. The closest were the "icon bar" in Acorn RISC OS (1987) and the Dock in NeXTstep (1988). Both are simpler.

The way the taskbar works is that whatever its orientation, its contents run right-to-left.

So you have the Start button, then (as of IE4's Active Desktop) an optional "quick launch" toolbar (still there in Win8 and Win10 but off by default), then buttons for all the open windows/apps, then the "system tray" or "notification area" containing status icons and the clock.

Wherever you put the taskbar — bottom, top, vertical on the left, vertical on the right — the icons in the system tray and quicklaunch run left to right, in rows if there isn't enough space.

Buttons have text running left to right. (R to L if you use Arabic, Hebrew etc.)

Buttons are wider than they are tall. (This is harder to see in Win7/8/10 because they don't contain text by default any more).

In a taskbar, as you resize the panel, you get more or fewer rows of icons. More or fewer buttons may fit. If it is so narrow there's only room for 1 icon, then they form a column.

This is good, because it means that on a widescreen, you get more room if the panel gets wider. You get more icons, more buttons, but they stay the same size — there is a "large icons"/"small icons" setting and it is honoured. I normally adjust mine for 4 columns of status icons, which gives me window buttons about the same size as the old traditional ones on Win9x/2K/XP.

In GNOME 2, MATE, Cinnamon, et al, the contents of a panel are arranged in the direction that the panel is arranged. So if you place the taskbar vertically, the contents run vertically. No rows or columns; just a single column. This is bad, because your status icons take up much of the panel leaving little room for window buttons.

If you resize the panel, some or all of the contents get bigger or smaller. So for example in KDE (3/4/5, doesn't matter, they all do vertical taskbars but badly), you get a HUGE start button because it's not resizable: it fits the width of the panel. You get a HUGE clock as well because there's no size setting. There are a million settings for where the panel is, how it's rendered, and how the file manager can display email, network shares, the entire Web and connect to some network protocol nobody's used in 3 decades, but you can't set the font size of the clock. Why would you want to do that?

GNOME 2 and MATE show some things vertically, and some horizontally. Just vertically is bad, but a mixture is even worse — you get the worst of both worlds, showing few things but some look weird or take a lot of room.

In the original Windows taskbar, if you make it really thick in a horizontal orientation, you get 2 rows of app buttons — and even 3 or 4 if it's big enough.

If the GNOME 2/MATE/Cinnamon ones did that in vertical orientation, it would help, but no, they don't implement that feature.

In other words, what annoys me is that almost every FOSS desktop out there is a copy of Win95. KDE (all versions); GNOME 2 & MATE; Cinnamon; XFCE; LXDE/LXQt; Enlightenment; Lumina.

But most of them are rubbish rip-offs of the Windows desktop, and they can't even do all the things the original could 26 years ago when version 1.0 of it shipped.

Xfce does it fairly well. It's a bit clunky but it works. LXDE and LXQt do it well too, but they're much less customisable.

I know of 3 current FOSS desktops that aren't Win95 ripoffs. GNOME 3 is its own thing (with heavy influence from Ubuntu Unity, which in turn is a rip-off of Mac OS X.) Pantheon (the Elementary OS desktop) is a — very poor — rip off of Mac OS X. Pretty, though. (PearOS was a good rip-off; Apple bought it and shut it down. Pantheon doesn't even have a menu bar, just an empty panel where it used to be. I've blogged about that before.) Budgie doesn't quite know what it is, but you can do the exact same thing with about 5min of customising Xfce with its built-in themes and controls.

(The ROX Desktop wasn't but it's basically dead, sadly. GNUstep isn't a desktop, they just implemented one by accident. It's a NeXTstep ripoff. There were long long ago ripoffs of Classic MacOS ("Sparta") and AmigaOS (amiwm + some file manager I forget.) All disappeared last century.)

OpenCDE isn't but despite an epic amount of work to get it made FOSS by a mate of mine, nobody seems to care and it hasn't been modernized or even adopted. Sad, really. It wouldn't be a vast amount of work to make it into a decent OS/2 Warp Workplace Shell clone, and a lot of people loved that.

It's the Linux way, isn't it? What we will do is, we'll divide into a dozen different groups that hate each other's guts. Three quarters of them will duplicate each other's work, badly, based on a rip-off of someone else's idea. Two of the others will rip-off a different idea instead. And one lunatic will do something totally different and new, half-finish it, get bored and go off and do something else which they also won't finish.

Meanwhile, the hardcore will use something horrible from 1973 but love it to death, proclaim how powerful it is and refuse to use anything more modern.

For bonus points, they'll pick one tool from 1973 and another tool from 1965 and despise each other for using the wrong one.

And repeat.

Meanwhile, most practical people with jobs just go and buy a Macbook.

Thirteen years ago this weekend, Steve Jobs announced the original iPhone, as former Microsofty Steve Sinofsky discusses in a great Twitter thread. The demo was epochal, but very hard to pull off behind the scenes, as the NY Times discussed six years later.

I was already a frustrated smartphone user. I had a Nokia 7710 – the last ever Symbian device with a derivative of the Psion UI, and therefore doubly compromised, as I discussed in what turned out to be a very poorly timed piece on OSnews.

After I saw the demo, I knew that finger-operated touchscreens were clearly the future – but as you can see from the comments on that January 2007 blog post, most of my techie friends were very much not convinced of this.

But it was very clear to me that the iPhone was the future. The comments there make amusing reading now: no, it can't be. It doesn't have the features. It doesn't have 3G. It's not about the UI, people want the features.

I couldn't believe that Apple had ported OS X to the ARM chip, though – and now, it's its native platform and all the new Macs will be ARM-based.

[Repurposed from a Reddit comment]

Ethernet is not just a kind of cable. It's also the electronic signals carried over that cable, and the format of the data packets that are sent over it.

Token Ring is a totally different kind of network, with totally different signals. You can't just convert one to the other.

If you write a sentence of Chinese in Roman characters, you've still got Chinese. It's not magically become Latin. "你吃了吗？" becomes "Nǐ chīle ma?" but it hasn't been translated -- it's still Chinese and unless you speak Chinese you cannot understand it.

This is not Token Ring converted to Ethernet -- it's Token Ring over unshielded twisted-pair cabling (UTP), the kind that some forms of Ethernet (10base-T, 100base-T, 1000base-T) happen to run over too. UTP comes in different categories – low grades are enough for voice phone calls but not for data. The minimum standard for 10base-T was Category 3, and 100base-T (called Fast Ethernet) used 2 higher: Cat5.

The connectors are a separate standard -- 8 position 8 contact (8P8C). However that doesn't tell you which wire is connected to which connector. Those are standardized as Registered Jack standards. The one that was used 10base-T was adapted from telephony standard #45 – RJ45.

The defining feature of Ethernet is that them medium is a straight line, A to B, and all computers share it. Everyone tries to talk at once, and if someone else is talking to, you hear it, shut up, wait a random time and then try again. This is called Collision Sensing Multiple Access with Collision Detection: CSMA/CD.

Dead simple to implement, therefore easy to implement, therefore cheap. But it doesn't scale. If too many people talk at once, they can't make themselves heard. 20-30 computers works OK; 200-300 and performance falls off a cliff.

Token Ring doesn't work like that. In a TR network, the wiring is a electronically a loop: no "ends". (Actually that's really fragile in real life, so the loop has long fingers reaching out from a central box, the Medium Access Unit – MAU – to each computer and back -- physically it's a star.) There is one magic golden ticket that means "I can use the network!" It goes round and round. If you need to talk, you grab it, send your message, then send it on its way. The next machine that needs to talk waits for the ticket, grabs it, talks, then lets it go. A single Token going round and round the ring.

This is complicated, so it's expensive, but because access to the medium is controlled, it scales really well, so it was worth it for big networks that had to perform even under heavy load.

Token Ring worked at 2 speeds: 4Mb/s and later 16Mb/s.

On top of the electronic signalling system, you can put whatever data you want. Normally, some kind of network protocol -- IBM used SNA and DLC, but also later NetBEUI in DOS and OS/2; Novell used IPX/SPX; Apple used AppleTalk; and those weird super-expensive UNIX computers in universities and reseach labs used their own weird thing called TCP/IP.

This isn't Token Ring over Ethernet. This is plain pure Token Ring, but using media converters to run it over cheap Cat5 UTP cabling with 8P8C connectors wired up as RJ45.

But hang on, you say, Ethernet cabling isn't one line. It's a star too.

Well, yes, it is now, because UTP is point-to-point. Older Ethernet standards such as 10base-5 (orginally called just Ethernet) and the later, thinner, cheaper 10base-2 ("CheaperNet", later renamed Thin Ethernet and the older stuff was retconned as Thick Ethernet) are a single long wire, up to a bit under 200 metres (600 feet), with special caps on the end called terminators. But if it breaks at any point, the whole network fails – and to add a new computer, you have to break the cable. Accidentally introduce a branch or fork and it fails. So, cheap but flawed.

So someone came up with a way to run it over UTP, adapted phone wiring really. Each machine has its own cable and they all meet in the middle in a box called a hub. But electronically, it's a line -- the ends aren't connected. You can just plug in new machines while the others keep talking. You need a lot more cables, dozens of them, but it's good, it works, and it's cheap.

You need a lot more cables and you need either a big hub -- but remember, Ethernet maxed out at under 50 machines or so. (Very hand-wavy number: the "everyone shout at once" model depends on what you're doing, obviously.)

It was difficult but you could interconnect hubs. But then you double the size of your network, and it doesn't scale.

So if you put a mini router in each hub, and it only passes traffic destined for the other hub, it scales better – but only to a 4-5 hubs or it gets too complex.

But once you're making cheap mini router chips, you can make a hub that listens to the traffic and only connects machines when they're talking. It's like a little telephone exchange, instead of lots of people on one line all talking at once. It switches circuits. Normally, client computers all talk to a server, not to each other, so it's quite scalable.

Now your hub has smarts. It doesn't act like a dumb everyone-to-everyone hub any more. It's a mini call-centre, routing calls from machine to machine: a switch. So normally only 2 machines are ever connected at once, and that scales really well, to hundreds and hundreds of machines with no drop in performance. No token required, just smarter, faster electronics. And all at 100Mb/s.

When switches got cheap, that was it for Token Ring.

There seems to be, from my own experience so far, 3 or 4 types of UEFI system in practice:

[1] UEFI systems where you can pick an option to work in legacy BIOS emulation, and then all the UEFI stuff disappears and it just looks and acts like a BIOS. Example: my Thinkpad X220 & T420 even on the latest firmware. You can enter the firmware with whatever the manufacturer's normal hot-key combination is, etc.

[2] UEFI systems which will look for legacy BIOS boot structures on the boot medium, load from them in BIOS mode and from then look like a BIOS machine. However, this is dynamic and if booted from a UEFI medium with an EFI System Partition etc., they act like pure UEFI machines. Examples: I have seen some fairly recent (Xeon) desktop Dells from the last 3-5 years like this.

[3] UEFI systems which offer a choice: for instance, when you enter the "select a boot medium" menu, and they detect a bootable USB , then you get 2 boot options for that medium: "legacy boot" or "BIOS boot" or words to that effect, or "UEFI boot". Depending on which you pick, the *same boot medium* will perceive itself to be starting on a BIOS system or on a UEFI system. If you know the difference, these are easy, but it's easy to get it wrong and enter a config where you can't install a bootable system, or your booted system can't see or manipulate the boot structures of an installed system of the other type.

Examples: I have seen modern 2019-model Dell Precision mobile workstations like this; my girlfriend's Lenovo Core i5 desktop (about a 2017-2018 machine).

Interestingly, I was only able to get my partner's machine to boot Linux Mint 19.2 or 19.3 from its HD by pressing F12 to pick a boot medium; then the GRUB menu appears. Normally, it boots direct to Win10, whatever settings are in the firmware. (This is based on Ubuntu 18.04, as mainstream as Linux gets). Upgrading the firmware made no difference.

Interestingly, this summer, when I upgraded to Mint 20 (based on Ubuntu 20.04), suddenly the EFI GRUB menu started working without F12. Someone somewhere has fixed something and now it works. Who knows who or what? All part of the fun of UEFI.

[4] UEFI systems which are pure UEFI and will only boot from a correct-configured UEFI medium. Some may say that there is a legacy boot option but it won't work. Example: my current work desktop, a Dell Precision Core i7 minitower. I inherited this from a colleague who quit. He spent days trying to get it to boot. Later, I tried to help. When he left, I asked for and got the machine, and I spent a week or so on it. I tried about 6-7 Linux distros, stable and cutting-edge versions, booted from USB or DVD or network. Nothing worked. I could not get a Linux distro to boot from the hard disk. In the end, in desperation, I put the latest Win10 on it, which worked perfectly. With the boot structures created by Win10, Linux will dual-boot perfectly happily and totally reliably.

I have received a lot of abuse from "experts" who tell me that what I've seen is impossible, not true, etc. Especially from enterprise Linux vendors, who just get their bootloader signed and therefore see no problem with this. This is a theme — I've been in the business 32 years now and I've had that a lot.

The watchword is this: one, single exception disproves a million people for whom something works perfectly.

It doesn't matter how many reviews say "X is great" if one review says "Y doesn't work and Z is missing." It is the negative assessments that matter; this is not a number game, not a vote. One failure outweighs any number of successes.

IMHO, UEFI is inadequately-specified, as of yet poorly-debugged, and is not yet really ready for prime time. It works with single-boot Windows systems, although it is hard to do things like change boot settings, and it's relatively easy to get an unbootable system if you, for instance, copy a working HDD install onto an SSD. Fixing this is a lot of work and the automated tools in Win10 don't work, which indicates to me that Microsoft don't fully understand this either. There is no longer any consistent way to get into the firmware setup program, into Windows' Safe Mode etc. Many systems intentionally conceal all this to make a smoother customer experience. You need to do things like set options in a Windows control panel to display the startup options when the system is next booted. If you can't load Windows, tough. If you can but it fails to complete boot, tough. If you don't have a Windows system, tough. I regard this as broken, badly broken; the industry apparently does not.

It is important to note, not as paranoia but as a simple statement of fact, that enterprise OS vendors focus on servers, and servers typically do not dual-boot, at all, ever. Most, in fact, run inside dedicated VMs, so they don't even interact with other OSes at all. Therefore all this stuff is poorly-debugged and little-tested.

It is also significant, I think, in paranoid mode, that while Microsoft says it loves Linux and FOSS now, this is marketing guff. No significant parts of Windows have been made FOSS. Windows will not dual-boot with any FOSS OS; in fact it disables other bootloaders. It is entirely the FOSS OS's job. Windows can't mount, read, or write Linux filesystems, or even identify them. MS only likes Linux if it's running safely inside a Windows VM.

This, for me, falsifies the claim that MS <3 FOSS. They talk the talk but do not walk the walk. It is their old embrace and extend tactic once again.

As such, the fact that UEFI works so badly with non-MS OSes seems likely to be quite intentional to me, and that it only cooperates with big enterprise server OS vendors. The situation is difficult for small FOSS players and not materially improving. 

The first computer I owned was a Sinclair ZX Spectrum, and I retain a lot of fondness for these tiny, cheap, severely-compromised machines. I just backed the ZX Spectrum Next kickstarter, for instance.

But after I left university and got a job, I bought myself my first "proper" computer: an Acorn Archimedes. The Archie remains one of the most beautiful computers [PDF] to use and to program I've ever known. This was the machine for which Acorn developed the original ARM chip. Acorn also had am ambitious project to develop a new, multitasking, better-than-Unix OS for it, written in Modula-2 and called ARX. It never shipped, and instead, some engineers from Acorn's in-house AcornSoft publishing house did an inspired job of updating the BBC Micro OS to run on the new ARM hardware. The result was called Arthur. Version 2 was renamed RISC OS [PDF].

(Incidentally, Dick Pountain's wonderful articles about the Archie are why I bought one and why I'm here today. Some years later, I was lucky enough to work with him on PC Pro magazine and we're still occasionally in touch. A great man and a wonderful writer.)

Seven or eight years ago on a biker mailing list, Ixion, I mentioned RISC OS as something interesting to do with a Raspberry Pi, and a chap replied "a friend of mine wrote that!" Some time later, that passing comment led to me facilitating one of my favourite talks I ever attended at the RISC OS User Group of London. The account is well worth a read for the historical context.

(Commodore had a similar problem: the fancy Commodore Amiga Operating System, CAOS, was never finished, and some engineers hastily assembled a replacement around the TRIPOS research OS. That's what became AmigaOS.)

Today, RISC OS runs on a variety of mostly small and inexpensive ARM single-board computers: the Raspberry Pi, the BeagleBoard, the (rather expensive) Titanium, the PineBook and others. New users are discovering this tiny, fast, elegant little OS and becoming enthusiastic about it.

And that's let to two different but cooperating initiatives that hope to modernise and update this venerable OS. One is backed by a new British company, RISC OS Developments, who have started with a new and improved distribution of the Raspberry Pi version called RISC OS Direct. I have it running on a Rasπ 3B+ and it's really rather nice.

The other is a German project called RISC OS Cloverleaf.

What I am hoping to do here is to try to give a reality check on some of the more ambitious goals for the original native ARM OS, which remains one of my personal favourites to this day.

Even back in 1987, RISC OS was not an ambitious project. At heart, it vaguely resembles Windows 3 on top of MS-DOS: underneath, there is a single-tasking, single-user, text-mode OS built to an early-1980s design, and layered on top of that, a graphical desktop which can cooperatively multitask graphical apps -- although it can also pre-emptively multitask old text-mode programs.

Cooperative multitasking is long gone from mainstream OSes now. What it means is that programs must voluntarily surrender control to the OS, which then runs the next app for a moment, then when that app gives up control of the computer, a third, a fourth and so on. It has one partial advantage: it's a fairly lightweight, simple system. It doesn't need much hardware assistance from the CPU to work well.

But the crucial weakness is in the word "cooperative": it depends on all the programs being good citizens and behaving themselves. If one app grabs control of the computer and doesn't let go, there's nothing the OS can do. Good for games and for media playback -- unless you want to do something else at the same time, in which case, tough luck -- but bad news if an app does something demanding, like rendering a complex model or applying a big filter or something. You can't switch away and get on with anything else; you just have to wait and hope the operation finishes and doesn't run out of memory, or fill up the hard disk, or anything. Because if that one app crashes, then the whole computer crashes, too, and you'll lose all your work in all your apps.

Classic MacOS worked a bit like this, too. There are good reasons why everyone moved over to Windows 95 (or Windows NT if they could afford a really high-end PC) -- because those OSes used the 32-bit Intel chips' hardware memory protection facilities to isolate programs from one another in memory. If one crashed, there was a chance you could close down the offending program and save your work in everything else.

Unlike under MacOS 7, 8 or 9, or under RISC OS. Which is why Acorn and Apple started to go into steep decline after 1995. For most people, reliability and robustness are worth an inferior user experience and a bit of sluggishness. Nobody missed Windows 3.

Apple tried to write something better, but failed, and ended up buying NeXT Computer in 1996 for its Unix-based NeXTstep OS. Microsoft already had an escape plan -- to replace its DOS-based Windows 9x and get everyone using a newer, NT-based OS.

Acorn didn't. It was working on another ill-fated all-singing, all-dancing replacement OS, Galileo, but like ARX, it was too ambitious and was never finished. I've speculated about what might have happened if Acorn did a deal with Be for BeOS on this blog before, but it would never have happened while Acorn was dreaming of Galileo.

So Acorn kept working on RISC OS alongside its next-gen RISC PC, codenamed Phoebe: a machine with PCI slots and the ability to take two CPUs -- not that RISC OS could use more than one. It added support for larger hard disks, it built-in video encoding and decoding and some other nice features, but it was an incremental improvement at best.

Meanwhile, RISC OS had found another, but equally doomed, niche: the ill-fated Network Computer initiative. NCs were an idea before their time: thin, lightweight, simple computers with no hard disk, but always-on internet access. Programs wouldn't -- couldn't -- get installed locally: they'd just load over the Internet. (Something like a ChromeBook with web apps, 20 years later, but with standalone programs.) The Java cross-platform language was ideal for this. For this, Acorn licenced RISC OS to Pace, a UK company that made satellite and cable-TV set-top boxes.

Acorn's NC was one of the most complete and functional, although other companies tried, including DEC, Sun and Corel. The Acorn NC ran NCOS, based on, but incompatible with, RISC OS. Sadly, the NC idea was ahead of its time -- this was before broadband internet was common, and it just wasn't viable on dial-up.

Acorn finally acknowledged reality and shut down its workstation division in 1998, cancelling the Phoebe computer after production of the cases had begun. Its ARM division went on to become huge, and the other bits were sold off and disappeared. The unfinished RISC OS 4 was sold off to a company called RISC OS Ltd. (ROL), who finished it and sold it as an upgrade for existing Acorn owners. Today, it's owned by 3QD, the company behind the commercial Virtual Acorn emulator.

A different company, Castle Technology, continued making and selling some old Acorn models, until 2002 when it surprised the RISC OS world with a completely new machine: the Iyonix. It had proved impossible to make new ARM RISC OS machines, because RISC OS ran in 26-bit mode, and modern ARM chips no longer supported this. Everyone had forgotten the Pace NC effort, but Castle licenced Pace's fork of RISC OS and used it to create a new, 32-bit version for a 600MHz Intel ARM chip. It couldn't directly run old 26-bit apps, but it was quite easy to rewrite them for the new, 32-bit OS.

The RISC OS market began to flourish again in a modest way, selling fast, modern RISC OS machines to old RISC OS enthusiasts. Some companies still used RISC OS as well, and rumour said that a large ongoing order for thousands of units from a secret buyer is what made this worthwhile for Castle.

ROL, meantime, was very unhappy. It thought it had exclusive rights to RISC OS, because everyone had forgotten that Pace had a license too. I attempted to interview its proprietor, Paul Middleton, but he was not interested in cooperating.

Meantime, RISC OS Ltd continued modernising and improving the 26-bit RISC-OS-4-based branch of the family, and selling upgrades to owners of old Acorn machines.

So by early in the 21st century, there were two separate forks of RISC OS:

• ROL's edition, derived from Acorn's unfinished RISC OS 4, marketed as Select, Adjust and finally "RISC OS SIX", running on 26-bit machines, with a lot of work done on modularising the codebase and adding a Hardware Abstraction Layer to make it easier to move to different hardware. This is what you get with VirtualAcorn.


• And Castle's edition, marketed as RISC OS 5, for modern 32-bit-only ARM computers, based on Pace's branch as used to create NCOS. This is the basis of RISC OS Open and thus RISC OS Direct.

When Castle was winding down its operations selling ARM hardware, it shared up the source code to RISC OS 5 in the form of RISC OS Open (ROOL). It wasn't open source -- if you made improvements, you had to give them back to Castle Technologies. However, this caused RISC OS development to speed up a little, and let to the version that runs on other ARM-based computers, such as the Raspberry Pi and BeagleBoard.

Both are still the same OS, though, with the same cooperative multitasking model. RISC OS does not have the features that make 1990s 32-bit OSes (such as OS/2 2, Windows NT, Apple Mac OS X, or the multiple competing varieties of Unix) more robust and stable: hardware-assisted memory management and memory protection, pre-emptive multitasking, support for multiple CPUs in one machine, and so on.

There are lightweight, simpler OSes that have these features -- the network-centric successor to Unix, called Plan 9, and its processor-independent successor, Inferno; the open-source Unix-like microkernel OS, Minix 3; the commercial microkernel OS, QNX, which was nearly the basis for a next-generation Amiga and was the basis of the next-generation Blackberry smartphones; the open-source successor to BeOS, Haiku; Pascal creator Niklaus Wirth's final project, Oberon, and its multiprocessor-capable successor A2/Bluebottle -- which ironically is pretty much exactly what Acorn ARX set out to be.

In recent years, RISC OS has gained some more minor modern features. It can talk to USB devices. It speaks Internet protocol and can connect to the Web. (But there's no free Wifi stack, so you need to use a cable. It can't talk Bluetooth, either.) It can handle up to 2GB of memory -- four thousand times more than my first Archimedes.

Some particular versions or products have had other niceties. The proprietary Geminus allowed you to use multiple monitors at once. Aemulor allows 32-bit computers to run some 26-bit apps. The Viewfinder add-on adaptor allowed RISC PCs to use ATI AGP graphics cards from PCs, with graphics acceleration. The inexpensive PineBook laptop has Wifi support under RISC OS.

But these are small things. Overcoming the limitations of RISC OS would be a lot more difficult. For instance, Niall Douglas implemented a pre-emptive multitasking system for RISC OS. As the module that implements cooperative multitasking is called the WIMP, he called his Wimp2. It's still out there, but it has drawbacks -- the issues are discussed here.

And the big thing that RISC OS has is legacy. It has some 35 years of history, meaning many thousands of loyal users, and hundreds of applications, including productivity apps, scientific, educational and artistic tools, internet tools, games, and more.

Sibelius, generally regarded as the best tool in the world for scoring and editing sheet music, started out as a RISC OS app.

People have a lot of investment in RISC OS. If you have using a RISC OS app for three decades to manage your email, or build 3D models, or write or draw or paint or edit photos, or you've been developing your own software in BBC BASIC -- well, that means you're probably quite old by now, and you probably don't want to change.

There are enough such users to keep paying for RISC OS to keep a small market going, offering incremental improvements.

But while if someone can raise the money to pay the programmers, adding wifi, or Bluetooth, or multi-monitor graphical acceleration, or hardware-accelerated video encoding or decoding, would be relatively easy to do, it still leaves you with a 1980s OS design:

• No pre-emptive multitasking


• No memory protection or hardware-assisted memory management


• No multi-threading or multiple CPU support


• No virtual memory, although that's less important as a £50 computer now has four times more RAM than RISC OS can support.

Small, fast, pleasant to use -- but with a list of disadvantages to match:

• Unable to take full advantage of modern hardware.


• Unreliable -- especially under heavy load.


• Unable to scale up to more processors or more memory.

The problem is the same one that Commodore and Atari faced in the 1990s. To make a small, fast OS for an inexpensive computer which doesn't have much memory, no hard disk, a single CPU with no fancy features, then you have to do a lot of low-level work, close to the metal. You need to write a closely-integrated piece of software, much of it in assembly language, which is tightly coupled to the hardware it was built for.

The result is something way smaller and faster than big lumbering modular PC operating systems which have to work with a huge variety of hardware from hundreds of different companies -- so the OS is not closely integrated with the hardware. But conversely, this design has advantages, too: because it is adaptable to new devices, as the hardware improves, the OS can improve.

So when you ran Windows 3 on a 386 PC with 4MB of RAM -- a big deal in 1990! -- it could use the hardware 16-bit virtualisation of the 386 processor to pretend to be 2, 3 or 4 separate DOS PCs at the same time -- so you could keep your DOS apps when you moved to Windows. They didn't look or feel like Windows apps, but you already knew how to use them and you could still access all your data and continue to work with it.

Then when you got a 486 in 1995 (or a Pentium with Windows NT if you were rich) it could pretend to be multiple 386 computers running separate copies of 16-bit Windows as well as still running those DOS apps. And it could dial into the Internet using new 32-bit apps, too. By the turn of the century, it could use broadband -- the apps didn't know any difference, as it was all virtualised. Everything just went faster.

Six or seven years after that, your PC could have multiple cores, but multiple 32-bit apps could be divided up and run across two or even four cores, each one at full speed, as if it had the computer to itself. Then a few years later, you could get a new 64-bit PC with 64-bit Windows, which could still pretend to be a 32-bit PC for 32-bit apps.

When these things started to appear in the 1990s, the smaller OSes that were more tightly-integrated with their hardware couldn't be adapted so easily when that hardware changed. When more capable 68000-series processors appeared, such as the 68030 with built-in memory management, Atari's TOS, Commodore's AmigaOS and Apple's MacOS couldn't use it. They could only use the new CPU as a faster 68000.

This is the trap that RISC OS is in. Amazingly, by being a small fish in a very small pond -- and thanks to Castle's mysterious one big customer -- it has survived into its fourth decade. The only other end-user OS to survive since then has been NeXTstep, or macOS as it's now called, and it's had a total facelift and does not resemble its 1980s incarnation at all: a 32-bit 68030 OS became a PowerPC OS, which became an Intel 32-bit x86 OS, which became a 64-bit x86 OS and will soon be a 64-bit ARM OS. No 1980s or 1990s NeXTstep software can run on macOS today.

When ARM chips went 32-bit only, RISC OS needed an extensive rewrite, and all the 26-bit apps stopped working. Now, ARM chips are 64-bit, and soon, the high-end models will drop 32-bit support altogether.

As Wimp2 showed, if RISC OS's multitasking module was replaced with a pre-emptive one, a lot of existing apps would stop working.

AmigaOS is now owned by a company called Hyperion, who have ported it to PowerPC -- although there aren't many PowerPC chips around any more.

It's too late for virtual memory, and we don't really need it any more -- but the programming methods that allow virtual memory, letting programs spill over onto disk if the OS runs low on memory, are the same as those that enforce the protection of each program's RAM from all other programs.

Just like Apple did in the late 1990s, Hyperion have discovered that if they rewrite their OS to take advantage of PowerPC chips' hardware memory-protection, then it breaks all the existing apps whose programmers assumed that they could just read and write whatever memory they wanted. That's how Amiga apps communicate with the OS -- it's what made AmigaOS so small and fast. There are no barriers between programs -- so when one program crashes, they all crash.

The same applies to RISC OS -- although it does some clever trickery to hide programs' memory from each other, they can all see the memory that belongs to the OS itself. Change that, and all existing programs stop working.

To make RISC OS able to take advantage of multiple processors, the core OS itself needs an extensive rewrite to allow all its modules to be re-entrant -- that is, for different apps running on different cores to be able to call the same OS modules at the same time and for it to work. The problem is that the design of the RISC OS kernel dates back to about 1981 and a single eight-bit 6502 processor. The assumption that there's only one processor doing one thing at a time is deeply written into it.

That can be changed, certainly -- but it's a lot of work, because the original design never allowed for this. And once again, all existing programs will have to be rewritten to work with the new design.

Linux, to pick an example, focuses on source code compatibility. Since it's open source, and all its apps are open source, then if you get a new CPU, you just recompile all your code for the new chip. Linux on a PowerPC computer can't run x86 software, and Linux on an ARM computer can't run PowerPC software. And Linux on a 64-bit x86 computer doesn't natively support 32-bit software, although the support can be added. If you try to run a commercial, proprietary, closed-source Linux program from 15 or 20 years ago on a modern Linux, it won't even install and definitely won't function -- because all the supporting libraries and modules have slowly changed over that time.

Windows does this very well, because Microsoft have spend tens of billions of dollars on tens of thousands of programmers, writing emulation layers to run 16-bit code on 32-bit Windows, and 32-bit code on 64-bit Windows. Windows embeds layers of virtualisation to ensure that as much old code as possible will still work -- only when 64-bit Vista arrived in 2006 did Windows finally drop support for DOS programs from the early 1980s. Today, Windows on ARM computers emulates an x86 chip so that PC programs will still work.

In contrast, every few versions of macOS, Apple removes any superseded code. The first x86 version of what was then called Mac OS X was 10.4, which was also the last version that ran Classic MacOS apps. By version 10.6, OS X no longer ran on PowerPC Macs, and OS X 10.7 no longer ran PowerPC apps. OS X 10.8 only ran on 64-bit Macs, and 10.15 won't run 32-bit apps.

This allows Apple to keep the OS relatively small and manageable, whereas Microsoft is struggling to maintain the vast Windows codebase. When Windows 10 came out, it announced that 10 was the last-ever major new version of Windows.

It would be possible to rewrite RISC OS to give it pre-emptive multitasking -- but either all existing apps would need to be rewritten, or it would need to incorporate some kind of emulator, like Aemulor, to run old apps on the new OS.

Pre-emptive multitasking -- which is a little slower -- would make multi-threading a little easier, which in turn would allow multi-core support. But that would need existing apps to be rewritten to use multiple threads, which allows them to use more than one CPU core at once. Old apps might still work, but not get any faster -- you could just run as many as you have CPU cores side-by-side with only a small drop in speed.

Then a rewrite of RISC OS for 64-bit ARM chips would require a 32-bit emulation layer for old apps to run -- and very slowly at that, when ARM chips no longer execute 32-bit code directly. A software emulation of 32-bit ARM would be needed, with perhaps a 10x performance drop.

All this, on a codebase that was never intended to allow such things, and done by a tiny crew of volunteers. It will take many years. Each new version will inevitably lose some older software which will stop working. And each year, some of those old enthusiasts who are willing to spend money on it will die. I got my first RISC OS machine in 1989, when I was 21. I'm 52 now. People who came across from the previous generation of Acorn computers, the BBC Micro, are often in their sixties.

Once the older users retire, who will spend money on this? Why would you, when you can use Linux, which does far more and is free. Yes, it's slower and it needs a lot more memory -- but my main laptop is from 2011, cost me £129 second-hand in 2017, and is fast and reliable in use.

To quote an old joke:
"A traveller stops to ask a farmer the way to a small village. The farmer thinks for a while and then says "If you want to go there I would not start from here."

There are alternative approaches. Linux is one. There's already a RISC OS-like desktop for Linux: it's called ROX Desktop, and it's very small and fast. It needs a bit of an update, but nothing huge.

ROX has its own system for single-file applications, like RISC OS's !Apps, called 0install -- but this never caught on. However, there are others -- my personal favourite is called AppImage, but there are also Snap apps and Flatpak. Supporting all of them is perfectly doable.

There is also an incomplete tool for running RISC OS apps on Linux, called ROLF... and a project to run RISC OS itself as an app under Linux.

Not all Linux distributions have the complicated Linux directory layout -- one of my favourites is GoboLinux, which has a much simpler, Mac-like layout.

It would be possible to put together a Linux distribution for ARM computers which looked and worked like RISC OS, had a simple directory layout like RISC OS, including applications packaged as single files, and which, with some work, could run existing RISC OS apps.

No, it wouldn't be small and fast like RISC OS -- it would be nearly as big and slow as any other Linux distro, just much more familiar for RISC OS users. This is apparently good enough for all the many customers of Virtual Acorn, who run RISC OS on top of Windows.

But it would be a lot easier to do than the massive rewrite of RISC OS needed to bring it up to par with other 21st century OSes -- and which would result in a bigger, slower, more complex RISC OS anyway.

The other approach would be to ignore Linux and start over with a clean sheet. Adopt an existing open-source operating system, modify it to look and work more like RISC OS, and write some kind of emulator for existing applications.

My personal preference would be A2/Bluebottle, which is the step-child of what Acorn originally wanted as the OS for the Archimedes. It would need a considerable amount of work, but Professor Wirth designed the system to be tiny, simple and easy to understand. It's written in a language that resembles Delphi. It's still used for teaching students at ETH Zürich, and is very highly-regarded [PDF] in academic circles.

It would be a big job -- but not as big a job as rewriting RISC OS...

[Repurposed from a Reddit comment here.]

Non everyone hates "jaggies" with a burning passion, or loves anti-aliasing. Well-designed GUIs for relatively low-res displays, even monochrome ones, can and did look great, and arguably, the fact that modern GUIs tend to need antialiasing, truecolour, transparency, scalable vector icons and so on is merely a sign that the former attention to detail in design has been lost.

Some of us miss the way 1990s desktops look.

Different display standards have different needs for good reasons.

Moving images are different to static ones. High colour depth has different needs from intermediate colour depth which has different needs to low colour depth -- my first computer had 8 colours, total, plus a Bright setting, and a resolution of 256*192 pixels.

The garish colour scheme of the original AmigaOS 1.x desktop -- white, blue and orange -- was chosen to deliver high contrast on an NTSC TV set, so it would be legible, because most owners of the early Amiga computers couldn't afford monitors.

The original Mac had 384*256 pixels, in monochrome, so every pixel in every icon was hand-picked and positioned for clarity. In situations like these, you very definitely do not want anti-aliasing even if it's possible (which of course it is not, in monochrome).

But by MacOS 8 and 9, most Macs could display 16-bit or 24-bit colour, so the desktop used it if you had it -- within the constraints of the same OS design, because the same OS could still run on machines with a mono screen.

The rounded rectangles of the original classic MacOS design were a feature that Steve Jobs insisted upon -- they were a hallmark of its design.

Look through a gallery of OS GUI design over the ages and see how it developed:

Compare and contrast the frankly clunky visual design of Smalltalk, the environment that inspired Apple's Lisa and Mac, with Susan Kare's hand-drawn mono icons. Each one is a miniature masterpiece, and she is justly famed for them.

The elegant pinstripes and bevels of Apple's Platinum theme in MacOS 8 and 9 are widely held to be the acme of traditional GUI design, from an age before flat screens, before graphics accelerators, before universal "true colour" on multi-megapixel hi-res screens, let alone HD or 4K screens.

Personally, I found the clear crisp greenscreen fonts of early IBM MDA screens, and even DEC VT-series terminals, on long-persistence phosphors for less flicker, more restful on my eyes than the glaring white Retina screen of the 27" iMac I'm looking at right now.

I gazed at those for 8 hours plus a day without eyestrain.

Colour screens were a step backwards from those for text-editing or coding.

So, no. Not everyone hates jaggies as much as you do. You will find plenty of people desperately trying to get non-anti-aliased fonts for programming under Linux, e.g.

https://www.reddit.com/r/unixporn/comments/49jjky/how_do_i_get_noantialiased_fonts_on_my_terminal/

https://superuser.com/questions/130267/how-can-i-turn-off-font-antialiasing-only-for-gnome-terminal-but-not-for-other

https://geoff.greer.fm/2017/06/14/gnome-terminal-antialiasing-saga/

The person to whom I was replying said that "everyone hates jaggies" and "everyone prefers a smooth, anti-aliased display."

For clarity: while I am disagreeing with this, I am not saying it is only them. I am merely saying that not everyone likes or wants anti-aliasing. Some of us like clear, crisp, sharp graphics or text. I like CRTs. I like monochrome screens, especially monochrome CRTs. I love using classic Macs partly for this reason. Some just want to turn their 2560*1080 TFT into a giant tiled session of Vim and shell instances, and want it as crisp as can be.