It really was nice to be able to at least still use the system if the display driver is crashing. 800x600 at 16 bit or whatever it was is still better than nothing.

Then almost immediately took them back out after realizing this was a bad idea

APIs used by crowdstrike et al are also what made WSL1 unworkable performance-wise. Can’t have security without slowness nowadays it seems.

Safe Mode existed in Win9x.

User space drivers that could restart without kernel panicking didn't exist until Windows Vista (well, on the home user side of Windows).

Fallback drivers were never a thing on Win9x, you would have to go into safe mode to uninstall broken drivers that wouldn't allow a boot (typically graphics drivers); or manually uninstall/replace them otherwise.

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.

Vaxes also had hardware support for ASTs in VMS (unlike NT) - they were essentially software interrupts that only triggered when the CPU was in a process context and no enabled interrupts were pending - so you could set a bit in a mask in another thread's context that would get loaded automatically on context switch and triggered once the thread was runnable in user mode .... device drivers could trigger a similar mechanism in kernel mode (and the 2 intermediate hardware modes/rings). There were also atomic queue instructions that would dispatch waiting ASTs

Especially since there was, apparently, MICA code copy pasted verbatim in NT.

https://www.techmonitor.ai/technology/dec_forced_microsoft_i...

I was wondering for years why MS continued to support DEC Alpha CPUs with NT.

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.

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.

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.

notably the NT equivalent of select(): WaitForSingleObject and WaitForMultipleObjects had a benefit that one select/wait type syscall could be tickled by any of a network, file or the NT equivalent of a pthread signal.

Originally, Windows NT 3.x was more "microkernelithic" as graphics and printer drivers where isolated. NT 4 moved them to Kernel mode to speedup the system.

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.

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.

For the record, NT comes from the codename for the Intel i860 (N10) which was the original target platform for NT.

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

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

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

In true Windows form, you have a memory access error.

Actually

M->N

Could you please explain on those characters ? What do they mean ? Thnks.

Yeah, we cannot see very far into the future and betting that system software will remain stagnate is not a good bet. If that means wholesale replacement, few of us will understand it at first. Otherwise retrofits will remain the norm for example one old idea that seems to be on the up and up is hardware-enforced capability systems and those working on them have found plausible ways to retain most of the existing C ABI world. Whether it always remains a good idea to continue propping up the past is one of the hardest questions and ultimately will be more of an economic one.

There are obsolete systems that meet your criteria, Plan 9 and Apollo Domain/OS had plausible early answers for networked computing that haven't been adequately explored.

For your last point, I would say scheduling, security, namespacing are the core features and everything else can be layered (perhaps interchangeably) on top. As a practical example, even in monolithic FreeBSD it supports fully runtime swappable TCP/IP stacks and out of tree network stacks.. the core illusion for that system is retaining the same Socket interface for userspace. Presumably if you get the namespacing thing right the entire system and network of things would look a lot more like deliberately interchangeable parts.

I believe we are obliquely agreeing.

To further my thoughts a bit, the distinction I would place on OS/2 over DOS is double: 1) first class memory protection 2) full preemptive multitasking. The distinction I would place against all widely used modern desktop OSes is the lack of first class multi-user support.

Early Windows gains cooperative multi-tasking like Mac OS classic but neither fundamentally use memory protection the way later OSes normalize and that turns out to be a pretty clear dead end. I believe there are extensions for both that retrofit protection in. Both also have some add on approaches to multi-user but are not first class designs.

So, even the most robust single user system that implements full memory protection and preemptive multitasking still seems to be stuck in a valley. I.e. whatever the actual cost in terms of implementation and increase in cognitive workload for single user systems (i.e. "enter your administrative password" prompts on current macOS or Windows administrative accept dialogs) seems to be accepted by the masses.

And note that this isn't an implicit a negative judgement, for instance I find BeOS or those in your list can be absolutely fascinating. And OS/2 is lovely even today for certain niche or retrocomputing things. Just pointing out that NT made a better bet for the long term, and some of that undoubtedly related to the difference of a couple years.. keep in mind OS/2 ran on a 286, which NT completely bypassed.

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

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

