Mach was developed as a replacement for the kernel in the BSD version of Unix, not requiring a new operating system to be designed around it.
These include all using the XNU operating system kernel which incorporates an earlier non-microkernel Mach as a major component.
[4][2] The developers rode bicycles to lunch through rainy Pittsburgh's mud puddles, and Tevanian joked the word "muck" could form a backronym for their Multi-User (or Multiprocessor Universal) Communication Kernel.
This contrasts with typical operating systems of the era, which require a single large program that can handle the entire task, or alternately, used files to pass data, which was resource expensive and time-consuming.
This made the pipe concept unsuitable for tasks where quick turnaround or low latency was needed, such as in most device drivers.
Unix pipes offered a conceptual system that could be used to build arbitrarily complex solutions out of small cooperating programs.
This concept greatly reduced the size of the kernel, and permitted users to experiment with different drivers simply by loading them and connecting them together at runtime.
Nevertheless, Aleph proved that the basic system was sound, and went on to demonstrate computer clustering by copying the memory over an early Ethernet interface.
Around this time a new generation of central processors (CPUs) were coming to market, offering a 32-bit address space and (initially optional) support for a memory management unit (MMU).
Such a kernel would be binary compatible with existing BSD software, making the system immediately available for everyday use while still being a useful experimental platform.
Additionally, the new kernel would be designed from the start to support multiple processor architectures, even allowing heterogeneous clusters to be constructed.
Physically copying the message would be too slow, so Mach relies on the machine's memory management unit (MMU) to quickly map the data from one program to another.
Under UNIX this problem was solved over time as programmers agreed on a number of "well known" locations in the file system to serve various duties.
Mach was initially hosted as additional code written directly into the existing 4.2BSD kernel, allowing the team to work on the system long before it was complete.
Work started with the already functional Accent IPC/port system, and moved on to the other key portions of the OS: tasks, threads, and virtual memory.
By 1987 the list included the Encore Multimax and Sequent Balance machines, testing Mach's ability to run on multiprocessor systems.
Unwieldy UNIX licensing issues also plagued researchers, so this early effort to provide a non-licensed UNIX-like system environment continued to find use, well into the further development of Mach.
A small team had built Mach and ported it to a number of platforms, including complex multiprocessor systems which were causing serious problems for older-style kernels.
Although in theory the Mach kernel would also have to be reentrant, in practice this is not an issue because its response times are so fast it can simply wait and serve requests in turn.
Mach also included a server that could forward messages not just between programs, but even over the network, which was an area of intense development in the late 1980s and early 1990s.
One was that the IPC was not the problem: there was some overhead associated with the memory mapping needed to support it, but this added only a small amount of time to making a call.
The process must then be repeated to return the results, adding up to a total of four context switches and memory mappings, plus two message verifications.
In the traditional monolithic operating systems the authors had direct experience with which parts of the kernel called which others, allowing them to fine-tune their pager to avoid paging out code that was about to be used.
Most developers instead stuck with the original POE concept of a single large server providing the operating system functionality.
This allowed them to develop in user-space and have all the advantages of the original Mach idea, and then move the debugged server into kernel-space in order to get better performance.
The Chorus microkernel made this a feature of the basic system, allowing servers to be raised into the kernel space using built-in mechanisms.
[10] In XNU, the file systems, networking stacks, and process and memory management functions are implemented in the kernel; and file system, networking, and some process and memory management functions are invoked from user mode via ordinary system calls rather than message passing;[18][19] XNU's Mach messages are used for communication between user-mode processes, and for some requests from user-mode code to the kernel and from the kernel to user-mode servers.
The rest, the majority of the actual problem, was due to the kernel performing tasks such as checking the message for port access rights.
DOS and the early Mac OS have a single large address space shared by all programs, so under these systems the mapping did not provide any benefits.
These realizations led to a series of second generation microkernels, which further reduced the complexity of the system and placed almost all functionality in the user space.