Hacker News Reader

Comment by nullindividual | Hacker News Reader

There's a large debate whether a 'hybrid' kernel is an actual thing, and/or whether NT is just a monolithic kernel.

The processes section should be expanded upon. The NT kernel doesn't execute processes, it executes _threads_. Threads can be created in a few milliseconds where as noted, processes are heavy weight; essentially the opposite of Unicies. This is a big distinction.

io_uring would be the first true non-blocking async I/O implementation on Unicies.

It should also be noted that while NT as a product is much newer than Unicies, it's history is rooted in VMS fundamentals thanks to it's core team of ex-Digital devs lead by David Cutler. This pulls back that 'feature history' by a decade or more. Still not as old as UNIX, but "old enough", one could argue.

[0] https://stackoverflow.com/questions/8768083/difference-betwe...

View on HN

Before VMS there was the family of RSX-11 operating systems which also had ASTs (now called APCs in NT parlance), IRPs, etc. Dave Cutler led the RSX-11M variant which significantly influenced VMS. The various concepts and design styles of the DEC family of operating systems that culminated in NT goes back to the 1960s.

It's sad that the article didn't mention VMS or MICA since NT didn't magically appear out of the void two years after Microsoft hired the NT team. MICA was being designed for years at DEC West as part of the PRISM project.

In many ways NT was a new, ground up implementation of “VMS NT”.

It started elegant, but all the backwards compatibility, technical debt, bad ideas, and dozens of versions later, with an endless list of perpetual features driven by whoever had a bigger wand at Microsoft at the time of their inception, takes a toll. Windows now is much more complicated than it could be.

It shocks me some apps get Windows NT4 style buttons even on Windows 11.

>In many ways NT was a new, ground up implementation of “VMS NT”.

Most definitely. There was a lot of design cleanup from VMS (e.g. fork processes -> DPCs, removing global PTEs and balance slots, etc), optimizations (converging VMS's parallel array structure of the PFN database into one), and simplification (NT's Io subsystem with the "bring your own thread" model, removing P1 space, and much more). SMP was also designed into NT from the beginning. You can start seeing the start of these ideas in the MICA design documents but their implementation in C instead of Pillar (variant of Pascal designed for Mica) in NT was definitely the right thing at the time.

How do you get Windows NT4 style buttons on 11? That's something I want to do with my application!

The GDI libraries/APIs that provide that are all still there, you just need to find a framework that lets you see them, are kick through the abstraction walls of [insert chosen app framework] to access them more manually. Be prepared for a bit of extra work on what more modern UI libraries make more automatic, and having to discuss everything rather than just what you want to differ from default.

Oh thanks, I always think what is there is the native. I don't realize the old graphics way is still there. Maybe the Win3.x style is still there too?

I think you can get back to Win9x/2k style controls by instructing the system to not add any theming. If you're finding a panel that is using 3.x controls, they're likely in the resources of the app/dll. Although the 3.x file picker can still be found in a couple of rare corners of the OS.

https://learn.microsoft.com/en-us/windows/win32/api/uxtheme/...

    STAP_ALLOW_NONCLIENT

Specifies that the nonclient areas of application windows will have visual styles applied.

Thanks, this is interesting!

If there is no application manifest, you will get Windows NT4 / Windows 9x style buttons. Just tested this on Windows 11.

>It shocks me some apps get Windows NT4 style buttons even on Windows 11.

This is good, though. The alternative is that the app won't run at all, right? Windows NT is good because of that background compatibility, both for business apps and games.

> The alternative is that the app won't run at all, right?

The alternative is that the application displays with whatever the current GUI uses for its widgets.

Under Windows it's very rare to have trouble to running software. When you have trouble it's usually due to some security considerations or because you're using something which has roots in other operating systems.

MacOS & Linux are nothing like this. You can run most software, as most of the basis for modern software on those stacks is available in source form and can be maintained. Software which isn't breaks.

Apple/Google with their mobile OSes take that a step further, most older software is broken on those platforms.

The way they've kept compatibility within Windows is something I really love about the platform.. but it I keep wondering if there's a way to get the best of both worlds. Can you keep the compatibility layer as an adhoc thing, running under emulation, so that the core OS can be rationalised?

