Kernels are programs that abstract the hardware of a computer to some extent, allowing other programs to use standardised system calls (e.g. malloc) to perform hardware tasks (e.g. writing to memory, displaying text on a screen) without resorting to "special memory values" or machine-dependent hacks.

Many early operating systems functioned as kernels. But by 1985 and the release of AmigaOS, separate kernels existed (i.e. Exec). When was the first independent* kernel** created?

* Where "independent" means "able to function without, or separately from, (the rest of) an operating system".
** Where "kernel", more specifically, means "resident monitor that is callable by user programs". (Thanks Ken Gober!)

  • 2
    I'm not sure I understand your definition of "independent kernel". Do you mean something like "microkernel" (other parts of the OS are moved "outside")? Most kernels were more or less modularized, and had a scheduler and memory management routines somewhere that in principle could have worked on their own, it's just that the rest of the kernel was usually also present, because it was needed anyway and it wasn't seen as necessary to do a strict separation. Even, say, Linux today doesn't do this. – dirkt Oct 31 '16 at 6:45
  • 1
    @dirkt Linux does do this; GNU can be taken off and replaced by, say, Android, and the kernel will still work. Although I appreciate that I haven't been clear; I'll try to reword it. – wizzwizz4 Oct 31 '16 at 7:07
  • 1
    Well, for every OS you can take the programs (user and system) and replace them with different programs, if you bother to invest the additional effort to write them, while retaining the kernel. Nearly all OS had a layered design, and system programs and utilities. Maybe look at the wikipedia article for microkernel, it also mentions the RC 4000 system as ancestor of microkernels. But on early hardware, microkernels were just too expensive. – dirkt Oct 31 '16 at 8:24
  • I read the question as looking for the first operating system where one could identify separate runtime components within the operating system itself (where "operating system" is defined as the components providing the system calls — which incidentally doesn't include malloc). AmigaOS has Exec, Intuition, and AmigaDOS at least; Linux doesn't apply IMO because you can't run portions of the kernel separately (modules become part of the kernel when loaded). – Stephen Kitt Oct 31 '16 at 8:26
  • I think that if you use the term "resident monitor" rather than "kernel" this question becomes easier to answer. In particular, I think the question being asked here is "what is the first resident monitor that was callable by user programs?" – Ken Gober Oct 31 '16 at 14:11

Reading through Per Brinch Hansen's The evolution of operating systems paper, I get the impression the two main candidates for operating systems with identifiably separate kernels are

  • Dijkstra's THE multiprogramming system, started in 1965; it's a layered operating system — so you could view its layer 0 as a kernel, which is smaller than the whole operating system;
  • Hansen's own RC 4000 multiprogramming system, built in 1969; it's the first operating system designed as separate components communicating with each other (which led to what are now known as microkernels).

To answer the revised question about callable monitors, the same paper indicates that

Atlas was the first system to exploit supervisor calls known as “extracodes”:

Extracode routines form simple extensions of the basic order code, and also provide specific entry to supervisor routines.

The Atlas system here is a computer built at Manchester University in the early 1960s.

Hansen's excellent book, Classic Operating Systems, reprints papers describing all these systems (and others) in detail. Regarding the Atlas supervisor:

It becomes activated in several different ways. Firstly, it can be entered as a direct result of obeying an object program. Thus, a problem being executed calls for the supervisor whenever it requests an action that is subject to control by the supervisor, such as a request for transfer to or from peripheral equipments or the initiation of transfers between core store and magnetic drums; the supervisor is also activated when an object program requires monitoring for any reason such as exponent or division overflow, or exceeding store or time allocation.

| improve this answer | |
  • The Manchester Atlas came to my mind as well when I read the question. I think it was also pretty much the first computer with virtual memory. – JeremyP Mar 10 '17 at 14:46
  • Danish DASK used a microkernel like architecture long before anyone knew that microkernels was an option. I don't recall the exact year it was programmed, but it was during the time that memory was stored in drums. – Clearer Apr 28 '17 at 8:40
  • @Clearer that’s intriguing — could you write a little more about it, perhaps in a separate answer? – Stephen Kitt Apr 28 '17 at 9:57
  • 2
    @Clearer that matches what I’d read; the DASK was too small for an operating system (but it did have drums for storage). Check out Hansen’s memoirs, they’re an interesting read! And my answer already mentioned the RC 4000 ;-). – Stephen Kitt Apr 29 '17 at 11:13
  • 1
    @StephenKitt You did mention the RC 4000 :-) My apologies for not having paid enough attention. – Clearer Apr 29 '17 at 15:01

In the realm of microcomputers specifically, the BBC Micro of 1981 had a very sophisticated kernel in ROM for a machine of its class. There were a number of defined entry points that both language ROMs and user programs were expected to use to interface with the hardware.

