Intel Fortran Module Wizard and 64-bit

[thomas_boehme]

In one of our codes, we use the Intel Fortran Module Wizard to generate an interface module to call msxml6.dll via COM. With some manual fixing of the generated interface code, this works quite well as long as we compile for Win32 (see post http://software.intel.com/en-us/forums/showthread.php?t=70220 for details).

When I tried to port our code to 64-bit, I could not generate an interface module for the 64-bit version of the msxml6.dll via the Intel Fortran Module Wizard.

There doesn't seem to be a choice whether to generate the interface module for 64-bit or the 32-bit version. If I select the msxml6.dll from c:\\windows\\system32\\msxml6.dll (which should be the 64-bit version), the generated code seems to be for the 32-bit version, as the offset pointers have a spacing of 4, and I would expect a spacing of 8 for 64-bit dlls.

Using the generated interface in the code leads to a crash as soon as I call anything using that interface module.

Did anybody successfully use the Intel Fortran Module Wizard for 64-bit or is that not supported at the moment?

regards,
Thomas

[Steven_L_Intel1]

It's supported, but the wizard just delivers what the DLL tells it to. Which particular "offset pointer" items are you referring to? Do you know for certain that these should be 64-bits? They may not. The module does use address-size integers for handles, etc.

I found some MS documentation on MSXML and the offsets are shown as "long". I would not expect these to change size for x64.

[thomas_boehme]

Hi Steve,

I do not know for certain that the dll is really 64-bit, but I strongly believe it is, because it's the version coming with Windows 7 64-bit.

I am using the IVF Module Wizard on a 64-bit Win 7 install and I am pointing it towards the msxml6.dll located in c:\windows\system32.

However, I see one possible issue. If a 32-bit program looks into c:\windows\system32, I think it actually gets redirected to c:\windows\SysWOW64 which, inspite of the name, actually shouldcontain the 32-bit versions of the files. So I guess that's what might happen with the module wizard.

To prevent this, I did try to copy the msxml6.dll file using the 64-bit explorer to a different folder, but that didn't help.

The offsets I am talking about are the offset used for determining the $VPTR in the generated interface module. Typically $VPTR is calculated from $VTBL and an offset. I believe these offsets should be seperated by 8 for 64-bit, as they are most likely pointers. However, I see routines at $VTBL+12, $VTBL+16, $VTBL+20, $VTBL+24 and so on.

Do you have any hints on how I might be able to find out if the msxml6.dll I have is really 64-bit and to make sure the IVF module wizard actually does use the same and does not get redirected to the 32-bit version?

Best regards,
Thomas

[Steven_L_Intel1 · Accepted solution]

Please forgive me, this COM stuff is not a strength of mine.

The DLL is indeed x64 - Dependency Walker (the x64 version) will tell you this.

I now see what you're referring to - but this happens only if you don't check the "Use Automation interfaces" box, which I usually do check. I don't really understand what is going on with the non-automation code and will ask the developers. Can you use the Automation version?

It isn't a matter of redirection, as far as I can tell.

Try editing the generated source, changing lines such as:

$VPTR = $VTBL + 36

to

$VPTR = $VTBL + (9 * SIZEOF($VTBL))

and see if that solves the problem for you.

[thomas_boehme]

Hi Steve,

thanks a lot for your answer. The COM stuff is not really a strength of mine either, especially in combination with FORTRAN, as there seems to be very little documentation.

I did never try automation interfaces, but I read somewhere that they are slower than COM, so I'd prefer COM interfaces. Also, I would have to rewrite my interface API to use the automation procedures, as the names seem to be diffferent.

I followed your advice and changed the offsets for some of the routines, and yes, that does seem to do the trick. I would be nice if that could be fixed at some time in the future.

regards,
Thomas

[Steven_L_Intel1]

I have filed a bug report on this issue.

[Steven_L_Intel1]

Thomas,

Would you be able to attach a small (if possible) test case that demonstrates the run-time error? Thanks.

[netphilou31]

Hi Steve, I am trying to perform the same task as Thomas with Intel(R) Visual Fortran Compiler XE on Intel(R) 64, version 12.1.1 (Package ID: w_fcompxe_2011.7.258) and I can see that the problem as not been fixed yet. With the growth of 64-bit platforms and software, it would be a very good idea to update the wizard with the so small modification that you have proposed. Have you some news on this to share with us ? Best regards, Phil.

[thomas_boehme]

Hi Phil, Are you sure that this is not fixed? At least in Visual Fortran 2013 it seems to be fine now. When I use the module wizard, I get offsets in the form of $VPTR = $VTBL + 34 * INT_PTR_KIND() ! Add routine table offset The use of INT_PTR_KIND() instead of the fixed offset that it used to be should make it work for x64 systems. I have not really tried that anymore, but it looks fine to me. Also, I don't remember whether this has been introduced before or is new with the 2013 release. Best regards, Thomas

[netphilou31]

Hi Thomas, I did not try this version. I am currently using version : 2011.7.258 and I have also tried with one of the latest : 2011.12.369 and they don't give the correct results for 64-bit dlls. In the meantime I have written a small tool that reads the generated f90 file and converts the corresponding lines. I hope to work soon with the 2013 version ! Best regards, Phil.

[Steven_L_Intel1]

This bug was indeed fixed in the Composer XE 2013 release.