On Mon, 30 Oct 2023, LIU Hao wrote:
在 2023-10-30 18:54, Martin Storsjö 写道:
FWIW, this is what we already had before
cb7f42e05b94cbb1d94edcebdbfb47b652a45484; we used GetTickCount64
unconditionally if _WIN32_WINNT was set to target vista or above.
Since f3c53a51df5c08f181e13a39b1cd6fd1d41edb96, our default _WIN32_WINNT is
set to target Win10, so a default-built toolchain will have a winpthread
that doesn't run on versions below Vista - one of the intents in
cb7f42e05b94cbb1d94edcebdbfb47b652a45484 was to make it so that one doesn't
need to use a special built toolchain in order to run things on older
versions of Windows.
There was a reply from Christian Franke which mentioned support for XP, which
still requires `GetModuleHandle()` or `LoadLibrary()` somehow. We may decide
that Windows 98 is outdated and not primarily (if not completely) supported,
but it does not seem to be the case with Windows XP, does it?
Agreed.
The history of this is that in 52f2ce12c6182bd239e4f1bbffcd420997b64b08,
in 2019, we added conditional use of GetTickCount64 if building with
_WIN32_WINNT >= _WIN32_WINNT_VISTA, but at the time, _WIN32_WINNT
defaulted to XP.
When f3c53a51df5c08f181e13a39b1cd6fd1d41edb96 bumped _WIN32_WINNT to
default to Win10, default builds of winpthreads essentially stopped
working on XP, unless one overrides the default _WIN32_WINNT.
Do Windows store apps link against the static winpthreads or shared one?
maybe it is possible to provide a helper function in winstorecompat which
imports `GetTickCount64()` for example, so the statically linked winpthreads
can make use of this helper function rather than call `GetModuleHandle()`
itself.
I think most store apps would link to static winpthreads; that's necessary
to override what actually gets imported from system DLLs and what gets
redirected to winstorecompat stubs. So it's possible to do such
redirection that would handle these cases as well, but I'm not offhand
sure exactly how to do it; GetProcAddress is used as-is from the system.
Perhaps it's possible to provide a fake PE image in memory, with only
those particular symbols available, return that for
GetModuleHandle("kernel32.dll") and, if the system GetProcHandle() can
load symbols from that? Not very neat/pretty though, perhaps there are
easier ways?
// Martin
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public