microsoft
Win32Metadata support
I opened the issue that requests DirectStorage support on win32metadata project. The contributor said it is needed that DirectStorage team produce its metadata. I think it would be helpful to generate language bindings.
We don't have a plan to do this in the short term, however we'd gladly consider a pull request to this repo that generates the win32metadata from dstorage.h/dstorageerr.h.
The request is noted. I, personally, am pretty keen on getting rust bindings for these via win32metadata, so this might be something I do in my spare time.
Is there a way to get the DirectStorage SDK besides nuget? For one, I would like such a thing for c++ development, however I'm not sure how that would be compatible with rust (which I would also be interested in), either. I see it's also in vcpkg (which just uses the nuget package)...but really, why is this not in a "mainline" windows sdk? How do you envision it being used by rust projects? I doubt that a random 3rd party can legally repackage the directstorage headers/libs into a *-sys crate...
https://www.nuget.org/packages/Microsoft.Direct3D.DirectStorage/1.0.2/License
b) Distribution Requirements. For any code you distribute, you must:
i. add significant primary functionality to it in your applications;
Thanks for the feedback, I'm going to try find an answer to the "can a third party redistribute the dlls in a rust crate" (or other packaging system) question. This is certainly a scenario we want to enable.
The easiest way to use a nuget package, if you don't want to use nuget or vcpkg directly, is to just unzip the nuget file (these are just zip files with a different extension) and use it from there.
@damyanp are there still plans to get these bindings into the Windows SDK - and as such into win32metadata - or is the .winmd in the NuGet package all that's available for now?
There are currently no plans to add the DirectStorage headers to the Windows SDK. However, the nuget package does include the windmds, and the header files are now under the MIT license.
@damyanp thanks, but the winmd itself is not code, and is also not in distributable_files.txt, meaning that a user-crate is not allowed to carry this file around?
For all intents and purposes the winmd file is equivalent to the header file. We can see about finding some way to more explicitly explain this in the license.
I'd imagine that any user crate would need to download the dlls anyway to be useful, so I wonder if the winmd needs to be included in the crate anyway?
@damyanp that'd be appreciated, as the winmd files are definitely binary.
Not exactly sure. For a Rust crate we'd need the .lib at build/compile time (Rust crates are distributed as source code), and the .dll at runtime, and there's not always a consensus whether the API wrapper crate or the crate consumer should provide these.
However, we don't need the winmd in the crate; only in the git repo (for convenience) to generate Rust source code that is checked in to the repo and published as a crate (so that the end-user has minimal dependencies, for what ends up being a 2k-2.5k generated bindings file).
Note that it's not my crate, so any of this is better discussed with the actual author.
Besides, I've filed https://github.com/microsoft/DirectStorage/issues/38 and am inclined to generate a .winmd locally to have improved bindings and dodge the licensing complexity.