Targeting Windows XP in VS2012

[nick6]

Hi,

I've read through the article describing how to support windows xp when compiling in VS2012. Unfortunately some of the fortran DLLs are now trying to link with MSVCR100.dll, which I dont want because all of our C++ DLLS/EXE in the same application are linking against MSVCR110.DLL.

Without applying the fix to the fortran DLLs, the application runs OK. However, I have a fortran executable (that links with the other fortran DLLs also) which STILL produces the 'not a valid win32 application' error, even with the change to library paths.

Is there a new method of supporting Windows XP in fortran now that VS2012 Update 1 has been released which adds the v110_xp platform toolset, which in our case, all of our VC11 DLLs/EXE compile with?

[SergeyKostrov]

>>...I have a fortran executable (that links with the other fortran DLLs also) which STILL produces the 'not a valid win32 application' >>error, even with the change to library paths. This is Not related to paths to these Fortran DLLs. We recently had a very similar discussion on Intel C++ compiler forum and please take a look: Forum Topic: Using toolset Visual Studio 2012 - Windows XP (v110_xp) with Intel Compiler Web-link: http://software.intel.com/en-us/node/365746

[SergeyKostrov]

>>...I have a fortran executable (that links with the other fortran DLLs also) which STILL produces the 'not a valid win32 application' >>error, even with the change to library paths. This is Not related to paths to these Fortran DLLs. We recently had a very similar discussion on Intel C++ compiler forum and please take a look: Forum Topic: Using toolset Visual Studio 2012 - Windows XP (v110_xp) with Intel Compiler Web-link: software.intel.com/en-us/node/365746

[nick6]

Sergey Kostrov wrote:

This is Not related to paths to these Fortran DLLs. We recently had a very similar discussion on Intel C++ compiler forum and please take a look:

Forum Topic: Using toolset Visual Studio 2012 - Windows XP (v110_xp) with Intel Compiler
Web-link: software.intel.com/en-us/node/365746

Thanks for pointing this out. I'm not sure  there is an equivalent of the _WIN32_WINNT define for fortran though?

[SergeyKostrov]

>>...I'm not sure there is an equivalent of the _WIN32_WINNT define for fortran though?.. But some kind targeting should exist for Fortran modules ( EXEs or DLLs ) and it make sense to review Fortran project settings.

[Steven_L_Intel1]

Ignore the part about _WIN32_WINNT - it is not relevant to Fortran. I will study this to see how one does this in Fortran.

[SergeyKostrov]

>>...it is not relevant to Fortran... Of course it is not relevant directly but it is relevant indirectly. It affects what information will be recorded into an Image Header of a Portable Executable ( PE ) file targeted for some Windows OS. >>...But some kind targeting should exist for Fortran modules ( EXEs or DLLs )... It can be controlled for Fortran modules as follows: Fortran Project -> Linker -> General -> Version ( this is a version number of image header ) Also, take a look on MSDN at a linker option /VERSION:major[:minor] and that number in your module(s) should match to a version of your target Windows OS.

[Steven_L_Intel1]

No, the define is not applicable because all it does is change the set of definitions from the various SDK .h files. /VERSION is not at all related to this - all that does is insert a version number that you can later display (or fetch). None of this has any bearing on the problem at hand which is linking against MSVC DLLs that use APIs not present in Windows XP.

http://blogs.msdn.com/b/vcblog/archive/2012/10/08/10357555.aspx is relevant and I will work through this to see what is needed for Fortran, if anything. It looks as if the CRT DLLs were updated in place to support XP SP3, and one just needs to link to the V7.1A SDK and, if building from the command line, set the console subsystem version appropriately.

[nick6]

Thanks once again for your time Steve.

I can also confirm that the /VERSION only injects the 'image version' into the EXE, it does not change the 'operating system version' or the 'subsystem version' values in the header. However, I've changed the Linker:System\SubSystem flag in the project settings to 'Not Set', and then added the linker command line '/SUBSYSTEM:CONSOLE",5.01" and now it DOES work.

So it seems that following the instructions in the article Linking Applications using Visual Studio 2012 to Run on Windows XP caused my DLLs to link against MSVCR100.dll (which I dont need since the DLLs worked fine against MSVCR110.dll anyway), and using the linker command line /SUBSYSTEM has allowed the EXE to run properly on windows XP. Is this maybe a result of the changes made in Update 1 for VS2012?

[SergeyKostrov]

