#256 mpg123 1.25.7 doesn't work on WinXP

[MuldeR]

Hello.

I noticed that mpg123 v1.25.7 doesn't work on Windows XP, verified on two machines. Apparently mpg123 imports a function _time32 from MSVCRT, which onvisouly is not avaialble in the Windows XP version of MSVCRT.DLL. For comparision, mpg123 v1.24.0 was still working fine on Windows XP. It was importing time rather than _time32, which I think is why.

Please see attached Dependency Walker for details! (new version on the right side)

Is there any way to compile latest mpg123 so that it will work on Windows XP? And yeah, I'm well aware that Windows XP is hopelessly outdated. But some of my usesrs insist on XP... sigh

Thanks and best regards,
MuldeR

[MuldeR]

Small update:

As it turns out, the only place in mpg123 where the time() function is actually called is in "playlist.c", where the random number generator is seeded. If I replace this time() call with an explicit _time64() call in the code, then I will get a binary that imports _time64 rather than _time32 from MSVCRT.DLL. And, indeed, _time64 does exist in the Windows XP version of MSVCRT.DLL.

Still I have no idea how a call to time() in the code can result in _time32 being imported. If we look at the "time.h" include file, we will see that time() is defined as a wrapper function around either _time32() or _time64(). And the latter is the default! The _time32() function would only be used if the macro _USE_32BIT_TIME_T was defined. But it isn't defined. I checked that.

So, yeah, replacing time() with _time64() in the code appears to be the solution for now...

[Jonathan Yong]

Can you try recompiling with -D__MINGW_USE_VC2005_COMPAT=1

The macro is defined in _mingw.h, this change affects ABI.

[MuldeR]

Thanks! I see the location in _mingw.h now:

#if defined (_WIN32) && !defined (_WIN64) && !defined (__MINGW_USE_VC2005_COMPAT)
#ifndef _USE_32BIT_TIME_T
#define _USE_32BIT_TIME_T
#endif
#endif

That surely explains why we get 32-Bit version of time(), even though _USE_32BIT_TIME_T was never defined in application code. But it makes absoloutely no sense to me! According to MSDN, time() is an alias for time64(), and time_t is an alias for time64_t – unless we explicitely define _USE_32BIT_TIME_T in application code before including <time.h>. Mabye this was different in very old MSVC versions. But then their #if statement is wrong! Should be the other way around, i.e. #if defined(__MINGW_USE_VC2005_COMPAT), not #if !defined(...).

Furthermore, it makes no sense either that the 32-Bit version of time() links against symbol _time32, which is not available in MSVCRT.DLL in older Windows versions. The symbol time, which is the very same function, has been available in MSVCRT.DLL since the beginning, and still is available in Windows 10. Ther's no advantage in using_time32, it's just more incompatible...

[MuldeR]

Indeed, and as expected, I can confirm that adding -D__MINGW_USE_VC2005_COMPAT=1 to my CFLAGS will cause mpg123 to link against _time64 rather than _time32.

Still doesn't make any sense, as the expected (correct) behavior of "VC2005 COMPAT" would be the exact oppsosite: Use 32-Bit time_t by default (like VC2005 and earlier did) instead of 64-Bit time_t (like VC2008 and later does). The real problem, though, is that linking against _time32 does not make any sense whatsoever, since we can just use time and thus avoid breaking Windoes XP.

[Jonathan Yong]

As the macro name implies, behavior changed in MSVC2005.

Take the discussion to the mingw-w64 mailing list.

[MuldeR]

Yeah, I think starting with MSVC2008 they made time() and time_t aliases for _time64() and time64_t, respectively – unless _USE_32BIT_TIME_T is defined before including <time.h>.

Before, e.g. MSVC2005, or when _USE_32BIT_TIME_T is defined, time() would just call a function of exactly that name and return a 32-Bit value. Accordingly, time_t used to be a 32-Bit type.

Consequently, if __MINGW_USE_VC2005_COMPAT is supposed to restore MSVC2005 compatibility, then _USE_32BIT_TIME_T shall be defined if and only if __MINGW_USE_VC2005_COMPAT has been defined – not when __MINGW_USE_VC2005_COMPAT has not been defined.

[Thomas Orgis]

Can we close this? Can we help it?

[MuldeR]

Hello,

I think on the Windows/MINGW platform, the define __MINGW_USE_VC2005_COMPAT should be added to the CFLAGS automatically by mpg123 Makefile, so that (by default) we get a binary that can work on Windows XP. The current default is to create a binary that does not work on Windows XP.

[Thomas Orgis]

Windows XP is further troubled now, with the dynamic module loading. It's simply an untested and rather unsupported platform now. You are still able to get a working build on it, but you have to tweak the toolchain and have to disable modules. And there's always old mpg123 for the old system.