installing old IVF version on windows 11

[ivf_171123]

I have a 9 year old version of IVF and am having a problem installing it on a new computer operating on windows 11.  It installed on windows 10 OK, so what is the problem?

[ivf_171123]

After receiving no feedback from my latest response, I thought it best to try again, this time in an effort to clarify my predicament more succinctly.

After having problems loading an old version of IVF, w_fcompxe_2013_sp1.2.176.exe, on my new computer running Windows 11, I was advised to install the latest version of Microsoft Visual Studio, oneAPI Base Toolkit and Fortran Compiler, all free downloads.  This I did, although not without some difficulty.  However, when I tried inputting my Fortran program, which is a large piece of engineering code, I ran into a number of problems.  The first being there was an objection in loading the resource file, warning it cannot open include file ‘string.h’.  My resource file was created using a text editor, which appears not to be the way a resource file is now generated.  Secondly, while compiling the Fortran files used specifically for general engineering computations seemed to go without a hitch, this was not the case for those files which interface with Windows.  There are three of these files, all several hundred lines in length.  The issue I have is that while I’m familiar with classical Fortran programming, I’m at a loss with the Windows interfacing code necessary for the Visual Studio platform – this was undertaken by an ex-colleague.  So while it might be beneficial for some to move over to this new free download, for me it would be quite impractical.  I have the above mentioned IVF code on a USB stick with the appropriate security code, so is it not possible for me to load said program onto my computer, yet somehow circumvent the step where it asks for the security code.  

Sure would appreciate some direction here.

[andrew_4619]

Trying to get old incompatible versions to run on Windows 11 isn't going to happens and to be honest is not worth trying. Fixing your project in a current versions is probably quite a simple matter to someone with the appropriate knowledge. Let us do things one at a time. If you post the .rc and associated .h files in a zip I suspect it will take a few minutes to fix. I have done this many time before but the solutions have not always been the same each time it has multiple ways to break. 

If you feed you can post the whole project that might get you a faster result.

[ivf_171123]

andrew_4619

Honored Contributor II

‎12-18-2023 08:41 AM

 5 Views

Trying to get old incompatible versions to run on Windows 11 isn't going to happens and to be honest is not worth trying. Fixing your project in a current versions is probably quite a simple matter to someone with the appropriate knowledge. Let us do things one at a time. If you post the .rc and associated .h files in a zip I suspect it will take a few minutes to fix. I have done this many time before but the solutions have not always been the same each time it has multiple ways to break. 

If you feed you can post the whole project that might get you a faster result.

Translate

Add tags

0 Kudos

Copy link

Reply

Steve_Lionel

Black Belt Retired Employee

‎12-18-2023 07:52 AM

 12 Views

Microsoft has moved around things related to resource files, over the years, with the result that some old resource files include MS-provided files that no longer exist. A second problem, which I struggled with for a long time, is that sometimes, even if the include file does exist and should be located by following the Include Files path, the resource editor and compiler don't find it. Weirdly, I sometimes found that simply creating a new solution/project and adding the files to it resolved the issue.

string.h is a curious case. If I look at the current MSVC include files, I find a file called "string" with no file type, that is evidently what used to be string.h. Maybe Microsoft changed Visual C++ to look for that? I don't know. 

The issues you're having here aren't really related to the Intel Fortran compiler, but rather the Microsoft Visual Studio tools and SDK. 

If we had a ZIP of your project that demonstrated the problem, perhaps we could help more. Simply providing vague descriptions of problems aren't useful.

Translate

Add tags

0 Kudos

Copy link

Authentication Failed.

• Authentication Ticket Mismatched, failed authentication.

ivf_171123

Beginner

‎12-18-2023 09:20 AM

Thanks for the two responses – quite encouraging.  I’m OK with uploading a zip file containing the entire program, but as I have already mentioned the code is extremely long.  However, large sections of it can be ignored since they are written in Classical Fortran.  How is the best way for me to upload the zip file.

I had problems logging onto the thread I started and have had to do some copying and pasting to establish some continuity - hope the result is not too confusing.  I tried uploading the zip file but didn't work.  I then tried uploading it via email as suggested by you Steve, but received a postmaster non delivery message.  What's the best method for uploading the zip file?  Thanks again for looking into this issue.

[ivf_171123]

As one can see I am having a problem posting replies on this platform, which appears to be bouncing me around different versions of the original thread I started some weeks back.  Anyway I hope anyone following this can makes sense of what has gone on - cheers.

[Steve_Lionel]

Microsoft has moved around things related to resource files, over the years, with the result that some old resource files include MS-provided files that no longer exist. A second problem, which I struggled with for a long time, is that sometimes, even if the include file does exist and should be located by following the Include Files path, the resource editor and compiler don't find it. Weirdly, I sometimes found that simply creating a new solution/project and adding the files to it resolved the issue.

string.h is a curious case. If I look at the current MSVC include files, I find a file called "string" with no file type, that is evidently what used to be string.h. Maybe Microsoft changed Visual C++ to look for that? I don't know. 

The issues you're having here aren't really related to the Intel Fortran compiler, but rather the Microsoft Visual Studio tools and SDK. 

