nullindividual

NT kernel still gets improvements. Think IoRing (copy of io_uring, but for file reads only) which is a new feature.

I think things like Credential Guard, various virtualization (security-related, not VM-related) are relatively new kernel-integrated features, etc.

Kernel bugs that need to exist because of backwards compat are going to continue to exist since backwards compat is a design goal of Windows.

That's a developer choice, not the registry in and of itself. You could just as easily have /etc filled files with GUIDs for file names.

Generally, 3rd party developers don't use a bunch of GUIDs for keys. Microsoft does for Windows components to map the internal object ID of whatever they're dealing with; my assumption is for ease of recognition/documentation on their side (and generally the assumption that the end user shouldn't be playing around in there).

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

This is the responsibility of the installer.

Using Windows Installer, this is easily accomplished. The Msi database _does_ track individual files and registry entries. If you're using another installer, or the developer allows their app to write something somewhere that isn't tracked by their installer, you're going to get files left behind.

macOS is especially bad in this respect. Bundles are great, until you have a ~/Library full of files that you never knew about after running an application.

Not quite.

NT 3.1 used a TCP stack from Spider Systems[0]. It was completely rewritten by Microsoft in 3.5[1].

The userland utilities, ping, tracert, etc were brought over from BSD.

[0] https://en.wikipedia.org/wiki/Spider_Systems

[1] https://web.archive.org/web/20151229084950/http://www.kuro5h...

Windows 2.0 for i386 was the first to introduce protected mode and preemptive multitasking. These features had to wait for Intel but it was available in 1987.

Win32 runs on Linux by way of SQL Server.

This is incorrect per David Cutler.

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

This is a Win32-ism rather than an NT-ism. This will work:

    mkdir \\.\C:\COM1

Not sure what NT4 systems you were dealing with, but I've dealt with ones thrashing the page file on spinning rust and the GUI is still responsive.

NT4 had a higher base RAM requirement than 9x. Significantly so.

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.

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

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

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/

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

A good visual representation:

https://psyche.co/films/enter-the-sensory-world-of-an-overst...

Isn't Windows more abstract than just a frontend[0]? I.e., Windows/386 added protected mode and other features.

[0] https://en.wikipedia.org/wiki/Microsoft_Windows#Early_versio...

You can provision a VHDX on your pre-existing NTFS volume (IIRC VHDX overhead is <=1% for Hyper-V, not sure if that's still the case and/or applies to DevDrive). But yes, I would say an additional drive is ideal. I did just that to put games on DevDrive.

https://devblogs.microsoft.com/visualstudio/devdrive/

https://learn.microsoft.com/en-us/windows/dev-drive/#set-up-...

It was roughly $1/MB in 1999. Or about $250 USD with inflation in 2024 dollars for a 128MB DIMM.

Link to interview: https://www.youtube.com/watch?v=xi1Lq79mLeE

(https://www.youtube.com/watch?v=xi1Lq79mLeE&t=4314s - yes, it stands for New Technology)

> What I really want is a Windows 2000-esque UI with dense

Engineers like you and I want that. The common end user wants flashy, sleek, stylish (and apparently CandyCrush).

But don't forget that that 2000 UI was flashy, sleek, and stylish with it's fancy pants GDI+ and a mouse pointer with a drop shadow!

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

In a nicely wrapped PDF :-)

> NT’s approach to file systems makes many file system operations very slow

This is due to the file system filters. It shows when using DevDrive where there are significant performance improvements.

And don't forget Alternate Data Streams for NTFS! Made specifically for Mac OS.

> And that compatibility problem was still a hard one for Microsoft to deal with, remember that NT was not ubiquitous until Windows XP despite being a massive improvement.

I think when it comes to this it is best to remember the home computing landscape of the time, and the most important part: DRAM prices.

They were absurdly high and NT4/2000 required more of it.

My assumption is Microsoft would have made the NT4/2000 jump much quicker if DRAM prices were driven in a downward direction.

This describes kqueue:

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

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.

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...

I pay 10 cents per KWH. Most of the electricity in my state is produced by hydropower.

The reason I asked is I used to run a dual X5650 server with SSDs and it was about $50/month with the cheapest (or very close to) rates in the US.

Thanks, but I've been referring people like you who lack an understanding of Windows I/O (and VMM) to this book since at least the 4th edition.

I've had my copy of the 7th since it came out.