How dare you ignore BeOS which isn't Windows or Nix

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.

I recall DRAM prices restricting the uptake of OS/2 also.

Definitely impactful for NT4, not for 2000.

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.

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)

Only in the user's perception. The implementation is nothing like UNIX, being a Mach2.5 derivative and later additions like DriverKit.

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

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.

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

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.

I had to write something to deal with quoting Windows _spawnvp and it's insane:

https://gitlab.com/nbdkit/nbdkit/-/blob/0b4a47b5430f8b757f51...

PS: Somewhat related, look at the bonkers way Windows resolves the program to execute from the command line string: https://learn.microsoft.com/en-us/windows/win32/api/processt...

PPS: Even less related, there's no exec() in Win32, so you can't write a starter program that does some setup and then runs another program (e.g. specified as a parameter). You need to keep the starter program open and act as a proxy to the started program! See the various dotenv CLI implementations. But I digress.

WTF-8 barely qualifies as "another encoding system" - it's a trivial superset of UTF-8 that omits the rule forbidding surrogate codes.

Imo that artificial restriction in UTF-8 is the problem.

Is this just a really good joke, or something real? I enjoyed it, regardless!

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.

Sorry but your argument is baseless. There is nothing in NT kernel that forces a certain UI toolset nor it deals with the UI anymore (it briefly did when PCs were less powerful via GDI API, not anymore). Linux kernel and its modesetting facilities are quite a bit invasive and it is Linux that forces a certain way of implementing GPU drivers.

Windows just requires a set of functions from the driver to implement. Win32 drawing APIs are now completely userspace APIs and Windows actually did implement a couple of different ones.

Browsers switched to using a single graphics API canvas component long ago. Instead of relying on high level OS graphics API, they come with their own direct renderers that's opaque to the OS apart from the buffer requests. This approach can utilize GPUs better. Windows was among the first systems to implement the same as a UI component library. It is called WPF and it is still the backbone of many non-Win32 UI elements on Windows. On the Linux side, I think Qt was the first to implement such a concept with QML / QtQuick which is much later than WPF.

Moreover your argument that Unix evolves better or more freely falls apart when you consider that we had to replace X. On Unix world, the tendency to design "minimal" APIs that are close to hardware is the source of all evil. Almost any new technology requires big refactoring projects from application developers in the Unix world since the system programmers haven't bothered to design future-proof APIs (or they are researchers / hobbyists who don't have a clue about the current business and user needs nor upcoming tech).

Windows didn't need to replace Win32 since it was designed by engineers who understood the needs of businesses and designed an abstract-enough API that can survive things like introduction of HiDPI screens (which is just a "display changed please rerender" event). It is simply a better API.

On the Unix side X was tightly designed as around 96 or 72 DPI screens and everything had to be bolted on or hacked since the APIs were minimal or tightly coupled with the hardware capabilities at the time. Doing direct rendering on X was a pain in the ass and had an intertwined web of silly hacks which was why the DEs in 2010s kept discovering weird synchronization bugs and it was why Wayland needed to be invented.

> an API that passes through ASCII or locale-based ANSI can have its docs changed to say UTF-8 without really being wrong

Actually, it can be wrong, and it is not necessarily a good idea to do this anyways (actually, is almost always is not a good idea to do this (just changing the documentation), I think, unless the problem was an error in the original documentation). Sometimes it is better to say that it is ASCII but allows 8-bit characters as well (without caring what they are), or something like that. For font rendering, it will be necessary to be more specific although it might depend on the font as well.

> it is obvious that UTF-16 is worse

UTF-16 is not always worse. It depends both on the program (and what requirements it has for processing the text) and on the language of the text. And then, there is also UTF-32. (And sometimes, Unicode is worse regardless of the encoding.)

UTF-8 wasn't a thing when the decision to go with UTF-16 was made.

UTF-8 became a thing shortly thereafter and everyone started laughing at MS for having followed the best industry standard that was available to them when they had to make a choice.

