6 ms·

As a believer in removing unnecessary layers of abstraction, this looks interesting. Is there a technical reason Rustix doesn’t support Windows, or is that just

As a believer in removing unnecessary layers of abstraction, this looks interesting. Is there a technical reason Rustix doesn’t support Windows, or is that just not a priority at the moment? (For a bit of background info: It might seem counterintuitive, but on Windows, a “native” application “should” actually call the programming language agnostic Kernel32.dll functions directly. At least that’s the documented, stable way of doing things. Instead, Rust’s std currently goes through libc, which is also fine, but on Windows is an abstraction built on top of the Windows APIs, and is historically a lot less stable. This can cause code bloat and distribution hassles. 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. As a result, on Linux, going libc-less is a bit harder in my limited experience — though certainly possible if you know what you’re doing.)

samhw 5y ago
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.)
- codeflo 5y ago
  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”.
- CodesInChaos 5y ago
  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".
  - pjmlp 5y ago
    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.
sanxiyn 5y ago
> 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/src/sys/windows/fs.rs#L287 https://github.com/rust-lang/rust/blob/master/library/std/sr...
- codeflo 5y ago
  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.
  - deleted 5y ago
    [deleted]
  - sanxiyn 5y ago
    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.
    - ChrisSD 5y ago
      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.
      - sanxiyn 5y ago
        Rust already ships with its own memcpy, so it should be possible: https://github.com/rust-lang/compiler-builtins/blob/master/src/mem/impls.rs https://github.com/rust-lang/compiler-builtins/blob/master/s...
      - ectopod 5y ago
        The startup/shutdown code is for the C runtime. If you avoid the C runtime you don't need it.
ylyn 5y ago
> 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.
- sanxiyn 5y ago
  Note that macOS syscall interface is specifically unstable so Rust needs POSIX/libc path anyway.
  - masklinn 5y ago
    Also on Solaris/Illumos/SmartOS/..., and on OpenBSD (where it's more or less verboten entirely since system-call-origin verification).
    - wahern 5y ago
      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 https://man.openbsd.org/msyscall, which implements one-time registration of a contiguous range of pages permitted to invoke syscalls.
- codeflo 5y ago
  Thanks, that’s a great correction/clarification.

samhw 5y ago

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

codeflo 5y ago
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”.
CodesInChaos 5y ago
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".
- pjmlp 5y ago
  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.

sanxiyn 5y ago

> 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/src/sys/windows/fs.rs#L287 https://github.com/rust-lang/rust/blob/master/library/std/sr...

codeflo 5y ago
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.
- deleted 5y ago
  [deleted]
- sanxiyn 5y ago
  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.
  - ChrisSD 5y ago
    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.
    - sanxiyn 5y ago
      Rust already ships with its own memcpy, so it should be possible: https://github.com/rust-lang/compiler-builtins/blob/master/src/mem/impls.rs https://github.com/rust-lang/compiler-builtins/blob/master/s...
    - ectopod 5y ago
      The startup/shutdown code is for the C runtime. If you avoid the C runtime you don't need it.

ylyn 5y ago

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

sanxiyn 5y ago
Note that macOS syscall interface is specifically unstable so Rust needs POSIX/libc path anyway.
- masklinn 5y ago
  Also on Solaris/Illumos/SmartOS/..., and on OpenBSD (where it's more or less verboten entirely since system-call-origin verification).
  - wahern 5y ago
    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 https://man.openbsd.org/msyscall, which implements one-time registration of a contiguous range of pages permitted to invoke syscalls.
codeflo 5y ago
Thanks, that’s a great correction/clarification.