This is really cool. Kudos to Microsoft for really getting open source lately. I wrote an app (which failed miserably) called zenaud.io . When I started writing the app, Apple was hands-down a better developer experience. Now, it's the exact opposite -- MacOS is increasingly painful, throwing up more and more roadblocks and constricting their platform ever more. And Visual Studio is better than Xcode IMO.<p>Also, as a C++/Python dev - it's increasingly hard not to notice the awesome momentum Rust has garnered.
Rust needed a GUI and Microsoft provided one. They seem to be very focused on giving developers what they need, but only to a point. I've been doing some system glue stuff and while it's nice that powershell has ssh an scp they are missing some options I want. I was going to use curses with python (batteries included!), only to find out it's not supported on windows.<p>It almost feels like a strategy - be standard enough to bring people in, but idiosyncratic enough to lock them in.<p>I'll be using gtk-rs thank you very much.
I was curious how this worked: The previous iteration of this only worked for WinRT API, and this new crate seemed to also work by generating code from WinMD files. But WinMD files only contained definitions for WinRT/COM APIs, so how could this possibly work?<p>Well turns out, microsoft started a project to also generate Win32 API information in WinMD file, to generate APIs from them automatically for all native languages! See win32metadata[0]. This could make interfacing with win32 APIs a lot more convenient!<p><a href="https://github.com/microsoft/win32metadata" rel="nofollow">https://github.com/microsoft/win32metadata</a>
Kenny Kerr's blog post on this may also be of interest. In particular, it answers the question I was going to ask about how they're handling Win32 and WinRT in a unified way.<p><a href="https://kennykerr.ca/2021/01/21/rust-for-windows/" rel="nofollow">https://kennykerr.ca/2021/01/21/rust-for-windows/</a>
As someone who writes Windows software now and then, I’m genuinely excited. I tried using this early, when it was limited to WinRT bindings. It looked promising, but compile times were prohibitive. It seems like they now include a build.rs and have clear recommendations around caching — I hope this solves the problem. Has anyone tried a recent version?
The lesson from Microsoft I think is that the fish really does rot from the head. Put another way: who the CEO is really does matter. We have night and day here with Ballmer compared to Nadella.<p>Credit where credit is due: Microsoft has really been doing a lot to try and rebuild their credibility when it comes to the developer community. Off the top of my head I can think of TypeScript, open sourcing .Net, WSL and now this.<p>Oh and they haven't done an Oracle or a Cisco (or, let's face it, a Google at this point) with their acquisition of Github by letting it die on the vine or with hostile forced integrations.<p>Kudos.
For Mac fans, the closest you'll have to this in OS-X is core-foundation-rs[1], by the servo team.<p>[1] <a href="https://github.com/servo/core-foundation-rs" rel="nofollow">https://github.com/servo/core-foundation-rs</a>
For someone not familliar with Windows API, why does creating a Windows needs unsafe and other low level things? I guess it's the same for the C++/C# version?<p><a href="https://github.com/kennykerr/samples-rs/blob/master/create_window/src/main.rs#L15" rel="nofollow">https://github.com/kennykerr/samples-rs/blob/master/create_w...</a>
There is some good stuff here but also some sloppiness.<p>1) Having everyone generate the bindings means there will be many copies of each type, causing type errors. This only works if Windows is always a private dependency, a concept which isn't even fully implemented, and that is a bad assumption. Public dependencies are the logical default.<p>2) Putting the proc macro and non-autogenerated parts in the same create is cute but a sloppy conflation of concerns and bad for cross compilation. There is a underlying <a href="https://crates.io/crates/windows_macros" rel="nofollow">https://crates.io/crates/windows_macros</a> thankfully, but that should be the only way to get the macro.
Wow, I thought by the name this would be an awkward Windows distribution of Rust packaged in an MSI. I'm pleasantly surprised. Microsoft has become one of the best big tech companies for open source in the past few years.
Wish there was something like this for Linux too. Rust system programing on Linux consist of dealing with a dumpster fire of badly implemented and incomplete wrapper crates for the kernel interfaces.
Really pleasing to see that MS have done this without feeling the need to start nailing proprietary extensions onto the Rust language. I feel Rust adoption is still at a low enough level where a separate windows fork would have been especially harmful. I guess there are a couple of factors helping here:<p>- MS were already moving to a model where they prefer to stick with the standards-compliant form of a language: vide C++/WinRT<p>- Rust has enough features built in to facilitate this, specifically being able to hook into the compilation process
Since Windows ships a stable ABI, why does this project need to generate the bindings at build time? Couldn't all of the bindings be pre-generated, eliminating the build-dependencies?
They managed to secure the crate name "windows" [1] which always is a nice touch.<p>I clearly remember that this name was squatted.<p>[1] <a href="https://crates.io/crates/windows" rel="nofollow">https://crates.io/crates/windows</a>
Very cool to see the start of official support. Unfortunately it looks like it requires unsafe { } for now, though maybe it's intended as a low-level foundation on which a higher-level, safer API can be built
Does this automatically generate safe API's as expected for Rust? If so, I wonder how they manage it? Did their metadata format have to be extended to describe the constraints on Rust callers and callbacks?
Any pointers / way for cross-compiling on linux for windows?<p>Now Apple for MacOS and iOS, Android and maybe game consoles and Rust is a 1st class citizen!
Why would I ever write code on Windows if I don't have to because I'd be writing a Windows program?<p>Microsoft is anti freedom, anti developer.<p>Windows is only good for games. Real development happens on other platforms.<p>They bought github and turned it into something against the spirit of free software.
First thing was to add deleting issues and comments.<p>Microsoft is evil. Always had been and if you trust them one bit you're a fool
This might be an inconsequential niggle, but I kind of dislike the Microsoft's approach to naming. Like calling this "rust for windows" makes it sound somewhat grandiose, and maybe as if Rust is somehow endorsing or expanding support for Windows, when it appears to be just a crate which auto-generates wrappers for windows API's.<p>The same applies to "Windows Subsystem for Linux" - maybe I'm alone but to me this sounds more like Linux was getting a bit windows embedded inside it rather than the other way around.<p>Also I find it a bit arrogant that VSCode wants to name-squat the very general term "code" in my PATH. vscode is already quite short and clear, and would have made a perfectly suitable cli name.