Windows, I believe, is WTF-16. It permits surrogates (e.g., you can stick an emoji in a filename) — thus it cannot be UCS-2. It permits unpaired surrogates — thus it cannot be UTF-16.

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.

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.

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.

Because modern world is full of computers with slow mobile CPUs and high-resolution high refresh rate displays. On such computers you need a 3D GPU to render anything, even a scrolling text, at the refresh rate of the display.

A 3D GPU is a shared hardware resource just like a disk. GPU resources are well-shaped slices of VRAM which can store different stuff, just like files are backed by the blocks of the underlying physical disks. User-space processes need to create and manipulate GPU resources and pass them across processes, just like they do with files on disks.

An OS kernel needs to manage 3D GPU resources for the same reason they include disk drivers and file system drivers, and expose consistent usermode APIs to manipulate files.

It seems Linux kernel designers mostly ignored 3D GPUs. The OS does not generally have a GPU API: some systems have OpenGL, some have OpenGL ES, some have Vulkan, some have none of them.

Why should a kernel have anything? Because it's useful and convenient, as the OP mentioned.

Rashid went to Microsoft _Research_, which is quite different.

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.

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

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

The registry would have been better if there were a stronger concept of "ownership" of the data it contains, tying each key to the responsible app / subsystem. I've tracked hundreds of software uninstalls and I would bet only about 1% of them actually remove all the cruft they originally stick in (or populated during use). The result is bloat, a larger surface area for corruption, and system slowdown.

Ironically in this respect it was a step backward... When settings lived in INI files, convention typically kept them in the same place as the program, so they were easy to find and were naturally extinguished when you deleted the software.

If you look at more modern OS's like Android and iOS they tend to enforce more explicit ties between apps and their data.

And since it supports variable-lenght binary values, it fully supports that "the persistent format of the leaf node is left to its implementer to decide".

What exactly do I gain from the registry that compensates for the fact I can use any tool that works on files to manage the /etc tree?

Can you manage registry folders with Git and keep track of the changes you make? Can you grep for content? On a Mac it’s indexed by the systemwide text search tooling.

Using the file system to store that data is extremely powerful.

I have no issue with the concept, but in practice the Windows registry is a lot more obfuscated than it needs to be. There can be trees and trees of UUIDs or similar, and there is no need for it to be so user unfriendly.

Part of this might be mixing internal stuff that people never need to see with stuff that people will need to access.

Labeling, fstab is supposed to be a .tsv, what happens if I mistype something? where's the safety? Does this need to be a DSL?

"rm -rf /etc/nginx" versus "try to remember where are the miriads of random keys spread everywhere"

> thanks to modern hardware, very little performance penalty

I would not call 1 order of magnitude performance penalty for accessing a local file system “little”: https://github.com/microsoft/WSL/issues/4197

I think (but am not sure) that WSL was a consolation prize of the cancelled Project Astoria, the initiative from the dying days of Windows Phone to support running Android apps on Windows. Implementing this with virtualisation would have been more painful and less practical on the smartphones of the day.

Honestly, before WSL 1 was a thing, Cygwin already existed, and it was good enough for most people.

Great! I’m thinking of adding a new SSD to my machine and would love to try this out.

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.

Indeed. And importantly, you could tell exactly which UI elements were which. It's sometimes genuinely difficult to tell if an element is text, a button, or a button disguised as a link on Windows 10/11.

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

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.

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

I run LTSC. You still get the tracking and some crapware sadly.

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.

https://en.wikipedia.org/wiki/List_of_alternative_shells_for...

Indeed the first thing I do on a new Windows install is load Open Shell.

You still can, and it's even exposed specifically for making constrained setups (though not everyone knows to use it)

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

Windows 7 was pretty great.

No, it was a real hypervisor, running VMs (and DOS) in ring 3. They didn't call it VMM32 for nothing.

I remember using NT4 for web dev work in the later 90's... was kind of funny how many times browsers (Netscape especially) would crash from various memory errors that never happened in Win9x... how many of those were early exploits/exploitable issues. That and dealing with Flash around that time, and finding out I can access the filesystem.

