7 ms·

Windows came from the single-user domain. Unix came from server space. It is literally two different evolutionary paths. From day-1, Unix was built for shared f

Windows came from the single-user domain. Unix came from server space. It is literally two different evolutionary paths. From day-1, Unix was built for shared file systems, multi-user accounts, and distributed computing. Networking on Microsoft was an afterthought until the mid-90's. Sure there were token ring and banyan vines drivers in the late 80's early 90's, but that was to share a drive letter. The entire idea of multiple users didn't appear until Win3.1 for workgroups, decades after multiuser OSes. WinNT started to take protected mode seriously, but they re-invented networking from an MS perspective (e.g., POP/SNMP? nope: MSExchange). It's not a surprise that Windows is such a mess under the hood compared to Linux/BSD/Unix/SystemV when you look at the history of Windows. I dunno, maybe that's not fair, but switching between *nux and Windows from a networking / distributed computing perspective is jarring. And that's just for simple things (interface config, tracing, configuration of multiple adapters and bridges...)

ThrowawayR2 6y ago
> "Windows came from the single-user domain. Unix came from server space." Windows 9x came from the single-user domain but is long dead except for compatibility stuff left over in modern Windows. Windows NT and its successors came from server space from its VMS lineage.
- ghostpepper 6y ago
  I have to wonder what percentage of the Windows 10 codebase is for backwards compatibility.
- oneplane 6y ago
  While that is true, the win32 API and other stuff that floats on top of NT for the GUI based stuff (which is most stuff) is still very much restricted by that legacy. NT was supposed to be very tunable and modular and have multiple personalities and abstractions but it turns out it mostly is just win32-on-NT and everything else ended up being on top of win32. It has gotten better, especially post-OneCore, but it still is very much restricted compared to Linux, BSD and Unix. Windows NT (and VMS) were not as much multi-user server as they were more closer to mainframes (which died/are dying for their own reasons). VMS, like plan9, had concepts to allow many (theoretically) fancy server things, but were to much a created world instead of a grown world (like post-system-v). Also, while the VMS dude who was on the NT team did influence it heavily, the legacy they had to support made it almost impossible to use any of that fancy 'new' stuff back then. While it was orders of magnitude better than DOS, it feels like Windows needs to make yet another evolution like it did going from DOS to NT to get back to current times instead of patching on top of patches every time.
  - mixmastamyk 6y ago
    Not expecting that to happen as MS is investing less in Windows.
    - pjmlp 6y ago
      Given that we just got the new SDK, DirectX 12 Ultimate is around the corner and release notes are a pleasure to read, it doesn't look to me like that.
  - int_19h 6y ago
    Can you give any examples of Win32 API that manifest design flaws or restrictions due to "single-user domain" legacy?
    - deleted 6y ago
      [deleted]
