What does HackerNews think of windows-rs?

In theory yes, but there's a lot of quirks and limitations.

The main issues are:

- Rust string types assume UTF-8, but Windows generally uses double-byte Unicode encodings. The Windows string type isn't even UTF16, because it can include invalid code points. This means that at every API call there will be the overhead of converting the string encodings and having to "deal" with invalid strings somehow.

- Rust compilation is still very slow. In C++, it was a simple matter of including "windows.h" and then start typing code. In Rust, trying to do this naively would result in terrible "inner loop" for the developers. There are some fixes, but they're fiddly.

- Enormous API surface with missing metadata. This is a problem with Rust-to-C interop in general, but the Win32 APIs are so huge that it's impractical to solve manually. There have been efforts by Microsoft to produce official and authoritative interface definitions with additional metadata such as tagging "in" and "out" parameters, etc... This isn't sufficient for Rust, which has a much more complex type system than vanilla C pointers. E.g.: lifetimes, non-null by default, etc...

At this time, programming in Rust for Windows is basically writing C++ code in Rust syntax, but with a slower compile time than C++ would have. Arguably, there isn't even much of a safety benefit, because that would require an extensive set of "shims" to be produced to make Win32 act more like Rust and less like C/C++. Take a look at the size of the .NET Framework standard library to get an idea of what that entails. Not impossible, but not a trivial effort either!

The best and most authoritative bindings are: https://github.com/microsoft/windows-rs

The "demo" looks okay at first glance:

    unsafe {
        let event = CreateEventW(None, true, false, None)?;
        SetEvent(event).ok()?;
        WaitForSingleObject(event, 0);
        CloseHandle(event).ok()?;

        MessageBoxA(None, s!("Ansi"), s!("Caption"), MB_OK);
        MessageBoxW(None, w!("Wide"), w!("Caption"), MB_OK);
    }

But if you start digging deeper into callbacks that manipulate structures that include hideous things such as lists of strings separated by null bytes, you're back in "the weeds" just like with C/C++.

It looks like this official MS Rust library adds a lot of Win32 support: https://github.com/microsoft/windows-rs

It should work well with VS Code.

You can have a look at its issues,

https://github.com/microsoft/windows-rs

Note the lack of of safe wrappers for Windows APIs, and still no good way to create the Windows Runtime objects necessary to interoperate with XAML.

Also the basic examples with very little UI code on what is supposed to be a projection for a Windows UI framework.

This discussion is making me wonder if windows-rs [1], the crate with official Rust bindings for all Windows APIs, is doing something that's not idiomatic Rust. Specifically, for any Windows API function that takes a UTF-16 string as a parameter, the signature for that parameter is something like "impl IntoParam". The crate then implements that trait for String and &str, so you can pass a normal Rust UTF-8 string (even a string literal), and it'll be automatically converted to a freshly-allocated, null-terminated UTF-16 string (which gets freed after the function call). That seems like it could lead to the same thoughtless inefficiency as in the story about the Chrome omnibox.

[1]: https://github.com/microsoft/windows-rs

There has been a Microsoft supported Rust projection of WinRT for a few years now [1].

[1] https://github.com/microsoft/windows-rs

The Rust Windows API provides a cast method to jump through the inheritance hierarchy.

Previously, additionally, all base class methods were generated for derived classes (structs). This was removed due to high compile times

https://github.com/microsoft/windows-rs

Microsoft have done a lot of working attempting to make every windows C/C++ API available for use in Rust. This task is/was too big to do by hand (and sensitive to changes) so they have automated it. See: https://github.com/microsoft/windows-rs

Not just that, but like, https://github.com/microsoft/windows-rs. Microsoft is a member of the Rust Foundation. etc etc.

If I'm not mistaken, the "rust people" were not involved in "Rust for windows". It's just a normal rust crate which wraps the windows API, developed by Microsoft.

That's part of what makes this kind of naming so confusing. "Rust for Windows" sounds like some kind of development in the rust language in the direction of supporting windows, but it's just a library.

I can imagine a trademark holder taking issue with something like this. For instance, imagine the Ford auto compnay marketed their USB port, which you can plug an iPhone into, as "iPhone for Ford Trucks".

edit:

Look at the title in the Rust for Windows github: https://github.com/microsoft/windows-rs

> Rust for the Windows SDK

What does that even mean? "Rust implementation of the Windows SDK API", or "Rust Wrapper for the Windows SDK" would make sense, but this phrasing is completely foreign to anyone doing software.

I've seen news that Microsoft is adopting Rust for safe systems programming. I believe they've been investing in Rust for a while.

- https://msrc-blog.microsoft.com/2019/07/22/why-rust-for-safe...

- https://github.com/microsoft/windows-rs

- https://cloudblogs.microsoft.com/opensource/2021/02/08/micro...

Judging by the getting started guide[0], they thankfully haven't forked Rust or anything, this is all about windows-rs[1], a Rust library for conveniently accessing the Windows API.

[0]: https://docs.microsoft.com/en-us/windows/dev-environment/rus...

[1]: https://github.com/microsoft/windows-rs

They released a while back Rust crate for Windows API: https://github.com/microsoft/windows-rs