If we had a ZIP of your project that demonstrated the problem, perhaps we could help more. Simply providing vague descriptions of problems aren't useful.

[ivf_171123]

Thanks for the two responses – quite encouraging.  I’m OK with uploading a zip file containing the entire program, but as I have already mentioned the code is extremely long.  However, large sections of it can be ignored since they are written in Classical Fortran.  How is the best way for me to upload the zip file?

[Steve_Lionel]

You can attach a ZIP to a reply here. The goal is to get the project to build, but if I test this it will be using the latest version of the Intel oneAPI Fortran compiler and VS2022. 

[ivf_171123]

I had problems logging onto the thread I started and have had to do some copying and pasting to establish some continuity - hope the result is not too confusing.  I tried uploading the zip file but didn't work.  I then tried uploading it via email as suggested by you Steve, but received a postmaster non delivery message.  What's the best method for uploading the zip file?  Thanks again for looking into this issue.

[andrew_4619]

What "didn't work" with the zip file? Was it more than 71MB? You can drag and drop files in the box that is there when writing a message. 

Yes threading on the forum is confusing, it has been that way since it was "improved" the old system of having a #no on each post  so you could refer to the # you were replying to used to work fine and each thread was then linear with newest  post always at the end. 

[ivf_171123]

I've attached the zip file, not large, less than 1MB.  The files with which I'm having problems are opticsoft.rc, osd_a.f90, osd_b.f90 and osd_c.f90.  There are a number of data files which can be ignored, only useful if running the program.  Thanks for any help. 

[andrew_4619]

Voila!

[andrew_4619]

I used the latest IFORT compiler in VS2022. The reason is that this is a 32 bit application. It will be a lot of work to make it 64bit because all the integers that should be of type pointer-kind are integer(4) hard coded. Note that IFX is only 64bit. Anyway:

1) make an empty windows project. set x86 project property

2) copy all the files to the project folder and at then add the source files to the project

3)  add the .rc and .h  to the project.

4) edit the .rc file, remove the top 3 and add the bottom 2 .h files:

//#include <windows.h>
//#include <commctrl.h>
//#include <richedit.h>
#include "osd.h"
#include "winres.h"
#include "winver.h"

5] build.

copy all data files to the hard coded directory name and then run!

I will zip of the project an post it later.

Regards

Andrew

[ivf_171123]

Well done.  I'm impressed that you were able to do it so quickly.

I tried following your instructions, although not sure about the x86 property option.  I did choose the 'Use compiler IFORT Intel Fortran Compiler Classic' option, is that the same?

I amended the lines in the resource file and it compiled without issue, however, some of the .f90 routines ran into problems, a couple of examples listed below. 

Compiling with Intel® Fortran Compiler Classic 2021.11.0 [Intel(R) 64]...

osd_a.f90

C:\opticsoft\i2302\osd_a.f90(85): warning #6075: The data type of the actual argument does not match the definition.   [GHWNDMAIN]

C:\opticsoft\i2302\osd_a.f90(194): error #6284: There is no matching specific function for this generic function reference.   [LOADICON]

C:\opticsoft\i2302\osd_a.f90(405): error #6284: There is no matching specific function for this generic function reference.   [LOADMENU]

C:\opticsoft\i2302\osd_a.f90(408): warning #6075: The data type of the actual argument does not match the definition.   [HMENU]

C:\opticsoft\i2302\osd_a.f90(409): warning #6075: The data type of the actual argument does not match the definition.   [HCHILDMENU]

C:\opticsoft\i2302\osd_a.f90(414): error #6284: There is no matching specific function for this generic function reference.   [CREATEWINDOWEX]

C:\opticsoft\i2302\osd_a.f90(474): warning #6075: The data type of the actual argument does not match the definition.   [GHWNDMAIN]

C:\opticsoft\i2302\osd_a.f90(477): warning #6075: The data type of the actual argument does not match the definition.   [GHWNDCLIENT]

Compiling with Intel® Fortran Compiler Classic 2021.11.0 [Intel(R) 64]...

Dia_wg.f90

C:\opticsoft\i2302\Dia_wg.f90(43): warning #6075: The data type of the actual argument does not match the definition.   [HDLG]

C:\opticsoft\i2302\Dia_wg.f90(53): warning #6075: The data type of the actual argument does not match the definition.   [HDLG]

C:\opticsoft\i2302\Dia_wg.f90(54): warning #6075: The data type of the actual argument does not match the definition.   [HWNDCTRL]

C:\opticsoft\i2302\Dia_wg.f90(55): warning #6075: The data type of the actual argument does not match the definition.   [HWNDCTRL]

C:\opticsoft\i2302\Dia_wg.f90(56): warning #6075: The data type of the actual argument does not match the definition.   [HWNDCTRL]

C:\opticsoft\i2302\Dia_wg.f90(57): warning #6075: The data type of the actual argument does not match the definition.   [HDLG]

Is it possible to send the corrected zip file?  Appreciate your help with this.

[andrew_4619]

You are making a 64bit application, that is why you get those errors. 

You need to change the x64 on the pull down.

