Running IA-32 Fortran exes in Windows 10

[NotThatItMatters]

I have an exe which is compiled IA-32 which is launched via VB.  We are noting on our newest Windows 10 laptops that the running of the exe "hangs" for approximately 60 seconds before continuing.  The app is a QuickWin app with a few Windows API calls.

If I launch the equivalent exe which is compiled Intel(R) 64, the exe runs without any "hanging."  What could be the source of this?

Dazed and confused

[NotThatItMatters]

Here are the linker settings from the vfproj file for the app.

Configuration Name="Debug|Win32"
<Tool Name="VFLinkerTool" OutputFile="$(OUTDIR)/###.exe"
 LinkIncremental="linkIncrementalNo" SuppressStartupBanner="true"
 GenerateDebugInformation="true" ProgramDatabaseFile="$(OUTDIR)/###.pdb"
 SubSystem="subSystemWindowsXP"/>

Configuration Name="Debug|x64"
<Tool Name="VFLinkerTool" OutputFile="$(OUTDIR)/###64.exe"
 LinkIncremental="linkIncrementalNo" SuppressStartupBanner="true"
 GenerateDebugInformation="true" ProgramDatabaseFile="$(OUTDIR)/###.pdb"
 AdditionalOptions="/SUBSYSTEM:WINDOWS,&quot;5.02&quot;"/>

With the testing I have done on the code, these are the only settings which allow the application to run without problems of steady resizing and incomplete scrolling of text lines in the MYSCREEN window configuration.

[Steven_L_Intel1]

I don't see "subSystemWindowsXP" as a valid option according to MSDN. Where did you find that? Otherwise you are specifying Windows XP compatibility. Why this should affect your GUI performance, I don't know. You may want to ask about this in MSDN forums.

[andrew_4619]

With the "hang" do you know exactly where this happens, is is before your code executes proper or is it actually in your code? Perhaps I am covering old ground but grabbing the system time at a few points near the start of your program will allow you to pinpoint the exact point at which the delay occurs.

[NotThatItMatters]

Again, that is directly copied from my project file.   SubSystem="subSystemWindowsXP" is equivalent to the option Windows for Windows XP (/SUBSYSTEM:WINDOWS,"5.1").

Again, the "hang" has been eliminated, but it was happening with an IA-32 executable which was compiled with the linker setting

 AdditionalOptions="/SUBSYSTEM:WINDOWS,&quot;5.01&quot;"

The "hang" occurred right at startup of the app.  The QuickWin window would form, but it had not title, no menus, no nothing and would sit there for roughly a minute before it would fully form itself and start program execution.

I cannot remember precisely where the options "5.01" and "5.02" came from, but I do remember a forum topic on this a year or more ago and I also recall finding this via Google at some point.

[Steven_L_Intel1]

5.01 and 5.02 I understand - those are the correct versions for XP32 and XP64. But "subSystemWindowsXP" is unknown to me, MSDN and Google.

[NotThatItMatters]

I'm not making this up.  My current VS implementation of Intel Composer is producing the subSystemWindowsXP.

[Steven_L_Intel1]

Would you please attach the .vfproj file?

[NotThatItMatters]

Is there any way to specify

/SUBSYSTEM:WINDOWS,"5.02"

for an Intel(R) 64 executable without using "Additional Options:"?  When I choose the System:SubSystem option "Windows for Windows XP (/SUBSYSTEM:WINDOWS,"5.1")" I get the warning

LINK : warning LNK4010: invalid subsystem version number 5.01; default subsystem version assumed

[Steven_L_Intel1]

This was a bug fixed in version 16.

[NotThatItMatters]

So I guess that settles it.  Damn the torpedoes, version 16.

[NotThatItMatters]

As per my question #21, what is the future of QuickWin graphics?  Is this using GDI or GDI+?  Is there something inherent in QuickWin which is demanding /SUBSYSTEM:WINDOWS,"5.1" (Windows XP) or is this a problem with my code?

Still dazed and confused

[Steven_L_Intel1]

As far as I know, the subsystem thing is merely an executable file format issue. It shouldn't affect how the program runs, but there may be some subtle thing I am not aware of. QuickWin code is quite ancient and has not changed materially since the late 1990s. If you can provide a standalone test case we can look at, we'll give it a shot.

Regarding the future of QuickWin, we have no plans to extend it nor to retire it. You may want to consider alternatives such as GINOMENU or Winteracter (or even Xeffort) if QuickWin is not meeting your needs.