Hacker News Reader

> While the original post was written well before NeXTSTEP, the Mach 3.0 kernel was converted into a monolithic kernel in NeXTSTEP, which later became MacOS.

The original Tanenbaum post is dated Jan 29, 1992.

NeXTSTEP 0.8 was released in Oct 1988.

https://en.wikipedia.org/wiki/NeXTSTEP#Release_history

3.0 was not the conversion into a monolithic kernel. That was the version when it was finally a microkernel. Until that point the BSD Unix part ran in kernel space.

https://en.wikipedia.org/wiki/Mach_(kernel)

NeXTSTEP was based on this pre-Mach 3.0 architecture so it would have never met Tanenbaum's definition of a true microkernel.

> Mach received a major boost in visibility when the Open Software Foundation (OSF) announced they would be hosting future versions of OSF/1 on Mach 2.5, and were investigating Mach 3 as well. Mach 2.5 was also selected for the NeXTSTEP system and a number of commercial multiprocessor vendors.

OSF/1 was used by DEC and they rebranded it Digital Unix and then Tru64 Unix.

After NeXT was acquired by Apple they updated a lot of the OS.

https://en.wikipedia.org/wiki/XNU#Mach

> The basis of the XNU kernel is a heavily modified (hybrid) Open Software Foundation Mach kernel (OSFMK) 7.3.[3] OSFMK 7.3 is a microkernel[6] that includes applicable code from the University of Utah Mach 4 kernel and from the many Mach 3.0 variants forked from the original Carnegie Mellon University Mach 3.0 microkernel.

> The BSD code present in XNU has been most recently synchronised with that from the FreeBSD kernel. Although much of it has been significantly modified, code sharing still occurs between Apple and the FreeBSD Project as of 2009

Back in the late 2000's Apple hired some FreeBSD people to work on OS X.

Before Apple bought NeXT they were working with OSF on MkLinux which ported Linux to run on top of the Mach 3.0 microkernel.

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

> MkLinux is the first official attempt by Apple to support a free and open-source software project.[2] The work done with the Mach 3.0 kernel in MkLinux is said to have been extremely helpful in the initial porting of NeXTSTEP to the Macintosh hardware platform, which would later become macOS.

