22 ms·

Rust for Windows

• Animats 6y ago
  Will this work when cross-compiling from Linux? That's supported by Rust.
  • monocasa 6y ago
    I don't see why not, the winapi crate is.
    • roblabla 6y ago
      The winapi does a lot of work to support that use-case. Importantly, it ships (mingw) import libraries to allow linking against windows libs from linux trivially[0]. EDIT: windows-rs doesn't yet support cross compilation as easily as winapi. Here's the issue tracking it: https://github.com/microsoft/windows-rs/issues/142 https://github.com/microsoft/windows-rs/issues/142 [0]: https://github.com/retep998/winapi-rs/tree/0.3/x86_64/def https://github.com/retep998/winapi-rs/tree/0.3/x86_64/def
    • Arnavion 6y ago
      The question is valid. The winapi crate binds the functions in the Windows headers explicitly. You can call `winapi::...::CreateEventW` because winapi has a `pub extern unsafe fn CreateEventW(...)` in its code. This new crate is a generator. If this new generator requires access to the .winmd files or .h files from the SDK or whatever, where is the non-Windows builder going to get those from? And will this generator look for them there? For example, I used to maintain a generator that took COM typelibs and generated Rust bindings for them, but it required calling into the Windows API for working with typelibs and thus obviously required a Windows builder. The functionality of this crate is split between the windows_gen and windows_macros crates, and from a cursory glance I could not tell how it works wrt win32 bindings. Edit: Answered by https://news.ycombinator.com/item?id=25863581 https://news.ycombinator.com/item?id=25863581 - the win32 API is now also described by .winmd files. So the question is, can a non-Windows builder get these files, and then convince this crate to look for them wherever it placed them?
      • dguaraglia 6y ago
        > This new crate is a generator. If this new generator requires access to the .winmd files or .h files from the SDK or whatever, where is the non-Windows builder going to get those from? And will this generator look for them there? From memory (I haven't done Windows development in forever): there's a few projects that try to provide an open source version of the Windows API headers. The MingW project, for example, has a full set of drop-in replacement headers (meaning you can take code that compiled with Visual C++ and compile it directly with MingW's GCC and it should 'just work'). The LCC-Win64 project has a similar set of headers. Does that answer your question?
        • Arnavion 6y ago
          Headers are irrelevant. We're talking about .winmd files.
      • orra 6y ago
        > So the question is, can a non-Windows builder get these files, and then convince this crate to look for them wherever it placed them? Yes, there's actually a prebuilt Windows.Win32.winmd file in the repo, underneath .windows/.
  • est31 6y ago
    https://github.com/microsoft/windows-rs/issues/143#issuecomment-629701676 https://github.com/microsoft/windows-rs/issues/143#issuecomm... > we could support this in future, but it is not an immediate goal. If this is something that folks would like to do, feel free to chime in on this issue and let us know. Note that most of Microsoft regards Linux mainly as a server OS. You are not supposed to use it on the desktop, instead you should use Windows there.
    • reader_mode 6y ago
      Even if that's true you really don't want to run a Windows box as a build server - licensing and security and all that.
      • pjmlp 6y ago
        I have a CentOS DVD to offer you.
    • phkahler 6y ago
      >> Note that most of Microsoft regards Linux mainly as a server OS. You are not supposed to use it on the desktop, instead you should use Windows there. Then what's the point of WSL? To allow server software development on a Windows desktop? OK. But then what's the point of trying to bring DX graphics to linux?
      • paavohtl 6y ago
        To run Tensorflow and other ML libraries in WSL.
        • phkahler 6y ago
          You dont need DX to run tensorflow on Linux. So Embrace Linux by providing WSL. Extend by bringing DX to it. Extinguish the standardized APIs for graphics and ML. Got it. Check. Thanks for the confirmation.
• Erlangen 6y ago
  I kind of expect it to be called "Windows for Rust".
  • deleted 6y ago
    [deleted]
  • joshuaissac 6y ago
    Or maybe "Windows API for Rust".
    • levesque 6y ago
      Rusty Windows?
      • deleted 6y ago
        [deleted]
      • medium_burrito 6y ago
        Tetanus
  • kaoD 6y ago
    I thought your comment was a tongue-in-cheek reference to Windows Subsystem for Linux and then I clicked the link.
    • YetAnotherNick 6y ago
      At least they are consistent in using the convection in reverse.
  • SloopJon 6y ago
    I had the exact same thought. I almost didn't bother following the link, because Rust for Windows is already a thing, but this is essentially a Rust equivalent to C++/WinRT.
    • 6y ago
• brundolf 6y ago
  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
  • _zamorano_ 6y ago
    Well, the Windows API is "unsafe" by design, is C-based, you pass pointers around, datatype sizes, etc... How can you avoid "unsafe" in this scenario? You're asking for a new framework or an API rewrite
    • brundolf 6y ago
      The domain itself isn't fundamentally unsafe, only the way the C API has been designed. You're right that meaningfully different abstractions (instead of a one-to-one translation) may be required to make a safe API, which is why I suggested that could be a possibility.
      • Spivak 6y ago
        But that wouldn't eliminate the need for unsafe code at the border. All ffi calls are inherently unsafe to Rust. You can design the cleanest nicest safest C api in the world but it's still unsafe as far as Rust is concerned.
        • MereInterest 6y ago
          Yes, but those unsafe blocks can be wrapped into the library. "Unsafe" doesn't inherently mean "bad", it just means that the programmer is explicitly taking the burden of making sure that the normal invariants still hold. So long as the library authors ensure that, then the "unsafe" blocks remain within the library and don't need to be worried about by the users of the library. On the other hand, if a library pushes that additional responsibility to me, it makes me more worried.
        • brundolf 6y ago
• mhh__ 6y ago
  D has fairly extensive windows API support, and the usual PE gubbins. Worth taking a look at
  • MaxBarraclough 6y ago
    Link: https://wiki.dlang.org/D_for_Win32 https://wiki.dlang.org/D_for_Win32 Ada has something similar: https://github.com/AdaCore/win32ada https://github.com/AdaCore/win32ada
  • gabereiser 6y ago
    Yes but the topic of discussion is rust here. D is awesome, but we are talking about the windows bindings for rust being “just good enough”.
  • vlang1dot0 6y ago
    Rust has had that for a long time as well. This is first-party support from Microsoft for Rust in contrast to community supported options like in D.
  • bluejekyll 6y ago
    Are these D bindings relevant to Rust developers? Or asked another way, is there some reason that the D bindings would be better to use than these native ones in Rust?
    • mhh__ 6y ago
      When I am writing or choosing (or bindings to) an API I always go and look at other languages (especially what the functional people do) to avoid repeating non-obvious mistakes and seeing where the impedance mismatches are. Most recently, I've been playing with eBPF on Linux: The system call API is terse and pretty impenetrable, whereas the high-level APIs either mean writing gadgets in C with a nearly-blind debugging experience or relying on a library to retain the power of the featureset the kernel exposes.
    • komuher 6y ago
      This is the same stuff like julia community is doing. Spam language in every Python/R related topic (D guys target Nim/Rust)
• phkahler 6y ago
  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. It almost feels like a strategy - be standard enough to bring people in, but idiosyncratic enough to lock them in. I'll be using gtk-rs thank you very much.
  • dgellow 6y ago
    WSL2 has almost everything you need if Windows isn’t enough
    • boogies 6y ago
      Yep, WSL2 is standard enough to draw some in. Its DirectX support is a[n early baby] step in the direction of making it idiosyncratic enough to keep them locked in (we should probably expect more in the future. Right now it otherwise seems to be just a VM, without a lot of non-standard stuff to give it an advantage over running the more stable OS on the bare metal and keeping the BSODing one contained with virtualization).
  • oaiey 6y ago
    Well they bring in the language and its runtime to windows development via WinRT. They don't bring WinRT to Rust. This is the windows team writing adapters for their COM API surface. They do the same for C++, C#, JS and now Rust.
    • Spivak 6y ago
      For people who have not lived in the Windows world this would be like GNOME writing Rust Glib bindings.
    • kyriakos 6y ago
      JS? can you point me to that?
• Maledictus 6y ago
  I'd say this marks the beginning of the `extend` phase.
  • Maledictus 6y ago
    For those who don't remember: https://en.wikipedia.org/wiki/J/Direct https://en.wikipedia.org/wiki/J/Direct
• codeflo 6y ago
  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?
  • hehehaha 6y ago
    Wow! Almost want to make Windows App now just for fun.
• seertaak 6y ago
  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. Also, as a C++/Python dev - it's increasingly hard not to notice the awesome momentum Rust has garnered.
  • bezout 6y ago
    OT: I must agree about your comparison of macOS and Windows. IMO Microsoft is doing a lot to improve the developer experience. WSL2 is so freaking good. It has its quirks and it has issues with some workflows, but I’m thinking about moving out of macOS after having tried it. Apple may have the fastest processor, but Microsoft has the most comfortable tools. Both companies are not perfect, but if we must choose the lesser evil...
    • seertaak 6y ago
      Indeed, WSL2 is pretty cool. Also, Windows Terminal is actually pretty sweet, and I even gave PowerShell a spin the other day. The crazy thing is you can basically use it as a bash shell, and it gets the job done. My developer experience right now consists of PowerShell, where I do all my regular directory jumping, editing (vim), etc., and a Developer Shell with god awful classic "terminal" which I only use to call conan/cmake/clang-windows. I have to add the following: MSVC supports clang on windows. And CMake - all within Visual Studio. And it works perfectly, with perfect support for C++17. Badass.
      • jolux 6y ago
        Visual Studio has supported Developer PowerShell for a while now, and it’s possible to load it into Windows Terminal. It’s just a set of arguments. This blog post explains them: https://devblogs.microsoft.com/visualstudio/say-hello-to-the-new-visual-studio-terminal/ https://devblogs.microsoft.com/visualstudio/say-hello-to-the...
• mwcampbell 6y ago
  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. https://kennykerr.ca/2021/01/21/rust-for-windows/ https://kennykerr.ca/2021/01/21/rust-for-windows/
  • jug 6y ago
    I wonder if Rust is becoming Microsoft's way forward for development rather than C++ (i.e. Rust for Windows rather than C++ for Win32), leaving .NET for higher level development? The bold introduction in the blog post surprises me, coming from Microsoft themselves who're right now hard at work on these individual and ununified technologies.
    • pjmlp 6y ago
      Here is some of the internal advocacy going on at Microsoft. - Managed languages if you can afford a GC - Rust - C++ with Core Guidelines https://github.com/microsoft/MSRC-Security-Research/tree/master/presentations/2020_06_SSTIC https://github.com/microsoft/MSRC-Security-Research/tree/mas... Note that there are still some teams like Azure Sphere and Azure RTOS, which are only providing C based SDKs, so no everyone is on the same wave length.
• Thaxll 6y ago
  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? https://github.com/kennykerr/samples-rs/blob/master/create_window/src/main.rs#L15 https://github.com/kennykerr/samples-rs/blob/master/create_w...
  • steveklabnik 6y ago
    Anything not defined in Rust needs to be marked as unsafe, because Rust cannot understand non-Rust code. FFI bindings are inherently unsafe.
    • ywei3410 6y ago
      On a side-note; do you know of any good resources where someone tries to wrap a non-trivial C wrapper where they go over common C idioms and ways to provide a (safer) API inside Rust without too much overhead? I've always found it to be incredibly difficult because of the number of gotchas which can leak into causing a segfault in Rust; it's immensely frustrating.
      • sensitive-ears 6y ago
        It's more of an example than a resource, but the 'git2' crate that wraps libgit2 does a good job of providing a nice rust interface over a C library.
      • cetra3 6y ago
        I think maybe the ZeroMQ rust crate as a case study is something that is non-trivial: https://github.com/erickt/rust-zmq https://github.com/erickt/rust-zmq
      • eska 6y ago
        https://medium.com/dwelo-r-d/using-c-libraries-in-rust-13961948c72a https://medium.com/dwelo-r-d/using-c-libraries-in-rust-13961...
      • steveklabnik 6y ago
• jdlyga 6y ago
  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.
• diego_moita 6y ago
  For Mac fans, the closest you'll have to this in OS-X is core-foundation-rs[1], by the servo team. [1] https://github.com/servo/core-foundation-rs https://github.com/servo/core-foundation-rs
  • edko 6y ago
    Thanks for the link. Do you know of any examples that use this crate that would be easy enough for a beginner to start learning how to use it?
    • diego_moita 6y ago
      The folder /cocoa/examples in the repo I linked has some very simple ones.
• Keyframe 6y ago
  Any pointers / way for cross-compiling on linux for windows? Now Apple for MacOS and iOS, Android and maybe game consoles and Rust is a 1st class citizen!
• roblabla 6y ago
  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? 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! https://github.com/microsoft/win32metadata https://github.com/microsoft/win32metadata
  • Arnavion 6y ago
    So does this generator need access to the .winmd files at build time to be able to generate the bindings? Are they available for non-Windows builders?
    • roblabla 6y ago
      The WinMD files are shipped with windows-rs. You can find them here[0]. For cross-compilation use-cases, the main blocker is [1]. [0] https://github.com/microsoft/windows-rs/tree/master/crates/winmd/default https://github.com/microsoft/windows-rs/tree/master/crates/w... [1] https://github.com/microsoft/windows-rs/issues/142 https://github.com/microsoft/windows-rs/issues/142
  • ROARosen 6y ago
    Does that meant it's compatible with any other language?
    • roblabla 6y ago
      Any language that can call C ABI and support the necessary datastructures, yes. That's the point of win32metadata.
• g051051 6y ago
  Welcome back, J/Direct! https://en.wikipedia.org/wiki/J/Direct https://en.wikipedia.org/wiki/J/Direct
  • pjmlp 6y ago
    P/Invoke, it never went away.
• skybrian 6y ago
  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?
  • ChrisSD 6y ago
    It does not generate safe bindings. Currently the metdata is scrapped from Windows headers which don't have all the necessary information to go that far. In the future the metadata could be improved. The metdata format is the same as used by .NET and WinRT.
• cletus 6y ago
  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. 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. 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. Kudos.
• edko 6y ago
  I wonder if this would allow using a WebView2 from Rust? I've searched the repository, but was not able to find it.
  • zRedShift 6y ago
    Search everything here: https://microsoft.github.io/windows-docs-rs/doc/bindings/windows/?search=WebView2 https://microsoft.github.io/windows-docs-rs/doc/bindings/win...
• type0 6y ago
  Can we expect to get a better compilation time with this?
  • jynelson 6y ago
    I'm helping work on the compile times :) https://github.com/microsoft/windows-rs/issues/420 https://github.com/microsoft/windows-rs/issues/420
• AndrewGaspar 6y ago
  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?
  • steveklabnik 6y ago
    https://www.reddit.com/r/rust/comments/l23fr7/rust_for_windows_bindings_generating_the_entire/gk3bcxb/?context=3 https://www.reddit.com/r/rust/comments/l23fr7/rust_for_windo...
• nn3 6y ago
  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.
  • bluejekyll 6y ago
    I assume you're talking about more than just libc. Many of the Linux specific facilities are captured in higher-level cross platform implementations, like mio abstracts over kqueue on BSD and epoll on Linux. What are the APIs you're interested in that are missing or of poor quality?
• Ericson2314 6y ago
  There is some good stuff here but also some sloppiness. 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. 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 https://crates.io/crates/windows_macros https://crates.io/crates/windows_macros thankfully, but that should be the only way to get the macro.
• sudeepj 6y ago
  They managed to secure the crate name "windows" [1] which always is a nice touch. I clearly remember that this name was squatted. [1] https://crates.io/crates/windows https://crates.io/crates/windows
• skohan 6y ago
  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. 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. 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.
• tragomaskhalos 6y ago
  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: - MS were already moving to a model where they prefer to stick with the standards-compliant form of a language: vide C++/WinRT - Rust has enough features built in to facilitate this, specifically being able to hook into the compilation process
• dalu 6y ago
  Why would I ever write code on Windows if I don't have to because I'd be writing a Windows program? Microsoft is anti freedom, anti developer. Windows is only good for games. Real development happens on other platforms. They bought github and turned it into something against the spirit of free software. First thing was to add deleting issues and comments. Microsoft is evil. Always had been and if you trust them one bit you're a fool
  • simooooo 6y ago
    “Why would I ever write code on Windows if I don't have to because I'd be writing a Windows program?“ That reads like a grammatical Infinite loop