4 ms·

* 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 in

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

scaladev 6y ago
>in Linux you have ‘root’ and everything else Well, you do have: - capabilities (which are so coarse-grained as to be practically useless) - 8 types of namespaces - seccomp-bpf - LSM (AppArmor, SELinux, TOMOYO, etc)
- raverbashing 6y ago
  Yes though a lot of this came "long after" the NT kernel (at least after NT 4.0) A lot of innovations on NT are late as well to be fair, like the whole Application Views (?) of the system (basically an FS/Registry app sandboxing)
  - tinus_hn 6y ago
    This is more like LD_PRELOAD. I’m not sure this is a kernel level feature.
- pjc50 6y ago
  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. https://docs.microsoft.com/en-us/troubleshoot/windows-server/identity/security-identifiers-in-windows https://docs.microsoft.com/en-us/troubleshoot/windows-server... Windows also differentiates between the human ADMINISTRATOR account and machine "root" accounts like "LOCALSYSTEM". User accounts are also disambiguated by "domain"; ADMINISTRATOR on the local machine is not automatically the same as the domain-wide ADMINISTRATOR.
  - tinus_hn 6y ago
    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.
    - pdw 6y ago
      Compared to Windows SIDs, Linux's 32-bit uid is a "smallish integer"
      - snuxoll 6y ago
        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.
      - vetinari 6y ago
        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.
wruza 6y ago
The architecture is really quite interesting, even though Microsoft didn’t make a lot of use of a large part of it. Sadly, that usually means it’s bugged as hell and impossible to use unless you’ve been trained for many years at ms to do that.
macksd 6y ago
I'm very intrigued by that list. Any recommendations on where to read technical, internal details?
- helloooooooo 6y ago
  Windows Internals 7th edition
- tinus_hn 6y ago
  There’s books but also the ReactOS project has been working for many years on replicating the functionality, so you can look at their source.
msla 6y ago
> the (underused) personalities system you can use to show different apis to different binaries Linux has this, but it is, as you say, underused. https://man7.org/linux/man-pages/man2/personality.2.html https://man7.org/linux/man-pages/man2/personality.2.html
HeckFeck 6y ago
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.

scaladev 6y ago

>in Linux you have ‘root’ and everything else Well, you do have: - capabilities (which are so coarse-grained as to be practically useless) - 8 types of namespaces - seccomp-bpf - LSM (AppArmor, SELinux, TOMOYO, etc)

raverbashing 6y ago
Yes though a lot of this came "long after" the NT kernel (at least after NT 4.0) A lot of innovations on NT are late as well to be fair, like the whole Application Views (?) of the system (basically an FS/Registry app sandboxing)
- tinus_hn 6y ago
  This is more like LD_PRELOAD. I’m not sure this is a kernel level feature.
pjc50 6y ago
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. https://docs.microsoft.com/en-us/troubleshoot/windows-server/identity/security-identifiers-in-windows https://docs.microsoft.com/en-us/troubleshoot/windows-server... Windows also differentiates between the human ADMINISTRATOR account and machine "root" accounts like "LOCALSYSTEM". User accounts are also disambiguated by "domain"; ADMINISTRATOR on the local machine is not automatically the same as the domain-wide ADMINISTRATOR.
- tinus_hn 6y ago
  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.
  - pdw 6y ago
    Compared to Windows SIDs, Linux's 32-bit uid is a "smallish integer"
    - snuxoll 6y ago
      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.
    - vetinari 6y ago
      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.

wruza 6y ago

The architecture is really quite interesting, even though Microsoft didn’t make a lot of use of a large part of it. Sadly, that usually means it’s bugged as hell and impossible to use unless you’ve been trained for many years at ms to do that.

macksd 6y ago

I'm very intrigued by that list. Any recommendations on where to read technical, internal details?

helloooooooo 6y ago
Windows Internals 7th edition
tinus_hn 6y ago
There’s books but also the ReactOS project has been working for many years on replicating the functionality, so you can look at their source.

msla 6y ago

> the (underused) personalities system you can use to show different apis to different binaries Linux has this, but it is, as you say, underused. https://man7.org/linux/man-pages/man2/personality.2.html https://man7.org/linux/man-pages/man2/personality.2.html

HeckFeck 6y ago

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.