I missed one other step. Right click in solution explorer on the osd.h file  and set a custom build step. This will make the fortran .fd file from the C++ .h file. When you edit the resourse file in the GUI it updates the .h file so this keep the .fd file in sync.

I think you are close to having in working.

I attached a zip for reference if you unpack to a folder. Open VS and open the project file you will get my setup. But it is better you make your own as the then get to understand it a bit better,

[JohnNichols]

Andrew:

I have been following this thread as I was interested, good work.

John

[ivf_171123]

I followed your latest instructions and was able to compile and actually run the program.  You must be very familiar with MVS and all its workings.  Thanks very much Andrew! 

[andrew_4619]

No worries! Great that you have now got a starting point. I do not think anyone really knows VS it has so many features, if you dig around you can find something new every day! I do not know what your plans are with this program but as a 32bit app its days are numbered.  IFORT is already deprecated  so updates will stop in a year or so, obviously you will be able to use IFORT as long as you have the IFORT installers, the VS installer  and an OS that will support it.

Someone has clearly spent a lot of time on this program, there is quite a lot of it and the layout whilst not to my likening (yuk all those common blocks and include files) is at least logically ordered and not too bad to follow.

If this program has a future it will need adapting to 64 bit which might not be  too hard having had a quick look around it all the windows API stuff is reasonably well partitioned within the code.

Anyway have fun with it. Regards, Andrew

[ivf_171123]

Most excellent starting point.  It will give me somewhat of a breather until I can master the new version.  As I have already mentioned I developed the entire program apart from the portion which allows VS to interface with the Fortran code, although I was able to make some modifications to that code.  I am an optical engineer with a little more than the rudimentary skills of computer programming, which is probably the reason for the ‘yuk’ in your response.  I was wondering whether it is possible to obtain a sample program running on the new platform supporting the 64 bit, one which I could use as a template for converting my program?  Also if I downloaded the current off-line code for Base ToolKit, HPC ToolKit and VC, could I use it at some time in the future?  Thanks once again for all your effort.  Cheers, Ian   

[andrew_4619]

Yes if you will be in IFORT for some time I would download and save the offline installers for OneAPI/HPC and VS in case a reinstall is needed and you can no longer get them. The main thing is see with 64 bit is many integer types  used  for the SDK are current integer of integer(4) then the need to be defined types such as integer(handle) etc. so they become the correct type based on 32/64 bit model. It seems that many of these declarations are in include files so it *might* not be so big a job. The intel sdk USE will look after itself.

The 'yuk' was not a serious criticism, stuff I wrote 25+ years ago had lots of include files and common blocks but for a long time now modules/submodules have been a better way to organise data and interfaces. The code will compile much faster and will let the compiler error check much better.

[ivf_171123]

Thanks Andrew for the advice and all your help.  Still wondering whether there is a sample program available which I could use as a template in converting from IFORT to IFX –  it would certainly make my life easier.  All the best for 2024.  Cheers, Ian

[andrew_4619]

"Template" no not really there are many things that need fixing, most are no difficult just time consuming and tedious. For example:

    function xxxx_dlgproc(hdlg,message,uparam,lparam) result(retval) bind(c,name='XXXX_DLGPROC')
       !DIR$ ATTRIBUTES STDCALL :: XXXX_DLGPROC
       !GCC$ ATTRIBUTES STDCALL :: XXXX_DLGPROC
       integer(int_ptr) :: retval
       integer(handle),intent(in),value  :: hdlg
       integer(uint),intent(in),value    :: message
       integer(fwparam),intent(in),value :: uparam
       integer(flparam),intent(in),value :: lparam
    end function xxxx_dlgproc

You have a lot of windows callback functions. 3 of those args and the return values should be 64 bit in a 64bit built but you have integer or integer*4. You "use dfwina" (old digital fortran but still works) which is the same as "use ifwina" which defines all the constants for types such as "handle" in such a way that it is correct in 32 or 64 builds. As a start you can  carry on with 32 build but start to  add all correct integer types.

You also need to look at all sdk calls for example LRES = SendMessage(hID, CB_GETCURSEL, 0_fwparam, 0_flparam)

LRES = SendMessage(hID, CB_GETCURSEL, 0, 0) is not correct in the 64bit world. If you google "msdn sendmessage" and look at the c++ interface it will explain and also tell you this function is in user32.lib. Look in C:\Program Files (x86)\Intel\oneAPI\compiler\2024.0\opt\compiler\include and open user32.f90 and you will find:

INTERFACE
FUNCTION SendMessage( &
        hWnd, &
        Msg, &
        wParam, &
        lParam)
use ifwinty
  integer(LRESULT) :: SendMessage ! LRESULT
    !DEC$ ATTRIBUTES DEFAULT, STDCALL, DECORATE, ALIAS:'SendMessageA' :: SendMessage
  integer(HANDLE) hWnd ! HWND hWnd
  integer(UINT) Msg ! UINT Msg
  integer(UINT_PTR) wParam ! WPARAM wParam
  integer(LONG_PTR) lParam ! LPARAM lParam
 END FUNCTION
END INTERFACE

The is showing the types the intel interface is requiring.

As I said a lot of tedious work....