[HN Gopher] Windows NT vs. Unix: A design comparison
___________________________________________________________________
Windows NT vs. Unix: A design comparison
Author : LorenDB
Score : 202 points
Date : 2024-09-09 16:37 UTC (6 hours ago)
(HTM) web link (blogsystem5.substack.com)
(TXT) w3m dump (blogsystem5.substack.com)
| nullindividual wrote:
| 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...
| mananaysiempre wrote:
| > 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.
| nullindividual wrote:
| 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.
| mananaysiempre wrote:
| POSIX AIO + FreeBSD kqueue or Solaris ports are
| functionally equivalent to IOCP as far as I can tell.
| nullindividual wrote:
| This describes kqueue:
|
| https://speakerdeck.com/trent/pyparallel-how-we-removed-
| the-...
| trentnelson wrote:
| 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.
| nullindividual wrote:
| Yes, please! And if you're interested, RegisteredIO and I
| assume you'd drop in IoRing.
|
| In a nicely wrapped PDF :-)
| trentnelson wrote:
| 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.
| netbsdusers wrote:
| 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)
| jhallenworld wrote:
| 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?
| nullindividual wrote:
| 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-p
| erforma...
|
| [1] https://devblogs.microsoft.com/visualstudio/devdrive/
| Sesse__ wrote:
| > 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.
| trentnelson wrote:
| 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.
| formerly_proven wrote:
| > 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.
| delta_p_delta_x wrote:
| > 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.
| PaulDavisThe1st wrote:
| 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.
| jjtheblunt wrote:
| 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/D
| a...
| PaulDavisThe1st wrote:
| I worked on Mach in the early 1990s :) For example:
|
| https://www.usenix.org/conference/usenix-mach-iii-
| symposium/...
| delta_p_delta_x wrote:
| 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.
| PaulDavisThe1st wrote:
| 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.
| immibis wrote:
| 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.
| ithkuil wrote:
| IIRC indeed Linux preserves the time honoured Unix
| semantics of a process ID by leveraging the thread group
| ID
| netbsdusers wrote:
| 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.
| PaulDavisThe1st wrote:
| > 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).
| epcoa wrote:
| 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.
| PaulDavisThe1st wrote:
| 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.
| emily-c wrote:
| 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.
| rbanffy wrote:
| 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.
| emily-c wrote:
| >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.
| markus_zhang wrote:
| How do you get Windows NT4 style buttons on 11? That's
| something I want to do with my application!
| dspillett wrote:
| 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.
| markus_zhang wrote:
| 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?
| saratogacx wrote:
| 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.
| heraldgeezer wrote:
| >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.
| Dwedit wrote:
| Threads aren't created in milliseconds, that would be really
| slow. It's more like microseconds.
| nullindividual wrote:
| Typo, thanks for the correction. Too late to edit :-)
| qsdf38100 wrote:
| WNT is VMS+1
|
| V->W
|
| N->M
|
| S->T
| nullindividual wrote:
| > https://www.youtube.com/watch?v=xi1Lq79mLeE&t=4314s
|
| "New Technology", but yes, it's funny
| steve1977 wrote:
| Initially actually (afaik) it stood for N10, for the Intel
| i860 CPU. I think "New Technology" came from marketing
| then.
| nullindividual wrote:
| 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.
| JeremyNT wrote:
| 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)
| pmontra wrote:
| Actually
|
| M->N
| lr1970 wrote:
| > 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)
| amatwl wrote:
| For the record, NT comes from the codename for the Intel i860
| (N10) which was the original target platform for NT.
| nullindividual wrote:
| This is incorrect per David Cutler.
|
| https://www.youtube.com/watch?v=xi1Lq79mLeE&t=4314s
| kev009 wrote:
| This is great! It would be interesting to see darwin/macos in the
| mix.
|
| On the philosophical side, one thing to consider is that NT is in
| effect a third system and therefore avoided some of the
| proverbial second system syndrome.. Cutler had been instrumental
| in building at least two prior operating systems (including the
| anti-UNIX.. VMS) and Microsoft was keen to divorce itself from
| OS/2.
|
| With the benefit of hindsight and to clear some misconceptions,
| OS/2 was actually a nice system but was somewhat doomed both
| technically and organizationally. Technically, it solved the
| wrong problem.. it occupies a basically unwanted niche above DOS
| and below multiuser systems like UNIX and NT.. the same niche
| that BeOS and classic Mac OS occupied.
| Organizationally/politically, for a short period it /was/ a
| "better DOS than DOS and better Windows than Windows" with VM86
| and Win API support, but as soon as Microsoft reclaimed their
| clown car of APIs and apps it would forever be playing second
| fiddle and IBM management never acknowledged this reality. 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.
| tivert wrote:
| > This is great! It would be interesting to see darwin/macos in
| the mix.
|
| But that's just another UNIX.
| kev009 wrote:
| Only in the user's perception. The implementation is nothing
| like UNIX, being a Mach2.5 derivative and later additions
| like DriverKit.
| steve1977 wrote:
| macOS _is_ a proper UNIX. As was OSF /1 (aka Digital UNIX
| aka Tru64 UNIX), which also had Mach 2.5 kernel.
| kev009 wrote:
| So is z/OS. UNIX branding under The Open Group is
| correctly focused on the user's perception and has little
| to do with kernel implementation. Mach is is no more UNIX
| than NT is VMS, to call one the other in this context of
| kernel discussion is reductionist and impedes correct
| understanding of the historical roots and critical
| differences.
| p_l wrote:
| OSF/1 however was a complete Unix system, even if it
| based its kernel on Mach (at least partially because it
| offered a fast path to SMP and threading), and formed the
| BSD side of Unix wars.
|
| And NeXTSTEP didn't diverge too much that when OSX was
| released they updated the code base with last OSFMK
| release.
| nullindividual wrote:
| > 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.
| euroderf wrote:
| I recall DRAM prices restricting the uptake of OS/2 also.
| kev009 wrote:
| Definitely impactful for NT4, not for 2000.
| p_l wrote:
| Was very impactful in early days of 2000. Seeing 64 MiB
| "used up" by barely loaded NT5.0 beta/RC was honestly a
| sort of chilling effect. But prices shortly fell and 128MB
| became accessible option, just in time for Windows XP to
| nail Windows 9x dead
| hnlmorg wrote:
| 128MB was pretty common by the time Windows 2000 was
| released. I could afford it and I wasn't paid well at
| that time.
|
| Plus Windows ME wasn't exactly nimble either. People talk
| about the disaster that was Vista and Windows 8 but ME
| was a thousand times worse. Thank god Windows 2000 was an
| option.
| somat wrote:
| My understanding is that ME from a technological point of
| view was 98 with NT drivers. It probably was a critical
| step in getting vendors to make NT drivers for all of
| their screwball consumer hardware, and this made XP, the
| "move the consumers to the NT kernel" step a success. The
| lack of drivers is also what made XP 64 bit edition so
| fraught with peril, but xp-64/vista was probably critical
| for win7's success for the same reason.
|
| But yeah, what a turd of a system.
| mepian wrote:
| 98 was the one that introduced NT drivers (WDM).
| nullindividual wrote:
| It was roughly $1/MB in 1999. Or about $250 USD with
| inflation in 2024 dollars for a 128MB DIMM.
| hnlmorg wrote:
| DOS compatibility was a far bigger issue.
|
| PC gaming was, back then, still very DOS-centric. It wasn't
| until the late 90s that games started to target Windows. And
| even then, people still had older games they wanted
| supported.
| dspillett wrote:
| I'd say both. IIRC the DOS story was better under OS/2 than
| NT, but the RAM requirements were higher (at least until
| XP).
|
| To add a third prong: hardware support was a big issue too
| as it is for any consumer OS, with legacy hardware being an
| issue just as it can be today if not more so. This hit both
| NT and OS/2 similarly.
| hnlmorg wrote:
| That "niche" you described was actually a desktop computing
| norm form more than a decade.
|
| Let's also not forget RISC OS, Atari TOS, AmigaOS, GEOS, SkyOS
| and numerous DOS frontends including, but not limited to,
| Microsoft Windows.
| nullindividual wrote:
| 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_ver
| sio...
| hnlmorg wrote:
| To be honest I was being flippant with that Windows remark
| but you're right to call me out for it.
|
| Microsoft get a lot of stick but Windows of the 90s do
| bring a lot to table. And by 9x DOS was basically a boot
| loader.
| netbsdusers wrote:
| The second system for Cutler was really Mica - he discusses its
| outrageous scope in his recent interview with Dave Plummer.
| nullindividual wrote:
| 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)
| markus_zhang wrote:
| Dave Cutler is really someone I look up to and wish I could
| be (but could never be due to numerous reasons). I strongly
| resonate with what he said in "Showstopper":
| What I really wanted to do was work on computers, not apply
| them to problems.
|
| And he sticks to it for half of a century.
| nyrikki wrote:
| There are a number of issues, like ignoring the role of VMS, that
| windows 3.1 had a registry, the performance problems of early NT
| that lead to the hybrid model, the hype of microkernels at the
| time, the influence of plan 9 on both etc...
|
| Cutler knew about microkernels from his work at Digital, OS/2 was
| a hybrid kernel, and NT was really a rewrite after that failed
| partnership.
|
| The directory support was targeting Netware etc...
| nullindividual wrote:
| And don't forget Alternate Data Streams for NTFS! Made
| specifically for Mac OS.
| netbsdusers wrote:
| What exactly was "hybrid" about the OS/2 kernel? "Hybrid" has
| always been basically a made up concept, but in OS/2 it seems
| especially bizarre to apply it to what's obviously a monolithic
| kernel, even one that bears a lot of similarity with older
| unix.
| nyrikki wrote:
| Real systems rarely can pass idealistic academic ideals.
|
| Balancing benefits and costs of microkernel and monolithic
| kernels is common.
|
| It looks like Google SEO gaming by removal of old content is
| making it hard to find good sources, but look at how OS/2
| used ring 2 if you want to know.
|
| Message passing and context switching between kernel and user
| mode is expensive, and if you ever used NT 3.51 that was
| clearly visible as were the BSoDs when MS shifted to more of
| a 'hybrid' model.
| AshamedCaptain wrote:
| You can even call Windows/386 or 3.x "hybrid", and in my
| opinion it would be more accurate to call Windows/386 a
| hybrid kernel than calling NT one. There's a microkernel that
| manages VMs, and there is a traditional, larger kernel inside
| each VM (either Windows itself, or DOS). The microkernel also
| arbitrates hardware between each of the VMs, but it is the
| VMs themselves that contain most of the drivers, which are
| running in "user space"!
|
| In comparison Windows NT is basically a monolithic kernel.
| Everything runs in the same address space, so there's 0
| protection. Or at least, in any definition where you call NT
| a hybrid kernel then practically any modular kernel would be
| hybrid. In later versions of NT the separations between
| kernel-mode components this post is praising have almost
| completely disappeared and even the GUI is running in kernel
| mode...
| immibis wrote:
| AFAIK, Windows 3.1's registry was only to store COM class
| information. It was just another type of single-purpose
| configuration file.
| steve1977 wrote:
| Also Richard Rashid - the project lead for Mach at CMU - joined
| Microsoft in 1991.
|
| Which is kinda interesting - Rashid went to Microsoft, Avie
| Tevanian went to NeXT/Apple.
| __d wrote:
| Rashid went to Microsoft _Research_, which is quite
| different.
| stevekemp wrote:
| I wonder how many of the features which other operating systems
| got much later, such as the unified buffer cache, were due to
| worries of software patents?
| kev009 wrote:
| UBC is one of the more technically challenging things to
| retrofit onto BSD, see
| https://www.usenix.org/legacy/event/usenix2000/freenix/full_...
| -- in particular note that it wasn't a universal performance
| improvement as of that paper. Some long lived UNIX like HP-UX
| never accomplished it.
|
| See http://mcvoy.com/lm/papers/SunOS.vm_arch.pdf and
| http://mcvoy.com/lm/papers/SunOS.vfs_arch.pdf
| PaulHoule wrote:
| (1) The has been some convergence such as FUSE in Linux which
| lets you implement file systems in user space, Proton emulates NT
| very well, and
|
| (2) Win NT's approach to file systems makes many file system
| operations very slow which makes npm and other dev systems
| designed for the Unix system terribly slow in NT. Which is why
| Microsoft gave up on the otherwise excellent WSL1. If you were
| writing this kind of thing natively for Windows you would stuff
| blobs into SQLLite (e.g. a true "user space filesystem") or ZIP
| files or some other container instead of stuffing 100,000 files
| in directories.
| nullindividual wrote:
| > 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.
| PaulHoule wrote:
| Great! I'm thinking of adding a new SSD to my machine and
| would love to try this out.
| nullindividual wrote:
| 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-...
| immibis wrote:
| I wonder how much of Linux's performance is attributable to it
| _not_ having such grand architectural visions (e.g. unified
| object manager) and therefore being able to optimize each
| specific code path more.
| chasil wrote:
| Many Linux systems on TPC.org are running on XFS (everything
| rhel-based). It's not simple, but it does appear to help SQL
| Server.
| delta_p_delta_x wrote:
| NT is why I like Windows so much and can't stand Unix-likes. It
| is object-oriented from top to bottom, and I'm glad in the 21st
| century PowerShell has continued that legacy.
|
| But as someone who's used all versions of Windows since 95, this
| paragraph strikes me the most:
|
| > What I find disappointing is that, even though NT has all these
| solid design principles in place... bloat in the UI doesn't let
| the design shine through. The sluggishness of the OS even on
| super-powerful machines is painful to witness and might even lead
| to the demise of this OS.
|
| I couldn't agree more. Windows 11 is irritatingly macOS-like and
| for some reason has animations that make it appear slow as
| molasses. What I really want is a Windows 2000-esque UI with
| dense, desktop-focused UIs (for an example, look at Visual Studio
| 2022 which is the last bastion of the late 1990s-early
| 2000s-style fan-out toolbar design that still persists in
| Microsoft's products).
|
| I want modern technologies from Windows 10 and 11 like UTF-8, SSD
| management, ClearType and high-quality typefaces, proper HiDPI
| scaling (something that took desktop Linux until this year to
| properly handle, and something that macOS doesn't actually do
| correctly despite _appearing_ to do so), Windows 11 's window
| management, and a deeper integration of .NET with Windows.
|
| I'd like Microsoft to backport all that to the combined UI of
| Windows 2000 and Windows 7 (so probably Windows 7 with the
| 'Classic' theme). I couldn't care less about transparent menu
| bars. I don't want iOS-style 'switches'. I want clear tabs, radio
| buttons, checkboxes, and a slate-grey design that is so
| straightforward that it could be _software-rasterised_ at 4K
| resolution, 144 frames per second without hiccups. I want the
| Windows 7-style control panel back.
| kev009 wrote:
| It's never been commonplace but can't you still run alternate
| shells (the Windows term for the GUI, not the command prompt in
| UNIX parlance)?
| p_l wrote:
| You still can, and it's even exposed specifically for making
| constrained setups (though not everyone knows to use it)
| bragr wrote:
| https://en.wikipedia.org/wiki/List_of_alternative_shells_for.
| ..
| chasil wrote:
| The wiki that you posted does not include busybox.
|
| https://frippery.org/busybox/index.html
| kev009 wrote:
| You didn't understand the parenthetical, busybox has no
| relation to the Windows shell.
| EricE wrote:
| Indeed the first thing I do on a new Windows install is load
| Open Shell.
| chasil wrote:
| Busybox has a great shell in the Windows port.
|
| It calls itself "bash" but it is really the Almquist shell
| with a bit of added bash syntactic sugar. It does not support
| arrays.
|
| https://frippery.org/busybox/index.html
| nullindividual wrote:
| > 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_!
| EvanAnderson wrote:
| > The common end user wants flashy, sleek, stylish (and
| apparently CandyCrush).
|
| Do they, though? I get the impression that nobody is actually
| testing with users. It seems more like UI developers want
| "flashy, sleek, stylish" and that's what's getting jammed
| down all our throats.
| mattkevan wrote:
| As a UI designer and developer, I would push the blame
| further along the stack and say that execs and shareholders
| want "flashy, sleek, stylish", in the same way everything
| has to have AI jammed in now, lest the number start going
| down or not up quite as fast as hoped.
| EvanAnderson wrote:
| I love that NT was actually designed. I don't necessarily like
| all of the design but I like that people actually thought about
| it.
| AshamedCaptain wrote:
| > The sluggishness of the OS even on super-powerful machines is
| painful to witness and might even lead to the demise of this
| OS.
|
| NT has been sluggish since _forever_. It is hardly a bloated
| GUI problem. On machines were 9x would literally fly NT would
| fail to boot due to low memory.
| nullindividual wrote:
| 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.
| reisse wrote:
| Ah, it's a cycle repeating itself. I remember when Microsoft
| first released XP it was considered bloated (UI-wise) compared
| to Windows 2000 and Windows 95/98/ME. Then Vista came and all
| of a sudden XP was in the limelight for being slim and fast!
| aleph_minus_one wrote:
| Even when Vista came, people told all the time that they
| consider Windows 2000 to be much less UI-bloated than Windows
| XP; it was just that of the "UI bloat evils" Windows XP was
| considered to be the lesser evil than Windows Vista. I really
| heard nobody saying that XP was slim and fast.
|
| BTW: Windows 7 is another story: at that time PC magazines
| wrote deep analyses how some performance issues in the user
| interface code of Windows Vista that made Vista feel
| "sluggish" were fixed in Windows 7.
| heraldgeezer wrote:
| I mean yes the default XP UI looks like bloated fisher price
| UI. But it has a classic mode that makes it look like Win
| 2000.
|
| https://en.wikipedia.org/wiki/Windows_XP_visual_styles#Windo.
| ..
| markus_zhang wrote:
| Win 2000 was the pinnacle. I stuck to it until WinXP was almost
| out of breath and reluctantly moved to it. Everything
| afterwards is pretty meh.
| pcwalton wrote:
| > slate-grey design that is so straightforward that it could be
| software-rasterised at 4K resolution, 144 frames per second
| without hiccups
|
| This is not possible (measure software blitting performance and
| you'll see), and for power reasons you wouldn't want to even if
| it were.
| Melatonic wrote:
| Agreed on you with everything here
|
| That being said if you run something like Win10 LTSC (basically
| super stripped down win10 with no tracking and crapware) and
| turn off all window animations / shadows / etc you might be
| very surprised - it is snappy as hell. With a modern SSD stuff
| launches instantly and it is a totally different experience.
| andrewla wrote:
| Practically speaking there are a number of developer-facing
| concerns that are pretty noticeable. I'm primarily a Linux user
| but I worked in Windows for a long time and have grown to
| appreciate some of the differences.
|
| For example, the way that command line and globbing works are
| night and day, and in my mind the Windows approach is far
| superior. The fact that the shell is expected to do the globbing
| means that you can really only have one parameter that can
| expand. Whereas Win32 offers a FindFirstFile/FindNextFile
| interface that lets command line parameters be expanded at
| runtime. A missing parameter in unix can cause crazy behavior --
| "cp *" but on windows this can just be an error.
|
| On the other hand, the Win32 insistence on wchar_t is a disaster.
| UTF-16 is ... just awful. The Win32 approach only works if you
| assume 64k unicode characters; beyond that things go to shit very
| quickly.
| stroupwaffle wrote:
| If wchar_t holds the majority of code points for given use,
| then there are some benefits to having a fixed-width character
| and certain algorithms.
|
| But it is fairly easy to convert wchar_t to-and-from UTF8
| depending on use.
|
| UTF16 is not _awful_ it is the same as an 8-bit character set
| but twice longer.
| andrewla wrote:
| UTF-16 is fine so long as you are in Plane 0. Once you have
| to deal with surrogate pairs, then it really is awful. Once
| you have to deal with byte-order-markers you might as well
| just throw in the towel.
|
| UTF-8 is well-designed and has a consistent mechanism for
| expanding to the underlying code point; it is easy to
| resynchronize and for ASCII systems (like most protocols) the
| parsing can be dead simple.
|
| Dealing with Unicode text and glyph handling is always going
| to be painful because this problem is intrinsically
| difficult. But expansion of byte strings to unicode code
| points should not be as difficult as UTF-16 makes it.
|
| Windows was converted to UCS-2 before higher code planes were
| designed and they never recovered.
| Dwedit wrote:
| The wchar_t thing is made much worse by disagreements on what
| type that actually is. On Win32, it's a 16-bit type, guaranteed
| to be UTF-16 code points (or surrogate pairs). But on some
| other compilers and operating systems, wchar_t could be a
| 32-bit type.
|
| Another problem with UTF-16 on Windows is that it does not
| enforce that surrogate pairs are properly matched. You can have
| valid filenames or passwords that cannot be encoded in UTF-8.
| The solution was to create another encoding system called
| "WTF-8" that allows unmatched surrogate pairs to survive a
| round trip to and from UTF-16.
| progmetaldev wrote:
| Is this just a really good joke, or something real? I enjoyed
| it, regardless!
| Dwedit wrote:
| It was previously discussed at
| https://news.ycombinator.com/item?id=9611710
| jhallenworld wrote:
| Wchar_t is definitely the biggest annoying difference in that
| it shows up everywhere in your C/C++ source code.
| TillE wrote:
| It depends on what you're doing, but after many years I've
| just settled on consistently using UTF-8 internally and
| converting to UCS-2 at the edges when interacting with Win32.
|
| There's just too much UTF-8 input I also need to take, and
| converting those to wstring hurts my heart.
| rbanffy wrote:
| NT was more ambitious from the start, and this might be one of
| the reasons why it didn't age so well: the fewer decisions you
| make, the fewer mistakes you'll have to carry. GNU/Linux (the
| kernel, GNU's libc, and a handful of utilities) is a very
| simple, very focused OS. It does not concern itself about
| windows or buttons or mice or touchscreens. Because of that,
| it's free to evolve and tend to different needs, some of which
| we are yet to see. Desktop environments come and go, X came and
| mostly went, but the core has evolved while keeping itself as
| lean as technically possible.
| andrewla wrote:
| This is more of a sweeping generalization than I think would
| be appropriate.
|
| The command line handling as I note above is a really crufty
| old Unix thing that doesn't make sense now and is confusing
| and offputting when you get papercuts from it.
|
| Another notable thing that they talk about to an extent is
| process creation -- the fork/exec model in Linux is basically
| completely broken in the presence of threads. The number of
| footguns involved in this process has now grown beyond the
| ability of a human to understand. The Windows model, while a
| bit more cumbersome seeming at first, is fully generalizable
| and very explicit about the handoff of handles between
| processes.
|
| The file system model I think is mostly a wash -- on the one
| hand, Window's file locking model means that you can't always
| delete a file that's open, which can be handy. On the other
| hand, it means that you can't always delete a file that's
| open, which can be painful. On Linux, it's possible that
| trying to support POSIX file system semantics can result in
| unrecoverable sleeps that are nearly impossible to diagnose
| or fix.
| panzi wrote:
| Hard disagree. The way Windows handles command line parameters
| is bonkers. It is one string and every program has to
| escape/parse it themselve. Yes, there is CommandLineToArgvW(),
| but there is no inverse of this. You need to escape the
| arguments per hand and can't be sure the program will really
| interpret them the way you've intended. Even different programs
| written by Microsoft have different interpretations. See the
| somewhat recent troubles in Rust: https://github.com/rust-
| lang/rust/security/advisories/GHSA-q...
| chasil wrote:
| As I understand it, CMD.EXE came from OS/2 and has had many
| revisions that allow more pervasive evaluation of variables
| (originally, they were expanded only once, at the beginning
| of a script).
|
| The .BAT/.CMD to build the Windows kernel must have
| originally been quite the kludge.
|
| Including pdksh in the original Windows NT might have been a
| better move.
|
| https://blog.nullspace.io/batch.html
| pmontra wrote:
| I quote URLs and "file names" with double quotes in Linux
| bash much like I quote "Program Files" in Windows cmd. It's
| the same. I quote spaces\ with\ a\ backslash\ sometimes.
| andrewla wrote:
| Question of where the pain goes, I guess. In unix, having to
| deal with shell escaping when doing routine tasks is super
| annoying -- URLs with question marks and ampersands screwing
| everything up, and simple expansions (like the `cp *` example
| above) causing confusing.
|
| Yes, Windows resolution and glob expansion can be
| inconsistent, but it usually isn't, but Unix makes you eat
| the cruft every time you use it. And you still get tools like
| ImageMagick that have strange ad hoc syntax for wildcard
| because they can't use the standard wildcarding, or even
| ancient tools like find that force you to do all sorts of
| stupid shit to be compatible with globbing.
| rwmj wrote:
| I had to write something to deal with quoting Windows
| _spawnvp and it's insane:
|
| https://gitlab.com/nbdkit/nbdkit/-/blob/0b4a47b5430f8b757f51.
| ..
| SkiFire13 wrote:
| > See the somewhat recent troubles in Rust:
| https://github.com/rust-
| lang/rust/security/advisories/GHSA-q...
|
| FYI this started out as a vulnerability in yt-dlp [1]. Later
| it was found to impact many other languages [2]. Rust, along
| with other languages, also considered it a vulnerability to
| fix, while some other languages only updated the
| documentation or considered it as wontfix.
|
| [1]: https://github.com/yt-dlp/yt-
| dlp/security/advisories/GHSA-42...
|
| [2]: https://flatt.tech/research/posts/batbadbut-you-cant-
| securel...
| pcwalton wrote:
| It's really strange to me that Microsoft has never added an
| ArgvToCommandLineW(). This would solve most of the problems
| with Windows command line parsing.
| mixmastamyk wrote:
| > command line and globbing
|
| Both Unix and NT are suboptimal here. I believe there was an OS
| lost to time (and my memory) that had globbing done by the
| program but using an OS-provided standard library. Probably the
| best way to do it consistently. That said, having to pick the
| runner up, I prefer the Unix way. As the unpredictable results
| happened to me more often on NT than... for example your cp
| example, which though possible I don't think I've ever done in
| my career.
|
| The rest of command.com/cmd.exe is so poorly designed as to be
| laughable, only forgiven for being targeted to the PC 5150, and
| should have been retired a few years later. Makes sh/bash look
| like a masterpiece. ;-)
| andrewla wrote:
| Win32 in theory has globbing done by an OS-provided standard
| library -- the `FindFirstFile` and `FindNextFile` win32 calls
| process globbing internally, and they are what you are
| expected to use.
|
| Some applications choose to handle things differently,
| though. For example, the RENAME builtin does rough pattern-
| matching; so "REN _.jpg_.jpg.old " will work pretty much the
| way that intuition demands that it work, but the latter
| parameter cannot be globbed as there no such files when this
| command begins to execute. Generally speaking this can get
| pretty messy if commands try to be clever about wildcard
| expansion against theoretical files.
| dspillett wrote:
| Not even UTF16. Just UCS2 for a long time.
| jmmv wrote:
| OP here. I did not touch upon CLI argument handling in this
| article because I wanted to focus on the kernel but this is
| indeed a big difference. And... I had written about this too :)
| https://jmmv.dev/2020/11/cmdline-args-unix-vs-windows.html
| chasil wrote:
| I would imagine that Windows was closer to UNIX than VMS was, and
| there were several POSIX ports to VMS.
|
| VMS POSIX ports:
|
| https://en.m.wikipedia.org/wiki/OpenVMS#POSIX_compatibility
|
| VMS influence on Windows:
|
| https://en.m.wikipedia.org/wiki/Windows_NT#Development
|
| "Microsoft hired a group of developers from Digital Equipment
| Corporation led by Dave Cutler to build Windows NT, and many
| elements of the design reflect earlier DEC experience with
| Cutler's VMS, VAXELN and RSX-11, but also an unreleased object-
| based operating system developed by Cutler at Digital codenamed
| MICA."
|
| Windows POSIX layer:
|
| https://en.m.wikipedia.org/wiki/Microsoft_POSIX_subsystem
|
| Xenix:
|
| https://en.m.wikipedia.org/wiki/Xenix
|
| "Tandy more than doubled the Xenix installed base when it made
| TRS-Xenix the default operating system for its TRS-80 Model 16
| 68000-based computer in early 1983, and was the largest Unix
| vendor in 1984."
|
| EDIT: AT&T first had an SMP-capable UNIX in 1977.
|
| "Any configuration supplied by Sperry, including multiprocessor
| ones, can run the UNIX system."
|
| https://www.bell-labs.com/usr/dmr/www/otherports/newp.pdf
|
| UNIX did not originally use an MMU:
|
| "Back around 1970-71, Unix on the PDP-11/20 ran on hardware that
| not only did not support virtual memory, but didn't support any
| kind of hardware memory mapping or protection, for example
| against writing over the kernel. This was a pain, because we were
| using the machine for multiple users. When anyone was working on
| a program, it was considered a courtesy to yell "A.OUT?" before
| trying it, to warn others to save whatever they were editing."
|
| https://www.bell-labs.com/usr/dmr/www/odd.html
|
| Shared memory was "bolted on" with Columbus UNIX:
|
| https://en.m.wikipedia.org/wiki/CB_UNIX
|
| ...POSIX implements setfacl.
| jhallenworld wrote:
| NT has its object manager.. the problem with it is visibility.
| Yes, object manager type functionality was bolted-on to UNIX, but
| at least it's all visible in the filesystem. In NT, you need a
| special utility WinObj to browse it.
| anthk wrote:
| Under ReactOS you have a bundled NT obj explorer under
| explorer.exe and maybe shell32.dll.
|
| Maybe if you can run that explorer under NT systems you could
| explore them under the original NT OSes too.
|
| Edit: https://winclassic.net/thread/1852/reactos-registry-
| ntobject...
| rbanffy wrote:
| I don't think the registry is a good idea. I don't mind every
| program having its own dialect of a configuration language, all
| under the /etc tree. If you think about it, the /etc tree is just
| a hierarchical key-value store implemented as files where the
| persistent format of the leaf node is left to its implementer to
| decide.
| mixmastamyk wrote:
| I like what the elektra project was trying to do, but it didn't
| catch on. Basically put config into the filesystem with a
| standard schema, etc. Could use basic tools/permissions on it,
| rsync it, etc. Benefits of the registry but less prone to
| failure and no tools needed to be reinvented.
| phendrenad2 wrote:
| So what's wrong with the registry if a file-based registry is
| okay? The registry could be an abstraction layer over a Unix
| /etc filesystem, after all.
| runjake wrote:
| The NT kernel is pretty nifty, albeit an aging design.
|
| My issue with Windows as an OS, is that there's so much cruft,
| often adopted from Microsoft's older OSes, stacked on top of the
| NT kernel effectively circumventing it's design.
|
| You frequently see examples of this in vulnerability write-ups:
| "NT has mechanisms in place to secure $thing, but unfortunately,
| this upper level component effectively bypasses those
| protections".
|
| I know Microsoft would like to, if they considered it "possible",
| but they really need to move away from the Win32 and MS-DOS
| paradigms and rethink a more native OS design based solely on NT
| and evolving principles.
| anthk wrote:
| Win32 is not the issue, MS could just create shims for these in
| a secure way. It's 2024, not 1997.
|
| Ditto with GNU/Linux and old SVGAlib games. It already should
| have been some a wrapper against SDL2.
| runjake wrote:
| I'm not sure what you're trying to say here, but those
| "shims" exist. Apps generally do not talk directly to the
| Executive (kernel). Instead, the OS has protected subsystems
| that publish APIs.
|
| Apps talk to the subsystem, and the subsystem talks to the
| Executive (kernel).
|
| Traditionally, Windows apps talk to the Win32 subsystem[1].
| This subsystem, as currently designed, is an issue as
| described in my previous comment.
|
| 1. https://en.wikipedia.org/wiki/Architecture_of_Windows_NT#W
| in...
|
| Caveat: Details of this may have changed in the last couple
| major Windows versions. I've been out of the NT game for a
| bit. Someone correct me, if so.
| fortran77 wrote:
| > The NT kernel is pretty nifty, albeit an aging design.
|
| Unix is an Apollo-era technology! Also an aging design.
| UniverseHacker wrote:
| Except unix nowadays is just a set of concepts and
| conventions incorporated into modern OSs
| phendrenad2 wrote:
| What percent of Unix users are using a "modern OS" and what
| percentage are using Linux, which hasn't significantly
| changed since it was released in 1994?
| SSLy wrote:
| let's be charitable, removal of global lock was fairly
| big change.
| jiggawatts wrote:
| How "modern" are they when they're just a bunch of shell
| scripts on top of POSIX? SystemD caught up to NT4 and the
| original MacOS.
| ElectricalUnion wrote:
| If by "modern" you mean stuff between 1930 and 1970, sure,
| most contemporany OSes can trace roots from that era.
| marcodiego wrote:
| I created a file named aux.docx on a pendrive with Linux. Tried
| to open it on windows 7. It crashed word with a strange error.
| Don't know what would happen on 8+.
| monocasa wrote:
| It's a dos holdover implemented in the win32 side of things
| in user space. I'm pretty sure it still exists on win11.
|
| https://stackoverflow.com/questions/40794287/cannot-write-
| to...
| uncanneyvalley wrote:
| It would fail, too. 'CON' has been a reserved name since the
| days of DOS (actually CP/M, though that doesn't have direct
| lineage to Windows) where it acted as a device name for the
| console. You can still use it that way. In a CMD window:
|
| `type CON > file.txt`, then type some stuff and press CTRL+Z.
|
| https://learn.microsoft.com/en-
| us/windows/win32/fileio/namin...
| nullindividual wrote:
| This is a Win32-ism rather than an NT-ism. This will work:
| mkdir \\.\C:\COM1
| robotnikman wrote:
| The backwards compatibility though is one of the major features
| of windows as an OS. That fact that a company can still load
| some software made 20 years ago developed by a company that is
| no longer in business is pretty cool (and I've worked at such
| places using ancient software on some windows box, sometimes
| there's no time or money for alternatives)
| sedatk wrote:
| That and it's 30+ years (NT was released in 1993). Backwards
| compatibility is certainly one of the greatest business value
| Microsoft provides to its customers.
| ozim wrote:
| People tend to forget that it already is 2024.
| runjake wrote:
| > The backwards compatibility though is one of the major
| features of windows as an OS.
|
| It is. That's even been stated by MSFT leadership time and
| time again.
|
| But at what point does that become a liability?
|
| I'm arguing that point was about 15-20 years ago.
| nox101 wrote:
| Seems to me they should pull an Apple. Run everything old in
| some "rosetta" like system and then make something 100% new and
| try to get people to switch, like say no new updates except
| security updates for the old system so that apps are
| incentivized to use the new one.
| mepian wrote:
| Carbon is a better Apple-related comparison since it's
| basically a cleaned-up version of the classic Mac OS API as a
| library that ran on both Mac OS X and classic.
| phendrenad2 wrote:
| > an aging design
|
| What does that mean, exactly? Linux is also an "aging design",
| unless I missed a big announcement where they redesigned it at
| any point since 1994.
| HPsquared wrote:
| cf Terry Davis saying "Linux wants to be a 1970s mainframe".
| runjake wrote:
| That was in response to the beginning of the article:
|
| "I've repeatedly heard that Windows NT is a very advanced
| operating system"
|
| It's _very advanced_ for decades ago. It 's not meant as an
| insult.
|
| About 20 years ago, despite being a Linux/UNIX/BSD diehard, I
| went through the entire Inside Windows NT book word by word
| and took up low-level NT programming and gained a deep
| respect for it and Dave Cutler. Also a h/t to Russinovich who
| despite having better things to do running Winternals
| Software[1], would always patiently answer all my questions.
|
| 1. https://en.wikipedia.org/wiki/Sysinternals
| bawolff wrote:
| > Internationalization: Microsoft, being the large company that
| was already shipping Windows 3.x across the world, understood
| that localization was important and made NT support such feature
| from the very beginning. Contrast this to Unix where UTF support
| didn't start to show up until the late 1990s
|
| I feel like this is a point for unix. Unix being late to the
| unicode party means utf-8 was adopted where windows was saddled
| with utf-16
|
| ---
|
| The NT kernel does seem to have some elegance. Its too bad it is
| not open source; windows with a different userspace and desktop
| environment would be interesting.
| chungy wrote:
| Windows would be so much better if it were actually UTF-16.
| It's worse than that: it's from a world where Unicode thought
| "16-bits ought to be enough for anybody" and Windows NT baked
| that assumption deep into the system; it wasn't until 1996 that
| Unicode had to course-correct, and UTF-16 was carved out to be
| mostly compatible with the older standard (now known as UCS-2).
| For as long as you don't use the surrogate sequences in
| strings, you happen to be UTF-16 compatible; if you use the
| sequences appropriately, you happen to be UTF-16 compatible; if
| you use them in invalid ways to UTF-16, now you've got a mess
| that's a valid name on the operating system.
|
| I can't really blame NT for this, it's unfortunate timing and
| it remains for backwards compatibility purposes. Java and
| JavaScript suffer similar issues for similar reasons.
| chungy wrote:
| I'll throw this out there too: UTF-8 isn't necessarily better
| than UTF-16; they both support the entirety of the Unicode
| character space.
|
| UTF-8 is convenient on Unix systems since it fits into 8-bit
| character slots that were already in place; file systems have
| traditionally only forbidden the NULL byte and forward-slash,
| and all other characters are valid. From this fact, you can
| use UTF-8 in file names with ease on legacy systems, you
| don't need any operating system support for it.
|
| UTF-8 is "space optimized" for ASCII text, while most extra-
| ASCII Latin, Cyrillic, Greek, Arabic characters need two
| bytes each (same as UTF-16); most of Chinese/Japanese/Korean
| script in the BMP requires three bytes in UTF-8, whereas you
| still only need two bytes in UTF-16. To go further beyond,
| all SMP characters (eg, most emoji) require four bytes each
| in both systems.
|
| Essentially, UTF-8 is good space-wise for mostly-ASCII text.
| It remains on-par with UTF-16 for most western languages, and
| only becomes more inefficient than UTF-16 for east-Asian
| languages (in such regions, UTF-16 is already dominant).
| bawolff wrote:
| Space savings are irrelavent. Text is small, and after gzip
| its going to be the same anyways.
|
| Seriously, when was the last time where you both cared
| about saving a single kb, but compression was not an
| option. I'm pretty sure the answer is never. It was never
| in the 90s, it is extra never now that we have hard drives
| hundreds of gb big.
|
| UTF-8 is better because bytes are a natural unit. You dont
| have to worry about surrogates. You dont have to worry
| about de-synchronization issues. You dont have to worry
| about byte order.
|
| Backwards compatibility with ascii and basically every
| interface ever, also helps. (Well not 7bit smtp..). The
| fact is, ascii is everywhere. Being able to treat it as
| just a subset of utf-8 makes a lot of things easier.
|
| > (eg, most emoji) require four bytes each in both systems.
|
| This is misleading because most emoiji are not just a
| single astral character but a combination of many.
| Circlecrypto2 wrote:
| A great article that taught me a lot of history. As a long time
| Linux user and advocate for that history, I learned there is
| actually a lot to appreciate from the work that went into NT.
| RachelF wrote:
| The original NT was a great design, built by people who knew
| what they were doing and had done it before (for VMS). It was
| superior to the Unix design when it came out, benefiting from
| the knowledge of 15 years.
|
| I worked on kernel drivers starting in with NT 3.5. However,
| over the years, the kernel has become bloated. The bloat is
| both in code and in architecture.
|
| I guess this is inevitable as the original team has long gone,
| and it is now too large for anyone to understand the whole
| thing.
| parl_match wrote:
| > Unix's history is long--much longer than NT's
|
| Fun fact: NT is a spiritual (and in some cases, literal)
| successor of VMS, which itself is a direct descendant of the RSX
| family of operating systems, which are themselves a descendant of
| a process control family of task runners from 1960. Unix goes
| back to 1964 - Multics.
|
| Although yeah, Unix definitely has a much longer unbroken chain.
| phendrenad2 wrote:
| One thing I don't see mentioned in this article, and I consider
| to be the #1 difference between NT and Unix, is the approach to
| drivers.
|
| It seems like NT was designed to fix a lot of the problems with
| drivers in Windows 3.x/95/98. Drivers in those OSs came from 3rd
| party vendors and couldn't be trusted to not crash the system. So
| ample facilities were created to help the user out, such as "Safe
| Mode" , fallback drivers, and a graphics driver interface that
| disables itself if it crashes too many times (yes really).
|
| Compare that to any Unix. Historic, AT&T Unix, Solaris, Linux,
| BSD 4.x, Net/Free/OpenBSD, any research Unix being taught at
| universities, or any of the new crop of Unix-likes such as Redox.
| Universally, the philosophy there is that drivers are high-
| reliability components vetted and likely written by the kernel
| devs.
|
| (Windows also has a stable driver API and I have yet to see a
| Unix with that, but that's another tangent)
| p0seidon wrote:
| This is such a well-written read, just so insightful and broad in
| its knowledge. I learned a lot, thank you (loved NT at that time
| - now I know why).
___________________________________________________________________
(page generated 2024-09-09 23:00 UTC)