Compiling for Windows: "This app can't run on your PC"

[philchiu]

I have a Fortran/C application with some GUI components. The main entry point is a console application. I am able to compile it on Windows and run the application without issues. 

However, I run into issues when trying to compile with the flag /real-size 64. In this case, the program compiles fine, but cannot be run. When I execute it from a command prompt, I get the error screen:

"This app can't run on your PC."

Or, when run in PowerShell

"Program 'myprogram.exe' failed to run: The specified executable is not a valid application for this OS platform.At line:1
char:1"

Other information which may be relevant:
- I am building/running on Windows 10
- I am building the program inside an Intel oneAPI command prompt, with CMake and nmake
- dumpbin reports that the resulting executable has dependencies on kernel32.dll, user32.dll, gdi32.dl, imagehlp.dll
- Intel Fortran and MSVC are being used

Here are the flags which I pulled out of CMake intermediate files:
- C compiler flags
    /DWIN32 /D_WINDOWS /W3 /O2 /Ob2 /DNDEBUG /MT
- Fortran compiler flags
    /W1 /nologo /fpp /libs:dll /threads /names:lower /MT /O2 /real-size:64 /double-size:64 /O2 /DNDEBUG
- Link flags
    /version:3.36 /machine:x64 /INCREMENTAL:NO /subsystem:console

Any help would be appreciated, thanks!

[Steve_Lionel]

My guess - you have very large arrays declared as REAL, using that option doubles their size, pushing you over the 2GB static code and data limit. Sometimes the linker will give you an error, but if the size is really big, it just results in an EXE you can't run. Building for x64 doesn't help this. 

I had written an Intel Knowledge Base article for this years ago, but it has disappeared (grumble...)

To diagnose this, set the linker properties to generate a link map - attach a ZIP of the map to a reply here.

[philchiu]

Thanks Steve! That could very well be the case as this is a legacy piece of software originally written in F77.

Attached are the two map files when compiled with and without /real-size 64.

I appreciate your help very much!

By the way, is this the article you were referring to?

https://web.archive.org/web/20200427052152/https://software.intel.com/en-us/articles/memory-limits-applications-windows/

[Steve_Lionel · Accepted solution]

Yep, that's it.

Here's the Start address and length of the data segment in your "without" build:

0003:0001dbc0 3e449ec8H .bss DATA

and here's with:

0003:00029f00 7c779488H .bss DATA

That's perilously close to 2GB, and Windows needs to find room for its own data structures (and the stack). 

I suspect that all of these large variables are in COMMON. The best approach is to turn large arrays into allocatable arrays, but that can require significant rework of the code (to add modules). An alternative is to not enlarge EVERYTHING and to selectively change the declaration of only a few arrays to be double. That may or may not be practical.

And, yes, that's the article. Thanks. I have no idea why Intel dropped it.

[philchiu]

As you suspected, this program had a lot of large arrays in COMMON, as you guessed. Rather than rewriting with allocatable arrays, the simplest solution (for now) was to turn down the hard-coded size limits just a bit where we can afford to. After doing so everything is working beautifully.

Thank you very much Steve!

[JohnNichols]

Reminds me of '88 and the old 640 k limit, math coprocessors and the need to select a MS Fortran math library. 

I miss those days, mainly because I had hair and could drink more beer. 

Thanks for the memory.

[JohnNichols]

I got my first real Compaq
Bought it from computerland
Struck the keyboard and learned to type
was the summer of ‘88

..

All alone as I was using Fortran
Had two disks and they worked real hard
Jimmy laughed, Jody went away
I should have known we’d hit the limit

BLAST YOU 640K  - 

My apologies to everyone.