`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.
I've verified that all of the header files in this module already
contain their own `extern "C"` blocks that are activated if compiling as
C++.
The additional [extern_c] attribute causes problems for some headers,
like PathCch.h, that define additional overloads of functions when
compiled as C++. The "global" [extern_c] essentially switches off name
mangling with these overloads, which causes them to conflict with the
functions they are overloading.
See here for more context:
https://github.com/apple/swift/pull/30233#issuecomment-601594221
See here for an example of failures caused by the [extern_c]:
https://ci-external.swift.org/job/swift-PR-windows/869/console
(Search for "PathCch.h".)
This extends the WinSDK module definition further to better modularise
the headers. This should improve the header organisation as well as
setup additional autolink rules.
Be more aggressive about using the autolinking functionality of modules
on Windows. This makes it easier to use WinSDK in Swift as the link
dependencies are implicitly taken care of.
Split out the User32 interfaces from the previously owning module
(WinSock2). This improves the debugging experience and more accurately
reflects the module structure but should not impact the ability to build
the swift runtime.
Additional APISets are required to implement the Foundation API surface.
Expand the module to include that. Unfortunately, I have not been able
to get the ImageHelp or the DebugHelp APIs or the RTLSupport APISet
covered under the module. Those are required to get stack captures to
work.
