I thought there were more cases of DLLs getting marked as prefer-native because of applications shipping hooks or unrelated homonyms, but these are the only two I can find. The vast majority seem to simply be DLLs marked as prefer-native due to being stubs, at least when they were introduced. Some of these are no longer particularly stubby (e.g. hid, mf, localspl, taskschd, d3dx). Some of these are relatively useful since the DLL is often bundled (or a redistributable installer is), e.g. d3dx*, quartz, vulkan-1. In other cases it seems quite unlikely that the DLL was ever redistributable (e.g. aclui, joy.cpl). In some cases, even if the DLL was redistributable, it surely could never have worked (e.g. dxva2, dcomp, ksuser, bluetoothapis, fltlib). In two cases I think the "Known DLLs" mechanism prevents application-provided DLLs from being used even on Windows (msctf, shcore). Should we consider getting rid of prefer-native from more DLLs, stubbiness notwithstanding? Should we restrict it to some of the above cases? Is it a matter of "welcome, but whoever does it has to promise to deal with the regressions"? How stubby is stubby? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10955#note_140731