microsoft / win32metadata

Tooling to generate metadata for Win32 APIs in the Windows SDK.

Overview

Win32 APIs provide functionality that not all languages and frameworks support themselves. When developing for Windows, developers often call into Win32 APIs to access this functionality.

Historically, this has required manually redefining the APIs to make them accessible, which is fragile and error-prone. Community projects like https://github.com/dotnet/pinvoke (.NET) and https://github.com/retep998/winapi-rs (Rust) have taken on the burden of providing strongly-typed and validated API signatures for their frameworks, but the projects are manually maintained, which is hard to sustain and makes it challenging to provide thorough API coverage.

This project aims to provide metadata for Win32 APIs such that idiomatic projections and projects like the ones above can be generated for all languages and frameworks in a more automated way and with more complete API coverage.

To call Win32 APIs from the language of your choice based off of this metadata, use the following language projections:

• C# - https://github.com/microsoft/cswin32 (Microsoft)
• Rust - https://github.com/microsoft/windows-rs (Microsoft)

---

• Beef - https://github.com/jayrulez/Win32-Beef (Community)
• D - https://github.com/rumbu13/windows-d (Community)
• Dart - https://github.com/dart-windows/win32 (Community)
• Python - https://github.com/ynkdir/py-win32more (Community)
• Zig - https://github.com/marlersoft/zigwin32 (Community)

Note: Community projects are listed here to help with discovery but are not officially validated by Microsoft.

See the roadmap and FAQ for more details.

If you'd like to browse the metadata to see what we're emitting, extract Windows.Win32.winmd from the Microsoft.Windows.SDK.Win32Metadata NuGet package and load Windows.Win32.winmd in ILSpy. Download the package and rename it to .zip to browse and extract its content.

Principles

Below are some principles that guide the metadata that we produce:

• Provide the broadest API coverage possible
• Keep the names of the original APIs, but express in metadata additional information that can make them easier to use.
• Convert non-specific types like uint that use constants into explicit enums to improve usability and discoverability. Keep enum member names consistent with the original constant names to preserve SEO.
• Express Win32 typedefs like HANDLE and GDI objects as strongly-typed structs. The definition of these structs include how to dispose of the resources (like CloseHandle or DeleteObject). It is up to language projections to make use of this information in a language-specific way. For example, a C# projection could use SafeHandle objects for HANDLE and GDI objects.

Architecture

See ARCHITECTURE.md.

Projections

See PROJECTIONS.md.

Contributing

See CONTRIBUTING.md.

Licensing

MIT

• All metadata assemblies (e.g. Windows.Win32.winmd)
• All tooling in this repository and in the Microsoft.Windows.SDK.Win32Metadata NuGet package

Windows SDK

• All Windows headers (e.g. RecompiledIdlHeaders) and Interface Definition Language (IDL) files in this repository and in the aforementioned NuGet package.

Trademarks

This project may contain trademarks or logos for projects, products, or services. Authorized use of Microsoft trademarks or logos is subject to and must follow Microsoft's Trademark & Brand Guidelines. Use of Microsoft trademarks or logos in modified versions of this project must not cause confusion or imply Microsoft sponsorship. Any use of third-party trademarks or logos are subject to those third-party's policies.

win32metadata's Issues

Retain info about int return type

Some methods return Win32 error codes while others return NTSTATUS or even HRESULT. We need to be aware of these return types so we can represent them with these semantics in our projections.

Consider simplifying structs with array fields

The metadata representation for structs containing fields of array types is unusually complex to parse. Using a more logical representation would significantly ease adoption and make life easier for future developers attempting to consume the metadata.

String parameters aren't always represented properly in metadata

Two different problems here, but they both result in projections not being able to project string parameters properly.

Missing marshalling descriptor.

The original definition of WideCharToMultiByte is:

int WideCharToMultiByte(
  UINT                               CodePage,
  DWORD                              dwFlags,
  _In_NLS_string_(cchWideChar)LPCWCH lpWideCharStr,
  int                                cchWideChar,
  LPSTR                              lpMultiByteStr,
  int                                cbMultiByte,
  LPCCH                              lpDefaultChar,
  LPBOOL                             lpUsedDefaultChar
);

The metadata definition shows up as this (from ILDasm):

.method /*0600337C*/ public hidebysig static pinvokeimpl("KERNEL32" nomangle winapi) 
        int32  WideCharToMultiByte([in] uint32 CodePage,
                                   [in] uint32 dwFlags,
                                   [in] uint16* lpWideCharStr,
                                   [in] int32 cchWideChar,
                                   [out][opt] int8* lpMultiByteStr,
                                   [in] int32 cbMultiByte,
                                   [in][opt] int8* lpDefaultChar,
                                   [out][opt] int32* lpUsedDefaultChar) cil managed preservesig

lpWideCharStr is represented as a uint16* with no clue to indicate that this is actually a wide string. Similarly, the lpMultiByteStr and lpDefaultChar parameters have no clues to indicate that they are a narrow string and narrow char, respectively.

Marshalling descriptor obscures actual type

The original definition of GetEnvironmentVariableW is:

DWORD GetEnvironmentVariableW(
  LPCWSTR lpName,
  LPWSTR  lpBuffer,
  DWORD   nSize
);

The metadata definition shows up as this (from ILDasm):

.method /*06002C1C*/ public hidebysig static pinvokeimpl("KERNEL32" nomangle winapi) 
        uint32  GetEnvironmentVariableW(uint16*  marshal( lpwstr) lpName,
                                        [out][opt] uint16*  marshal([ + 2]) lpBuffer,
                                        [in] uint32 nSize) cil managed preservesig

The lpName param has a marshal spec that denotes it as lpwstr. But the lpBuffer param has had its "string-ness" discarded in favor of representing it as an array of uint16.

PathFindSuffixArrayW is missing metadata to describe parameter element as character

The apszSuffix parameter of the PathFindSuffixArrayW function has a custom attribute to describe it as an array, but it fails to initialize the ArraySubType property to indicate that the array elements are characters. As a result, in C# we're getting ushort as the type instead of char, which is much less usable.

Consider including machine readable docs for published APIs so that languages can generate code comments

Unecessary constants for interface GUIDs in Apis class

The interface definitions already have the GuidAttribute where the value is store. These constants should probably be removed.

We need a way to distinguish handles from pointers from pointer-sized integers

Ryan said:

I've been operating from the assumption that our metadata maps "native int" and "native uint" to integer types, not pointer types. This is because they are being used for integer types like WPARAM, LPARAM (see WNDPROC), and SIZE_T (see D3D12CreateVersionedRootSignatureDeserializer).

I agree. We need to distinguish handles/pointers from pointer-sized integers for the best language experience.

In .NET, we want to use IntPtr for handles, void* for pointers, and nint for integers that the user may actually care to read/write.

Consider simplifying the definition of delegates

WinRT delegates are defined as System.MulticastDelegates with a single Invoke method (beyond the .ctor). Win32 delegates additionally contain superflous BeginInvoke and EndInvoke methods that are specific to C# and do not provide additional value to generators. Only the Invoke method should be present.

This isn't a big problem, so if its too much work to elide these that's also OK.

NativeTypeInfo attribute is applied to method rather than return

Return types are not being interpreted properly because the NativeTypeInfoAttribute is applied to the method instead of to the return value.

[DllImport("USER32", ExactSpelling = true)]
[NativeTypeInfo(UnmanagedType.Bool)]
public unsafe static extern int GetLastInputInfo([Out] LASTINPUTINFO* plii);

Document when and how APIs are transformed to provide "friendlier" names

What's the philosophy or guiding principles that govern whether an API is given a friendlier name in metadata. Can we document or point to the current list of transformations?

