> Instead, Rust's std currently goes through libc

Are you sure about this? Rust's std's File::open calls CreateFile on Windows, not libc open. Isn't CreateFile correct Kernel32.dll API to call?

https://github.com/rust-lang/rust/blob/master/library/std/sr...

It is. I haven’t checked the complete source code. What I know for sure is that a program using Rust’s std still requires the C runtime to link and run, and from that perspective, it doesn’t really matter if some or even many parts of the std don’t actually use it.

I see. I wonder where Rust's std is using libc on Windows. I know for a fact filesystem portion of std doesn't call libc at all on Windows.

Rust needs the C runtime for startup/shutdown code (and vcruntime for panics). It also needs basic memory functions such as memcpy and stack probes. There is no way round this except rewriting those in Rust.

Rust already ships with its own memcpy, so it should be possible: https://github.com/rust-lang/compiler-builtins/blob/master/s...

The startup/shutdown code is for the C runtime. If you avoid the C runtime you don't need it.

At a minimum Rust would have to run the C initializers as these are used even in pure Rust code. It might also make use of the security cookie but I'm uncertain about that. Also the C runtime is needed by the SEH handling code (in vcruntime) so Rust would have to replace that before it can replace the C startup/shutdown.

To be clear, this is feasible but it'll require someone knowledgable to put in the work of rewriting this in Rust.

SEH doesn't need the C runtime, they are only required when using the C language extensions for frame-based Exception Handling, with the new vectored Exception Handling, plain Win32 calls will do,

https://docs.microsoft.com/en-us/windows/win32/debug/vectore...

Granted, they are more cumbersome to use and probably not worth the effort to try to avoid them other than special cases.

Sure. I did not mean to imply that SEH itsef requires the C runtime. However, the __CxxFrameHandler3 that Rust/llvm uses would need to be rewritten.

IIRC llvm itself generates calls to __CxxFrameHandler3 when SEH is being used, making it awkward to replace with something that's not compatible.

https://crates.io/crates/r0 exists (not everything you're talking about but like, there's some of this stuff around, in some contexts. We'll see if the whole pile of stuff needed ever gets ported or not, I'm guessing yes but on a long timeframe.)

> This is a bit different from Linux, where the abstractions are layered the other way round: the OS (POSIX) spec mostly assumes an existing libc.

FWIW the POSIX spec assumes libc, but on Linux specifically the syscall interface is stable.

Note that macOS syscall interface is specifically unstable so Rust needs POSIX/libc path anyway.

Also on Solaris/Illumos/SmartOS/..., and on OpenBSD (where it's more or less verboten entirely since system-call-origin verification).

AFAIU, you don't need to use libc on OpenBSD, however only one contiguous region of code is permitted to invoke syscalls, and so you can't mix-and-match ad hoc libraries. See https://man.openbsd.org/msyscall, which implements one-time registration of a contiguous range of pages permitted to invoke syscalls.

Thanks, that’s a great correction/clarification.

Is there a reason "native" and "should" are in scare quotes? I think "should" is pretty well defined - after all, we've got an RFC for it!

Edit: I'm not altogether sure why this is being downvoted, but in case it wasn't clear: this is a sincere question and not some kind of pedantic rhetorical question. (I don't really mind whether people upvote or downvote the comment, except to the extent that it's a signal that I perhaps wasn't clear in what I was asking.)

There isn't anything objectively wrong with using libc as an abstraction on Windows, especially since Win10 ships the "Universal C Runtime" out of the box (earlier you had to deploy a separate crt for each Visual Studio version).

Personally I'm also in favour of cutting out libc and invoking the windows API directly. But others might argue that using it as a shared abstraction that's very similar on Windows, Linux, OSX, BSD, is worth it.

And "native" is ill defined. It's just one more abstraction layer in the libc -> Win32-API -> NT-API -> Kernel chain. Libc isn't comparable to a java runtime or electron, which is what people usually mean when they talk about applications not being "native".

Kind of, it is still a language runtime specially on non-UNIX OSes.

The recent thread about cutting down the startup of C applications on Linux proves the point it isn't a zero cost library.

I didn’t downvote, in fact, I’m a bit amused because the reason I used quotes is exactly because I’m not using any official definition! There’s no consensus definition of “native”, and I’m using “should” purely in the colloquial sense of “something I’d like to see”.