Migration of CVF project to IVF solution issues

[dannycat]

I've just downloaded and installed the evaluation copies of IVF and Visual Studio 2008 and attempted to compile a large application originally developed in CVF. I eventaully hope the purchase both products as soon as I am confident that I can successfully build and link the program as 32-bit in vew to creating a 64-bit version later.

The migration process itself, firstly doneon a 32-bit Vista machine, was really quite painless and after getting used to the new environment it was quite easy to use.However I encountered a couple of possible problems when rebuilding the subprojects within the "Solution".

1) the compiler picked up that the RGB and MAKEINTRESOURCE macro arguments are incompatable. I assume they should be unsigned integers. How do we get round this in FORTRAN as INT1 values range between -128 & 128? As these are warnings rather than errors, will these functions still work as they did in CVF? I have not had chance to check yet.

2) the compiler also produced a severe error when attempting to compile a module which contains internal recursive procedures. (I confirmed this by removing the internal procedure code and recompiling).

3) the compiler sometimes doesn't like the use of NULL as a parameter (I think it is defined in dfwin). It says that it is defined by more than one use statement, although this was never an issue in CVF. When a routine includes a 2 modules that both use dfwin could this cause the problem. It would help if the warning named the offending modules.

4) on one occasionthe compilercomplained about "type(DIALOG) :: dlg" statement by pointing to DIALOG saying it was defined by more than one use statement. A similar message appeared for "type(T_RECT)" declaration statement.

5) Is there a similar switch to force the linker to "Force file output" on the CVF Project Settings/Link/Customise Tab?. In CVF I utilised this to enable an old third party library to be linked.

6) I triedto repeat the process on our 64-bit (running XP)machine but had problems when trying to search for strings in the Visual Studio. The program crashed every time. I will send this as a bug report to Microsoft.

On a positive note there were several occurences where I'd mistakenly used "call function" instead of "ret = function" in my CVF project. These errors were not picked up by the CVF compiler although the code seemed to work OK.

Any help on these issues would be much appreciated.

Finally something which may be of interest to forum users is that the one major stumbling block in fully recompiling my project is that several routines were built utilising the F90SQL libraries originallyobtained fromLahey. These are not currently available for Intel compilers and Laheyno longer support the code. But having contacted the original vendor, CanaimaSoft, the F90SQL libraries and modules are hopefully going to be available as soon as they can sort out a new distributor.

Thanks

[Steven_L_Intel1]

1. Use INT(RGB(...),WORD) as the argument to MAKEINTRESOURCE
2. If you have a test case, we'd like to look at it
3. It's not a problem to use two modules that both use DFWIN. The issue would be if there were two distinct definitions of NULL being used. A test case would be helpful.
4. Hard to say without seeing your code -again it looks as if you have two or more distinct declarations of these types somehow. Workarounds include ONLY clauses and renaming, but I don't see how CVF-compiled code would have this problem.
5. It looks as if Microsoft removed this option as a property. You can add /FORCE or /FORCE:MULTIPLE to the Linker > Command Line property page

Your note about f90SQL is interesting. Last I heard, which was 2-3 years ago, Canaima was closing down. You can use the CVF-compatible version of f90SQL with Intel Fortran with a bit of work. Attached is a version of f90SQL-Lite with modules for Intel Visual Fortran. I think you will also need dforrt.dll from CVF on your system.

[dannycat]

Steve,

Thanks for your prompt reply. 

I'm not sure what you mean for the macro arguments fix. I have several instances where

icolref = RGB(ired,igreen,iblue) macro is used, where ired, iblue and igreen can be in the range of 0 to 255

The RGB macro expects unsigned integer(1) arguments (I assume) but these will, in FORTRAN, range between -128 and 128.

I have attached below the source file that caused the severe compiler error in item 2) of my list.

This code was pulled off the web. I only use the last part so the section causing problems

can be removed. I forward so that you can locate a possible compiler bug.

Annoying amount of code removed by Author!

[Steven_L_Intel1]

Which version compiler are you using? I can't reproduce the compiler failure and your RGB issue should not be a problem with the current version (10.1.024). Can you show me the command line used and the output, or the build log?

In the future, you can attach a large file rather than pasting it into a reply. Use the Options tab while posting.

[dannycat]

Steve,

I'm using version 10.1.021 [IA-32]. (Sorry about the large posting above but I couldn't find where to attach files yesterday). This may be the reason RGB still flags up mismatched arguments.

