Problem running Fortran compiler

[ivf_ian]

I am having problems running Fortran on Visual Studio platform.  I had been running my code successfully until recently when I received an objection that it couldn’t find a couple of ddl files.  I then installed VS, Base Toolkit, HPC Toolkit in that order and have now other problems.  See drop boxes, showing (1) cannot open include file string_h when trying to open a resource file and (2) warning about data type not matching when trying to compile a file.  I believe I was using ifort compiler before when things were running well, but now I suspect it is ifx.  I really don’t care which one is being used as long as the compiler works.  Appreciate any assistance with this problem

[JohnNichols]

Your pictures show X64 mode, were you running it in X32 before and the move to IFX has caught an error in upgrading. 

If you still have IFORT installed try that.  If not do you have an old installer.  

Do you have the correct version of the Windows kits installed, an easy error. 

It is a matter of playing with the code. 

[ivf_ian]

Thanks for your help.  I am fairly certain I was running my program in x32 before and was fine with that, but suddenly VS wouldn’t run, noting that there were some missing dll files.  I tried finding them to install, but got nowhere, which is why I download the new code for VS together with the 2 kits.  So I guess I’m now trying to run my program in the x64 mode.  Not sure what you mean by still having IFORT installed – what code is that exactly?   And which old installer are you referring to, how old?  As far as the correct version of the Windows kits, I downloaded the latest ones, so don’t see that being an issue.   I really don’t care whether I’m running in the x32 or x64 mode.

[Steve_Lionel]

The first image reflects an inconsistency with the resource file (.rc) and the various Windows API kit files it wants to include.  string.h should be in one of the folders under C:\Program Files (x86)\Windows Kits\10\Include\ - it's part of the standard C library.

John is correct regarding the second image, where you apparently have M_HANDLE declared as a 32-bit integer where it should be 64-bits. The supplied Intel module IFWINTY declares a HANDLE named constant that will be the correct integer kind - use INTEGER(HANDLE).

[Steve_Lionel]

Ignore IFORT - it doesn't matter whether you have it or not. But you DO care about x64 if you incorrectly declare Windows API handles as 32-bit. So, you need to fix that - luckily, it's an easy fix.

The include file issue can be more complicated, and it's the sort of thing that pops up from time to time, unrelated to the Fortran compile. One thing you can try is to locate the folder containing string.h and add it to the list of Include folders in your project. I can't promise this will work - the resource compiler is unpredictable as to how it finds include files.

[ivf_ian]

Thanks! 

Great - I believe I managed to get rid of the string.h resource error by including the appropriate include file location in the debug properties location.  (More luck than anything else as I’m unfamiliar with finding my way around the Visual Studio Platform.)  I then received another error related to an include file, this time within the Windows Kit…. directory.  Having included that also in the debug properties location, it appears that the resource file compiled OK. 

Next I inserted the line ‘module IFWINTY’ into the source file with the M_HANDLE issue (probably a mistake) and tried to compile the revised code.  The compilation process appeared to hang and while I could load and work (change text) on other files within the program, the compile button could not be activated until I closed the solution and opened it up again.  Then, when compiling the same file, but having commented out the IFWINTY line, I received the message “build log could not be opened…..’  See drop box.  Strangely enough after a short while this message did not reappear during compiling a file.

Would appreciate knowing exactly what I should do with IFWINTY (where in my code) to solve this M_HANDLE problem.

Thanks for help.

[andrew_4619]

To use the module the syntax would be "USE IFWINTY" not "MODULE IFWINTY"