In fairness, closed source software is a very very tiny minority of the software available on Linux, which is why ABI backwards-compatibility hasn't been much of a concern. In that respect, it's essentially the polar opposite of Windows and even MacOS.

However, it'd be very nice if it did become more of a focus (especially in the glibc/audio/glx areas), especially now that gaming has become very popular on Linux.

Trying to get old, closed-source games like Unreal Tournament to work on Linux can be a real chore.

I'm not so sure, I like the Linux model of 99.999% of the code you'll run being available in source form. The result is that we have that code running everywhere.

I strongly dislike the Apple model.

Fun fact. If you increment each letter of VMS by one, you get WNT. If that isn't on purpose, it's a convenient coincidence.

Vaxes also had hardware support for ASTs in VMS (unlike NT) - they were essentially software interrupts that only triggered when the CPU was in a process context and no enabled interrupts were pending - so you could set a bit in a mask in another thread's context that would get loaded automatically on context switch and triggered once the thread was runnable in user mode .... device drivers could trigger a similar mechanism in kernel mode (and the 2 intermediate hardware modes/rings). There were also atomic queue instructions that would dispatch waiting ASTs

Months ago I found this presentation on youtube, "Re-architecting SWIS for X86-64"[0], about how VMS was ported from VAX to Alpha to Itanium to x86 that did not have the same AST behaviour.

[0] https://www.youtube.com/watch?v=U8kcfvJ1Iec

Especially since there was, apparently, MICA code copy pasted verbatim in NT.

https://www.techmonitor.ai/technology/dec_forced_microsoft_i...

I was wondering for years why MS continued to support DEC Alpha CPUs with NT.

Didnt it end brilliantly for MS? Settlement involved MS supporting Alpha while DEC trained its enormous sales/engineering arm to sell and support NT thus killing any incentives to buy DEC hw in the first place. DEC moved upstream the value chain and Microsoft moved tons of NT to all existing DEC corporate customers.

Oh yes. MS took full advantage of the situation. MS was always better at strategic planning than DEC.

> The processes section should be expanded upon. The NT kernel doesn't execute processes, it executes _threads_. Threads can be created in a few milliseconds where as noted, processes are heavy weight; essentially the opposite of Unicies. This is a big distinction.

I am not sure what point you are attempting to make here. As written, it is more or less completely wrong.

NT and Unix kernels both execute threads. Threads can be created in a few microseconds. Processes are heavy weight on both NT and Unix kernels.

The only thing I can think of is the long-standing idea that Unix tends to encourage creating new processes and Windows-related OS kernels tend to encourage creating new threads. This is not false - process creation on Windows-related OS kernels is an extremely heavyweight process, certainly comparing it with any Unix. But it doesn't make the quote from you above correct.

On a separate note, the state of things at the point of creation of NT is really of very little interest other than than to computer historians. It has been more than 30 years, and every still-available Unix and presumably NT have continued to evolve since then. Linux has dozens to hundreds of design features in it that did not exist in any Unix when NT was released (and did not exist in NT either).

Processes and threads on NT are distinct nominative types of objects (in a system where “object” has a much more precise meaning) and the GP is at least correct that the former are not schedulable entities. This distinction doesn’t really exist on Linux for instance where there are at one approximation on the user side only processes (at least to use the verbiage of the clone syscall - look elsewhere and they’re threads in part due to having to support pthreads), and the scheduler schedules “tasks” (task_struct) (whereas in NT the “thread” nomenclature carries throughout). FreeBSD may have separate thread and proc internally but this is more an implementation detail. I guess this all to say at the level lower than an API like pthreads, process/thread really isn’t easily comparable between NT and most Unixes.

It’s not so much “heavyweight” vs “lightweight” but that NT has been by design more limited in how you can create new virtual memory spaces.

For better or worse NT tied the creation of VM spaces to this relatively expensive object to create which has made emulating Unix like behavior historically a pain in the ass.