>>... /VERSION is not at all related to this - all that does is insert a version number that you can later display (or fetch)... Steve, Please read and here is a quote from MSDN ( if you don't trust what I say... ): ... The information specified with /VERSION does not affect the version information that appears for an application when you view its properties in Windows Explorer. That version information comes from a resource file that is used to build the application... ... Next, have you ever seen a message Not a valid win32 application when testing or running some application? Here is example: Let's say some application is built for Windows Server 2003 operating system. If you look at an Image Header of the executable a code 5.2 will be there. Now, if you try to execute that application on Windows XP Professional the message Not a valid win32 application will be displayed. What I clearly see that you're mixing a term Version commonly used in a Resources section ( and displayed in About dialog box ) of some executable with a term Version recorded in the Image Header ( related to a target OS ). So, an executable could have two different "version" numbers: - A version in an Image Header related to some target operating system, for example 5.1 for Windows XP OSs and - A version in a Resource section related to some software vendor who controls some release, for example 13.0.089 for Initial Release of Intel Parallel Studio XE 2013 MSDN clearly says that /VERSION controls The version number you want in the header (!!!) of the .exe or .dll file. Note: I know about that article you've mentioned on blogs.msdn.com for at least 6 months after a similar problem happened with a developer who uses Intel C++ compiler and Visual Studio 2012 ( TimP posted that link as far as I remember ). It happened again about 1.5 months ago with another user.

[SergeyKostrov]

>>...However, I've changed the Linker:System\SubSystem flag in the project settings to 'Not Set', and then >>added the linker command line '/SUBSYSTEM:CONSOLE",5.01" and now it DOES work. Thanks Nick for a description of your solution. Note: I checked and 'Not Set' in the Subsystem attribute has to be used for 64-bit Windows operating systems. Best regards, Sergey

[SergeyKostrov]

>>... Is this maybe a result of the changes made in Update 1 for VS2012?... Unfortunately, I do not know. My theory is as follows: Microsoft does whatever it possible to force Loyal to Windows XP users to upgrade the system to some newer Windows operating system and, as everybody knows, such upgrades are not for free...

[nick6]

Sergey Kostrov wrote:

Note: I checked and 'Not Set' in the Subsystem attribute has to be used for 64-bit Windows operating systems.

Setting 'no set' just dropped the /SUBSYSTEM switch from the command line, so maybe if no switch is specified the default is for targetting 64bit? I only did that so my linker switches didnt include /SUBSYSTEM twice.

Cheers.

[IanH]

Sergey Kostrov wrote:
MSDN clearly says that /VERSION controls The version number you want in the header (!!!) of the .exe or .dll file.

Sergey - for clarity - what Steve and nick say about /VERSION is right.  That specific number in the executable header has nothing to do with operating system version.  You can see the value of that field in the dependency walker screen shot you posted in another thread.  This is separate to a version resource and separate to the required operating system/subsystem version (both set by /SUBSYSTEM).

[SergeyKostrov]

>>...This is separate to a version resource and separate to the required operating system/subsystem version >>(both set by /SUBSYSTEM). Thanks for the note. [ A quote from Nick ] >>... >>...I can also confirm that the /VERSION only injects the 'image version' into the EXE... >>... and this is a screenshot from a Visual Studio with a description ( just in case... ): I'm very glad to see that Nick understood that 5.01 needs to be set after /SUBSYSTEM:CONSOLE to solve the problem. MSDN says that: ... /SUBSYSTEM:{CONSOLE|EFI_APPLICATION|EFI_BOOT_SERVICE_DRIVER| EFI_ROM|EFI_RUNTIME_DRIVER|NATIVE|POSIX|WINDOWS|WINDOWSCE}[,left[,right]] ... The default is version 4.00 for CONSOLE, WINDOWS, and NATIVE; and version 19.90 for POSIX. ... Best regards, Sergey

[Bernard]

Sergey Kostrov wrote:

>>... Is this maybe a result of the changes made in Update 1 for VS2012?...

Unfortunately, I do not know.

My theory is as follows: Microsoft does whatever it possible to force Loyal to Windows XP users to upgrade the system to some newer Windows operating system and, as everybody knows, such upgrades are not for free...

Realy expected behaviour from Microsoft.

[Bernard]

>>>Of course it is not relevant directly but it is relevant indirectly. It affects what information will be recorded into an Image Header of a Portable Executable ( PE ) file targeted for some Windows OS.>>>

It is not relevant for the Fortran program itself,but as Sergey said it is relevant for the compuiled into PE format exe file.