“EMMs (Extender Memory Managers) for 386 systems to emulate Expanded Memory without the real memory card Hardware also adds overhead.”

I remember not loading EMM386 unless absolutely necessary on my 386 (and later 486) since it would cause visible slowdowns in many games as well as some other programs that required a powerful CPU. I had a config.sys boot-menu with options for XMS, XMS+EMM386 NOEMS (for Upper-Memory-Block), and XMS+EMS(+UMB, of course)

Speaking of memory, many programs were only using base memory and temporay files. Using a disk caching program was almost the best use for XMS at the time 🙂

As you say, direct hardware access really was important. Also, most programs already had (or had access to) libraries for using all the memory (e.g. DOS4GW). However, there were applications (especially smaller/cheaper ones) that were built to only use the “base memory” in order to work on all “PC Compatibles”. For most vedors it was quite important not to reduce their market share with hardware requirements unless absolutely needed, so, until the beginning of the 90s programs to *require* a 386 CPU were few and far between.

As an example, the first Autodesk Animator (released in 1989 on 2 720k diskettes BTW) only required a 286 computer with 1MB of RAM (and VGA, of course). Windows 3.0 was usable on XT-class machines.

And then, there’s the money problem. Before Linux (and a while after), the price gap between DOS and Unix was about an order of magnitude (in the ’90s SCO Unix was priced around a thousand USD).

I now realize that there is a similarity between DOS and UNIX. Both were good enough (not great) for their time and place, and both were free or dirt cheap at the time. And thus acquired world domination. Of course, one difference is that Unix kept evolving since its introduction, while DOS didn’t change much 🙂

By the way, I assume you read The Cathedral and the Bazaar. If not, I think you would enjoy it.

I did considered than something UNIX based would be slower than DOS and thus a hard sell (Actually, I had a single sentence saying that in the PC Evolution article, “In addition to that, Xenix itself also required more resources than PC DOS, so users that didn’t made use of any of Xenix advanced features would certainly have their applications running slower than on PC DOS due to the higher OS overhead for no tangible benefit”). Heck, instruction execution latency on the 286 was slower on Protected Mode than Real Mode, so it was a bad idea to use it if you didn’t needed Virtual Memory/MMU or > 1 MiB addressing. However, for how much that would hold true is questionable…

Expanded Memory/EMS added an API for Bank Switching. This adds overhead (Do note than it was the most viable way to add more RAM to a 8088 PC class system, so maybe it would have happened anyways)
A20 Handlers to access the 64 KiB HMA, which DOS could use for itself, also adds overhead due to switching A20 Gate state latency
The XMS API to provide a means to move data back and forth from the Conventional Memory to the Extended Memory also adds a substantial overhead if using a 286 class system (Before Microsoft began to cheat by using 286 LOADALL in HIMEM.SYS in order to avoid entering and exiting Protected Mode)
EMMs (Extender Memory Managers) for 386 systems to emulate Expanded Memory without the real memory card Hardware also adds overhead. I think that a guy that tested Chipset-based EMM emulation vs a 386 EMM said that the difference in gaming was quite major

While UNIX would have begun slower, chances are that as soon as you broke the 640 KiB RAM barrier, these overheads would have begin to pick up. And yeah, there is also the matter about direct Hardware access for things like graphics, which in DOS was a free-for-all. Not sure if UNIX would be so generous about letting Software abuse certain resources.

UEFI is an overengineered specification, like ACPI. I tend to like overengineered stuff. The problem is that besides having overengineered specifications, vendors usually decide to implement them improperly, and you have a whole lot of UEFI/ACPI bugs that keep track of because there is a big rule book yet everyone still has its own flavour when it comes to implement it.
And no way that I consider than the BIOS was nice. Yeah, the basic stuff was far simpler, but it had a completely chaotic evolution with a lot of propietary extensions or interfaces that went nowhere, and just some that became popular achieved de facto standard status before being formally standarized (Which I think was the case with the famous e820 Memory Map function, which was first implemented by Phoenix BIOS before it got adopted by almost everyone with different behavior, then formally standarized: http://www.ctyme.com/intr/rb-1741.htm). You could rely only on the basic stuff to work, everything else I suppose that would be like UNIX before POSIX.

You raise valid points regarding DOS ubiquity but I would like to add something. Even by the time of the 386 and Linux, in most use cases DOS was the preferred option, based -in part- on its simplicity and in part on all the tools already available (some ported from CP/M).

Avery Pennarun has a good article regarding Internet evolution here: https://tailscale.com/blog/two-internets-both-flakey/
I think what he says about IPv4 and the “first edition Internet” could equally be said about DOS (and x86 architecture).

Around 1995, one of the few companies in Romania to have a LAN changed from a custom made Xenix based accounting software (with multi-user support) to mostly DOS based software (Novell Netware server, diskless PCs as workstations and dBASE-IV). The new software (also multi-user) was perceived to be way faster and more user-friendly than the old Xenix based one. (As an aside, when later switching to Windows-based software with GUI, the GUI software was perceived as being worse)

I guess my point is that, especially with the computing power available back then, the Unix level of abstraction was useful for portability but taking its toll on execution speed. E.g. text interfaces for DOS programs were mainly using some simple functions (put_char, put_string, put_attribute) that operated more or less directly on video memory, maybe taking advantage of the multiple pages of video memory that even CGA had. On Unix, one would have to use the curses library that would use back-buffers (in system RAM), then emit the strings and escape-codes according to terminfo database (in system RAM), which would then be interpreted by the kernel video driver or the terminal and finally that would then put chars in the video memory. When the hardware is slow, all these intermediate steps make the interface feel sluggish.

In fact, even nowadays there are some DOS programs that “feel” very responsive, even on those old computers. E.g. Borland’s Turbo C IDE is perfectly usable even on an XT machine. The compilation is slow, but editing, switching between (text-mode) editor windows, menus, help etc. is nearly-instant. The same with debugging – the integrated debugger was way more user-friendly than adb (or later gdb). Another advantage was the ease of getting some nice graphics done. The BGI (Borland Graphics Interface) library was easy to learn and use, as opposed to the huge complexity of X Window; not to mention that most of Unix world was text based back then.

That reminds me: what surprised me about QNX was how quickly the compiler worked. Back in the 90s I switched from C to Pascal simply because of compiler speed (I returned to C some years later). For programs of similar complexity, a Pascal compilation would take a few seconds, as opposed to C taking around 10 times as much.

As an aside, your idea about Coreboot reminded me of something Linus said some years ago wrt EFI:
So EFI has this cool shell, a loadable driver framework, and other nice
features. Where “nice” obviously means “much more complex than the simple
things they designed in the late seventies back when people were stupid
and just wanted things to work”.
from: https://yarchive.net/comp/linux/efi.html
I love his definition of nice!