pthreads is a user-space API, and has nothing to do with the kernel. It is possible to implement pthreads entirely in user space (though somewhat horrific to do so). Linux does not have kernel threads in order to support pthreads (though they help).

Anyway, I see your point about the bleed between the different semantics of a task_t in the linux kernel.

> Linux does not have kernel threads in order to support pthreads

Yes, what I was alluding to somewhat cryptically was things like tgids and the related tkill/tgkill syscalls that as far I am aware were added with the implementation of 1:1 pthread support in mind.

> io_uring would be the first true non-blocking async I/O implementation on Unices.

I would agree with that statement in isolation, except by that standard (no need for a syscall per operation) the first “true” asynchronous I/O API on NT would be I/O ring (2021), a very close copy of io_uring. (Registered I/O, introduced in Windows 8, does not qualify because it only works on sockets.) The original NT API is absolutely in the same class as the FreeBSD and Solaris ones, it’s just that Linux didn’t have a satisfactory one for a long long time.

POSIX AIO is not non-blocking async I/O; it can block other threads requesting the resource. IOCP is a true non-blocking async I/O. IOCP also extends to all forms of I/O (file, TCP socket, network, mail slot, pipes, etc.) instead of a particular type.

POSIX AIO has usability problems also outlined in the previously linked thread.

Remember, all I/O in NT is async at the kernel level. It's not a "bolt-on".

IoRing is limited to file reads, unlike io_uring.

POSIX AIO + FreeBSD kqueue or Solaris ports are functionally equivalent to IOCP as far as I can tell.

This describes kqueue:

https://speakerdeck.com/trent/pyparallel-how-we-removed-the-...

I should do an updated version of that deck with io_uring and sans the PyParallel element. I still think it’s a good resource for depicting the differences in I/O between NT & UNIX.

And yeah, IOCP has implicit awareness of concurrency, and can schedule optimal threads to service a port automatically. There hasn’t been a way to do that on UNIX until io_uring.

Yes, please! And if you're interested, RegisteredIO and I assume you'd drop in IoRing.

In a nicely wrapped PDF :-)

Yeah I’d definitely include RegisteredIO and IoRing. When I was interviewing at Microsoft a few years back, I was actually interviewed by the chap that wrote RegisteredIO! Thought that was neat.