IEnumDebugPropertyInfo.Next is missing annotations about array parameter, and out parameter

EXPECTED

unsafe int Next(
   uint celt,
   [NativeTypeInfo(SizeParamIndex = 0, ArraySubType = UnmanagedType.IUnknown)] DebugPropertyInfo* pi,
   [Out] uint* pcEltsfetched);

ACTUAL

unsafe int Next(
   uint celt,
   DebugPropertyInfo* pi,
   uint* pcEltsfetched);

Handles are discarding type information and turning into void*

I thought that handles such as HANDLE, HWND, etc used the DECLARE_HANDLE macro to define them and their types, to protect against accidental mixing. So HWND isn't typedef'd as void*, but as

struct HWND__ { int unused; }; typedef HWND__* HWND;

Let's try to preserve this typing in some way.

Distinguishing equivalent SafeHandle types

I'd like to reuse SafeHandle-derived types from .NET wherever possible to facilitate interop with .NET APIs as well as the p/invoke methods. So for example instead of defining my own SafeHandle-derived type to call Kernel32's CloseHandle, I could use .NET's SafeFileHandle or SafeProcessHandle, both of which close their handles with Kernel32's CloseHandle.

❓ But the question would be which of these two SafeHandle types to use in the API for a given IntPtr that is annotated as being closed with CloseHandle? Picking the right one means meeting customer expectations of taking that SafeHandle to other .NET APIs that fit that scenario. CreateFile should return SafeFileHandle and process-related functions should take the other. But should the metadata include such .NET-specific annotations or should I create such a table of extra data specific to .NET within the C# projection?

Summarize in readme of how API coverage is determined and what is currently available

Since many important APIs are missing.

Streamline enum definitions

The metadata for enums are a little messy right now. For example:

enum ACTCTX_COMPATIBILITY_ELEMENT_TYPE
  ACTCTX_COMPATIBILITY_ELEMENT_TYPE_UNKNOWN: 0
  ACTCTX_COMPATIBILITY_ELEMENT_TYPE_OS: 1
  ACTCTX_COMPATIBILITY_ELEMENT_TYPE_MITIGATION: 2
  ACTCTX_COMPATIBILITY_ELEMENT_TYPE_MAXVERSIONTESTED: 3

Most languages require the enum type and enum field combined, so a developer wanting "OS" would need to specify ACTCTX_COMPATIBILITY_ELEMENT_TYPE::ACTCTX_COMPATIBILITY_ELEMENT_TYPE_OS. Needless to say that's a little painful.

The trouble is that there's not a whole lot of consistency. The example above is simple enough as you can just remove the type name from the field names. But there are many examples that would require different handling. For example:

enum ACL_INFORMATION_CLASS
  AclRevisionInformation: 1
  AclSizeInformation: 2

enum ACTCTX_REQUESTED_RUN_LEVEL
  ACTCTX_RUN_LEVEL_UNSPECIFIED: 0
  ACTCTX_RUN_LEVEL_AS_INVOKER: 1
  ACTCTX_RUN_LEVEL_HIGHEST_AVAILABLE: 2
  ACTCTX_RUN_LEVEL_REQUIRE_ADMIN: 3
  ACTCTX_RUN_LEVEL_NUMBERS: 4

Then there are those that seem like they were intended to be constants and not enums at all:

enum __AnonymousEnum_Shlwapi_L2424_C1
  CTF_INSIST: 1
  CTF_THREAD_REF: 2
  CTF_PROCESS_REF: 4
  CTF_COINIT_STA: 8
.
.
.

There are also some that imply they should not be included at all (reserved):

