I guess saying "every project" has 5 dependencies might be somewhat hyperbolic (or at least domain specific) but it would be interesting to know the kinds of things they're talking about that haven't yet been uplifted.

For this "story" to gain legs, someone must have pulled that sentence out of content without mentioning the source and then added some misleading context for the outrage.

https://devblogs.microsoft.com/oldnewthing/20140411-00/?p=12...

https://learn.microsoft.com/en-us/cpp/windows/universal-crt-...

And you can of course use non-C languages to call the Win32 API. Or even directly using assembly code.

It wasn't until fairly recently that the C runtime was stably shipped with Windows. Previously you had to install the correct version of the C library alongside your application.

I'm not sure which docs you mean but that's not true. The NT kernel has used ACLs long before rust was invented. But it's indeed true that rust adds platform-specific methods based on demand. The trouble with ACLs is it means either creating a large API surface in the standard library to handle them or else presenting a simple interface but having to manage raw pointers (likely using a wrapper type but even then it can't be made totally safe).

> the de-facto standard winapi crate, which provides access to the raw syscall

Since the official Microsoft `windows-sys` crate was released many years ago, the winapi crate has been effectively unmaintained (it accepts security patches but that's it).

That's not true. They use ProcessPrng since versions earlier than 10 are no longer supported (well, rust also has a windows 7 target but that couldn't use ProcessPrng anyway since it wasn't available). The issue they linked is from a decade ago. E.g. here's Chromium: https://github.com/chromium/chromium/blob/dc7016d1ef67e3e128...

> If [ProcessPrng] fails it returns NO_MEMORY in a BOOL (documented behavior is to never fail, and always return TRUE).

From Windows 10 onward ProcessPrng will never fail. There's a whitepaper that gives the justification for this (https://aka.ms/win10rng):

> We also have the property that a request for random bytes never fails. In the past our RNG functions could return an error code. We have observed that there are many callers that never check for the error code, even if they are generating cryptographic key material. This can lead to serious security vulnerabilities if an attacker manages to create a situation in which the RNG infrastructure returns an error. For that reason, the Win10 RNG infrastructure will never return an error code and always produce high-quality random bytes for every request...

> For each user-mode process, we have a (buffered) base PRNG maintained by BCryptPrimitives.dll. When this DLL loads it requests a random seed from kernel mode (where it is produced by the per-CPU states) and seeds the process base PRNG. If this were to fail, BCryptPrimitive.dll fails to load, which in most cases causes the process to terminate. This behavior ensures that we never have to return an error code from the RNG system.

That's a very "shoot the messenger" statement. While Aurich is the community "face" of Ars, I very much doubt he has the power to do anything like that.

Fun fact: NT 3.1 was the first version of NT, released in 1993. It was versioned like that to match Windows 3.1 which had been released the previous year.

And NT really took off with Windows 2000. Not just business people but more ordinary people were using it as a more stable alternative to Windows 95/98 (albeit lacking some compatibility, especially with games).

The System V ABI is as close as we get to an actual specification but not everyone uses it and in any case it only covers a small part of the protocol.