I pretty much ran NT/Win2K at home for all internet stuff from then on, without flash at all. I do miss the shell replacement I used back in those days, I don't remember the name, but also remember Windowblinds.

I think it's because that architecture was less understood than the traditional OS model at the time; and they could've easily virtualised more of the hardware and gradually made passthrough not the default, eventually arriving at something like Xen and other bare-metal hypervisors that later became common.

...and as the sibling comment alludes to, MS eventually adopted that architecture somewhat with Hyper-V and the VBS feature, but now running NT inside of the hypervisor instead of protected-mode DOS.

If you look at more recent Windows APIs, I'm really thankful that the traditional Win32 APIs still work. On average the older APIs are much nicer to work with.

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.

  > The backwards compatibility though is one of the major features of windows as an OS.

But at what point does that become a liability?

I'm arguing that point was about 15-20 years ago.

It is a great achievement. But the question is: Is it really relevant? Couldn't they move the compatibility for larger parts to a VM or other independent Subsystem?

Of course even that isn't trivial, as one wants to share filesystem access (while I can imagine some overlay limiting access), might need COM and access to devices ... but I would assume they could push that a lot more actively. If they decided which GUI framework to focus on.

My question is why cant M$ ship the old OS running as VM. And free themselves from Backward compatibility on a newer OS.

If 20 years is so ancient, why did they go by so fast....

It's possible that wine is more "backwards compatible" than the latest version of Windows though.

And while wine doesn't run everything, at least it doesn't circumvent security measures put in place by the OS...

> I'd love if it Microsoft simply abandoned NT and threw their weight behind the Linux kernel

I don't understand why people keep repeating this wish, rather than the arguably better, more competitive option: open-source the NT and Windows codebase, prepare an 'OpenWindows' (nice pun there, really) release, and simultaneously support enterprise customers with paid support licences, like places like Red Hat currently do.

> Cygwin, msys2/git-bash are all fantastic but they are no replacement for the kind of development experience you get on Linux & MacOS.

I couldn't disagree more. As someone who comes from a mostly-Windows pedigree, UNIX is... pretty backwards, and I look upon any attempt to shoehorn UNIX-on-Windows with a fair bit of disapproval, even if I concede that their individual developers and maintainers have done a decent job. Visual Studio (not Code) is a massively superior development and debugging tool to anything that the Unix crowd have cooked up (gdb? perf? Tell me when you can get flame graphs in one click).

20+B annually is not “nearly negligible.” That’s more revenue than all but 3 other software companies: oracle 46B, SAP $33B, and salesforce 430B. It’s more annual revenue than Adobe and every other software company.

> I'd love if it Microsoft simply abandoned NT and threw their weight behind the Linux kernel

Oh hell no!

Diversity in operating systems is important, and the NT architecture has several advantages over the Linux approach. I definitely don't want just one kernel reigning supreme, not yet at least - although that is probably inevitable.

> I guess a less extreme option would be for Microsoft to extend NT to be POSIX compliant...

Microsoft had this and abandoned it. I was building GNU software on NT in 2000 under Interix. It became Services for Unix and then was finally abandoned.

> Cygwin, msys2/git-bash are all fantastic but they are no replacement for the kind of development experience you get on Linux & MacOS.

> WSL1 was a great start and gave me hope, but is now abandonware.

Exactly my thoughts. I really admired the design and how far WSL1 got. It is just sad to see it abandoned.

> WSL2 is a joke, if I wanted to run Linux in a VM, I'd run Linux in a VM.

I couldn't have said it better. If I wanted to run Linux in a VM, I'd run Linux in a VM, why are we pretending something special is going on.

> My understanding is that the main thing keeping Windows relevant is the support for legacy software, so they'd be hesitant to jeopardize that with any bold changes to the kernel or system APIs.

Without Windows, there would be no platform to sell office (macOS aside). That as a side note.

The important piece you are missing is this: The entirety of Azure runs on an optimized Variant of Hyper-V, hence all of Azure runs on Windows. That is SUBSTANTIAL!

"I guess a less extreme option would be for Microsoft to extend NT to be POSIX compliant"

