GetPerformanceInfo() on Win-XP

[Gisle Vanem]

I just built MPIR and speed.exe on my Win-XP SP3 box using
MSVC 2010. Only problem was AFAICS now is with win_timing.c

Somewhere in the Solution or a header (?), _WIN32_WINNT is set to
Win-Vista which defines this function as:

#define GetPerformanceInfo K32GetPerformanceInfo

Thus speed.exe refuses to run since K32GetPerformanceInfo isn't in my
kernel32.dll.

An easy fix for me was this:

@@ -1,5 +1,7 @@
#define WIN32_LEAN_AND_MEAN
+#undef _WIN32_WINNT
+#define _WIN32_WINNT 0x501

#include <windows.h>
#include <time.h>

--gv

[Gisle Vanem]

I just built MPIR and speed.exe on my Win-XP SP3 box using
MSVC 2010. Only problem was AFAICS now is with win_timing.c

(BTW. why are there 3 of the same of this?)

Somewhere in the Solution or a header (?), _WIN32_WINNT is set to
Win-Vista which defines this function as:

#define GetPerformanceInfo K32GetPerformanceInfo

Thus speed.exe refuses to run since K32GetPerformanceInfo isn't in my
kernel32.dll.

An easy fix for me was this:

@@ -1,5 +1,7 @@
#define WIN32_LEAN_AND_MEAN
+#undef _WIN32_WINNT
+#define _WIN32_WINNT 0x501

#include <windows.h>
#include <time.h>

--------------

Or I could have done "-DPSAPI_VERSION=1" as per the comment in MS's
PSapi.h.

--gv

[Brian Gladman]

Thank you for this report.

On Windows versions prior to Windows 7, GetPerformanceInfo is provided
by psapi.dll rather than kernel32.dll so psapi.dll would need to be
added to the link stage of the build on this OS.

I would expect MSVC 2010 on your system to automatically add this DLL to
the link stage of the build but it seems that you may have to do this
manually.

It is, of course, possible that this link failure is the result of an
issue in the MPIR code base but it looks more likely that it is an MSVC
2010 configuration issue.

If you can tarck it down to an MPIR issue, I will happily see if any
changes needed can be incorporated into MPIR.

with my best regards,

Brian

[Gisle Vanem]

"Brian Gladman" <b...@gladman.plus.com> wrote:

> On Windows versions prior to Windows 7, GetPerformanceInfo is provided
> by psapi.dll rather than kernel32.dll so psapi.dll would need to be
> added to the link stage of the build on this OS.

Right. Or better, the function could be loaded dynamically from psapi.dll / kernel32.dll
depending on OS.

> I would expect MSVC 2010 on your system to automatically add this DLL to
> the link stage of the build but it seems that you may have to do this
> manually.

psapi.lib is NOT among the default libs (link pulls in few standard libs
by default, compared to MingW).

> If you can tarck it down to an MPIR issue, I will happily see if any
> changes needed can be incorporated into MPIR.

I'm having a hard time understanding the build-process, so that would
be next to impossible. I have to study the .tlog files from msbuild to
check.

--gv

[Brian Gladman]

On 08/01/2014 11:33, Gisle Vanem wrote:
> "Brian Gladman" <b...@gladman.plus.com> wrote:
>
>> On Windows versions prior to Windows 7, GetPerformanceInfo is provided
>> by psapi.dll rather than kernel32.dll so psapi.dll would need to be
>> added to the link stage of the build on this OS.
>
> Right. Or better, the function could be loaded dynamically from
> psapi.dll / kernel32.dll depending on OS.
>
>> I would expect MSVC 2010 on your system to automatically add this DLL to
>> the link stage of the build but it seems that you may have to do this
>> manually.
>
> psapi.lib is NOT among the default libs (link pulls in few standard libs
> by default, compared to MingW).

Which appears to be an inconsistency in the Microsoft build process
since the build succeeds without having to add this library in later
Windows OS's. I would guess that adding psapi.lib to the build would
solve this since this would hopefully not cause problems on later OS
builds where it is not needed. But I doubt that its worth taking the
risk in order to solve a problem on Windows XP since this is now a
rather old OS.

>> If you can tarck it down to an MPIR issue, I will happily see if any
>> changes needed can be incorporated into MPIR.
>
> I'm having a hard time understanding the build-process, so that would
> be next to impossible. I have to study the .tlog files from msbuild to
> check.

If you have a solution, please don't feel the need to do this as it is
very unlikely that the MPIR build files for MSVC 2010 will be updated to
accommodate any needed changes as they are no longer being maintained
(and won't be unless someone volunteers to do this).

Brian