The API that will not die: Microsoft opens crypt to unleash Win32 on Rust
- Reference: 1611586027
- News link: https://www.theregister.co.uk/2021/01/25/win32metadata/
- Source link:
The Windows API exposes large chunks of the Windows operating system to programmers. If you code in C or C++, the API calls are "readily accessible," according to Microsoft.
[2]
Anything else usually requires some sort of wrapper. An example of this is [3]P/Invoke , which is intended to service C# developers (although it now points users to "a new, preferred approach for Win32" – Microsoft's win32metadata project.)
Microsoft's aim, as custodian of the Windows SDK, is to "make achieving broad and sustainable API coverage across languages a reality." In other words, it wants a one-stop shop for these API calls using whatever language a developer cares to bring to the table. Eventually.
[4]
As one would expect, the first language projection is C#/Win32, built with the assistance of Andrew Arnott of the P/Invoke project.
Interestingly, a [5]Rust language projection is also in progress, allowing users to hit the Windows API directly from the metadata "as if they were just another Rust module."
On top of this, Microsoft is working on a modern C++ projection, and a look at the [6]roadmap has the Win32 metadata packaged published to NuGet.org for the latest Windows SDK version in time for the company's Build 2021 event in May this year.
The Windows API itself (both in Win16 and Win32 guise) has long been a fixture for those targeting the Windows operating system. A dog-eared and decades-old copy of Dan Appleman's [7]Visual Basic Programmers Guide to Win32 API likely decorates more than a few bookshelves, bookended by an additional tome or two by [8]Charles Petzold . Works by Petzold, if you have some extra reading time, really drive home the potential horrors that await a careless coder seeking to prod the weirder corners of the operating system.
At the last Build, back in May 2020, Microsoft kicked off [9]Project Reunion , a recognition that despite multiple attempts to replace the Win32 API with something fresher (WinRT and UWP spring to mind), Windows developers still needed those low-level calls.
[10]
The win32metadata project remains in a preview state at the moment. The publishing of the Win32 metadata package with all supported Windows SDK versions, as well as the publication of C#, C++, and Rust projections, is planned for the end of 2021. Other languages will follow in 2022 "based on demand." ®
Get our [11]Tech Resources
[1] https://blogs.windows.com/windowsdeveloper/2021/01/21/making-win32-apis-more-accessible-to-more-languages/
[2] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2YA75I@sXBP2FJxB5-B8sOQAAABQ&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[3] https://github.com/dotnet/pinvoke
[4] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33YA75I@sXBP2FJxB5-B8sOQAAABQ&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[5] https://github.com/microsoft/windows-rs
[6] https://github.com/microsoft/win32metadata/blob/master/docs/roadmap.md
[7] https://www.goodreads.com/book/show/3515657-v-b-programmers-guide-to-the-win32-api
[8] https://www.goodreads.com/search?q=Charles+Petzold&qid=qsMs7K8kA5
[9] https://www.theregister.com/2020/05/19/project_reunion_microsoft/
[10] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44YA75I@sXBP2FJxB5-B8sOQAAABQ&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[11] https://whitepapers.theregister.com/
FFI
I think this is basically what FFI gives you for many languages but this approach is never as nice as proper hand-crafted bindings.
Re: FFI
The FFI allows you to call C libraries, in a similar way to JNI. These are what allows bindings to be created but unfortunately do not replace bindings. Unfortunately it is still a lot of work. Some of it can be automated to an extent but C libraries are often far more intricate than that. Simple things like callbacks or "who holds the data" cannot be easily automated.
Bindings already existed
Rust has had Win32 / WinRT bindings via the winapi crate for a long time but they're manually defined. The potential benefit of the new approach is that they are machine generated and need less maintenance to benefit Rust or any other language target. It might even be possible to generate the bindings as part of the build process, i.e. the external crate just contains the meta data and a build.rs and bindings get generated automatically depending on what the code is using. It could also generate documentation and other stuff onto the bindings so they are available in the IDE.
This looks to be a similar approach that Gtk has traditionally used.
It is so annoying that so much effort is on binding all these other languages to C. I honestly think that just embedding a tiny C compiler in other languages just to consumer header files and help link against native objects could be a better solution than others. For example I imagine C++ would not be nearly as popular if it wasn't one of the few languages which can natively consume C.
Looking at the trendy stuff, most of Rust's crates.io is filled simply with bindings to C libraries. They should just bolt on a tiny C compiler and be done with it. I think the only language that is going in the generally correct direction is Go where they do allow some C in the go preamble. However they are still very far from utilizing C headers.
C at this point shouldn't be thought of as a language but pretty much base platform. Better integration with it can only improve other languages.