Win32 APIs provide powerful functionality that let you get the most out of Windows in your applications. While these APIs are readily accessible to C and C++ developers, other languages like C# and Rust require wrappers or bindings in order to access these APIs. In C#, this is commonly known as platform invoking or P/Invoke.
Historically this has required developers to handcraft the wrappers or bindings, which is error prone and doesn’t scale to broad API coverage. In recent years, given the strong demand for calling Win32 APIs from various languages, several community projects have spawned to provide more strongly typed and idiomatic representations of these wrappers and bindings to provide an improved developer experience and spare developers the overhead of creating them themselves. Some notable projects include PInvoke for .NET and winapi-rs for Rust.
The main challenge with these projects is they are manually maintained, which makes broad and sustained API coverage difficult and costly, and their work doesn’t really benefit other languages.
As owners of the Windows SDK, we wanted to see where we could provide unique value here, take some of the burden off of the community, and make achieving broad and sustainable API coverage across languages a reality.
The result of this is our win32metadata project and corresponding Win32 language projections now in preview on GitHub!
I’m not a developer, but I think this means that Microsoft is trying to make it easier to tap into the Win32 API with languages other than C and C++. This seems like a smart move considering how popular some of these more modern and/or recent languages have become. It also highlights that despite repeated attempts to kill Win32, Microsoft seems to have accepted that it simply isn’t going anywhere anytime soon.
Basically, the header files that define the API for C and C++ don’t provide enough information for languages that provide stronger compile-time guarantees, so, historically, bindings for those languages have been written by humans trawling through the MSDN API documentation and manually translating the instructions about how the APIs must be called into something a compiler for a given language can enforce.
What Microsoft has done is similar to what Glib-based libraries (eg. GTK) do with GObject Introspection definitions.
They provided higher-level interface definitions that (i.e. data files that give additional machine-readable information on what invariants must be upheld when interacting with the APIs), so it’s possible to programmatically generate language bindings.
If Microsoft wants win32 to go away, they can always make Metro/UWP apps easily installable outside their Store. I mean, Microsoft is still trying to convince developers to sign their executables (some open-source projects still don’t), what makes them think those same developers will put their apps in the Store, where they have to agree to all kinds of terms and conditions (and a cut of the revenue for paid apps).
Basically, Microsoft’s “problem” is their OS was developed in pre-App Store times and has to maintain compatibility with it’s legacy of openness (compared to iOS, obv, which is the strategy Microsoft tries to emulate).
kurkosdr,
I think there can be a lot of merit in new toolkits & frameworks, but you are right that when your upgrade path is accompanied with handcuffs it’s a harder sell. I’m glad when people say they’ll protest it, but at the same time people’s attention spans are short. They resist changes in the short term, but a few news cycles later and the resistance has faded. Both apple and microsoft are keeping the pressure on and playing the long game. And to win this game their restrictions don’t even need to be 100% effective, they just have to be effective against the masses who will rope the rest of us in via network effects rendering independent/3rd party distribution not commercially viable. I’m afraid that mainstream computing platforms will get increasingly locked down like IOS in the future 🙁
There is always the likes of Adobe and Autodesk, which refuse to give 30% of the retail price to Microsoft and Apple for the flagship version of their product, to keep Windows and Mac OS open.
kurkosdr,
Yeah, I hope so too. But I hope it isn’t just open for the big guys, that wouldn’t be right. Most of us aren’t on equal footing and some backroom deals could persuade the big companies to buy in while throwing all the little guys under the bus.
They are merging both stacks, Win32 and UWP, check sibling comment from me.
I’m glad I don’t code any more. It’s somebody else’s problem!
HollyB,
Personally I really like coding and it isn’t something I want to ever give up. My biggest gripes aren’t programming itself so much as office politics and the lack of interesting work, haha.
I think microsoft is doing this to hedge its bets in case alternative system programming languages become more popular, they wouldn’t want a popular language to not support windows APIs! That said anything that makes it easier to use languages beyond C/C++ is progress IMHO.
@Alfman
I used to like the end result and some of the philosophically sound structures and professional interactions and, yes, artistic elements of finished products more than the actual coding itself. If I were to do anything now it would be a major investment or I would have to rely on frameworks.
My mind just doesn’t have the enthusiasm or energy for the design issues anymore which makes the drudge work and office politics stuff begin to take over. The stuff I worked on was once new ground but others have since independently broadened and had various successful implementations succed. Nothing all in one place but the concepts and implementations are out there.
I still use the philosophical and conceptual tools I learned but apply them in other ways to largely none IT things. I have more scope for art and more scope for making my own things and more scope for different relationships. Nothing necessarily new but new for me. A bit like a good OS or good design if you can’t find an obvious trace of my work it means I’m doing okay with it.
There is a possibility I can commercialise some things especially some of the manufactured stuff but that would be an end point not a goal in itself. Viewing most of the consumer stuff out there almost all of it is wrong so there is a gap in the market for one thing I’m making which solves a problem for me. Going back to coding I suppose the same is true with this. As and when you discover or rediscover something interesting for the right reasons the output and the people you work with may change and it’s not always a direct path to this.
Yes a range of new language API bindings is very useful. I don’t know the technicals of this but a generic mechanism which allowed new additions would be useful.
Myself I would refactor C/C++ and boost the libraries and put templates in their place and deprecate the junk and have compilers carry on merrily compiling the new model and the old model with warning systems handling this. That’s just me. Other opinions may vary. There’s also other things like portability layers and issues with toolchains which need sorting out.
> It also highlights that despite repeated attempts to kill Win32, Microsoft seems to have accepted that it simply isn’t going anywhere anytime soon.
Microsoft already accepted that last year, this is why Project Reunion was born.
https://blogs.windows.com/windowsdeveloper/2020/09/22/kevin-gallo-microsoft-ignite-2020/
https://github.com/microsoft/ProjectReunion
Which was actually even reported on this same website,
https://www.osnews.com/story/131815/microsoft-to-unify-win32-and-uwp-apps-with-new-project-reunion/
So what is to wonder with yet another milestone of Project Reunion?