The Apple Newton used a microkernel inspired by Mach, with a custom MMU that reduced the cost of context switching.

It was . . . okay. The number of cycles it actually took to do a lightweight message pass was dismaying, though. The newt would have benefited from a less partitioned design for the underlying page and storage management.

I used another microkernel OS on a set-top box. Now that was a misery, but one I attribute more to the uncaring attitude of the company that wrote the STB's firmware than any inherent problem with their OS (a decade later, critical and customer-affecting race conditions are still present in their code). To be honest, their OS didn't help.

I don't think microkernels are bad. Making bad choices about performance that affect performance, battery life and other things that customers care about is bad, and you might have to break some abstractions in your microkernel to address those.

> Now that was a misery, but one I attribute more to the uncaring attitude of the company that wrote the STB's firmware than any inherent problem with their OS (a decade later, critical and customer-affecting race conditions are still present in their code). To be honest, their OS didn't help.

Hmmm STMicro-based? :)

68K, actually, and MIPS. Different platforms, same damned OS bugs. Let's hear it for portability :-)

Didn't the Microsoft NT project start off as a micro kernel and then changed course to a hybrid model ?

https://en.wikipedia.org/wiki/Hybrid_kernel

NT was never a microkernel. It has an intenral microkernel-like design, though; it's divided into cleanly separated modules, and modules may only communicate using a special IPC mechanism. But like OS X, the classic pieces (file systems, graphics, device drivers) run in kernel mode.

Originally, graphics ran in user mode, but Windows 2000 moved it back into kernel mode for performance reasons. Vista got a new device driver model and a new graphics driver model (WDDM), which has a way for graphics to run partly in user mode. Vista and later also support user-mode device drivers.

Windows NT 3.1 was based on Microsoft OS/2 NT 3.0, it was originally Microsoft's version of OS/2 with the Windows 3>X GUI added to it instead of IBM's Presentation Manager.

The NT Kernel and OS was designed to run DOS, POSIX, OS/2 1.X CLI apps (But not GUI) and 16 bit Windows and 32 bit Windows apps. Later on OS/2 and POSIX support got dropped.

Microsoft OS/2 NT 3.0 was a rewrite of OS/2 for 32 bit systems, before that OS/2 was on 16 bit systems with 1.X and IBM and Microsoft fought over 2.0 standards, and Microsoft stopped support for OS/2 and focused on Windows instead. Then renamed their OS/2 to NT for New Technologies.

The Interesting thing about Windows NT was that Microsoft had plans to port it to different processors and eventually dropped those plans and stuck with X86 processors instead.

https://en.wikipedia.org/wiki/Windows_NT

It was designed as a modified microkernel.

> The NT Kernel and OS was designed to run DOS, POSIX, ...

What you're referring to were what the NT team called "personalities", or more formally "environment subsystems".

A subsystem was an API on top of the native NT API. Win32 was one such subsystem; users were exposed to the Win32 API, and weren't supposed to talk directly to the intentionally undocumented NT API (although some developers did reverse-engineer it eventually). POSIX and OS/2 compatibility was implemented as subsystems, but these were rarely used by anyone, and eventually removed in XP. DOS was not a subsystem, but rather its own thing.

Note that this has nothing to do with microkernels. In a microkernel architecture, things like file systems and device drivers live run as normal processes separate from the kernel. In NT, everything was in the kernel. These subsystems didn't act as part of a microkernel design.

Oh, and NT was not a rewrite of OS/2. It was written from scratch. The project was started back when Microsoft and IBM had a good relationship, and NT was originally planned to as OS/2 3.0.

> The Interesting thing about Windows NT was that Microsoft had plans to port it to different processors

The didn't plan it, they did it. I was looking after Windows NT on Alpha processors at one job. I never personally saw the NT on PowerPC or MIPS, though they did exist.

You got it wrong (your first sentence), WinNT3.1 is written from scratch by Dave Cutler and his group from 1989 to 1994. Originally there would have been a OS/2 compatible subsystem, and some ideas stem from OS/2 but NT has a lot of more similarities with VMS, the previous OS project of Mr Cutler at DEC.

as an aside, how is Mach doing these days? I suppose the most visible use is OS X and I assume Apple's engineers have evolved it greatly to keep up with the times compared with the earlier versions of OS X?

Apple's XNU is de facto monolithic in nature. It simply reuses OSF Mach primitives to build the BSD Unix layer next to it. Mach IPC is used primarily for service discovery these days, I think, what with launchd being responsible for being the bootstrap server, which maintains name-port bindings for Mach services to call into. This is a side effect of Mach port namespaces being internal to tasks, and hence not having an intrinsic arbiter. In contrast though, the Hurd decentralizes this activity by just assigning a bootstrap port for the client making the RPC call to rendezvous with the server or library in question. These days, OS X seldom uses Mach IPC directly, but rather via XPC.

Mach had a surprising resurgence in interest over NextBSD implementing a ton of compatibility layers and mangling Apple sources in a weird, misguided attempt to make FreeBSD the new OS X. We'll see how it turns out.

By way of example, you can't create a Mach task that isn't a BSD process as well: https://github.com/opensource-apple/xnu/blob/10.10/osfmk/ker...