Not a valid win32 application

[Brian_A_]

After installing the latest IFC on my Windows 7 computer and compiling our code unter the 32bit compiler, the exe will not run on WinXP but will run on Win7.

Version 2013 update 1

When I try to run it in WinXP, it says, "Not a valid win32 application"

Windows 7 works just fine

On anotgher computer running windows 7, I have the IFC version of 12.1.4.325 Build 20120410 and the code compiled on the 32bit compiler on that version works fine on WInXP and Win7.

[Steven_L_Intel1]

That's a new one for me. Usually that error indicates a corrupted file. Would you please attach a ZIP of the EXE that fails on XP to a reply here, or you can use "Send Author A Message" to send it to me privately. Make sure that it is exactly the EXE that fails on XP (ZIP it on the XP system.)

[Ferdinando_Alde]

Hi Steve, I got the same problem with a module compiled in VS12. Recompiling the same code in VS10 all run well also in Windows XP.

[Ferdinando_Alde]

Ops! I attached the exe wich fails. You can run it .... it only ask to choose a file. With a couple of 'Cancel' ends the execution.

[Ferdinando_Alde]

Is it arrived? I hope yes .... at the last try.

[Steven_L_Intel1]

Ok, finally got the ability to test this. I can reproduce the problem, and it appears to be that the program uses several Windows API routines that do not exist in XP. Normally I would expect XP to give an "ordinal not found" error, which it usually does for DLLs, but I guess this is different. What I can't tell is whether the references are from the user code or some static library it links to, but there are a dozen or more. One example is CompareStringEx. I don't find references to this or the other missing routines in the Intel Fortran libraries. Please rebuild the application and enable the creation of a link map in the Linker properties, and attach the map to a reply here. (You'll have to ZIP it.)

[Ferdinando_Alde]

Hi Steve, here is the link map. Thank for all. Ciao

[Brian_A_]

I used Dependency Walker and found the two DLL files that are not on XP. Problem solved.

[Steven_L_Intel1]

Which were those? I didn't see any missing DLLs. I did see the typical two "delayed load" DLLs that are usually reported. It looks as if the API reference is coming from the MSVC library.

[Brian_A_]

mpr.dll and shlwapi.dll

[Steven_L_Intel1]

Interesting. My XP system has shlwapi.dll and I see no reference to mpr.dll in your EXE.

[Brian_A_]

ok so I created a map file.

[Brian_A_]

here is the file.

[Steven_L_Intel1]

Brian, The only thing that looks like it might be a problem is that you have nearly a gigabyte of static data (COMMONs, local arrays and the like). This may combine with other sizable contributions to push you over the 2GB limit, and this can cause bizarre symptoms including the one you described. If you're right "on the edge" then small differences, such as less user address space taken by the OS, can make the difference between running and not running. I don't see any other issues here - the program is statically linked, as it has to be since you are using Quickwin.

[Brian_A_]

Steve Lionel (Intel) wrote:

Brian,

The only thing that looks like it might be a problem is that you have nearly a gigabyte of static data (COMMONs, local arrays and the like). This may combine with other sizable contributions to push you over the 2GB limit, and this can cause bizarre symptoms including the one you described. If you're right "on the edge" then small differences, such as less user address space taken by the OS, can make the difference between running and not running.

I don't see any other issues here - the program is statically linked, as it has to be since you are using Quickwin.

When you say 1gb of static data, how is that possible when the code will run on a machine with less than 1gb of hard drive space.? Also everything ran just fine on the previous release of the IFC, but now with the latest release it does not run on Windows XP.

[Steven_L_Intel1]

As I said, the size of static data was the only unusual thing I noticed from the link map. Whether or not that's really the issue, I can't say. It does appear to be an address space issue - why changing compiler versions made a difference, I don't know. This isn't normally something affected by that. Can you attach the EXE (in a ZIP)? Or the .dwi file saved from Dependency Walker?

[Brian_A_]

I have attached the depends files for a version that runs and doesn't run. I have attached a comparison of map files for the good exe and the bad exe I have attached the map files as well. What does not make sense is I can take the same coding and compile it with version IFC 12.1.4.325 and it runs just fine on WinXP. Then I take the same coding and compile it on version IFC 13.0.0.089 and it fails on WinXP. I do not change how I compile it. Also the file sizes are different. The one that runs is 8,759kb and the one that fails is 9,367kb.

[Brian_A_]

ok I narrowed it down to my MAC. I am running Windows 7 on Paralells and I am compiling using the 32-bit compiler but I think the 64bit machine is interfering. I just compiled on my Win7 computer at the office with the latest compiler and it works fine.

[Steven_L_Intel1]

Ah, so you don't have "a Windows 7 computer" after all...

[Brian_A_]

Steve Lionel (Intel) wrote:

Ah, so you don't have "a Windows 7 computer" after all...

I do have a Win7 machine, but I had discovered the problem on my Mac running virtually Win7. Why though if my computer at the office that is a Win7 machine compile a 32bit app just fine, even though the machine is a 64bit machine. My mac is a 64bit machine but does not compile the 32bit version that runs on WinXP. I am using the 32bit compiler on both machines, but my Win7 machine the exe runs just fine on XP.

[Steven_L_Intel1]

What do you mean "does not compile the 32bit version"?