Thanks for the SQL modules, I can now compile all of the code.

Is there an equivalent run time MatherrQQ routine in IVF this has now cropped up?

[Steven_L_Intel1]

The code you posted does not use RGB, so I am not sure what you are seeing. 10.1.021 should be fine. Can you show me an example?

There is no direct equivalent to MATHERRQQ at this time, but there may be other ways of handling math errors. What do you need to accomplish?

[Jeffrey_A_Intel]

> Sorry about the large posting above but I couldn't find where to attach files yesterday

When you click on "Reply", you're brought to a windows which hasthree tabs near the top. The "Compose" tab is selected and that's where you create your reply. If you click on the "Options" tab, you're taken to a windows where you'll be able toappend one file to your posting.

[dannycat]

Steve,

1) I'll explain what I have found regarding RGB macro.

The RGB function is treated differently in CVF and IVF. The following statement passes CVF with no warning:

integer :: red,green,blue

hBkBrush = CreateSolidBrush(RGB(red,green,blue))

however IVF gives incompatible argument warning whereas.

hBkBrush = CreateSolidBrush(RGB(int1(red),int1(green),int1(blue))) seemingly be OK.

Conversely the statement;

hBkBrush = CreateSolidBrush(RGB(int1(255),int1(255),int1(255))) passes IVF but gives an overflow while evaluating expression in CVF.

2) Also in the following example:

type(T_POINT) :: pt

How do you specify MAKELPARAM(pt%x,pt%y) so that incompatible argument message does not appear?

I don't really mind the message, it's just that I want to program the code correctly to ensure the macros work.

3) I tried to utilise the MATHERRQQ to trap divide-by-zero type errors in my CVF program and redirect to prevent program crash. It never worked though. Any advice on the best method to capture math errorswould be welcome.

4) I have progressed as far as linking now but get an error saying that the file dfwin.lib cannot be found. I have not got this library in the project and it seems like a reference to the original CVF libraries that has been missed by the conversion.

Any suggestions?

Thanks again for your help.

Steve

[Steven_L_Intel1]

1) If you make red, green and blue PARAMETERs with the desired values, it will work without the INT1 and in both compilers. You are tripping over a bug in CVF in that it silently converted integer and real arguments when the explicit interface had a different KIND. IVF allows this as an extension only for constants (where it is safe).

2) MAKELPARAM(INT2(pt%x),INT2(pt%y))

3) In version 10.1, you'd need a C++ wrapper to do this effectively. Read the chapter on exception handling. In a future version, the Fortran 2003 IEEE floating point features will be available and you can use these without C++.

4) The conversion process does not try to remove explicitly specified libraries. You will need to find where this is specified in your project - probably in Linker > Input.

[dannycat]

Steve,

Thanks I've sorted out the most argument issues now, there is one more though:- What should BOOL arguments be defined as in FORTRAN. I've tried various integers and logicals but only explicit TRUE or FALSE seems to be acceptable. This example refers to the last argument in the MoveWindow function.

The linker command doesn't like the /FORCE specification (error LNK4075). I can't find any reference to DFWIN.LIB (error LNK1104). Is it worth cleaning out all projects and rebuilding.

Thanks again.

[Steven_L_Intel1]

The Windows BOOL type should be INTEGER(BOOL). If you want to pass true or false, use the constants TRUE and FALSE defined in the modules, NOT the Fortran LOGICAL values .TRUE. and .FALSE.

LNK4075 is a warning about one option being ignored because of another - perhaps /INCREMENTAL in your case. You can ignore it.

Feel free to recreate the project if you want. Look at the Linker > Command Line page to see if you can spot dfwin.lib. Or you may have an !DEC$ OBJCOMMENT directive in your source.

[dannycat]

Steve, I tried cleaning solution and doing a full rebuild but I stillget the link error 1104 'cannot open DFWIN.LIB'. I've searched all properties and can't find any reference to it at all. I also obtained a full listing of the link process to see if this would provide any clues, the only possiblity being /DEFAULTLIB:OLDNAMES (not sure what this relates to).

Dependencies listed are: kernel.lib user.lib winspool.lib comdlg.lib advapi.lib shell32.lib ole32.lib oleaut.lib uuid.lib odbc32.lib odbccp32.lib

and libc.lib is ignored.

I don't have the !DEC OBJCOMMENT anywhere in the source and dfwin.lib does not appear on the linker command line.