martinald 6y ago
I think both are a mess under the hood. I cannot make sense of where things will be configured in Linux. maybe /etc/, maybe somewhere else, with loads of setting file configurations. There's not a huge amount of consistency. What would be interesting is a complete re-imagining of a server OS. Consistent file locations for everything, which are automatically versioned a la git allowing you to roll back any specific change, built into the OS level. All processes totally sandboxed from each other with specific permission elevations as required (like iOS).
- bitcharmer 6y ago
  I'd still take a heavily configurable and customizable "mess", as you put it, than the one that doesn't allow me to control how it works. There's a good reason why Linux absolutely dominates the server space.
  - ThrowawayR2 6y ago
    > "There's a good reason why Linux absolutely dominates the server space." Yeah, it was cheaper (in both senses of the word) than all the other contenders and more or less Unixy enough that software could easily be ported over.
    - tombert 6y ago
      Well, not to mention that you're allowed to add features to it without waiting for Microsoft to do it. Linux might not be the best codebase in the world, but it's probably easier to add a feature to Linux than it is to get MS to add a new feature. Correct me if I'm wrong, but wasn't Linux quicker to support multithreading than Windows, largely because big megacorps needed that for their servers?
      - ThrowawayR2 6y ago
        > "Correct me if I'm wrong, but wasn't Linux quicker to support multithreading than Windows, largely because big megacorps needed that for their servers? " Surely you jest. The other Unixes, including Microsoft Xenix, supported multithreading before either Windows NT or Linux even existed. Big megacorps in that era used Sun Microsystems ("The com in dotcom™") server and other proprietary Unix servers because both Windows NT and Linux on the x86 hardware of the time weren't considered good enough to handle megacorp server loads and that didn't change until around '00. If you go strictly by release date, Linux 0.01 came out in '91 and Windows NT 3.1 came out in '93 so it's technically correct that Linux had multithreading first but neither Linux 0.95 (what would have been available in '93) nor NT 3.1 was exactly something anyone would consider using in production, let alone at a megacorp.
tombert 6y ago
I agree that networking stuff feels pretty frustrating on Windows compared to POSIXey stuff; for the most part using a good networking library like (as mentioned above) ZeroMQ or even some of the built-in JVM socketing stuff will help abstract it, but Unix sockets are simply better out of the box. Even a simpler example though; the fact that there wasn't really a built-in analog for the "pipe" until PowerShell sort of boggles the mind. Yes, I'm aware that Windows isn't command-line focused, but it baffles me that software engineers didn't really see a need in Windows to compose programs together. (Someone, please correct me if I'm wrong on this point, I haven't touched Windows in any serious capacity in almost a decade).
- stinos 6y ago
  socketing stuff will help abstract it, but Unix sockets are simply better out of the box Can you elaborate? Do you mean performance? Because the on the C level both use (apart from some minor differences, which aren't enough to call one 'simply better' than the other) the same berkeley socket API.
  - tombert 6y ago
    Again, haven't touched Windows in years so it's entirely possible that I'm wrong or out of date, but the last time I did any kind of networking on Windows was with the WinSock API, which if I recall correctly, didn't have any support for any kind of IPC out of the box, and I had to do everything with TCP. I might have been too harsh on Windows there, I've never paid to do any direct socket-level programming within Windows.
    - int_19h 6y ago
      Do you mean Unix domain sockets by "IPC"? TCP sockets are also a perfectly valid IPC mechanism, as are many others. Win32 generally promotes pipes (named, if needed) for this purpose. For sockets, if you insist on them, it offers some optimizations for local/local TCP connections. Win10 eventually added Unix sockets, mostly for WSL integration (https://devblogs.microsoft.com/commandline/af_unix-comes-to-windows/ https://devblogs.microsoft.com/commandline/af_unix-comes-to-...). In the end, it's all just byte streams, so it doesn't matter much once you get past establishing connection. The biggest annoyance with Windows sockets is that they aren't really unified with files - as in, a socket file descriptor cannot be passed to file APIs that work on FDs, like read() and write(); you have to use send/recv(). This makes it harder to write generic code in C, since you need an abstraction layer for code that deals with I/O streams. But most frameworks already offer such an abstraction layer - e.g. a .NET API would just use Stream (and if it's a socket, it would be a NetworkStream instance).
mavhc 6y ago
Unix was originally a single tasking OS, that's what the U is for
mixmastamyk 6y ago
Yep, many years ago I casually stated here that Windows was clumsy on the network, and it really offended some guy. Limited drive letters and backslashes didn’t help, but the history you mentioned is the foundational problem. The misdesign around console/remote admin is another. For more background read the Art of Unix programming and the Windows Terminal blog about all the layers they had to work around to shoehorn it in.
- pnutjam 6y ago
  I still run into Windows Admins who don't understand UNC paths vs mapped drives.
pjmlp 6y ago
Lots of FUD and misunderstanding going on there. Windows NT, which is what everyone uses, is a descendant of VMS design and culture, built for shared file systems, multi-user accounts, and distributed computing just like UNIX.
- kalleboo 6y ago
  GP is unfair in as you say, NT was a from-the-ground-up new OS based on VMS design without the single-user baggage of old DOS/Windows. But still for a long time Windows NT made a lot of concessions to the single-GUI-user model that UNIXes didn't, like putting font rendering in the kernel.
  - pjmlp 6y ago
    Except for UNIXes like NeXTSTEP and Sun NeWS, as no other UNIX ever had any clue about GUI development, as Jobs used to say.

ThrowawayR2 6y ago

> "Windows came from the single-user domain. Unix came from server space." Windows 9x came from the single-user domain but is long dead except for compatibility stuff left over in modern Windows. Windows NT and its successors came from server space from its VMS lineage.

ghostpepper 6y ago
I have to wonder what percentage of the Windows 10 codebase is for backwards compatibility.
oneplane 6y ago
While that is true, the win32 API and other stuff that floats on top of NT for the GUI based stuff (which is most stuff) is still very much restricted by that legacy. NT was supposed to be very tunable and modular and have multiple personalities and abstractions but it turns out it mostly is just win32-on-NT and everything else ended up being on top of win32. It has gotten better, especially post-OneCore, but it still is very much restricted compared to Linux, BSD and Unix. Windows NT (and VMS) were not as much multi-user server as they were more closer to mainframes (which died/are dying for their own reasons). VMS, like plan9, had concepts to allow many (theoretically) fancy server things, but were to much a created world instead of a grown world (like post-system-v). Also, while the VMS dude who was on the NT team did influence it heavily, the legacy they had to support made it almost impossible to use any of that fancy 'new' stuff back then. While it was orders of magnitude better than DOS, it feels like Windows needs to make yet another evolution like it did going from DOS to NT to get back to current times instead of patching on top of patches every time.
- mixmastamyk 6y ago
  Not expecting that to happen as MS is investing less in Windows.
  - pjmlp 6y ago
    Given that we just got the new SDK, DirectX 12 Ultimate is around the corner and release notes are a pleasure to read, it doesn't look to me like that.
- int_19h 6y ago
  Can you give any examples of Win32 API that manifest design flaws or restrictions due to "single-user domain" legacy?
  - deleted 6y ago
    [deleted]

martinald 6y ago

I think both are a mess under the hood. I cannot make sense of where things will be configured in Linux. maybe /etc/, maybe somewhere else, with loads of setting file configurations. There's not a huge amount of consistency. What would be interesting is a complete re-imagining of a server OS. Consistent file locations for everything, which are automatically versioned a la git allowing you to roll back any specific change, built into the OS level. All processes totally sandboxed from each other with specific permission elevations as required (like iOS).

bitcharmer 6y ago
I'd still take a heavily configurable and customizable "mess", as you put it, than the one that doesn't allow me to control how it works. There's a good reason why Linux absolutely dominates the server space.
- ThrowawayR2 6y ago
  > "There's a good reason why Linux absolutely dominates the server space." Yeah, it was cheaper (in both senses of the word) than all the other contenders and more or less Unixy enough that software could easily be ported over.
  - tombert 6y ago
    Well, not to mention that you're allowed to add features to it without waiting for Microsoft to do it. Linux might not be the best codebase in the world, but it's probably easier to add a feature to Linux than it is to get MS to add a new feature. Correct me if I'm wrong, but wasn't Linux quicker to support multithreading than Windows, largely because big megacorps needed that for their servers?
    - ThrowawayR2 6y ago
      > "Correct me if I'm wrong, but wasn't Linux quicker to support multithreading than Windows, largely because big megacorps needed that for their servers? " Surely you jest. The other Unixes, including Microsoft Xenix, supported multithreading before either Windows NT or Linux even existed. Big megacorps in that era used Sun Microsystems ("The com in dotcom™") server and other proprietary Unix servers because both Windows NT and Linux on the x86 hardware of the time weren't considered good enough to handle megacorp server loads and that didn't change until around '00. If you go strictly by release date, Linux 0.01 came out in '91 and Windows NT 3.1 came out in '93 so it's technically correct that Linux had multithreading first but neither Linux 0.95 (what would have been available in '93) nor NT 3.1 was exactly something anyone would consider using in production, let alone at a megacorp.

tombert 6y ago

I agree that networking stuff feels pretty frustrating on Windows compared to POSIXey stuff; for the most part using a good networking library like (as mentioned above) ZeroMQ or even some of the built-in JVM socketing stuff will help abstract it, but Unix sockets are simply better out of the box. Even a simpler example though; the fact that there wasn't really a built-in analog for the "pipe" until PowerShell sort of boggles the mind. Yes, I'm aware that Windows isn't command-line focused, but it baffles me that software engineers didn't really see a need in Windows to compose programs together. (Someone, please correct me if I'm wrong on this point, I haven't touched Windows in any serious capacity in almost a decade).

stinos 6y ago
socketing stuff will help abstract it, but Unix sockets are simply better out of the box Can you elaborate? Do you mean performance? Because the on the C level both use (apart from some minor differences, which aren't enough to call one 'simply better' than the other) the same berkeley socket API.
- tombert 6y ago
  Again, haven't touched Windows in years so it's entirely possible that I'm wrong or out of date, but the last time I did any kind of networking on Windows was with the WinSock API, which if I recall correctly, didn't have any support for any kind of IPC out of the box, and I had to do everything with TCP. I might have been too harsh on Windows there, I've never paid to do any direct socket-level programming within Windows.
  - int_19h 6y ago
    Do you mean Unix domain sockets by "IPC"? TCP sockets are also a perfectly valid IPC mechanism, as are many others. Win32 generally promotes pipes (named, if needed) for this purpose. For sockets, if you insist on them, it offers some optimizations for local/local TCP connections. Win10 eventually added Unix sockets, mostly for WSL integration (https://devblogs.microsoft.com/commandline/af_unix-comes-to-windows/ https://devblogs.microsoft.com/commandline/af_unix-comes-to-...). In the end, it's all just byte streams, so it doesn't matter much once you get past establishing connection. The biggest annoyance with Windows sockets is that they aren't really unified with files - as in, a socket file descriptor cannot be passed to file APIs that work on FDs, like read() and write(); you have to use send/recv(). This makes it harder to write generic code in C, since you need an abstraction layer for code that deals with I/O streams. But most frameworks already offer such an abstraction layer - e.g. a .NET API would just use Stream (and if it's a socket, it would be a NetworkStream instance).

mavhc 6y ago

Unix was originally a single tasking OS, that's what the U is for

mixmastamyk 6y ago

Yep, many years ago I casually stated here that Windows was clumsy on the network, and it really offended some guy. Limited drive letters and backslashes didn’t help, but the history you mentioned is the foundational problem. The misdesign around console/remote admin is another. For more background read the Art of Unix programming and the Windows Terminal blog about all the layers they had to work around to shoehorn it in.

pnutjam 6y ago
I still run into Windows Admins who don't understand UNC paths vs mapped drives.

pjmlp 6y ago

Lots of FUD and misunderstanding going on there. Windows NT, which is what everyone uses, is a descendant of VMS design and culture, built for shared file systems, multi-user accounts, and distributed computing just like UNIX.

kalleboo 6y ago
GP is unfair in as you say, NT was a from-the-ground-up new OS based on VMS design without the single-user baggage of old DOS/Windows. But still for a long time Windows NT made a lot of concessions to the single-GUI-user model that UNIXes didn't, like putting font rendering in the kernel.
- pjmlp 6y ago
  Except for UNIXes like NeXTSTEP and Sun NeWS, as no other UNIX ever had any clue about GUI development, as Jobs used to say.