* It is (with a lot of ifs and buts) a microkernel
* it is optimized for integration with third party software from people who don’t have the source, so for instance the driver model is interesting
* the built in configuration system (the registry) and how it’s used throughout
* the (underused) personalities system you can use to show different apis to different binaries
* the security model is much more interesting, while in Linux you have ‘root’ and everything else, on Windows this is much more granular (unfortunately it’s so complex it’s basically impossible to use).
The architecture is really quite interesting, even though Microsoft didn’t make a lot of use of a large part of it.
If I'm not mistaken, the Win32 API is actually a subsystem to the NT kernel. You can call the kernel itself a layer below with functions beginning with 'nt*'.
Hardware is actually mapped as an object namespace, which is presented to the user as the drive letters. This was exposed with Windows XP booting in safe mode; during the boot process it would print file paths as object paths, not drive paths.
Much as I'm more in the *nix way now, there's plenty of curiosities to explore and tinker in Windows.
The big difference is when you're in a multi-computer (Active Directory / NIS / LDAP) environment. On UNIX all the IDs are smallish integers, so you have to be careful to ensure they're unique and non-overlapping. On Windows you have a "SID" which is variable length and (for users) usually a big random number.
Linux User IDs since decades are 32 bit integers; you can just use some mapping system to allocate them automatically and you’ll never run out.
The limitation is that there is one user ID, 0 which can do everything and all the other IDs can do almost nothing.
This has nothing to do with domains and everything with the distinction you describe between the Windows Administrator, local system or even more powerful trustedinstaller accounts.
Yes and no. Bear in mind, a large part of a Windows SID is a namespace - the actual id within that namespace is so far without exception under 32-bits. An entire Active Directory domain (read: single domain, not forest) is actually limited to 2^30 RID's being issued - after which no new accounts (including computer accounts) can be created, period. You can technically unlock an extra bit and issue 2^31 RID's starting with WS2012, but compatibility is a potential issue and MS's documentation says you should only use it while planning a migration to a new domain (and for good reason).
This does technically give Windows some advantage here as SID's are namespaced - you can have multiple domains in a forest, domain trusts, etc - but I don't think as far as realistic number of users accessing a network it makes much of a difference.
Where it does suck on Linux, however, is user namespaces. 32-bits is a lot when it comes to just giving out accounts, but it's nowhere near enough to give every user a 16-bit chunk of accounts for mapping the traditional 0-65535 (because nobody) ranges for use with unprivileged user namespaces. I'd really like to see a push for 64-bit uid/gid's for this reason.
And yet in practice the only problem with them is when mapping Windows SID is needed. Otherwise, they are fine.
Also, Windows SIDs are fixed-size 128 bit. They were supposed to be GUIDs, but they are not that random; user SIDs contain common prefix from the domain SID.
Almost every time I talked to pseudo nt gurus, IOCP was mentioned as something nt did and linux don't. Now, io_uring seems to have finally closed the gap.
No, like io_uring which Linux got in 2019 and still doesn't cover everything yet (e.g. currently mkdirat() is being added). It also often falls back to a kernel-level thread pool, since many e.g. file systems don't implement async IO.
>since many e.g. file systems don't implement async IO
If we're picking on Linux here we should also mention that this issue cannot exist on Windows because it doesn't support anything else besides NTFS and a couple of options dating back to the 18th century or so.
Oh, and WinFS, of course, F being short for future which is like the horizon, or the communism, always out there just a month or two away.
Sure, and there are third party drivers for ext* and btrfs and god knows what else… but we're talking about official support here, I think. You can find all sorts of craziness in out-of-tree patches for the Linux kernel.
“ n the mid-1980s, Microsoft and IBM cooperated to develop the OS/2 operating system, which was written in assembly language for single-processor Intel 80286 systems. In 1988, Microsoft decided to make a fresh start and to develop a “new technology” (or NT) portable operating system that supported both the OS/2 and POSIX application programming interfaces (APIs). In October 1988, Dave Cutler, the architect of the DEC VAX/VMS operating system, was hired and given the charter of building this new operating system.”
Is the fact that it's a very stable and robust kernel that evolved over different means, with different priorities and expectations not enough?
The kernel itself is very interesting, regardless of what happened in the Linux world. If all you ever look at is Linux, you get stuck in Linux ideas of how things should, or even can, be done.
What? Can you elaborate? I mean if you want non blocking IO from an fd in Linux, you can just do that. Not sure what defaults have to do with anything. Your code will still have to be written appropriately.
Default in linux is read()/write() and be blocked. Doing async is a lot more work and until relatively (to NT timelines) recently quite limited (select).
On NT the standard way is async, and doing things in the block-and-wait way is abnormal and unusual.
Defaults matter. Because that's what most people will do.
Linux use read(2)/write(2) for both blocking and non-blocking. Still don't understand what you mean by how NT does it. Either your code is written to accomodate Async IO or not.
* it is optimized for integration with third party software from people who don’t have the source, so for instance the driver model is interesting
* the built in configuration system (the registry) and how it’s used throughout
* the (underused) personalities system you can use to show different apis to different binaries
* the security model is much more interesting, while in Linux you have ‘root’ and everything else, on Windows this is much more granular (unfortunately it’s so complex it’s basically impossible to use).
The architecture is really quite interesting, even though Microsoft didn’t make a lot of use of a large part of it.