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

[Steven_L_Intel1]

No idea. I haven't seen this behavior on Windows 10. Do you see this if you launch the program directly, rather than from the VB app?

[NotThatItMatters]

Actually, yes.  I launched it from a command prompt with the same result.

[NotThatItMatters]

Might this be something with Windows 10 Home as opposed to Windows 10 Professional?

[Steven_L_Intel1]

No idea. And I can't think of what might be the cause, other than some antivirus solution.

[NotThatItMatters]

The IA-32 exe has the link option /SUBSYSTEM:WINDOWS,"5.01".

The Intel(R) 64 exe has the link option /SUBSYSTEM:WINDOWS,"5.02".

[Steven_L_Intel1]

Well, that would be right for Windows XP. What if you take off the 5.01 or 5.02?

[NotThatItMatters]

Yes, taking off the 5.01 (and 5.02) made it run well in Windows 10.  I am noting the opposite on Windows Vista, 7 and 8.  If I run the application with the switch SubSystem="subSystemWindows" as opposed to the previous switches, the application flashes and resizes all the time and the page scrolling becomes faulty.

So, in summary: running the app on Windows anything besides 10 requires the link option /SUBSYSTEM:WINDOWS,"5.01" for IA-32 or /SUBSYSTEM:WINDOWS,"5.02" for Intel(R) 64.

Compiling the application with the switch /SUBSYSTEM:WINDOWS allows it to run just fine in Windows 10.

Go figure.

[Steven_L_Intel1]

How are you specifying this? There's a property for it. You shouldn't be entering it by hand.

[NotThatItMatters]

This WAS entered as an AdditionalOption.  I am noting that if I do it as the SubSystem option in the linker (and eliminate the additional options) now I get it working for the IA-32 app but not working for the Intel(R) 64 app.  The option now for the IA-32 app is SubSystem = Windows for Windows XP (/SUBSYSTEM:WINDOWS,"5.1") whereas the option for Intel(R) 64 is Windows (/SUBSYSTEM:WINDOWS).

The IA-32 app runs as before, but the Intel(R) 64 app runs with the form resizing all the time and the text scrolling being frozen.  I suppose I can rebuild the 64 bit app with the AdditionalOptions as before.  I am a bit confused.

[Steven_L_Intel1]

I went to my Windows 10 system and built three of the sample programs (Whizzy, Puzzle and Poker) with VS2013, IA-32 and x64. I verified that they all ran without delay there. I then took them to my WIndows 7 system and ran them all - again, they all ran fine. (The only issue I had was a momentary delay while my AV scanner griped about them.)

For all of them, the linker option was simply /subsystem:windows , with no version.

[NotThatItMatters]

I must admit this is NOT the case with my code.  I cannot compile it with SUBSYSTEM:WINDOWS anywhere,  I need the WindowsXP option for the IA-32 compile and a bizarre kluge of AdditionalOptions for the 64-bit.

I am investigating.  It is probably the "unique" things I am doing with QuickWin as far as window sizing, the handling of minimization, the handling of menu choices, etc.

[NotThatItMatters]

Here is a snippet of declarations within a module which is used to populate the QuickWin display:

! MODULE variables (among others)
!  MAXIMUM_COLS   - maximum number of columns in calls to SETTEXTWINDOW
!  MAXIMUM_ROWS   - maximum number of rows in calls to SETTEXTWINDOW
!  NFONTS         - obtained from INITIALIZEFONTS
!  PIXELS_PER_COL - number of pixels per column in the display
!  PIXELS_PER_ROW - number of pixels per row in the display
!  X_SIZE         - number of X pixels for display
!  Y_SIZE         - number of Y pixels for display
INTEGER (KIND = 2), PRIVATE :: MAXIMUM_COLS = -1_2
INTEGER (KIND = 2), PRIVATE :: MAXIMUM_ROWS = -1_2
INTEGER (KIND = 2), PRIVATE :: NFONTS
INTEGER (KIND = 2), PRIVATE :: PIXELS_PER_COL = -1_2
INTEGER (KIND = 2), PRIVATE :: PIXELS_PER_ROW = -1_2
INTEGER (KIND = 2), PRIVATE :: X_SIZE = -1_2
INTEGER (KIND = 2), PRIVATE :: Y_SIZE = -1_2
!  WINFO          - display frame attributes 
TYPE (QWINFO) :: WINFO
!  MYSCREEN       - display window attributes
TYPE (WINDOWCONFIG) :: MYSCREEN

