Hi,
On 2023-10-11 13:35, Martin Storsjö wrote:
Hi,
Explicitly pulling in Steve Lhomme to disuss this matter:
On Tue, 3 Oct 2023, Mark Harmstone wrote:
diff --git a/mingw-w64-crt/lib-common/api-ms-win-core-io-l1-1-1.def
b/mingw-w64-crt/lib-common/api-ms-win-core-io-l1-1-1.def
index 9401e3d53..c13c4928b 100644
--- a/mingw-w64-crt/lib-common/api-ms-win-core-io-l1-1-1.def
+++ b/mingw-w64-crt/lib-common/api-ms-win-core-io-l1-1-1.def
@@ -4,6 +4,7 @@ EXPORTS
CancelIo
CancelIoEx
+CancelSynchronousIo
CreateIoCompletionPort
DeviceIoControl
GetOverlappedResult
So, the main issue is that both the mincore and windowsapp umbrella
libraries link against api-ms-win-core-io-l1-1-1.dll. When linking with
windowsapp, there's no CancelSynchronousIo symbol anywhere to link
against, but when linking against mincore, this symbol does exist and is
provided in that DLL.
This means that if we apply this patch, our windowsapp import library
also will expose CancelSynchronousIo even if the MS version doesn't.
Steve, do you feel that this is ok? Or should we separate all the
api-ms-win-* import libraries, into one version for mincore and one for
windowsapp, to keep things strict and correct?
I guess there's a potential risk, if there's e.g. a configure script,
that tests whether the symbol can be linked, and uses it if available -
such cases are broken if our umbrella import libraries export too many
symbols.
I guess there's also a risk, if e.g. windowsapp would be providing this
symbol in another DLL; then our umbrella library would expose it in two
forwarder DLLs, and it'd be up to the linker which one it ends up picking.
What do you say Mark and Steve, is this ok with both of you? If it is,
most of the rest of this patchset should be fine as well. If not, we'll
need to spend a lot more effort on this...
CancelSynchronousIo was exposed in windowsapp in the Windows 8 SDK. But
it hasn't been since then and is not allowed by the Windows App
Certification Kit (WACK) either.
If mincore and windowsapp linked DLL references keep being shared,
windowsapp should have prevalence because it's still more or less valid,
while mincore is dead.
So in this case I think CancelSynchronousIo should not be added to
api-ms-win-core-io-l1-1-1. If someone really needs to link with that
function, the documentation [1] says it's only available on desktop and
should be linked through kernel32.lib.
[1]
https://learn.microsoft.com/en-us/windows/win32/fileio/cancelsynchronousio-func
_______________________________________________
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
