3b / 3b-winmd Goto Github PK

Currently it just generates a com-on definition for each interface.

For more complicated APIs it might be nicer to have a smarter/more automatic wrapper generator. (CLOS wrappers, Automatic marshalling, handling object lifetime (gc vs apartments, etc), hiding the GUID stuff, event handling/delegates, etc)

For things like DirectX (nano-COM, agile interfaces, etc) it might be nicer to have something simpler/faster?

misc links:

• .net/clr
  https://learn.microsoft.com/en-us/dotnet/standard/native-interop/com-callable-wrapper
  https://learn.microsoft.com/en-us/dotnet/standard/native-interop/runtime-callable-wrapper
• c++
  https://learn.microsoft.com/en-us/windows/uwp/cpp-and-winrt-apis/
  https://learn.microsoft.com/en-us/windows/uwp/cpp-and-winrt-apis/consume-apis
  https://learn.microsoft.com/en-us/windows/uwp/cpp-and-winrt-apis/consume-com

a few combinations to consider

• full "projection" (nice wrappers as main API, hide details where possible, etc)
  The metadata provides lots of useful things to allow automatic generation of "nice" APIs:
  • which function to use to release various return values
  • which arguments are reserved and should be 0 (so can be skipped in wrapped API)
  • which argument/field shows size or count of elements in an array
  • fields that must be initialized to size of struct
• low-level direct C-like bindings (pointers, manual resource management etc)
  Easier to generate, but harder to use. Good enough for a lot of simple things though. Probably can get close enough to the 'nice' api for a lot of slightly more complicated things by generating with-foo macros.

and orthogonal to that:

• Generate entire FFI at once (probably as a bunch of separate systems so people don't have to download everything at once).
  Probably easier, since it doesn't require the parser/generator code to be reliable enough for general use, but also leads to shipping a big pile of untested code, and not sure how much overhead compiling/loading unused FFI definitions would add.
• API to let users generate just the FFI they need and put it directly into their project.
  More work since the parser/generator needs to be more reliable and more configurable. Savings from generating just what you need might in practice be lost if dependencies also needed the same thing and you ended up with multiple copies (or more work to avoid the duplication).

• test with other winmd files (WinRT, App SDK, etc)
• decide if it should generate a full ffi, or be a tool for generating project-specific subsets #2
• generate proper ffi defs (fix names, generate package definitions, etc)
• (optionally?) filter out ansi or unicode versions of things (A and W suffix)
• translate typedef and GUID constant structs properly
• generate something for the GUIDs attached to COM structs
• accessors for sub-octet struct slots (c bit fields)
• add comments/docstrings for more custom attributes (docs, const, etc)
• write tests for struct/union layout generation (generate some C code to compare offsets against?)
• generate high-level wrappers
• clean up code
• api, documentation
• figure out the details of COM and decide if generating com-on definitions is enough for everything, or if some APIs could/should use something else #3