> OS X is based on the Mach 3.0 microkernel, designed by Carnegie Mellon University, and later adapted to the Power Macintosh by Apple and the Open Software Foundation Research Institute (now part of Silicomp). This was known as osfmk, and was part of MkLinux (http://www.mklinux.org). Later, this and code from OSF’s commercial development efforts were incorporated into Darwin’s kernel. Throughout this evolutionary process, the Mach APIs used in OS X diverged in many ways from the original CMU Mach 3 APIs. You may find older versions of the Mach source code interesting, both to satisfy historical curiosity and to avoid remaking mistakes made in earlier implementations.

So modern OS X is a mix of various code from multiple versions of Mach and BSD running as a hybrid kernel because as you said Mach 3.0 in true microkernel mode is slow.

I had forgotten that NeXTSTEP went back that far. Thanks for the correction.

Back in the times when I read that statement, it had immediately lost credibility to me. The argument was basically an appeal-to-authority/argument from authority. It put Tanenbaum onto the "villain" side in my mind, someone who was willing to use his position of authority to win argument rather than merits. Subsequent strings of microkernel failures proved the point. The moment Microsoft moved the graphic subsystem from user mode into the kernel mode to mitigate performance problem was the death of microkernel in Windows NT.

If the GPU driver crashes, your kernel does not crash on Windows still, right? It continued working fine on Windows 7.

It depends on what part of the GPU driver crashes. The kernel mode part crashing caused countless BSODs on Vista. The switch to WDDM was painful for Windows. Things had improved by the time Windows 7 was made.

Meanwhile they moved it back into userspace by Windows Vista, and nowadays many kernel subsystems run sandboxed by Hyper-V.

One of the reasons for the Windows 11 hardware requirements, is that nowadays Windows always runs as a guest OS.

> kernel subsystems run sandboxed by Hyper-V

What subsystems? Is there a documentation outlining that.

> nowadays Windows always runs as a guest OS

What is hypervisor in that case?

Yes,

https://learn.microsoft.com/en-us/windows-hardware/design/de...

https://learn.microsoft.com/en-us/windows/security/hardware-...

https://learn.microsoft.com/en-us/shows/ignite-2016/brk4010

Naturally it is Hyper-V, given it is a type 1 hypervisor, and Microsoft owned.

Not just that but between 3.51 and 4.0 many NT drivers like graphics were moved to ring 0, trading performance for robustness.

Do you mean robustness for performance?

Are graphics just specially handled by the kernel with how recoverable they are from crashes?

Vista moved graphics mostly out of kernel even if part of GDI was still handled internally, but essentially the driver model changed heavily and enabled restartable drivers and by Windows 7 IIRC the new model was mandatory.

In "classic" Windows and NT 4.0 - 5.2 GDI would draw directly into VRAM, possibly calling driver-specific acceleration routines. This is how infamous "ghosting" issues when parts of the system would hang happened.

With new model in Vista and later, GDI was directed at separate surface that was later used as texture and composited on screen. Some fast paths were still available to bypass that mainly for full screen apps, and were improved over time.

Windows standard file locking prevents a number of useful user experiences that file base OSes like Linux and BSD provide. Main they can update the files while open / in use.

Windows needs to stop a service or restart one to apply updates in real-time. Ever watched the screen flash during updating on Windows? That is the graphic stack restarting. This is more present on slower dual and quad core CPU systems. Microsoft needed to do this to work around how they handle files.

Windows even wired HID event processing in the OS to verify that the display manager is running. If the screen ever goes black during updates, just plug-in a keyboard and press a key to restart it.

* There are ways to prevent a file lock when open a file in Windows but it not standard and rarely used by applications, even ones written by Microsoft.

> There are ways to prevent a file lock when open a file in Windows but it not standard and rarely used by applications, even ones written by Microsoft.

mpv happily opens files while they are downloading, and they don't interfere each other.

> Windows even wired HID event processing in the OS to verify that the display manager is running. If the screen ever goes black during updates, just plug-in a keyboard and press a key to restart it.

Funny you mention this, I just have managed to set up my laptop to listen audiobooks. It was such a pain. I somehow disabled the windows lock screen, made a script that calls "nircmd monitor off" every 5 seconds. And with mpv I can listen audio in total dark, and change volume and seek position on the touchpad with gestures. It works, but it is probably cheaper to get an mp4 player with volume and jump back buttons

IIRC, didn't they move drivers back to userspace in Windows Vista or Windows 7?

No drivers are kernel modules

I believe GP misspoke or misremembered and is referring to GDI, not drivers. GDI is the original Windows 2d graphics interface, widely used for drawing UI.

For performance reasons it lived in the NT kernel, together with the Window manager (which also draws windows using GDI).

Vista moved to a compositing window manager, I believe that was the point when GDI moved fully into userspace, drawing into the new per-window texture buffer instead of directly to the screen. And of course Windows 7 introduced Direct2d as the faster replacement, but you can still use GDI today.

Maybe the reference is about the XDDM/XPDM vs. WDDM driver models, the latter has a kernel-mode and a user-mode portion: https://learn.microsoft.com/en-us/windows-hardware/drivers/d...

Yes, that's what I was thinking of.

> For performance reasons it lived in the NT kernel, together with the Window manager (which also draws windows using GDI).

Only from NT 4 onwards.

NT 3.1, 3.5 and 3.51 ran GDI in user space.

NT 4 moved it into the kernel.

NT 5 (branded "Windows 2000") and NT 5.1 (branded "Windows XP") kept it there.

It is interesting to consider is as moving back out again; it never was, in my understanding, and even today in "Windows Server Core" it still has the window system built in.

But GDI was not so much moved back out of the kernel again as replaced in NT 6 ("Vista") with the new Aero Compositor.

Yes, I remember blue screening a customers server just by opening a print queue.

All Intel CPUs have a Minix 3.0 powering their management engine.

Modern Windows 11 is even more hybrid than Windows NT planned to be, with many key subsystems running on their own sandbox managed by Hyper-V.

The management engine is an embedded processor.