Community
cancel
Showing results for 
Search instead for 
Did you mean: 
philchiu
Beginner
215 Views

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

Jump to solution

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!

0 Kudos
1 Solution
Steve_Lionel
Black Belt Retired Employee
167 Views

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.

View solution in original post

6 Replies
Steve_Lionel
Black Belt Retired Employee
207 Views

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
Beginner
177 Views

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-a...

Steve_Lionel
Black Belt Retired Employee
168 Views

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.

View solution in original post

philchiu
Beginner
156 Views

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
Valued Contributor I
135 Views

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
Valued Contributor I
130 Views

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. 

Reply