Microsoft provides a natural and idiomatic way for Rust developers to call Windows APIs

announcements
1

Good News folks!

18 Likes
2

Wow, I don't do much windows programming atm, but this is huge no? Getting direct Win API support from Microsoft... Looks great.

Would be nice if hardware manufacturers like AMD, Nvidia, Intel would follow suit for drivers, firmware...

2 Likes
3

Just to be clear this is for WinRT, the modern Windows APIs, not the old Win32 Windows APIs (of winapi fame).

One interesting thing about this is that instead of using a build script to generate the necessary module code, it instead uses a proc_macro. So you can just do this:

import!(
    dependencies
        "os"
    modules
        "windows.data.xml.dom"
        "windows.foundation"
        "windows.ui"
);
2 Likes
4

I do think this is very cool, but someone pointed out to me in a discussion about this that it's missing the rerun-if-changed that a build script can use, so it may not be appropriate, depending. Still, very interesting idea for sure!

5

Another thing is these kinds of proc_macros impede things like GitHub - dtolnay/watt: Runtime for executing procedural macros as WebAssembly which promotes isolation as part of its rationale:

a macro's only possible interaction with the world is limited to consuming tokens and producing tokens

1 Like
6

Well it is a pre-release version so this may still change. Or not.

7

Well, considering the recent state of AMD's graphics drivers, it might be good if they made the switch...

8

Pure proc_macros can still take advantage of watt, and there are and will be many of them. That's always how optimizations are, you conform to some limitations, you get better performance. If you need more power, you don't get the better performance, but the optimization is still there for other code to use nonetheless.

9

While true, I'm not sure I would cast the anything which inhibits dependency tracking as merely a missed optimization. I'm more long-term concerned by rerun-if-changed things Steve mention above, being the other half of that discussion he mentioned. This kind of thing is why build-plan's don't and won't work.

I'm never going to even on a system where these proc_macros would run, but it is still likely to cause me problems. I really don't like this successful attempt to bypass the build and module system.

That is really all I have to/will say on the matter.

10

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.