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`
`WinSDK.core.console` only specified `consoleapi.h` header, while `consoleapi2.h` & `consoleapi3.h` were included in the WinSock2 submodule since these headers are included by `windows.h`
When linking on a case sensitive file system, the import library must be
named with the matching case. The import library is named
`ComDlg32.Lib` in the SDK, adjust the case.
The WinSDK module failed to expose WinBase properly for reuse, which the
newer clang seems to object to (via an assertion). Add a separate
module for WinBase which allows reuse of the definitions without causing
conflicts. This caused some additional fallout requiring the creation
of the WinSVC submodule (service handling, part of security and
identity) and splitting up the legacy WinSock header from the WinSock2
module. This allows building Foundation again on Windows.