enum BINDF2
  BINDF2_DISABLEBASICOVERHTTP: 1
  BINDF2_DISABLEAUTOCOOKIEHANDLING: 2
  BINDF2_READ_DATA_GREATER_THAN_4GB: 4
  BINDF2_DISABLE_HTTP_REDIRECT_XSECURITYID: 8
  BINDF2_SETDOWNLOADMODE: 32
  BINDF2_DISABLE_HTTP_REDIRECT_CACHING: 64
  BINDF2_KEEP_CALLBACK_MODULE_LOADED: 128
  BINDF2_ALLOW_PROXY_CRED_PROMPT: 256
  BINDF2_RESERVED_17: 512
  BINDF2_RESERVED_16: 1024
  BINDF2_RESERVED_15: 2048
  BINDF2_RESERVED_14: 4096
  BINDF2_RESERVED_13: 8192
  BINDF2_RESERVED_12: 16384
  BINDF2_RESERVED_11: 32768
  BINDF2_RESERVED_10: 65536
  BINDF2_RESERVED_F: 131072
  BINDF2_RESERVED_E: 262144
  BINDF2_RESERVED_D: 524288
  BINDF2_RESERVED_C: 1048576
  BINDF2_RESERVED_B: 2097152
  BINDF2_RESERVED_A: 4194304
  BINDF2_RESERVED_9: 8388608
  BINDF2_RESERVED_8: 16777216
  BINDF2_RESERVED_7: 33554432
  BINDF2_RESERVED_6: 67108864
  BINDF2_RESERVED_5: 134217728
  BINDF2_RESERVED_4: 268435456
  BINDF2_RESERVED_3: 536870912
  BINDF2_RESERVED_2: 1073741824
  BINDF2_RESERVED_1: -2147483648

Preserve interface inheritance relationships

All the interfaces are re-defining the IUnknown methods, and none of the inheritance relationships are preserved.

The metadata needs to reflect this relationship, through some combination of:

• Actually having the interfaces inherit from each other.
• Using the InterfaceImpl table to indicate methods that are inherited from the base.
• Using a custom attribute to call out that relationship.

ACTION REQUIRED: Microsoft needs this private repository to complete compliance info

There are open compliance tasks that need to be reviewed for your win32metadata repo.

Action required: 4 compliance tasks

To bring this repository to the standard required for 2021, we require administrators of this and all Microsoft GitHub repositories to complete a small set of tasks within the next 60 days. This is critical work to ensure the compliance and security of your microsoft GitHub organization.

Please take a few minutes to complete the tasks at: https://repos.opensource.microsoft.com/orgs/microsoft/repos/win32metadata/compliance

• The GitHub AE (GitHub inside Microsoft) migration survey has not been completed for this private repository
• No Service Tree mapping has been set for this repo. If this team does not use Service Tree, they can also opt-out of providing Service Tree data in the Compliance tab.
• No repository maintainers are set. The Open Source Maintainers are the decision-makers and actionable owners of the repository, irrespective of administrator permission grants on GitHub.
• Classification of the repository as production/non-production is missing in the Compliance tab.

You can close this work item once you have completed the compliance tasks, or it will automatically close within a day of taking action.

If you no longer need this repository, it might be quickest to delete the repo, too.

GitHub inside Microsoft program information

More information about GitHub inside Microsoft and the new GitHub AE product can be found at https://aka.ms/gim or by contacting [email protected]

FYI: current admins at Microsoft include @mikebattista, @kennykerr, @sotteson1, @dunhor, @BenJKuhn

Many structs are not unique in metadata

Similar to #34, we also have duplicate structs. These structs for example appear at least twice in the metadata file:

COINIT
COMPARTMENT_ID

Reconsider representing metadata logically

Right now the Win32 metadata often/always attempts to use C# types that guarantee a certain binary layout that is compatible with the ABI, rather than simply representing the APIs using logical metadata and leaving the ABI to be inferred. For example, an interface is modeled as a struct with a sequence of nested delegates. Various parameters, fields, and arrays are modeled in very awkward and confusing ways to ensure they meet some ABI constraint, or just because the C# compiler happens to gen them that way.

