NT has ACLs for everything. Each handle (read: descriptor) has associated ACLs.
Also, each handle can be waited ("selected") with same system call. No select()/epoll() vs wait() distinctions. Nw Linux has timerfd and procfd and others, but NT had these from birth.
In some way NT is more UNIX ("everything is a file") than UNIX itself.
• Disk volumes and physical disks
• Pipes
• Registry keys
• Processes and threads
• Inter-process synchronization primitives like mutexes, semaphores, and mailslots
• Shared memory sections
• Desktops; you need to pass access check before interacting with a desktop. The OS has multiple of them, used for fast user switching, concurrent remote desktop sessions, UAC prompt, logon screen.
• Other, more exotic things like job objects, windows stations, and ALPC ports.
To be fair, some of them are protected with ACLs on Linux because they are mapped into the file system. For example, physical disks are visible in the file system and the kernel does apply these security things to them.
I’m not sure Cairo is comparable to Direct2D, the ecosystem is too different.
On Windows, Direct3D 11.0 is guaranteed to be available. Even on computers without any GPU (like most cloud VMs) the OS uses a decently performing software emulation called WARP. For this reason, Direct2D is designed from the ground up to use these shaders as much as possible, and it shows because hardware GPUs deliver way more gigaflops than CPUs. For example, on my computer D2D implements anti-aliasing on top of MSAA hardware.
Cairo is cross-platform, and Linux doesn’t have a universally available GPU API. Some Linux computers have GL 4.5+, some have GLES 3.1+ (both GPU APIs have approximate feature parity with D3D11) some others have none of them. For this reason, Cairo renders vector graphics on CPU. Some computers, with slow CPUs and high resolution displays, don’t have the performance to render complicated 2D scenes in realtime on CPU.
This may change some day once Vulkan support on Linux is ubiquitous, but that day is yet to come.
Linux does not have anything similar to Direct2D, despite it’s technically possible to make it. Here’s a proof of concept for ARMv7 Debian (Raspberry Pi4), on top of GLES 3.1: https://github.com/Const-me/Vrmac/?tab=readme-ov-file#2d-gra...
Sure it does: WINE. Not only is it similar, but it's the exact same API & ABI.
And sometimes minor hardware revision of these Mali GPUs change the internal API between user mode and kernel mode halves of these Linux GLES drivers.
The kernel handled it pretty well as it supported both hardware revisions. But my user mode app failed because the new hardware required a different version of that libmali-midgard*.so DLL.
Unlikely to happen on Windows because the GPU driver installs both kernel/user mode halves of the driver in one transaction. Linux doesn’t have ABI for drivers, all kernel mode drivers are pre-compiled into the kernel.
That's why free software should be a requeriment at least for drivers.
I remember the -fake Intel- GMA500/3000 fiasco. My old GL 2.1 based n270 netbook it's still supported and with a small ~/.drirc it fixes some quirks as it MESA misdetects it as a GL 1.4 device, but overall it's tons better than the PowerVR chipset with an Intel coat.
The GMA500 users are stuck even without EXA.
I’ll bite. POSIX permissions are lousy, and NT permissions are mostly worse. It’s way too easy to mess up, and it’s way too hard to specify a sensible policy like “only a specific user can access such—and-such path”. At least NT can restrict directory traversal.
S3 got it right when they deprecated object-level ACLs.
> This makes launching new processes and opening files more expensive due to the overhead of access checks,
fork() is terrible and slow. CreateProcess is overcomplicated, but creating a process directly is a vastly better design IMO.
> but with good multithreading support it’s IMO a reasonable tradeoff.
Huh? Linux has had proper multithreading support since NPTL, which was a long time ago. Windows, in contrast, didn’t have reasonable support for multithreading on systems with >64 CPUs until Windows 11:
https://learn.microsoft.com/en-us/windows/win32/procthread/p...
I assume this is related to the way that Windows leaks all kinds of bizarre threading details into the user ABI.
I will grant that Linux’s original threading was an abomination.
> Related to the above, CreateRestrictedToken kernel call for implementing strong sandboxes.
Eww. The Windows sandboxing scheme is IMO an overcomplicated mess. Seccomp is not particularly friendly, but it does exactly what it says on the tin, and I would be far more comfortable running untrusted user code under seccomp than under Windows restrictions from token, jobs, integrity, etc.
ABI for device drivers allows to add support for new hardware without recompiling the kernel.
First-class support for multithreading, Vista even added thread pool to the userland API.
Efficient asynchronous APIs for IO including files, pipes, and everything else. Linux only got this recently with io_uring, NT implemented IOCP decades go in version 3.5.
NT security descriptors with these access control lists and nested security groups are better than just 3 roles user/group/root in Linux. This makes launching new processes and opening files more expensive due to the overhead of access checks, but with good multithreading support it’s IMO a reasonable tradeoff.
Related to the above, CreateRestrictedToken kernel call for implementing strong sandboxes.
Good GPU support, Direct3D being a part of the kernel in dxgkrnl.sys. This enables good multimedia support in MediaFoundation framework because it allows applications to easily manipulate textures in VRAM without the complications of dma-buf in Linux.
Related to the above, GPU-centric 2D graphics (Direct2D) and text rendering (DirectWrite) in the userland API.