This adds the memoryapi submodule to WinSDK which isolates the memoryapi
contract. This enables additional functions such as
`QueryVirtualMemoryRegion` to now be available.
This adds a missing link directive to the ComCtl32 module. This allows
use of the module without requiring the user to explicitly add the
linked library to the target when building code against this module.
The debug header is used for enumeration of certain DXGI interfaces
related to debugging of the pipeline. Add this to gain access to the
interfaces and some of the global GUIDs associated with it.
The DirectX subsystem may require access to the HLSL compiler for
building the shaders before uploading to the GPU. This is adds to the
modulemap the D3DCompiler module to get access to the compiler.
There is no usermode header which has the DXGI1.6 interfaces included
unfortunately. This adds the interfaces to the module which is required
for IDXGIAdapter4 interface.
Add the extensions for the Direct3D v10 API to enable access to the
newer DXGISwapChain interfaces. Additionally, correct the linking to
ensure that we pick up the v10 version of the import library.
In some cases when building the `XAudio` module, we would end up going
down C++ paths:
```
C:\Program Files (x86)\Windows Kits\10\/Include/10.0.17763.0/um/xaudio2.h:61:26: error: 'uuid' attribute is not supported in C
interface __declspec(uuid("2B02E3CF-2E0B-4ec3-BE45-1B2A3FE7210D")) IXAudio2;
^
<module-includes>:29:10: note: in file included from <module-includes>:29:
^
```
Although this works with newer SDKs, it does not work with older SDKs.
Filter out the module for the time being with a requirement on `C++`.
This should be possible to use with `-enable-cxx-interop`.
Add the module definitions for:
- Direct3D v12
- XAudio 2.9
- XInput 1.4
Additionally, add the following, unusable modules:
- DXCore
DXCore requires C++ Support (C++11 or newer to be precise) and is not
yet available until C++ interop can be made to work fully.
The SensorsAPI headers are not part of the Windows umbrella header and
do not get pulled into the module through some transitive set.
Explicitly list the SensorsAPIs contract into the WinSDK modulemap to
allow use of the api contract from Swift.
Both `immdev.h` & `windows.h` include `imm.h`, and sometimes this header gets assigned to the module containing `windows.h` (currently `WinSDK.WinSock2`) instead of the Internationalization submodule
The MSDN documentation indicates that you should link against the
`Pathcch.lib` import library when using functions from `pathcch.h` which
can also be verified by use functions failing to link due to unresolved
symbols. Add the missing linking to enable autolinking for `WinSDK`.
Currently winver.h gets included into `WinSDK.WinSock2`, however its usages might not be related to sockets, and it requires linking against `Version.Lib`