win32metadata

Hi JB! Funny to cross paths with you in this context. I don't know if you remember me but I was a rookie programmer who got the pleasure of joining the VideoLan Conference in Dublin back in 2014, and then Paris the next year, and you were very kind to me. The GitHub issue title here is unfortunately misleading. I have renamed it to "ideas to improve windows header files and libc". Also, I hope it is clear that I rebutted the points made by the OP, because I completely agree with your summary that the mingw-w64 people are skilled, nice and very clever and think about all use cases. If any drive-by HN readers work at Microsoft, please help us with this issue: https://github.com/microsoft/win32metadata/issues/766

Windows has partly moved and is moving in this direction - WinRT (higher-level, C#-like but without requiring the .NET runtime and GC) APIs are already defined in metadata, and now Win32 (lower-level, C-style) APIs are being defined that way as well: https://github.com/microsoft/win32metadata/blob/master/docs/...

Interesting. The real thing here is the Win32 Metadata project: https://github.com/microsoft/win32metadata It contains definitions that can be used to automatically generate bindings to any language. So, we have C# and Rust as examples, but the very same definitions could be used with languages like Zig. Very cool initiative.

See: https://github.com/microsoft/win32metadata#winmd-emitter-ove... It seems at least one of their hacks is not valid in the CLR, so that bridge has been crossed. Plus they do make use of attributes.

There is a performance penalty when accessing APIs over WinMD and that is acceptable when you're only using them sparingly. I'd be curious how using Win32 APIs over WinMD performs instead of using PInvoke or FFI. Edit: Here is the actual project if anyone is interested in following along. https://github.com/microsoft/win32metadata/

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