The code itself which does most of the work for showing the display is as follows:

    INTEGER (KIND = 4) LARGE_RESULT
    LOGICAL (KIND = 4) MODESTATUS

    LARGE_RESULT = SETWSIZEQQ(QWIN$FRAMEWINDOW, WINFO)
    MYSCREEN.title = TRIM(SCREEN_TITLE) // CHAR(0)
    MYSCREEN.numxpixels = X_SIZE
    MYSCREEN.numypixels = Y_SIZE
    MYSCREEN.numtextcols = 120_2
    MYSCREEN.numtextrows = 24_2
    MYSCREEN.numcolors = -1_2
    MYSCREEN.fontsize = QWIN$EXTENDFONT
    MYSCREEN.bitsperpixel = -1_2
    MYSCREEN.mode = -1_2
    MYSCREEN.extendfontname = 'Courier New'
    MYSCREEN.extendfontsize = -1_2
    MYSCREEN.extendfontattributes = QWIN$EXTENDFONT_BOLD
    MODESTATUS = SETWINDOWCONFIG(MYSCREEN)
    LARGE_RESULT = CLICKMENUQQ(%LOC(WINSIZETOFIT))
    MODESTATUS = GETWINDOWCONFIG(MYSCREEN)
    WINFO.TYPE = QWIN$MAX
    LARGE_RESULT = SETWSIZEQQ(0_4, WINFO)
    LARGE_RESULT = GETWSIZEQQ(0_4, QWIN$SIZEMAX, WINFO)
    PIXELS_PER_COL = INT(MYSCREEN.fontsize / 65536_4, 2)
    PIXELS_PER_ROW = INT(MOD(MYSCREEN.fontsize, 65536_4), 2)
    MAXIMUM_COLS = WINFO.W
    MAXIMUM_ROWS = WINFO.H
    NFONTS = INITIALIZEFONTS()

I want to point out the use of WINSIZETOFIT in order to get the size of MYSCREEN to fit within the frame window of WINFO.  This code was written many years ago in an attempt to get the two to fit together without gaps.  If I am to guess, this is the source of all my trouble!

[jimdempseyatthecove]

What may be happening is the (32-bit) DLL search path is traversing over a "repository path" that takes a long time to complete (or time out). It could also be AV checking the code (though that usually isn't longer than 10-15 seconds).

(as an experiment) Can you determine the DLL dependencies, find them, and copy them to the location of the .EXE?

RE: WHATSIZEOFIT

I seem to recall issues when Windows 8 that the presences of and/or style of vertical elevator bunged-up (wasn't consistent with earlier versions) the pixel counts.

Jim Dempsey

[NotThatItMatters]

Yes, that is what gave me the idea to use WINSIZETOFIT in the first place.  I had been hard-wiring the size difference and noting I was off by a few pixels here and there.  Then when I changed the display to full screen it would do things badly (or do things well).

Jim, with Steve's suggestion to switch the link option to Windows for Windows XP (/SUBSYSTEM:WINDOWS,"5.1") and remove the AdditionalOptions I had been using, the IA-32 problem disappeared.

[jimdempseyatthecove]

NotThatItMatters,

I do not like the idea of sticking linker versioning options into project. This is too prone to get mucked up when you port the project.

Have you considered including a .cpp file containing:

#pragma comment(linker, "the options you want")

In the file, you can also insert verbose comments...
... as well as use conditional compilation directives to give you more control.

Steve,

Fortran has: !DIR$ OBJCOMMENT LIB:"youLibraryHere.lib"

Can this be used to pass in object files and/or linker options?

Jim Dempsey

[Steven_L_Intel1]

The option being used here can't be done in an objcomment. It affects the format of the executable file created by the linker. The option on /subsystem is there for compatibility with Windows XP, though I don't know what other options are being used.

[JVanB]

I have tried to follow this thread, but Visual Studio is way beyond me. For some reason by default it wants to put the module file it creates somewhere that is not in its INCLUDE path.

But if you had a subroutine that printed out the time and called it at points during initialization, you might be able to pin down just where the problem occurs

program P
   implicit none
   integer logfile
   open(newunit=logfile,file='logfile.txt',status='replace')
   call time_and_fortune(logfile,'I am here')
end program P

subroutine time_and_fortune(iunit,fortune)
   implicit none
   integer iunit
   character(*) fortune
   character(12) time
   call date_and_time(time=time)
   write(iunit,'(*(a))') time(1:2),':',time(3:4),':',time(5:),fortune
   flush(iunit)
end subroutine time_and_fortune

.Is DPI awareness responsible for the weird effects you see on different versions of Windows?

[Steven_L_Intel1]

Repeat Offender wrote:

I have tried to follow this thread, but Visual Studio is way beyond me. For some reason by default it wants to put the module file it creates somewhere that is not in its INCLUDE path.

That is definitely not the case - if you can show me an example where that happens I would like to see it. Please attach a zip of the .vfproj file and the buildlog.htm. Feel free to send it to me by email or PM if you want.

You don't need VS to do what he is doing with the linker, though I don't know what all the options being used are. The /subsystem option is being discussed.

[JVanB]

You're right, Steve. My mistake was not taking into account the program structure and putting the second chunk of code into a main program rather than a module procedure. Had the problem fit my description, I would have gotten an error about the module file not being found rather than all of its variables not being declared, which was happening because they were PRIVATE. Putting that block of code into a module procedure did allow it to build, but with no apparent delay in launch.

Visual Studio is still a mess though, because every piece of software wants to mung it up somehow. I installed a brand-X assembler for a brand-X processor and that pretty much trashed all my registry entries for Visual Studio, not to mention wiping out my PATH environmental variable. Installing the latest ifort at least fixed things up to the extent that DUMPBIN /DISASM works again. These programming environments are hard enough without the added aspect that different software on your computer has wars over them.

[NotThatItMatters]

Okay, aside from the crazy construct I have written, what other way might a display be dynamically sized in a manner in which the enclosed window remains maximized inside the frame window?  When I say "dynamically sized" I am speaking of the user grabbing the frame and moving or sizing it while it is displaying output.