The headlined article credits the Amiga ROM Kernel Manual: Exec. If you read that book, you'll find that there is indeed a user-mode/supervisor-mode dividing l

The headlined article credits the Amiga ROM Kernel Manual: Exec. If you read that book, you'll find that there is indeed a user-mode/supervisor-mode dividing line. What you mean is that TRAP instructions aren't used as the system call interface, which isn't the same thing as not actually having a dividing line. The headlined article does in fact make this very point, however. No, Exec was not an example of the micro-kernel paradigm. There was no inter-task memory protection, one of the foundations of the micro-kernel model, underpinning the idea that a bug in one part of the system cannot overwrite other parts of the system, which is clearly not the case for Exec. Again, the headlined article actually points out this lack. Exec was a fairly clean design, with good modular cohesion. But the 1990s thinking evident in the article is to try to contrast it with OS/2 and others, along with the silly "Whatever my operating system doesn't do is obviously something that no-one needs on a personal computer." stuff, instead of recognizing (with 5 years of hindsight even at the time) that Exec was yet another case study of the same design changes happening in multiple systems. DOS+Windows 2.0 in 1987 and OS/2 1.0 in 1986 also exemplified the notions of user-mode-callable function libraries, directly callable by languages such as C and Pascal (and MS Fortran), for the system API, instead of special machine instructions as in MS/PC/DR-DOS, that were left to the runtime library implementors, or even to the applications programmers, to wrap in library functions. Those systems also exemplified the idea that some of this library code (such as the MSG library on OS/2 for example, which is implementable entirely on top of the Control Program API) was actually a user-mode layer on top of the kernel API and didn't need to be specifically kernel code itself; something that the headlined article tries to make out to be a contrast with other systems. Indeed, at the time that the headlined article was published in 1991, Windows NT had already been implemented with an Object Manager as its name-to-handle mechanism. And the fact that it might be useful to have and to expose the common library functions that the system uses for manipulating its data structures, as Exec did for its linked lists, is evident in the existence of all of the RtlXXX() functions in the Native API. These ideas weren't all necessarily new in the 1980s, as the Big Iron world had been there before as had the Unix world in the 1970s. What was happening was that they were catching on. Ironically, Linux took a step in the reverse direction when it came along, as its kernel API is (with a small exception) once again officially the special machine instructions rather than a pre-supplied library of mid-/high-level language callable functions. There are cases over the years, especially for languages other than C and C++, where if there had been a linux-system.so or some such, not tightly coupled to the (at least two) C runtime libraries, life would have been a lot easier.