Programs which relied exclusively on these interfaces could expect to run correctly on future versions of the BBC Micro and on the 6502-based incarnations of the Second Processor expansions. Much of this functionality was exposed in a programmer-friendly manner by the included version of BASIC.

For example, to draw text or graphics on the screen, you were expected to send ASCII characters, control codes and escape sequences to the VDU driver through the OSWRCH entry point at &FFEE - which was always present, even if the display memory had been remapped into the shadow bank (on the Master) or simply didn't exist in your memory space (on the Second Processor). Most graphics operations could be specified through a six-byte escape sequence corresponding to the BASIC PLOT statement. To check the colour of a pixel, or to perform a variety of auxiliary operations such as hiding the text cursor, the more general OSBYTE entry point could be used.

Some games found this interface too restrictive for adequate performance, so they had to access display memory directly. These games were consequently incompatible with the Second Processor and Shadow RAM, but could still be run on a machine so equipped, by temporarily disabling those features.

Other entry points dealt with handling a very basic command shell, filesystem operations (abstracted so that you didn't need to care about tape/floppy/HDD/network differences), and so on.

This approach to constructing an operating system was considered so successful that it was copied very closely in the subsequent Acorn Archimedes series, which introduced the now-ubiquitous ARM CPU to the world.

The story goes that a more professional microkernel-based OS (ARX) was being developed for the Archimedes, but that it was so slow and memory-hungry that it would have ruined the machine for its intended market. A large part of that was because it was written in Modula-2 via an incredibly inefficient compiler; to multiply two integers it would emit 25 ARM instructions and then call a subroutine. (The ARM2 could already do that with a single instruction.)

A demo was arranged, where the ARX devs proudly showed off sixteen clocks running on their desktop - under which load their top-of-the-line 4MB machine was swapping heavily, and each clock only updated every several seconds. The other team came in with a 256KB machine running the MOS-derived OS (Arthur), and they had sixteen clocks written in BBC BASIC, all running smoothly. ARX was cancelled the next day, and Arthur eventually became RiscOS.

Yes, that means you can still call OSWRCH and OSBYTE natively on a Raspberry Pi!

| improve this answer | |

Even an OS kernel on a some very modern system (certainly compared to what is relevant here) uses "special memory values" and machine dependent hacks to provide an ABI.


"Independence" of a kernel could likely be best measured by whether the kernel can force user programs not to interfere with it or not. This became possible as soon as memory management units or comparable hardware became available commercially - and likely operating systems quickly followed since these features - that were expensive to build in pre-single-chip-CPU systems - would be useless without an OS taking advantage of them. Architectures like IBM 370, DEC VAX and part of PDP-11 were tailored to such usage, and ran UNIX, VMS and even hypervisors in case of the 370 from the 1970s on. Home/Office grade computers only partially had that kind of feature set - the first widely used microprocessor CPUs that were capable without extra hardware were the 80286 (limited, the 80386 had far better features in that area) and Motorola 68030.


Added detail on why I said "limited" about the 80286: IIRC it was bugged and once you switched into protected/virtual memory mode (an x86 cpu always boots with these features switched off!), any attempt to return it to "real" mode (which you needed to do I/O) utterly crashed it unless you added extra hardware to guard against it (the A20 gate logic in the PC architecture).

| improve this answer | |
  • 2
    On a 286, you need real mode to call the BIOS (unless you have an ABIOS), not to do I/O. You can write a protected-mode OS on a 286 without relying on external hardware, you just can’t use real-mode code inside it (so no BIOS except during initialisation before the PM switch, and no DOS which was the real killer at the time). – Stephen Kitt Apr 28 '17 at 9:24
  • Didn't all 80286 PC's beginning with the IBM AT include the software reset ability to get the CPU back to real mode? – Brian H Apr 28 '17 at 14:17
  • @BrianH Not sure about "ability". Going by Wikipedia, the documented way of doing it was via the keyboard controller, but it turned out that triple faulting the CPU was faster. en.wikipedia.org/wiki/Triple_fault#Other_uses – a CVn Apr 28 '17 at 15:24
  • 2
    @Brian check out this question for info on the 286 and tricks to reset it to real mode. The LOADALL question is also relevant. – Stephen Kitt Apr 29 '17 at 11:18
  • Expanding on @StephenKitt's first comment above: the problem with the 80286 and switching to real mode wasn't a bug, but a lack of foresight from the design team. They simply never considered backwards compatibility; they assumed that once a processor was switched to protected mode that there'd be no reason to ever return to real mode, so didn't design in any way of doing so. Protected mode was so obviously better, that they assumed all software would be reimplemented to use it in short order and real mode would be a forgotten relic. This did of course happen, but not as quickly as they hoped. – Jules Sep 15 '17 at 15:49

Your Answer

