X64 against WIN32

X64 against WIN32

John Nichols's picture

Dear All:

I recently got a new Dell computer, put Windows7 64 bit and the Intel Fortran Compiler 64 bit onto the machine, after I updated my licence. I did not mean to do it. This is the latest IVF that is not beta.

I had not used this flavour, its telling me the following error upon running a program that has complied nicely before.

Warning 3 warning #6075: The data type of the actual argument does not match the definition. [LPARAM] B:\\Users\\John\\Documents\\Visual Studio 2010\\Projects\\CX1Reader4\\CX1Reader4\\CX1Reader4_mod.f90 539

cxClient = loword(lParam)

cyClient = hiword(lParam)

it is upset at the loword being a DWORD and the lParam is a long_ptr.

Is there a difference from WIN32 to WIN64 for these two types? Is there a fix?

Thanks

JMN

12 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.
Paul Curtis's picture

Windows items need to be typed in a manner which automatically tracks 32- or 64-bits; these "universal" types are present in IFWINTY; here are the usual Windows proc arguments:

INTEGER(HANDLE),  INTENT(IN)   :: hwnd

INTEGER(UINT),    INTENT(IN)   :: msg

INTEGER(fWPARAM), INTENT(IN)   :: wParam

INTEGER(fLPARAM), INTENT(IN)   :: lParam

John Nichols's picture

Paul:

Thanks for the response.

I tried to download the 32 bit IVF, but we have had power outages all afternoon, but I just got it. I took off the X64 and loaded both back on. (Steve this is not beta, this is real Fortran)

Considering the various sources for this program , my own poor windows skills it is a wonder it runs at all, well actually it only runs because of much kind help here over the last few years.

It compiled and ran in 32 bit, so I need to go slowly through all of the calls and check the types against the IFWINTY module and the interfaces for the subroutines. It is not a trivial exercise, pretty much like writing it for the first time.

I am going to integrate the program into a 2012 SQL Server database using the German SQL Fortran routines, I am hoping they arrive tomorrow. Accountant type says they have paid for them, so fingers crossed. Out IT types do not like SQL Server.

Should be a lot of fun.

JMN

John Nichols's picture

Dear Steve:

It has taken a while to get a small windows program that runs nicely and will start me to do some real Fortran programming, whilst feelling slightly younger than a DEC 32 computer. I have it running under 32 bit as noted above, but there are a few quirky errors which I was wondering if you would look at in 64 bit compiler to tell me I am at least headed in the right and true path.

This program comes from many sources, including great help by Anthony Richards, Petzold's book, the great CVF book by Lawrence and yourself. I am not sure how many copyright owenreships I am breaching by putting the code here, but I am happy if anyone wants to try it, if there are errors please let me know.

PS: The code has source control embedded, just ignore it.
PS1:I chose the colour as tribute to Trapper John who wanted a Robin's egg blue convertible.

JMN

Attachments: 

AttachmentSize
Download InstronAnalysis.zip1.05 MB
Lorri Menard (Intel)'s picture

Hi John --

Steve is on a well-deserved vacation, so won't get back to you until he's back.

We'll have the "second-string" take a look at your program -- I did download it, and got one error building (and a handful of warnings). Is that what you saw too?

--Lorri

John Nichols's picture

Lorri:

It is ok, you are talking to a third string man, so you are still in front.

Yes, the warnings are interesting, but the error had me stuck.

As I liberated the code as I went I was hoping to put it back onto this site so other third stringers like me had a model that worked in IVF modern instead of CVF Olde Englishe for a simple Windows program that works in Fortran. It is not pretty, it could be turned into modules, but it doth worketh. Slowly like me.

thanks
JMN.

Annalee (Intel)'s picture

Hi John,

The error and warning are caused by using 4byte integers as pointers. In 32bit mode, pointers are 4bytes so this works, but in 64bit mode pointers are 8bytes.

You can work around the error by changing the lastargument passed to the functionDialogBoxParam on line 894 of InstronAnalysis_mod.f90. Instead of passing 0 for the pointer, pass "0_long_ptr" or "0_8"

I would suggest changing your code so that the pointer size is set automatically though.

Regards,
Annalee

John Nichols's picture

function HiWord (param)

import

integer(WORD) :: HiWord

!DEC$ ATTRIBUTES DEFAULT :: HiWord

