On 26/05/2021 20:18, Corinna Vinschen wrote:
On May 26 13:04, Yaakov Selkowitz wrote:
On Wed, 2021-05-26 at 17:51 +0100, Jon Turney wrote:
On 26/05/2021 10:04, Corinna Vinschen wrote:
On May 25 22:37, Jon Turney wrote:
On 22/05/2021 16:08, Jon Turney wrote:
On 20/05/2021 19:05, Corinna Vinschen wrote:
Hi Jon,
On May 20 18:46, Jon Turney wrote:
The default PSAPI_VERSION is controlled by WIN32_WINNT, which we
set to
0x0a00 when building ldd, which gets PSAPI_VERSION=2.
In the just released w32api 9.0.0, _WIN32_WINNT is now set to 0xa00 by
default, so this issue is probably going to surface in a few other
places as
well.
I added _WIN32_WINNT and NTDDI_VERSION settings to make sure we notice
any problems right away.
I'm not sure what the mechanism by which we're going to notice is?
Build problems?
:confused:
This is a run time problem, not a build time problem.
#define WIN32_WINNT=0x0a00 ->
#define PSAPI_VERSION 2 ->
#define GetModuleFileNameExA K32GetModuleFileNameExA ->
The procedure entry point K32GetModuleFilenameExA could not be located
in the dynamic link library kernel32.dll
Adding WIN32_WINNT=0x0a00 everywhere changes the meaning of '#include
<psapi.h>' in a way that is incompatible with Vista.
Isn't that easily fixed by adding PSAPI_VERSION=1 prior to including
psapi.h? We can add that to the Makefile as well...
So this has broken dumper, and possibly other utils, on Vista.
I don't know if there are any other imports in other header which also
have this annoying behaviour...
I think the psapi stuff is the only one changing their imports.
Does Vista REALLY still need to be supported at this point?
It's probably not much of a problem but per the latest statistics
we still have... uhm... about 4 Vista users...
'4 users running setup per week' != '4 users'
but yes, it's not very many.