Posix AIO is just an interface. Windows also relies on thread pools for some async io (I.e. when reading files when all the data necessary to generate a disk request isn't in cache - good luck writing that as purely asynchronous)

This is all fine, but Window-NT file access is still slow compared with Linux- this shows up in shell scripts. The reason is supposedly that it insists on syncing during close, or maybe waiting for all closed files to sync before allowing the process to terminate. Shouldn't close finality be an optional async event or something?

The reason is due to file system filters, of which Windows Defender is always there. There is a significant delay from Defender when performing CloseFile()[0].

> As I was looking at the raw system calls related to I/O, something immediately popped out: CloseFile() operations were frequently taking 1-5 milliseconds whereas other operations like opening, reading, and writing files only took 1-5 microseconds. That's a 1000x difference!

This is why DevDrive was introduced[1]. You can either have Defender operate in async mode (default) or remove it entirely from the volume at your own risk.

The performance issue isn't related to sync or async I/O.

[0] https://gregoryszorc.com/blog/2015/10/22/append-i/o-performa...

[1] https://devblogs.microsoft.com/visualstudio/devdrive/

Windows FS stack is still _way_ slower than Linux. Filesystem operations have to create IRPs and submit them for execution through a generic mechanism. These IRPs can get filtered and modified in-flight, providing quite a bit of overall flexibility.

In Linux, filesystem paths are super-optimized, with all the filtering (e.g. for SELinux) special-cased if needed.

But even still, Windows also had to cheat to avoid completely cratering the performance, there's a shortcut called "FastIO": https://learn.microsoft.com/en-us/windows-hardware/drivers/i...

I wrote a filesystem for Windows around 25 years ago, and I still remember how I implemented all the required prototypes and everything in Explorer worked. But notepad.exe was just showing me empty data. It took me several days to find a note tucked into MSDN that you need to implement FastIO for memory mapped files to work (which Notepad.exe used).

That's interesting, why would notepad.exe use mmapped files?

Probably to save space when opening large files?

But it simply isn't slower than Linux.

Robert Collins explains that performance is just as good as Linux and the performance loss on Windows is due to file system filters (Defender)[0].

This is what DevDrive intends (and does) fix.

[0] https://youtu.be/qbKGw8MQ0i8?t=1759

The last time I did FS tests was admittedly around 4 years ago, but back then Windows was several times slower on pure FS performance benchmarks (creating/listing/deleting large number of directories and files).

It used to be _much_ slower, like orders of magnitude slower, especially for directories with a large number of files.

You're not seeing "pure" FS performance. You're seeing all of the abstractions between you and the file system.

To get more of the abstractions out of the way, you want DevDrive. And don't use Explorer.exe as a test bed which has shims and hooks and god knows what else.

I was testing the performance using plain C++ code.

These days there is a full native Btrfs implementation for Windows.

https://github.com/maharmstone/btrfs

It's complete enough you can boot and run Windows from Btrfs.

https://lilysthings.org/blog/windows-on-btrfs/

I wonder how many of these limitations affect this, notably performance.

If WSL1 could natively talk to Btrfs without the performance-sapping translation to NTFS, would that resolve the poor Git performance etc?

This probably has a lot to do with the mandatory file locking on Windows - afaik on Windows, the file is the representation of the underlying data of the disk, unlike on Linux, where it's just a reference to the inode, so locking the file on open is necessary. This is why you always get those 'file in use and cannot be deleted' prompts.

This impacts performance particularly when working with a ton of tiny files (like git does).

> Remember, all I/O in NT is async at the kernel level. It's not a "bolt-on".

All I/O in Linux is also async at the kernel level! The problem has always been expressing that asynchronicity to userspace in a sane way.

Filesystem io (and probably more) is not async at the kernel level in Linux. (Just imagine trying to express the complexity of it in continuations or some sort od state machine!) As such io_uring takes the form of a kernel thread pool. Disk block io by contrast is much easier to be fundamentally async since its almost always a case of submitting a request to an HBA and waiting for an interrupt.

Just imagine trying to express the complexity of [a filesystem] in continuations or some sort of state machine!

Arguably asyc/await could help with this; obviously it didn't exist in 1991 when Linux was created but it would be interesting to revisit this topic.

> Arguably asyc/await could help with this; obviously it didn't exist in 1991 when Linux was created

Wouldn't that just consist of I/O operations returning futures and then having an await() block the calling thread until the future is done (i.e. put it on a waitqueue)?

> Just imagine trying to express the complexity of it in continuations or some sort od state machine!

With Rust in the kernel this becomes somewhat possible to conceptualize.

> Just imagine trying to express the complexity of it in continuations or some sort o[f] state machine!

You’d probably want to use either some sort of code generation to do the requisite CPS transform[1] or the Duff’s-device-like preprocessor trick[2], but it’s definitely doable with some compiler support. Not in an existing codebase, though.

(Brought to you by working on a C codebase that does express stuff like this as explicit callbacks and context structures. Ugh.)

[1] https://dx.doi.org/10.1007/s10990-012-9084-5, https://www.irif.fr/~jch/research/cpc-2012.pdf, https://github.com/kerneis/cpc

[2] https://www.chiark.greenend.org.uk/~sgtatham/coroutines.html

> IOCP is a true non-blocking async I/O.

Unfortunately that's only half-true. You can (and will) still get blockage sometimes with IOCP, it depends on a lot of factors, like how loaded the system is, I think. There is absolutely no guarantee that your I/O will actually occur asynchronously, only that you will be notified of its completion asynchronously.

Also, opening a file is also always synchronous, which is quite annoying if you're trying not to block e.g. a UI thread.

The implication of both of these is you still need dedicated I/O threads. I love IOCP as much as anyone, but it does have these flaws, and was very much designed to be used from multiple threads.

The only workaround I'm aware of was User-Mode Scheduling, which effectively notified you as soon as your thread got blocked, but it still required multiple logical threads, and Microsoft removed support for it in Windows 11.

None of the UNIXes have the notion of WriteFile with an OVERLAPPED structure, that’s the key to NT’s asynchronous I/O.

Nor do they have anything like IOCP, where the kernel is aware of the number of threads servicing a completion port, and can make sure you only have as many threads running as there are underlying cores, avoiding context switches. If you write your programs to leverage these facilities (which are very unique to NT), you can max perform your hardware very nicely.

notably the NT equivalent of select(): WaitForSingleObject and WaitForMultipleObjects had a benefit that one select/wait type syscall could be tickled by any of a network, file or the NT equivalent of a pthread signal.

> There's a large debate whether a 'hybrid' kernel is an actual thing, and/or whether NT is just a monolithic kernel.

I don't think it's a concept that meaningfully exists. Microkernels are primarily concerned with isolating non-executive functions (e.g. device drivers) for stability and/or security (POLA) reasons. NT achieves virtually none of that (see e.g. Crowdstrike). The fact that Windows ships a thin user-mode syscall shim which largely consists of thin-to-nonexistent wrappers of NtXXX functions is architecturally uninteresting at best. Arguably binfmt_misc would then also make Linux a hybrid kernel.

Originally, Windows NT 3.x was more "microkernelithic" as graphics and printer drivers where isolated. NT 4 moved them to Kernel mode to speedup the system.

> The NT kernel doesn't execute processes, it executes _threads_

This is amongst the most important and visible differences between NT and Unix-likes, really. The key idea is that processes manage threads. Pavel Yosifovich in Windows 10 System Internals Part I puts it succinctly:

  A process is a containment and management object that represents a running instance of a program. The term “process runs” which is used fairly often, is inaccurate. Processes don’t run - processes manage. Threads are the ones that execute code and technically run.

NtCreateProcess is extremely expensive and its direct use strongly discouraged (but Cygwin and MSYS2, in their IMO misguided intention to force Unix paradigms onto Windows, wrote fork() anyway), but thread creation and management is extremely straightforward, and the Windows threading API is as a result much nicer than pthreads.

It is hard to accept that this is written by someone with any idea about how Linux works (as a Unix).

A process (really, a "task") is a containment and management object that represents a running instance of a program. A program ("task") does not run, its threads do.

The significant difference between Windows-related OS kernels and Unix-y ones is that process creation is much more heavyweight on the former. Nevertheless, on both types of systems, it is threads that execute code and technically run.

Mach before Linux was using task and threads as you seem to attribute to Linux.

A nice historical overview is…

https://developer.apple.com/library/archive/documentation/Da...

I worked on Mach in the early 1990s :) For example:

https://www.usenix.org/conference/usenix-mach-iii-symposium/...

i was programming on NeXT as a registered developer back then too. Middle aged nerds unite!

If you're splitting hairs, you're correct; processes manage threads on all OSs.

However, from the application programmer's perspective, the convention on Unix-likes (which is what really matters) is to fork and pipe between processes as IPC, whereas on Windows this is not the case. Clearly the process start-up time on Unix-likes is considered fast enough that parallelism on Unix until fairly recently was based on spinning up tens to hundreds of processes and IPC-ing between them.

I believe the point stands.

For a certain kind of application programming, that is and was true, yes.

But not for many other kinds of application programming, where you create threads using pthreads or some similar API, which are mapped 1:1 onto kernel threads that collectively form a "process".

I'm not sure what your definition of "fairly recently" is, but in the mid-90s, when we wanted to test new SMP systems, we would typically write code that used pthreads for parallelism. The fact that there is indeed a story about process-level parallelism (with IPC) in Unix-y systems should not distract from the equally fact existence and use of thread-level parallelism for at least 35 years.

This was written about Windows kernels.

Linux is the only Unix-like kernel I actually know anything about. In Linux, processes essentially do not exist. You have threads, and thread groups. A thread group is what most of the user-space tooling calls a process. It doesn't do very much by itself. As the name implies, it mostly just groups threads together under one identifier.

Linux threads and "processes" are both created using the "clone" system call, which allows the caller to specify how much state the new thread shares with the old thread. Share almost everything, and you have a "thread". Share almost nothing, and you have a "process". But the kernel treats them the same.