!DEC$ IF DEFINED(_M_IX86)

!DEC$ ATTRIBUTES STDCALL, ALIAS : '_HiWord@4' :: HiWord

!DEC$ ELSE

!DEC$ ATTRIBUTES STDCALL, ALIAS :  'HiWord'   :: HiWord

!DEC$ ENDIF

integer(DWORD) param

end function HiWord

end interface

interface !lib=ifwin.lib

function LoWord (param)

import

integer(WORD) :: LoWord

!DEC$ ATTRIBUTES DEFAULT :: LoWord

!DEC$ IF DEFINED(_M_IX86)

!DEC$ ATTRIBUTES STDCALL, ALIAS : '_LoWord@4' :: LoWord

!DEC$ ELSE

!DEC$ ATTRIBUTES STDCALL, ALIAS :  'LoWord'   :: LoWord

!DEC$ ENDIF

integer(DWORD) param

end function LoWord

end interface

John Nichols's picture

Dear Annalee:

I am not the world's best on pointers and such, but for the warning the LOWORD macro is defined with DWORD and LONG_PTR, in IFWINTY, LONG_PTR is variable but DWORD is fixed at 4. So it works at 32 but gives warning at 64, whereas there is a DWORDLONG, so why not use it?

Or am I completly lost?

JMN

Repeat Offender's picture

I looked at InstronAnalysis_mod.f90 and concluded it would be a long hard slog.I only got through a few hundred lines and found a few things that look like errors.

InstronAnalysis_mod.f90

109: !integer*4 ret

139: integer(HANDLE) hbrush

163ff:     lpszClassName   =   "InstronAnalysis"//ACHAR(0)

197ff:        brush%lbStyle = BS_SOLID

420: integer(LONG) iSBheight

421: integer cxWidth, iStep, i ! A guess


Just about any specification statement in a Windows program that writes out the number of bytes of an integer kind as an integer literal is suspect. Line 109 seems superfluous because ret is declared but never used. Perhaps you can get ifort to warn you about this? Line 139 is fatal because CreateBrushIndirect (just look up CreateBrushIndirect MSDN) returns an HBRUSH, which (look up Windows data types MSDN) is a HANDLE and so will be promoted on translation to x64. Lines 163 ff. are a needless DVF extension, as are lines 197 ff. which will cause problems if you try to catch errors en masse by requesting standards checking. There was no good reason to specify integer(2) in lines 420-421, and I ran out of energy there.

The Lawrence book is the best place to start Windows Fortran programming, but it was written before MicroSoft introduced 64-bit Windows and is not at all 64-bit safe. The only thing I know to do is to examine each INTEGER declaration with literal KIND number (e.g. INTEGER(4) x instead of INTEGER(HANDLE) x) and check the usage of the variable in question via MSDN and replace the literal with the appropriate name as illustrated in the above paragraph. The book's web site has the examples in the book and more; it would be nice if someone could update those examples to be 64-bit safe and fix errors and unnecessary extensions.

John Nichols's picture

Dear Repeat Offender:

Thank you for the comments. This is probably the most useful set from the Lawrence book, I am happy to fix it, just need to learn the X64 pointer stuff. Actually hating pointers does not help, but I will try.

Yes I know it is a long slog, it was a long slog to get this working in 32 as I had to learn Windows and C, whilst going deeply into the Fortran include files, and it was a long slog to get a Windows Driver to compile in Visual Studio 2010 instead of the WDK compilers, so now I can attach blinking lights to my programs to tell me there are high pressures in a system without having to look at the data.

I created a searchable PDF of all of the Fortran include files so I could get this working in 32 and then lost it. Looks like I am doing it again.

Thanks again.

JMN

Lorri Menard (Intel)'s picture

The warnings are all over the place, and I saw lots of good suggestions about how to fix them.

But, the error, the actual "sticking point" is in your file instronAnalysis_mod.f90, line 894.

The code is:

ret = DialogBoxParam(ghInstance,LOC(lpszName),hWnd, LOC(Dialog1), 0)

but should be

ret = DialogBoxParam(ghInstance,LOC(lpszName),hWnd, LOC(Dialog1), 0_LONG_PTR)

(Note: you have it specified that way in your other call to DialogBoxParam, around line 972)

--Lorri

Login to leave a comment.