By contrast, WinRT metadata is purely logical. Interfaces are represented as interfaces in metadata, interface methods are simply virtual methods, the types of struct fields are simply those of the logical type of the field, etc. The end result is that the metadata is minimal, concise, unambiguous, and very compact on disk. This all makes it very easy to understand and parse and even reproduce with independent tools.

I would strongly urge we follow the WinRT model and simply treat the metadata as just the logical representation of the APIs - it's not the C# projection.

DXGI_ADAPTER_FLAG_FORCE_DWORD

The DXGI_ADAPTER_FLAG enum has this "special" constant that should probably be removed.

https://docs.microsoft.com/en-us/windows/win32/api/dxgi/ne-dxgi-dxgi_adapter_flag

HeapFree method is missing a flags enum

The HeapFree documentation define a flags parameter for which no enum is defined in the metadata.

We need either a flags enum or metadata to identify which constants may be used so we can create the enum in the projection.
In this case, the HEAP_NO_SERIALIZE constant is not even found in the metadata anywhere.

Nested anonymous enums are missing definitions

Looking at the type WhitePoint, it contains both an anonymous union and an anonymous enum. (Oddly, the anonymous enum doesn't appear in the docs).

The definition in icm.h looks like this:

typedef struct WhitePoint
{
    enum {CHROMATICITY,TEMPERATURE,D65} type;
    union
    {
        XYYPoint xyY;
        float CCT;
    };
} WhitePoint;

In the metadata, the nested union is defined, but the nested enum is not.

Non-COM interfaces shouldn't have the InterfaceTypeAttribute

Take ID3D11FunctionParameterReflection. It is not COM, and is not IUnknown-based. These types shouldn't have an InterfaceTypeAttribute on them.

Consider providing API partitioning attributes in metadata to allow minimal rebuilds

There's no obvious way to retrieve only the metadata for Direct2D or DirectWrite or WinHTTP or BCrypt or any other API in isolation. That's going to be very important.

Consider moving attributes into a different namespace

Does it make sense to have our custom attributes for the projection in a different namespace?

This might aid navigation/inspection of the metadata, by making the attributes easier to find and not cluttering up the SDK namespace with non-API related types.

Document how developers can contribute missing APIs

What are the steps, how to test changes, ideally how a CI build or at least a PR reviewer would validate changes, and how we ensure quality, coverage, and completeness.

Types implementing interfaces are handled incorrectly

Take CFunctionDiscoveryNotificationWrapper. It's defined as a default implementation of IFunctionDiscoveryNotification like so:

class CFunctionDiscoveryNotificationWrapper : public IFunctionDiscoveryNotification
{
  // Implements all 3 of IFunctionDiscoveryNotification methods with a stub, returning S_OK
}

CFunctionDiscoveryNotificationWrapper is appearing in the metadata, but it has two big issues:

• It provides duplicate definitions of the 3 override methods. Specifically, IFunctionDiscoveryNotification has three methods in addition to IUnknown: OnUpdate, OnError, and OnEvent. CFunctionDiscoveryNotificationWrapper erroneously duplicates these three methods in its own type definition.
• It is defined as an interface in the metadata. Seems like this should probably be a class. (Or perhaps not in the metadata at all?)

Method names are not unique

In the 10.0.21269.1000 update to the metadata, I see method signatures are no longer unique. For example, I see both of these methods, in the same class:

[DllImport("KERNEL32", ExactSpelling = true)]
public unsafe static extern ushort RtlCaptureStackBackTrace([In] uint FramesToSkip, [In] uint FramesToCapture, [Out][NativeTypeInfo(UnmanagedType.LPArray, SizeParamIndex = 1)] void** BackTrace, [Optional][Out] uint* BackTraceHash);

[DllImport("ntdll", ExactSpelling = true)]
public unsafe static extern ushort RtlCaptureStackBackTrace([In] uint FramesToSkip, [In] uint FramesToCapture, [Out][NativeTypeInfo(UnmanagedType.LPArray, SizeParamIndex = 1)] void** BackTrace, [Optional][Out] uint* BackTraceHash);

Is that really intentional?

Documentation-wise for this particular method, it only shows up in ntdll. So I'm wondering why we have a kernel32 export as well.
When there are more than one, how should a projection decide which one to use?

WSPUPCALLTABLE loses all type information of its delegates

The docs (and presumably the header file) specifies the type for each function pointer, but in the metadata all we get is IntPtr for each one.
I'd like to make use of native function pointers in C# 9 for this struct (and any similar ones).

__AnonymousEnum_Icm_L1401_C5 is missing

The WhitePoint struct contains a member that refers to a __AnonymousEnum_Icm_L1401_C5 struct, but that struct is not defined.

metadata version: 10.0.21269.1001

Consider removing empty enums

Is there a reason we needs these?

FormatMessage takes va_list args and deserves its own annotation

Native methods with variable argument lists deserve a special annotation. FormatMessage for example today is just listed with this as its last parameter [Optional, In] sbyte** Arguments. In C# we'd like to render this as void*, I suppose, and then provide a friendly overload that takes params object[] I suppose. But we'll need to know the nature of this parameter more than the metadata currently expresses.

COM interfaces should derive from each other

On COM interfaces, we should express base interfaces using CLR base type metadata instead of NativeInheritanceAttribute.

As discussed on Teams, .NET can absolutely interop with COM interfaces that derive from each other. For example in VS we do it with this interface: https://docs.microsoft.com/en-us/dotnet/api/microsoft.visualstudio.shell.interop.ivsfilechangeex3?view=visualstudiosdk-2019

varargs not being represented in metadata?

The SetupWriteTextLog method documentation says it takes a variable number of arguments. But the metadata doesn't have any hint of this.

Const strings can't be represented in struct fields

The original plan was to use [in] vs [out] parameters to put const on string parameters (wchar_t* vs const wchar_t*). But this scheme doesn't work for struct fields, which don't have [in] or [out] markers.

JsRuntimeVersionEdge should be an enum member instead of a constant

Per this doc, the JsRuntimeVersion enum should have 3 members. But in the metadata it has only two. The third is an independent constant which incidentally typed as the enum (the only constant which is) and is initialized to a value that does not belong to the enum, since it is itself missing from that enum.

Derive from `IDispatch` or `IUnknown` instead of using `InterfaceTypeAttribute`

Can we switch wholesale from InterfaceTypeAttribute to using interface base types? In the process, a COM interface would presumably derive from either IDispatch or IUnknown.

IDispatch would also need to derive from IUnknown.

Include link in readme for public nuget.org feed where metadata is published

ITypeLib.GetTypeComp is missing ComOutPtrAttribute

I believe there may be many more methods that are missing the ComOutPtrAttribute attribute on its parameters.

Release methods need semantic understanding

In order to invoke the release methods properly, we need to understand whether they were successful. But they're all over the map on this. For example:

• bool FindClose returns non-zero (true) on success.
• NTSTATUS LsaDeregisterLogonProcess returns zero (STATUS_SUCCESS) on success.
• DWORD WNetCloseEnum returns zero on success.
• LSTATUS RegCloseKey returns zero on success.
• byte ClosePrivateNamespace returns non-zero on success.

These is just a sampling. For each method, we need to know what constitutes success.

IUnknown has no methods (but IDispatch does)

IUnknown has no methods defined, but IDispatch does have methods defined. Why the disparity?

In particular, now that methods are not defined at every interface level, it's important to define the methods at the derivation level that they are defined at. In this case, IUnknown really needs its methods.

Include lib file for published APIs to allow linking without SDK

Include most popular 2D rendering APIs

Great to see D3D beginning to surface. Let's include the most popular 2D rendering APIs as they tend to be even more popular (for their relative ease of use):

#include <d2d1_3.h>
#include <d3d11_4.h> // required for D2D
#include <dwrite_3.h>
#include <UIAnimation.h>
#include <wincodec.h>

Struct fields named event are named @event in the metadata

In the latest version of the metadata, I'm having errors because BANNER_NOTIFICATION has a field named @event.

Remove "tags" from struct names

The metadata includes the C-style tag names rather than the official struct names in some cases. For example, instead of TVITEMW the struct is named tagTVITEMW. This is a relic of C-style struct definitions but we should avoid this and simply use the official name in metadata if possible. Similar for WBEMSTATUS which shows up as tag_WBEMSTATUS (although that's an enum).

Ideally, the metadata can simply include the correct name and avoid having every language having to strip this out.

Formally, when parsing something like this:

typedef struct tagNAME {
.
.
.
} NAME;

You should pick NAME rather than tagNAME.

ARM64EC_NT_CONTEXT contains structs with the same name as those they nest

The ARM64EC_NT_CONTEXT struct contains an _Anonymous_e__Struct struct which itself contains an _Anonymous_e__Struct (same name).
This causes problems for C#, at least. I strongly suspect it will cause issues in other languages as well (whether compiler error, malfunction or user confusion).

Can we ensure that each struct is given a unique name at least within a nested family of structs?

Many delegates defined twice

Many delegates are not unique in the metadata dll in version 10.0.21269.1001

3>D:\git\pinvoke\bin\Debug\netcoreapp3.1\output\NativeMethods.cs(259136,50,259136,67): error CS0101: The namespace 'Microsoft.Windows.Sdk' already contains a definition for 'EXCEPTION_ROUTINE'
3>D:\git\pinvoke\bin\Debug\netcoreapp3.1\output\NativeMethods.cs(259138,50,259138,68): error CS0101: The namespace 'Microsoft.Windows.Sdk' already contains a definition for 'PEXCEPTION_ROUTINE'
3>D:\git\pinvoke\bin\Debug\netcoreapp3.1\output\NativeMethods.cs(259140,34,259140,57): error CS0101: The namespace 'Microsoft.Windows.Sdk' already contains a definition for 'ENCLAVE_TARGET_FUNCTION'
3>D:\git\pinvoke\bin\Debug\netcoreapp3.1\output\NativeMethods.cs(259142,34,259142,58): error CS0101: The namespace 'Microsoft.Windows.Sdk' already contains a definition for 'PENCLAVE_TARGET_FUNCTION'
3>D:\git\pinvoke\bin\Debug\netcoreapp3.1\output\NativeMethods.cs(259144,34,259144,59): error CS0101: The namespace 'Microsoft.Windows.Sdk' already contains a definition for 'LPENCLAVE_TARGET_FUNCTION'
3>D:\git\pinvoke\bin\Debug\netcoreapp3.1\output\NativeMethods.cs(259146,33,259146,52): error CS0101: The namespace 'Microsoft.Windows.Sdk' already contains a definition for 'PIMAGE_TLS_CALLBACK'
3>D:\git\pinvoke\bin\Debug\netcoreapp3.1\output\NativeMethods.cs(259148,33,259148,62): error CS0101: The namespace 'Microsoft.Windows.Sdk' already contains a definition for 'RTL_UMS_SCHEDULER_ENTRY_POINT'
3>D:\git\pinvoke\bin\Debug\netcoreapp3.1\output\NativeMethods.cs(259150,33,259150,63): error CS0101: The namespace 'Microsoft.Windows.Sdk' already contains a definition for 'PRTL_UMS_SCHEDULER_ENTRY_POINT'
3>D:\git\pinvoke\bin\Debug\netcoreapp3.1\output\NativeMethods.cs(259152,33,259152,41): error CS0101: The namespace 'Microsoft.Windows.Sdk' already contains a definition for 'PAPCFUNC'
3>D:\git\pinvoke\bin\Debug\netcoreapp3.1\output\NativeMethods.cs(259154,32,259154,59): error CS0101: The namespace 'Microsoft.Windows.Sdk' already contains a definition for 'PVECTORED_EXCEPTION_HANDLER'
3>D:\git\pinvoke\bin\Debug\netcoreapp3.1\output\NativeMethods.cs(259156,33,259156,56): error CS0101: The namespace 'Microsoft.Windows.Sdk' already contains a definition for 'WAITORTIMERCALLBACKFUNC'
3>D:\git\pinvoke\bin\Debug\netcoreapp3.1\output\NativeMethods.cs(259158,33,259158,51): error CS0101: The namespace 'Microsoft.Windows.Sdk' already contains a definition for 'WORKERCALLBACKFUNC'
3>D:\git\pinvoke\bin\Debug\netcoreapp3.1\output\NativeMethods.cs(259160,33,259160,54): error CS0101: The namespace 'Microsoft.Windows.Sdk' already contains a definition for 'APC_CALLBACK_FUNCTION'
3>D:\git\pinvoke\bin\Debug\netcoreapp3.1\output\NativeMethods.cs(259162,33,259162,52): error CS0101: The namespace 'Microsoft.Windows.Sdk' already contains a definition for 'WAITORTIMERCALLBACK'
3>D:\git\pinvoke\bin\Debug\netcoreapp3.1\output\NativeMethods.cs(259164,33,259164,55): error CS0101: The namespace 'Microsoft.Windows.Sdk' already contains a definition for 'PFLS_CALLBACK_FUNCTION'
3>D:\git\pinvoke\bin\Debug\netcoreapp3.1\output\NativeMethods.cs(259166,33,259166,62): error CS0101: The namespace 'Microsoft.Windows.Sdk' already contains a definition for 'PSECURE_MEMORY_CACHE_CALLBACK'
3>D:\git\pinvoke\bin\Debug\netcoreapp3.1\output\NativeMethods.cs(259258,33,259258,52): error CS0101: The namespace 'Microsoft.Windows.Sdk' already contains a definition for 'PTP_SIMPLE_CALLBACK'
3>D:\git\pinvoke\bin\Debug\netcoreapp3.1\output\NativeMethods.cs(259260,33,259260,66): error CS0101: The namespace 'Microsoft.Windows.Sdk' already contains a definition for 'PTP_CLEANUP_GROUP_CANCEL_CALLBACK'
3>D:\git\pinvoke\bin\Debug\netcoreapp3.1\output\NativeMethods.cs(259262,33,259262,50): error CS0101: The namespace 'Microsoft.Windows.Sdk' already contains a definition for 'PTP_WORK_CALLBACK'
3>D:\git\pinvoke\bin\Debug\netcoreapp3.1\output\NativeMethods.cs(259264,33,259264,51): error CS0101: The namespace 'Microsoft.Windows.Sdk' already contains a definition for 'PTP_TIMER_CALLBACK'
3>D:\git\pinvoke\bin\Debug\netcoreapp3.1\output\NativeMethods.cs(259266,33,259266,50): error CS0101: The namespace 'Microsoft.Windows.Sdk' already contains a definition for 'PTP_WAIT_CALLBACK'

Windows.Win32

As discussed on Teams, let's use Windows.Win32 as the namespace for Win32 metadata as this is more natural and consistent with existing Windows metadata.

Rename RIAAFreeAttribute to RAIIFreeAttribute

I assume this attribute refers to the Resource Acquisition Is Initialization idiom, not the Recording Industry Association of America. 😉

OSVERSIONINFOW.szCSDVersion fixed buffer lacks metadata indicating wide character type

The projection for the OSVERSIONINFOW struct produces an inline array of ushort instead of char because no metadata exists to hint that the content is actually UTF-16 characters.

Can such metadata be added?