Binary compiled by ICL 2021 doesn't work on XP

[LoRd_MuldeR]

I'm trying to compile MediaInfo with the latest "2021" version of the Intel C++ compiler. For whatever reason, the Intel C++ compiler now seems to be called "oneAPI DPC++ Compiler" and all traces of the normal Intel C++ compiler have vanished from their web-site. But that's not the problem. Except for that fact that the "/Qax" option has disappeared - which was the outstanding feature of Intel C++ compiler - it seems to work as usual

However, I noticed that the binary created by ICL 2021 doesn't work on Windows XP:

(works fine on my Windows 10 though)



The binary was compiled with VS2017, the "v141_xp" Toolset and the /MT option, so should be compatible with Windows XP.

Also, the binary was linked fully static. It think it definitely is not a missing dependency issue:

(If it was a missing DLL or a missing entry point problem,then Windows also would give a different error message, I think)





The NT header of the binary created by ICL 2021 looks as expected to me.

Operating system version and sub-system both are set to "5.1", i.e. Windows XP, which should be fine:



Trying to run the binary in WinDbg gives the following error (Win32 error 14001):



Win32 error 14001 is:

14001 (0x36B1)
The application has failed to start because its side-by-side configuration is incorrect. Please see the application event log or use the command-line sxstrace.exe tool for more detail.

Any ideas what is going on here

[StainlessS]

Maybe not related [no idea what that German stuff says], but you should be made aware of this if you are not already aware,
(see from linked post till end, about 4 posts):- https://forum.doom9.org/showthread.p...48#post1935348

Originally Posted by qyot27

Then Microsoft changed the vcredist silently, because it was the standard 2015-2019 vcredist download link.

Originally Posted by FranceBB

Yep...
I just checked and it seems that VC++ 2019 version 14.28.29213.0 (August 2020) is the last version compatible with Windows XP... C++ Redistributable AIO (XP Compatible)
I've just archived it... For future XP releases, we should always include that one I think.

[LoRd_MuldeR]

Originally Posted by StainlessS

Maybe not related [no idea what that German stuff says], but you should be made aware of this if you are not already aware,
(see from linked post till end, about 4 posts):- https://forum.doom9.org/showthread.p...48#post1935348

The message says:
This application could not be started, because the application configuration is incorrect. In order to solve the problem you should reinstall the application.

Also, since the binary was compiled with the /MT option, it is fully static and it does not have any dependencies on the Visual C++ runtime, as can easily be checked with Dependency Walker (see screenshot above).

[FranceBB]

I don't get it. You used Intel Parallel Studio to compile and the resulting exe is not XP compatible, right?
Then you tried to use the Microsoft Compiler with v141_xp within Intel Parallel Studio and the resulting binary is still not XP compatible?

(if that's not what you've done, then I didn't understand)

[LoRd_MuldeR]

Originally Posted by FranceBB

I don't get it. You used Intel Parallel Studio to compile and the resulting exe is not XP compatible, right?
Then you tried to use the Microsoft Compiler with v141_xp within Intel Parallel Studio and the resulting binary is still not XP compatible?

(if that's not what you've done, then I didn't understand)

Well, I used what is called "oneAPI DPC++ Compiler" now. But yeah, that is what used to be Intel C++ compiler (Intel Parallel Studio). Apparently it is the "2021" incarnation of the Intel C++ compiler.

Intel C++ compiler integrates into Visual Studio. So, I used Visual Studio 2017 to compile MediaInfo, but with the Intel C++ Compiler.

If you select the Intel C++ compiler, you can still select the "Base Platform Toolset" separately. I selected "v141_xp" here, in order to ensure that the resulting binary will be compatible to Windows XP.

(I also tried with a "pure" MSVC binary and that works just fine under Windows XP)



By the way: That is what I have been doing for years to build MediaInfo. Binaries have been working in Windows XP thus far. Something must have changed. But I don't know what exact is different with the binary now

[LoRd_MuldeR]

Meh, I just realized that there is a subtle difference between the Manifest generated by Intel C++ compiler and MSVC:

• https://pastebin.com/FTKMFwhA (Intel)
• https://pastebin.com/J35R8bB6 (MSVC)

So I edited the binary created by the Intel C++ compiler with Resource Hacker and "implanted" the Manifest from the MSVC binary. Surprise, surprise, binary now works in Windows XP

[StainlessS]

Well spotted, glad you got it sorted.

[FranceBB]

Wow, well done! I didn't think about that, but this is gonna be useful to know, thanks!

[jpsdr]

Stupid question i have to ask : When building, you have added the following option :
/Zc:threadSafeInit-
(In C/C++ -> "Command line").

This is necessary to have a Windows XP working build, selecting the toolset is not enough.

[LoRd_MuldeR]

Originally Posted by jpsdr

Stupid question i have to ask : When building, you have added the following option :
/Zc:threadSafeInit-
(In C/C++ -> "Command line").

This is necessary to have a Windows XP working build, selecting the toolset is not enough.

I did not explicitly add that option. Nonetheless, in my test, the resulting binaries do work on my Windows XP VM now.

Problem was definitely caused by the Manifest, but I still have no idea what exactly in the Manifest generated by the Intel C++ compiler caused Windows XP to reject the binary.

[EDIT]

Thread-safe static local variables use thread-local storage (TLS) internally to provide efficient execution when the static has already been initialized. The implementation of this feature relies on Windows operating system support functions in Windows Vista and later operating systems. Windows XP, Windows Server 2003, and older operating systems do not have this support, so they do not get the efficiency advantage. These operating systems also have a lower limit on the number of TLS sections that can be loaded. Exceeding the TLS section limit can cause a crash. If this is a problem in your code, especially in code that must run on older operating systems, use /Zc:threadSafeInit- to disable the thread-safe initialization code. – https://docs.microsoft.com/de-de/cpp...?view=msvc-160

If I understand this correctly, then "Thread-safe Local Static Initialization" is less efficient on Windows versions prior to Vista (i.e. Windows XP), but still supported.

Also, Windows XP apparently has a lower limit on the number of TLS sections. And, because "Thread-safe Local Static Initialization" makes uses of TLS internally (i.e. it draws from the TLS sections limit), there is a higher risk of exceeding the TLS section limit on Windows XP - when "Thread-safe Local Static Initialization" is enabled. That is why "/Zc:threadSafeInit-" may be needed for some applications to avoid that problem on Windows XP.

But is it always good to disable "Thread-safe Local Static Initialization"? It may break applications that expect correct C++11 behavior, I think

[FranceBB]

Originally Posted by LoRd_MuldeR

But is it always good to disable "Thread-safe Local Static Initialization"? It may break applications that expect correct C++11 behavior, I think

Over here I've always seen it within binaries compiled for XP for plugins and other things and even Avisynth itself, so I think it's pretty safe. Technically you could release two versions, like most people over here are doing: a legacy XP one with thread safe and another without targeting newer OS. Still, in your very case it was the manifest so it might not be related.