win32metadata VS panama-foreign

As /u/huellenoperator notes, that this needs a pointer to a mutable string comes straight from microsoft through win32metadata. Maybe it's a mistake on Microsoft's side, but if it's not you're taking big risks.

Microsoft offers official "bindings" to Win32 APIs through win32metadata. However, until recently, it did not include metadata for kernel-level functions or WDK. In early 2021, an issue was raised through windows-rs regarding this limitation, but progress was slow until now. Microsoft has finally released official metadata for WDK, which can be found on the wdkmetadata repository. The latest comment on the issue thread can be found here:

for win32metadata's kernel api tracking issue, https://github.com/microsoft/win32metadata/issues/401

Small quirk, but this is Microsoft's official crate, based on their own win32metadata project! I've been using it preferentially now instead of the winapi crate since it's offically from MS, regularly updated, and more feature-rich in general.

Any examples? Since the API bindings in windows-sys are generated from the metadata generated from official Windows SDK headers I'd not expect to see this kind of difference.

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.

It might be interesting to have bindings generated for the entirety of Win32 API through https://github.com/microsoft/win32metadata

Note that the data (or the tool to extract the data) is publicly available under an open source license.

The Rust bindings are indeed generated from metadata, which provides several language projections, not only Rust.

Going to copy my Reddit comment over to HN because I think it's valuable:

---

One of the coolest things that's been worked on (by this same author, no less!) isn't even in the article!

Per has written a pretty-printer for MemorySegments and ByteBuffers that can hex-dump memory or render memory/buffers as their "struct" representations given some MemoryLayout.

You can also customize it with your own printers, it's wicked cool and helps so much to debug buffers when working with them.

https://github.com/openjdk/panama-foreign/pull/695

What do I mean by that? Have a look at this comment for an image of a raw memory structure layout I represented with MemoryLayout, and the pretty-print rendering of it:

https://github.com/openjdk/panama-foreign/pull/695#issuecomm...

[Here's the project github](https://github.com/openjdk/panama-foreign)

https://github.com/openjdk/panama-foreign/blob/foreign-jextract/doc/panama_jextract.md ..look at these examples

Incentive for JVM devs? We know that C interoperability, malloc, free, structs are already supported on JVM natively since Java 14 with project panama's foreign-memory-api without JNI. I've been using sun.misc.Unsafe since Java8 and also LWJGL's C API.

Automated ffi parser soon (TM) to be in standard Java: https://github.com/openjdk/panama-foreign/blob/foreign-jextr...