Have found another argument in the following function that produced a warning of a mismatch (MAKELANGID macro):

subroutine w32_checkerror

!**********************************************************
! Check for Windows W32 Error And Display Message
!**********************************************************

use dfwin, NULLPTR => NULL
use kernel32

implicit none

! Local Variables
character*255 :: string
integer :: nchar
nchar = FormatMessage_G1(FORMAT_MESSAGE_ALLOCATE_BUFFER.or. &
 FORMAT_MESSAGE_FROM_SYSTEM .or. &
 FORMAT_MESSAGE_IGNORE_INSERTS, &
 0, &
 GetLastError(), &
 MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT), & ! Default language
 string, &
 0, &
 0)

! Display the string.
if(nchar.gt.0) then
 call grp_message('Windows Error: '//trim(string))
endif

return
end subroutine

[anthonyrichards]

You include 'USE DFWIN' in the above code.

Module DFWIN includes a reference to module DFWBASE, as follows:

MODULE DFWIN
use advapi32
use comdlg32
use dfwbase
use gdi32
use kernel32
use lz32
use mpr
use shell32
use user32
use version
use winmm
use winspool
use wsock32
END MODULE DFWIN

Module DFWBASE contains the following

module dfwbase
use dfwinty
!DEC$OBJCOMMENT LIB:"DFWIN.LIB"
!******************************************************

could that be the source of your message?

[dannycat]

Hi Anthony,

Ialready triedchanging all referencesofdfwin to ifwin in the solution that I am trying to link. Besides I understand that there IVF has a module dfwin that is a wrapper for ifwin and so should not be an issue. The code listed in my previous post was from the original CVF version of the same project. I have not changed other df*** module use statements to if*** yet through.

[Steven_L_Intel1]

Danny, you are correct about the USE DFWIN not being a problem.

Have you turned on Fortran standards checking? I would not expect the MAKELANGID call to be an issue the way you have it.

Do you link with some other library? The f90sql library doesn't do this, I know. One thing you can do to diagnose this is to turn on the "verbose" output ("Display progress messages") from the Linker property, link the application, and look at the build log. It will show you its progress as it goes through objects and libraries and where it picks up default library directives.

[dannycat]

Steve,

Regarding the Fortran Standards checking I have not reset this settingas Ican't findwhere it is set.

On a positive note another hurdle has beennegotiated! The DFWIN.LIB problem was caused by an old module file that had not been rebuild using IVF.

I now have several hundred undefined symbols referring to mainly OpenGL and COM object calls to Excel and Word interfaces. I have explicitly loaded the F90GL.lib, F90glu.lib, f90glut.lib and glut32.lib into my solution. All symbols have preceding underscores, could it be something to do with the way it is calling C libraries.

[Steven_L_Intel1]

Are you using the IVF-built version of f90GL?

[dannycat]

Steve,

I obtained the IVF version from your post f90-1.2.12.zip. The mod, lib and dllfiles have been moved as per instructions given in the readme-Intal-IA32.txt file.

Example message is "error LNK2019: unresolved external symbol _OPENGL_FWRAP_mp_F9GLPUSHMATRIX@0 referenced in _GM_DRAWPOINT".

I'm have similar problems with COM calls e.g. "error unresolved external symbol __imp__WORD2000A_mp_RANGE_SETBOLD@12 referenced in function _WORDLIB_mp_WRD_SETBOOKMARKTEXT". My library is calledWordLib.lib and has been rebuilt in IVF. I have not regenerated the Word and Excel interfaces using the COM Module Wizard. I assumed that just rebuilding the source would suffice.

Regards

Steve (aka Danny)

[Steven_L_Intel1]

I can't look at this right now, but I would suggest you go into all your Fortran project properties, go to the External Procedures property page, and set Calling Convention to Default and String Length Argument passing to "inherit from project defaults"., then rebuild everything.

[dannycat]

Steve,

Thanks for your suggestion. I tried what you suggested and the unreferenced external for Opengl routines have gone, but the linker now is flagging up all C routines and still can't resolve the Word & Excel COM procedures. The SQL routines are also being flagged up as areFortran routines with explicit interfaces (containing a character string declaration).

In summary, my "Solution" consists of several C libraries, built separately, OpenGL, SQL, COM objects for Word and Excel and third party static libraries.

I very confused.

[Steven_L_Intel1]

I think we'd need to see the error messages. Perhaps your C libraries were built assuming CVF conventions?