On Friday 16 January 2026 11:53:26 Martin Storsjö wrote: > On Mon, 29 Dec 2025, Pali Rohár wrote: > > > The problem is that symbol cannot be in two of those def files as both > > def files are "merged" into one import library. > > Well it's not really that they _cannot_ be in both of them; it can just fine > be in both. But then it's not clear which one is chosen. > > > And then linker randomly chose one. > > Saying that it is random sounds a bit surprising - it's probably > deterministic (possibly the one added first or the one added last), but the > exact rule for which one is chosen might not be obvious.
Yes, that is truth. The better wording would be that it is unspecified which symbol will be used and for linking application it can be unexpected to which library the application would be linked. > > Anyway, for this matter - I would vote -1 for this patch: > > While it's nice to be able to target XP, I don't see the reason for why > anybody would be linking against api-ms-win-core-*.dll while targeting XP. > You usually don't link directly against them with -lapi-ms-win-..., but you > link against it when linking against an umbrella library like > libwindowsapp.a, libmincore.a, libonecore.a etc. And I don't think anybody > expects to link against e.g. libonecore.a and still execute on XP. > > We did spend some effort to sync our imports between the api-ms-win-* import > libraries and the WinSDK versions of the umbrella libraries (onecore, > windowsapp etc) - and if we change this, we increase the discrepancy instead > of decrease it. > > For some specific cases where we really want to have different sets of > imports from one API set library between different umbrella libraries, then > we need to split the .def file into separate copies for each umbrella lib; > we have that for a number of libraries with a "_windowsapp.def" suffix. > > Although: In most cases, as far as I know, it's fine to import symbols from > an older version of the API set, even though the WinSDK import libraries > import it from a newer one. So if we would have applied this patch, it would > most probably be fine in all practical cases. But it would increase the > discrepancy against the WinSDK import libraries, which would be annoying for > no real gain. > > // Martin Ok, that is a fair point. Just for completeness, I tried to investigate the origin of the source that PeekConsoleInputA is in l1-1-0 version, and here is what I found: I found that Windows 7 has also PeekConsoleInputA in l1-1-0 version and does not provide the api-ms-win-core-console-l2-1-0.dll at all. Some sources for Windows 7: https://www.geoffchappell.com/studies/windows/win32/apisetschema/history/sets61.htm https://www.geoffchappell.com/studies/windows/win32/apisetschema/api/ms/win/core/console/l1-1-0.htm https://apisets.info/apisetschemas/06.1.7601.23455-amd64/ In Windows 8 the MS documentation said that PeekConsoleInputA is also in the l1-1-0 version, even the fact that Windows 8 provides also l2-1-0: https://web.archive.org/web/20120923000722/http://msdn.microsoft.com/en-us/library/windows/desktop/hh802935(v=vs.85).aspx So linking the PeekConsoleInputA against api-ms-win-core-console-l1-1-0.dll is not only for Windows XP compatibility, but also for Windows Vista and Windows 7 compatibility. My guess is that after MS dropped support for XP/Vista/7 it changed documentation that PeekConsoleInputA would be in l2-1-0, instead of original l1-1-0. Maybe checking some older Windows 8 or 8.1 SDK could confirm if also SDK used PeekConsoleInputA from l1-1-0 as was written documentation. Anyway, in any case if there is some deviation in import symbols and libraries from WinSDK, I would suggest to add comments into def files (or to other visible place) to document such thing and reason for it. Because any future synchronization of WinSDK symbols to mingw-w64 def files would cause issues and lot of manual work, like I did when I was cleaning up msvcr* def files. _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
