I feel like MS naming convention are flipped on the head.<p>Rust for Windows -> a version of Rust for Windows?
Windows Library for Rust -> a library for Rust that allows to interface with Windows APIs<p>Same with Windows Subsystem for Linux. It's a Linux system for Windows.<p>But hey, that's just names. Nice for win-devs to get more languages supported.
I'm completely confused by Microsoft's use of "for Windows" naming.<p>Rust for Windows already exists. This is a Windows SDK for Rust.<p>Windows Subsystem for Linux is Linux subsystem for Windows.<p>Is this some usage of the "for" word that I'm not getting? I'm a non-native English speaker so I could be at fault here.
I just started using this library 2 weeks ago. It is beautiful. We were in python land, and dreading moving to C++ for performance. This is a life saver.<p>Not having to dig up COM UUIDs for interfaces is super nice. The lead developer of com-rs told me that com-rs is deprecated in favor of windows-rs (he works on both.)
I recently tried to use this library and had to go back to winapi-rs for the mean time.<p>The bindings to set it up gave hard to debug errors and there is no support for compiling the x86_64-pc-windows-gnu toolchain on anything else besides a windows system; Which makes sense but winapi-rs compiled on Linux so I stuck with it. I don't want to manage another build machine and I know I'm probably like the one guy.<p>Working with strings was a bit rough too, it'd be nice if you could just pass a CStr and call it a day instead of messing with buffers and lengths and double function calls, one to get size of the string and then another to fill the actual buffer. I know this is how Win32 works, but it doesn't feel natural coming from Linux Kernel Dev.<p>Regardless of my criticisms, I am excited to see the future of this crate. I think it's an awesome effort and a great addition to Rust and Windows.
A bit off-topic but is the C++ API library for Windows coming along too? I've been looking out for that, but I'm not sure what state it's in.