Yes, ultimately setupapi would import cfgmgr32, but right now it's the other way around. However, cfgmgr32 already has some of its specific functions implemented (which aren't exported from setupapi) over the higher level setupapi functions and there's a dependency circle that's more easily broken by sharing the sources. For instance `CM_Get_Device_Interface_Property` is a lower level function, that only exists in cfgmgr32, and which needs the underlying registry access helpers to be implemented. It cannot even use `CM_Open_Device_Interface_Key` because that one opens `<iface>\\Device Parameters` while `CM_Get_Device_Interface_Property` needs to access `<iface>\\Properties` and other sibling keys. Some other like the `DevObject` API will also need to be re-implemented using the CM functions, which might be possible, but it's actually better and more efficient to using the internal helpers for them too. The one thing that will need to be properly handled without sharing sources is the `CM_Get_Device_ID` API, which is stateful, and that can implemented in setupapi only (cfgmgr32 forwarding calls to it), then moved at once later. I also didn't and still don't understand why it was such a big deal with source sharing when it actually allows use the same helpers in both modules, and avoids having to move code at all. Moving functions from one module to another can be done entirely through the spec file entry mapping: stateless functions can safely be exported from both modules at any time, and cfgmgr32 can import stateful functions from setupapi until we move them all at once by swapping the spec forwards around. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10078#note_129596