Their was a time MS sales posted NT to be more POSIX compatible than UNIXes.

> I'd love if it Microsoft simply abandoned NT and threw their weight behind the Linux kernel

This entire article is an elegant argument why this would be a terrible idea. Didn't you RTFA?

> I guess a less extreme option would be for Microsoft to extend NT to be POSIX compliant

Way to expose and highlight your ignorance. :-( NT 3.1, the first release, was POSIX compliant in 1993, and every release since has been.

Pulling WSL from windows 10 was particularly nasty

>threw their weight behind the Linux kernel (or if GNU is too restrictive

The GPL isn't too restrictive. Google has no issue with it on Android (which uses a modified Linux kernel). GPL doesn't mean you have to open-source everything, just the GPL components, which in the case of the Linux kernel, is just the kernel itself. MS already contributes a bunch of drivers (for their hypervisor) to the Linux kernel. They could easily make a Linux-based OS with their own proprietary crap on top if they wanted to.

>support for Android apps without emulation

They wouldn't need CPU-level emulation, but the API would need some kind of compatibility layer, similar to how WINE serves this purpose for Windows applications on Linux.

>Microsoft could build Windows on top of that POSIX kernel and provide a compatibility layer for NT calls and Win32 APIs.

They don't need to: they can just use WINE. They could improve that, or maybe fork it and add some proprietary parts like CodeWeavers does, or they could even just buy out CodeWeavers.

In Microsoft's perfect world your local machines would just be lightweight terminals to their Azure mainframe.

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

Linux actually did have some pretty significant redesigns with some notable breaking changes. It wasn't until the 2.4 line ended in the late oughts that Linux as we know it today came fully into existence.

FWIW Linux got support for kernel modules in January 1995.

cf Terry Davis saying "Linux wants to be a 1970s mainframe".

Except unix nowadays is just a set of concepts and conventions incorporated into modern OSs

The "aging design" arguments holds water like a sieve. Electricity and engines are 1800s vintage designs The wheel is a prehistorical aging design american government is an aging design

The quality of an idea is independent of the time of its conception.

The utility of an idea is dependent on the time and place where it may be used however.

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

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

Did it?

Certainly would have helped in the era of embedding AI into the operating system.

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

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.

Nobody wants something 100% new. Users don't want it. Developers don't want it. You can make a new OS but then you'll have zero developers and zero users.

Yet this fantasy exists.

And as soon as you make something new, it'll be old, and people will call for its replacement.

You left out the important part: abandon the Rosetta-like system a mere few years later once you've lured them in, then fuck everyone over by breaking backwards compatibility every OS release. Apple really has the "extinguish" part nailed down.

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.

Are you pretty sure on that? These are some quotes among others on the topic in a forum discussions back in 2005:

"While Microsoft did technically 'buy' their TCP/IP stack from Spider Systems, they did not "own" it. Spider used the code available and written for BSD, so it doesn't appear that Microsoft directly copied BSD code (which, again, it is perfectly legal and legitimate to copy), they got it from a third party. Also ftp, rcp and rsh seems to have come with the bundle. I have heard that ftp was, but have never used rcp and rsh on Windows, so don't know what version(s) those were or were not included in any particular Windows version. Anyone can look through the .exes for those files and look for "The Regents of the University of California" copyright notice, if they want to see for themselves (rather than take the word of some anonymous geeks on a forum) ;)"

[1] Windows TCPIP Stack Based on Unix ?

https://www.neowin.net/forum/topic/381190-windows-tcpip-stac...

>They didn't

Didn't they?

I am not questioning the fact that BSD is a commercial and Microsoft 'friendly' license, and Microsoft and Unix vendors hired many of BSD developers, it's a win-win situation for them.

What is so sinister by saying Microsoft at the time didn't particularly like Linux GPL license and their ex-CEO called it a cancer (their words not mine) since it's not compatible with their commercial endeavours at that particular time. Perhaps you have forgotten or too young to remember the hostility of Microsoft towards Linux with their well documented FUD initiatives [1].

[1] Halloween documents:

https://en.wikipedia.org/wiki/Halloween_documents