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

I tried to spin up a project with the Microsoft Rust bindings but for what I needed (DirectX12) there’s a lot of necessary helpers in the header files that haven’t got ported over there. And working from one of the samples it was nowhere near as reliable as the C++ version. Beyond ‘oh the C++ code isn’t catching errors’ - every HRESULT was checked as it was using the WinRT bindings.

Kenny Kerr has done an excellent job with both the C++ and Rust bindings, but the Rust one isn’t there yet.

What I’d like to see is more use of a WinMD style metadata for the ABI for functions in DLLs you create. It would be quite simple to define a Span type that could then be imported and called safely from a diverse range of FFIs. I really shouldn’t be having to declare the ABI all over again with ctypes in Python.

I disagree with the "excelent job" for C++.

Using C++/WinRT is like going back to developing COM with Visual C++ 6.0, but I guess that is what WinDev craves for.

They should have provided a proper development experience for IDL files, automatic merges of generated code, and only then, deprecate C++/CX.

Not deprecating C++/CX, and leaving us with editing IDL files with a Notepad like experience, and manually merging generated code.

Rust/WinRT is even worse in regards to WinUI tooling.

Pretty sure most win32 now has an alternative utf8 function?

No, they don't. We typically use the UTF-16 functions (with the W suffix).

More specifically, the 8-bit 'A'-suffixed functions could be used as UTF8, but only on some versions of Windows if, and only if, the system code page is set to use UTF8 instead of the Latin1 (or whatever).

I don't think the system code page needs to be set? https://learn.microsoft.com/en-us/windows/apps/design/global...

https://learn.microsoft.com/en-us/cpp/c-runtime-library/refe...

No, it isn't. Yes, you can make Windows or macOS or Linux GUI in rust. Yes, there are options, but:

- ecosystem for GUI is weak

- Can't' imagine using anything, but relm or gtk-rs

- Existing GUI paradigms don't work well in Rust at all

As much as I love writing rust, I would rather write "core" in rust and link with it from something else for GUI.

GUI code is fine with garbage collection. So it still fits with his message.

I'd imagine that he would recommend C# for GUI programming.