win32metadata

I know Jonathan Marler for some of his Zig talks and his work in the win32 api bindings for Zig[0], they are even linked from Microsoft's own repo[1] (not sure why he has 2 github users/orgs but you can see it's the same person in the commits). [0] https://github.com/marlersoft/zigwin32 [1] https://github.com/microsoft/win32metadata

Yeah this is correct. You don't want to pass these values around "by value" but, you should be able to "embed them" and pass "pointers to them". It's a middle-ground between a completely opaque type which you would also pass around by address, but, with the added benefit that you allocate your own storage for it. I sort of mentioned this in the blog but this is good clarification. > if you want to pass a shared_ptr to Zig, you need to pass a pointer to the shared pointer For lore, I believe this GitHub thread is where I first learned about the how types of the same size/alignment can still have different ABIs :) https://github.com/microsoft/win32metadata/issues/623#issuec...

Its close in spirit to DRM: they enforce that if you are using their projects, it is under their legal terms. Many of their VS Code extensions[0] have license terms which /prohibit/ them from being used in editors that are not Microsoft's VS Code editor, and Microsoft can issue cease-and-desist for violations of this, as well as 'open source forks of VS Code' using their marketplace services. Microsoft also has a pattern they follow where they publish repositories on GitHub to proclaim they are open source, while actually distributing proprietary binary blobs in them that are fundamental core parts of functionality to the codebase[2][3][4] [0] https://github.com/microsoft/vscode-cpptools/issues/6388#iss... [1] https://github.com/microsoft/vscode-cpptools/issues/5784 [2] https://github.com/microsoft/win32metadata/issues/766 [3] https://dev

I'm always looking for alternatives to AutoHotkey and small C WINAPI programs I've written. Rust doesn't quite cut it, even with Microsoft's windows-rs library using the WinAPI functions is worse than it was with plain C. This is because you have to hunt the right libraries and features to import, it's surprisingly time-consuming. Excited to look how LuaRT exposes WinAPI, my ideal would be one global namespace where you can easily auto-import all the normal functions. Microsoft has made it somewhat easy for library authors to generate the externs with their relatively new Win32metadata package: https://github.com/microsoft/win32metadata

Have you looked at Microsoft's Win32 API metadata package [0]? They're using it to generate C# and Rust bindings, and other people have targeted other languages. [0] https://github.com/microsoft/win32metadata

There is still the occasional incredibly subtle link time fuckery in Rust. https://github.com/microsoft/win32metadata/issues/1274 "Minor" semver updates to crates breaking things via e.g. unexpected MSRV bumps is pretty common too, with some resulting bitrot. That said, I agree with you that things in Rust are at least better. Imperfect, but better.

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