WinSDK: extract several submodules

[egorzhdan]

Currently WinSDK.WinSock2 includes several headers which aren't specific to sockets, for example, windef.h which includes typedefs for DWORD, HKEY, etc.

This PR extracts some of these headers into separate WinSDK submodules, making it cleaner and easier to navigate.
It also reduces the size of the generated Swift interface for WinSDK.WinSock2 which used to exceed 2.7 MB.

[egorzhdan]

@swift-ci please smoke test

[compnerd]

@egorzhdan this is an excellent idea, especially if we can get it to work. I had accidentally done some of this with the latest rebramch, and it seems that we have a bunch of module fixes that enable a better set of submodules.

Im not particularly keen on referring to the shared headers. I would rather keep the references to just the um directory. The other thing is that I think that we should draw boundaries as per the MSDN module grouping.

The IMM and WinNLS modules look great to tease apart, would you mind separating that into a separate PR that we merge right away?

BTW, I'll try to see if I have a change still laying around - I had split WinSock into WS and WS2.

The CommDlg - should that be a separate module or should it be part of commctrl?

[egorzhdan]

Im not particularly keen on referring to the shared headers. I would rather keep the references to just the um directory

Okay. Do the shared headers belong in some separate module, other than WinSDK?

The other thing is that I think that we should draw boundaries as per the MSDN module grouping.

Hmm, agreed, I'll make the changes here.

The IMM and WinNLS modules look great to tease apart, would you mind separating that into a separate PR that we merge right away?

Sure, I'll send a new PR with these modules only. BTW, they are grouped together under Internationalization in MSDN, so I'll probably merge them.

The CommDlg - should that be a separate module or should it be part of commctrl?

The MSDN lists them in separate sections (Windows Controls for CommCtrl and Dialog Boxes for CommDlg) so I've made them separate as well, but I think it might be nicer to have them both as submodules of something like WinSDK.Controls, @compnerd what do you think?

[compnerd]

Im not particularly keen on referring to the shared headers. I would rather keep the references to just the um directory

Okay. Do the shared headers belong in some separate module, other than WinSDK?

They are shared, I don't think that we want more modulemaps. We should let them be owned by some um module as a result of inclusion.

The other thing is that I think that we should draw boundaries as per the MSDN module grouping.

Hmm, agreed, I'll make the changes here.

The IMM and WinNLS modules look great to tease apart, would you mind separating that into a separate PR that we merge right away?

Sure, I'll send a new PR with these modules only. BTW, they are grouped together under Internationalization in MSDN, so I'll probably merge them.

The CommDlg - should that be a separate module or should it be part of commctrl?

The MSDN lists them in separate sections (Windows Controls for CommCtrl and Dialog Boxes for CommDlg) so I've made them separate as well, but I think it might be nicer to have them both as submodules of something like WinSDK.Controls, @compnerd what do you think?

Either is fine by me. It seems Microsoft splits rheum, under a UI module, which corresponds with your idea of a larger module. But, that seems good to get merged.

[egorzhdan]

Leaving shared headers as is might be problematic: for example, shared/cderr.h is only included by um/Windows.h, which is gigantic and includes loosely related stuff. I think it would be nice to avoid having a giant Windows module, but at the same time include cderr.h in the SDK somehow. The only way that I could see is to create a submodule with a path to cderr.h.

[compnerd]

Yeah, I think that there will need to be one gigantic module that has basically windows.h, but whatever we can shear off into modules, we should (especially at the library boundaries) as per MSDN.

[compnerd]

Hmm, really? Winver was converted into the winapi contract? Cool.

I think that we should find a better name than misc, since it really is the core of the WinSDK. Can we put windows.h without a sub module into winsdk?

[egorzhdan]

I think windows.h will contain just several orphaned headers once all the meaningful modules are extracted. I'll extract a few more of them.
BTW, if windows.h is in the top-level module, would it limit the ability to provide overlays (like CW_USEDEFAULT, but declared in the top-level module instead of some submodule) since there would be two declarations with the same name in the same module?

[compnerd]

I think that we should extract the meaningful modules no matter what we end up with. There is no reason to have a single module that contains everything. This should both help IDE integration in the future and should improve the usability of the modules. So I think that the work that you are doing here is valuable.

As to Windows.h being left with just orphan headers - that actually sounds like a pretty good state to be in.

I don't think that it should prevent the SDK overlay from providing the declarations since it overlays the module. But we should test that to verify.

[compnerd]

@egorzhdan would you mind putting up a PR for the version API contract part of the change? I think that we should get that merged as well.

[egorzhdan]

Okay, extracted in #34085

[shahmishal]

Please update the base branch to main by Oct 5th otherwise the pull request will be closed automatically.

• How to change the base branch: (Link)
• More detail about the branch update: (Link)

[egorzhdan]

I've tried moving Windows.h to the top level, but that fails to compile:

<module-includes>:2:10: note: in file included from <module-includes>:2:
#include "WinSock2.h"
         ^
C:\Program Files (x86)\Windows Kits\10\/Include/10.0.18362.0/um/WinSock2.h:116:10: note: in file included from C:\Program Files (x86)\Windows Kits\10\/Include/10.0.18362.0/um/WinSock2.h:116:
#include <ws2def.h>
         ^
C:\Program Files (x86)\Windows Kits\10\/Include/10.0.18362.0/shared\ws2def.h:238:16: error: redefinition of 'sockaddr'
typedef struct sockaddr {
               ^
C:\Program Files (x86)\Windows Kits\10\/Include/10.0.18362.0/um\winsock.h:482:8: note: previous definition is here
struct sockaddr {
       ^
<module-includes>:2:10: note: in file included from <module-includes>:2:
#include "WinSock2.h"
         ^
C:\Program Files (x86)\Windows Kits\10\/Include/10.0.18362.0/um/WinSock2.h:116:10: note: in file included from C:\Program Files (x86)\Windows Kits\10\/Include/10.0.18362.0/um/WinSock2.h:116:
#include <ws2def.h>
         ^
C:\Program Files (x86)\Windows Kits\10\/Include/10.0.18362.0/shared\ws2def.h:247:3: error: typedef redefinition with different types ('struct (anonymous struct at C:\Program Files (x86)\Windows Kits\10\/Include/10.0.18362.0/shared\ws2def.h:238:16)' vs 'struct sockaddr')
} SOCKADDR, *PSOCKADDR, FAR *LPSOCKADDR;
  ^
C:\Program Files (x86)\Windows Kits\10\/Include/10.0.18362.0/um\winsock.h:1005:25: note: previous definition is here
typedef struct sockaddr SOCKADDR;
                        ^

I guess, submodules are not allowed to depend on top level modules?

[compnerd]

I think that the WinNT module, though not great, might be okay, but the Misc module is not really correct.

[compnerd]

This really is incorrect. Windows.h is an umbrella header, not a miscellaneous module.

[egorzhdan]

Uh, I don't think it's possible to make it an umbrella header without changes to SourceKit or Clang, so I'll just drop this commit.

[compnerd]

@swift-ci please test