Somewhere (maybe in one of those include files you have:

integer :: M_HANDLE

which needs to be 

Integer(handle) :: M_HANDLE

"handle" is an integer  type defined in IFWINTY   which will make M_HANDLE 32 or 64 bit as apppropriate

[ivf_ian]

Thanks for response.

I found the IFWINTY file, C:\Program Files (x86)\Intel\oneAPI\compiler\2025.3\opt\compiler\include\intel64\ifwinty.mod and included the appropriate directory in the Visual Studio Platform.  See drop box.   This placement was the same as where I put the Tool Kit include files earlier to overcome the string.h problem.  I see there is another place under the fortran directory above the resource one.  Does it matter where the include files go?  When I try compiling the B2.f90, the process just hangs like before.  Thanks again for the help.

[andrew_4619]

I really don't understand why you needed to look for ifwinty. It should just know where that is in default search paths. There should be no need to change anything for that to be found.

[ivf_ian]

Thanks.  I removed the link from the resources directory and tried to re-compile code.   However, while there was no error or warning, things just hung up.  See drop box.  Is there a problem with messagebox?

[andrew_4619]

"USE WIN_INTR" this that a winteractor module being used? Do you build that or do you have pre-made .mod and .lib files in your project?  If so what is the pedigree of those files? Are they 64 bit and what compiler built them? If you comment that line out does it not hang (expect a load of compile errors)? Lots of guessing as all we have is some limited screen grabs.

[ivf_ian]

Not sure how to answer your questions, especially those re. pre-made .mod and .lib files.  I'm an engineer rather than software developer, so apologies for my ignorance.  I had a colleague develop a good portion of my program for interfacing with Windows.  I believe she developed the win_intr module - this was several years ago, so suspect they were 32 rather than 64 bit.  See drop box.  Thanks for your patience!

[andrew_4619]

Well you have the source and it is in the project so we can presume you compile win_intr.f90 so that answers that. I will note that in the small part I can see, there are two derived types which are a creation of the author as they are not windows sdk types. Those have hParent entries which all most certainly should be integer(handle) rather than integer*4.  That may be the tip if the iceberg. It needs carefully checking  and sdk calls an any interfaces need checking. I see DWFINA used so I am guessing most if not all the interfaces come for the Intel include modules which is a blessing for you as those should all be good presuming the standard DFWINA is used and not some source copied from an old system.

When   you do a 'clean' and then a 'build' on this project what is the first error you see? You should post the buildlog.html file so we can see the chain of events and errors. 

[ivf_ian]

I followed your advice , cleaned and build project.  The project is very large, containing dozens of files, resource, dialog and typical Fortran files.  While a number of the files were compiled successfully, it appears that the processing finally got bogged down with too many warnings and stopped without producing an html file.  The drop boxes show (1) the build upto the point when warnings appear and (2) the filt_sub.f90 file showing problem line and (3) a file containing the warnings starting with the subroutine tool.f90 - a subroutine whose function is to interface with Windows.  While there were literally hundreds of warnings, there didn't appear to be any error messages as such.  Hope this is helpful.  Let me know if you require more information. 

[andrew_4619]

You do a rebuild, if the build is long just cancel when the first errors start to appear. Fix the first ones and rinse repeat. Errors tend to cascade so there is no point in fixing later ones as many will be a consequence of earlier not fixed errors.

Many of the warnings are in fact bugs in your code:

Looking at the first 4:
C:\opticsoft\temp_03\Dia_gsa.f90(817): warning #6075: The data type of the actual argument does not match the definition. [HDLG]
C:\opticsoft\temp_03\Dia_gsa.f90(818): warning #6075: The data type of the actual argument does not match the definition. [HDLG]
C:\opticsoft\temp_03\Dia_gsa.f90(1096): warning #6075: The data type of the actual argument does not match the definition. [HWNDCTRL_C]
C:\opticsoft\temp_03\Dia_gsa.f90(1188): warning #6075: The data type of the actual argument does not match the definition. [HWNDCTRL_C]

In windows SDK hdlg is normally a handle (integer pointer) to a dialog
hwnd is normally a handle to a window/control/button whatever.

These should all be integer(handle) types in x64 builds. Every time you pass an incorrect type to an sdk routine you will get an interface mismatch error= error cascade.
Every module that does not build will give multiple errors later where ever that is used.....

[ivf_ian]

Once again thanks for your help.  When carrying out a rebuild after a clean, warning messages started printing out after a few files were compiled successfully (including win_intr.f90).  This occurred with file plot.f90.  See screen_dump_11.jpg.   Carrying out a clean followed immediately by trying to compile plot.f90 resulted in error messages related to win_intr.f90.  See screen_dump_12.jpg.  I have included the files plot.f90 and win_intr.90. 

[witwald]

The error messages offered by the compiler point to type mismatch problems. It seems that it will be necessary to go through the code and edit it to ensure that the correct types are used when declaring variables. The original code may have been written under the assumption of a 32-bit environment, but on Windows 11 that's no longer the case, so a conversion to 64-bit handles/pointers will be needed. It shouldn't be too big a job, as the compiler will serve to guide you as to which sections of the code need changing. Just read up on what's going on to get a good understanding prior to embarking on the editing/refactoring task.

[ivf_ian]

Thanks.  That sounds encouraging.  Will try that over the next couple of days.

[ivf_ian]

I believe I making progress with the handle issue – thanks.  Oddly enough now when loading the resource file, I get the message that it can’t open include file string.h, however, I can edit it OK.  See drop box.

[andrew_4619]

Clean deletes all the results of compilation for the project. Trying to build a specific source such as Plot.f90 after a clean is a bad idea. It is clearly dependant on Win_intr.f90  having been already successfully built. When you run build VS analyses file dependencies and then compiles things in an order that works.

Looking at the contents  of the two source files you attached they contain a large number of handle declarations that will simply not create a successful x64 build.  They all need the usage checking and correcting as appropriate.

To be brutally  frank, based on your posts/questions, you have a steep hill of learning to be able to do that task.  It probably isn't that big a job for someone with the appropriate knowledge and experience. 

[Steve_Lionel]

This string.h issue shows up a lot. If you can locate it on your disk - may be in the same folder mentioned in the message - add that path to fully specify the path to string.h.