By contrast, processes in NT are real data structures that hold all kinds of attributes, none of which is a running piece of code, since that's still handled by a thread in both designs.

IIRC indeed Linux preserves the time honoured Unix semantics of a process ID by leveraging the thread group ID

My knowledge might be very out of date, but I remember a Linux process being an unit of execution as well as isolation. Creating a process without a thread is not possible afaik.

In contrast, Linux threads were implemented essentially as a hack - they were processes that shared memory and resources with their parent process, and were referred to internally as LWPs - lightweight processes.

I also remember a lot of Unix/Linux people not liking the idea of multithreading, preferring multiple processes to one, single-threaded process.

Linux took quite a path getting to its current threading implementation. Before NPTL[2], there was LinuxThreads[1], before that, I'm pretty sure threads were userspace only.

[1]https://en.wikipedia.org/wiki/LinuxThreads

[2]https://en.wikipedia.org/wiki/Native_POSIX_Thread_Library

All kernels execute threads. It's just that very old unixes had a unity of thread and process (and Linux having emulated that later introduced an unprecedented solution to bring in support for posix threads). The other unixes for their part all have a typical process and threads distinction today and have had for a while.

> It should also be noted that while NT as a product is much newer than Unicies, it's history is rooted in VMS fundamentals thanks to it's core team of ex-Digital devs lead by David Cutler.

WNT = VMS + 1 (next letter in alphabet for all three)

For the record, NT comes from the codename for the Intel i860 (N10) which was the original target platform for NT.

This is incorrect per David Cutler.

https://www.youtube.com/watch?v=xi1Lq79mLeE&t=4314s

He doesn't actually disagree, you know.

NT used to mean "New Technology," if I remember correctly. Not sure if that was the internal codename or a marketing creation anymore.

Threads aren't created in milliseconds, that would be really slow. It's more like microseconds.

Typo, thanks for the correction. Too late to edit :-)

Process is a way to segregate resources (memory, sockets, file descriptors, etc). You kill a proc - it will release all memory and file descriptors.

Thread is a way to segregate computation. You spawn a thread and it will run some code scheduled by the OS. you kill/stop a thread and it will stop computation, but not the resources.

Coming from working with Vax/VMS to NT I was struck by the similarities between them. It was only years later I found out about NT's DEC connections.

WNT is VMS+1

V->W

N->M

S->T

> https://www.youtube.com/watch?v=xi1Lq79mLeE&t=4314s

"New Technology", but yes, it's funny

Initially actually (afaik) it stood for N10, for the Intel i860 CPU. I think “New Technology” came from marketing then.

If you watch the interview with David Cutler to the time code I linked to, he explains that NT stands for New Technology which marketing did not want.

In which he specifically says that there may have been some point, early on, where it stood for N-10.

I just watched it. He does not say what you are maintaining he says.

One of my very favorite facts about Windows 2000, as revealed in its boot screen, is that it's based on New Technology Technology.

(I no longer work with Windows very much, but this little bit of trivia has stuck with me over the years)

Actually

M->N

Nice catch. Too late to edit unfortunately.

Could you please explain on those characters ? What do they mean ? Thnks.

VMS[1] is an OS for VAX[2] systems by Digital that Dave Cutler worked on before Windows NT (with the abandoned MICA OS for the equally abandoned PRISM CPU architecture between the two). As people have noted, the NT kernel is rather VMS / MICA like, because it's written by some of the same people, so they're solving problems with things they know work (with some people suggesting directly copied code as well, although VMS and MICA didn't use C as their main programming languages).

Some people point out if you shift characters by one "VMS" becomes "WNT", and give it as an explanation of the name choice of Windows NT, but it's a coincidence. For one thing, nobody ever explains how this gag was going to work back when the project was "NT OS/2"[3].

[1] Virtual Memory System, originally VAX/VMS, later OpenVMS.

[2] Later DEC Alpha, Intel Itanic and now AMD64 systems.

[3] AKA OS/2 3.0 or Portable OS/2.

In true Windows form, you have a memory access error.

Reply on news.ycombinator.com