Community
cancel
Showing results for 
Search instead for 
Did you mean: 
arney
Beginner
117 Views

IFDLG100.DLL: Porting 32-bit App to Win10

I'm up against a deadline to get a CVF application with ActiveX controls ported to IVF/Win10.  First off, I apologize, but I've read the topics regarding CVF porting/AvisGrid and registering IFDLG100.DLL, but just didn't seem to find a comprehensive solution. 

The application included the AvisGrid Grid Control. After deactivating the AvisGrid calls, I have successfully been able to port/build and fully execute the application on a WinXP using IVF12 and VS 2005, with no glitches.  All GUI screens work w AvisGrid deactivated portions just blank, which is what I was going for. However, when I built this on a new system with Composer XE 2016, VS Studio Pro 2015, and Win10, and try to execute, it bombs.

Investigations revealed issues with IFDLG100.DLL.  Initially, the program bombed because it could not find IFDLG100.DLL.  Even after following directions to register IFDLG100.DLL it is failing.  This is confusing when it works successfully on the IVF12/VS2005/WinXP.  For starters, I'm unsure how to properly register IFDLG100.DLL for Win10 for a 32-bit application.  I followed directions on how to register using regsvr32.  However, this step was not successful (i.e., it still was not finding IFDLG100.DLL when running the app).  

I then used regWow32 and the full path to 32-bit IFDLG100.DLL.  This is now causing an access violation error message that I was not getting before when it simply wasn't finding the DLL.

Not a high-end user, but appreciate prompt advice.  

 

 

0 Kudos
31 Replies
arney
Beginner
80 Views

Here's the error: "0xC000041D: An unhandled exception was encountered during a user callback."

Lorri_M_Intel
Employee
80 Views

I'm going to assume that you've got "/iface:cvf " in your project (since you're porting from CVF)

With that thought, please find your call back routines and make sure that they *explicitly* have "ATTRIBUTES DEFAULT".

In other words, if you've declared a dialog callback routine FOO, find the declaration of foo and add this:

subroutine foo (a, b, c)
!dec$ attributes default :: foo
   ...

              --Lorri

arney
Beginner
80 Views

Yes, the program was compiled using /iface:cvf.   Each call back routine does have !dec$ attributes, but not necessarily the "default" attribute in your example.  Some of the routines are actually 16-bit. 

I did experience one other oddity which may or may not be related.  For some reason, the program also bombs unless I explicitly include IFLOGM.F90, instead of just linking to the library.  The program will build successfully without IFLOGM.F90, but it bombs on the very first call to the dialogs.  With IFLOGM.F90 included, it doesn't bomb until the dialogs which had the Grid Control features commented out (Function DlgDoModal).  Function DlgDoModal is within IFLOGM.F90, which does have the "!DEC$ ATTRIBUTES DEFAULT :: DlgDoModal" statement.

Lorri_M_Intel
Employee
80 Views

Instead of including IFLOGM.F90, how about USE IFLOGM instead.   That will define all the interfaces for you.

I would check the callback routines for the dialogs which had the Grid Control features commented out.   Make sure they have DEFAULT attributes set.  It is not relevant that DlgDoModal is declared that way; the ATTRIBUTES DEFAULT on that declaration applies ONLY to that declaration.    It is true, however, that DlgDoModal assumes that everything it calls has been declared ATTRIBUTES DEFAULT -- it is up to you to make sure that everything it calls has been explicitly declared ATTRIBUTES DEFAULT (or the command line option /iface:cvf will prevail).

I'm not sure what you mean by 16-bit callback routines.  Do you mean old DOS routines?  Are those the ones being called here?

 

arney
Beginner
80 Views

Actually USE IFLOGM is used in the code everywhere.  However, for some reason, it would bomb unless I I explicitly included the code for the module itself in the solution (vs relying on the library being in the path).  

I will check on the attributes for the commented-out Grid Control routines (the "calls" are commented out, but I think the interfaces to some of the subroutines are still in the solution). Not sure why this would matter if they aren't being used.  

My remark to 16-bit is in reference to several windows handles are declared in the program.  Here's an example:

    Integer(4) Function  DbgFlagsProc( hWnd, mesg, wParam, lParam )
      !DEC$ ATTRIBUTES STDCALL, ALIAS : '_DbgFlagsProc@16' :: DbgFlagsProc

 

I just assumed by the alias that these were somehow 16-bit, but I inherited this code, so I can't tell you the purpose as to why it was done this way.  

 

IanH
Black Belt
80 Views

arney wrote:

My remark to 16-bit is in reference to several windows handles are declared in the program.  Here's an example:

    Integer(4) Function  DbgFlagsProc( hWnd, mesg, wParam, lParam )
      !DEC$ ATTRIBUTES STDCALL, ALIAS : '_DbgFlagsProc@16' :: DbgFlagsProc

 

I just assumed by the alias that these were somehow 16-bit, but I inherited this code, so I can't tell you the purpose as to why it was done this way.  

That's just a normal 32 bit STDCALL (the same convention as used by the 32 bit Windows operating system) calling convention procedure.  The @16 means that there are 16 bytes of arguments on the stack - 4 bytes (32 bits) for each argument listed.

andrew_4619
Valued Contributor III
80 Views

!DEC$ ATTRIBUTES STDCALL, DECORATE, ALIAS : 'DbgFlagsProc' :: DbgFlagsProc

Is better the appropriate "decoration" - underscores, @bytecount etc is added automatically and will work fro both 32 and 64 bit projects.

"The program will build successfully without IFLOGM.F90, but it bombs on the very first call to the dialogs. " This sounds like you have bugs that corrupt memory such that any random and unrelated code change will cause it to work or not work. All it means is the thing you corrupted was either more or less critical in that instance. Ensure you build with all the checking switch on, that will often expose many bugs.

 

arney
Beginner
80 Views

Thank you for the "DECORATE" hint to facilitate seamless 32/64-bit migration. At the moment, just want the app to build 32-bit.

As I stated, the program builds perfectly fine using IVF12/VS2005/WinXP.  No special tricks that I recall.  That said, the porting from CVF to IVF has been going on for nearly 10 years due to loss of Avis Grid Control w/ IVF. Maybe long ago I did have to manually register IFDLG100.DLL on WinXP system, but I don't recall doing that.  I do wonder why IFDLG100.DLL came up unregistered in a IVF16 clean install, and the quirkiness of IFLOGM.F90 (specifically including code in solution vs using the library).  As a bonus, specifically including and compiling IFLOGM.F90 has allowed me to capture where the program bombs (dlgmodal function call).  

Ultimately, IVF16 did not appear to find IFDLG100.DLL (said unregistered) until I specifically registered it with RegWow64 (not regwow32 as mentioned above); or, at the least gave me a different error message (access violation) than before.

andrew_4619
Valued Contributor III
80 Views

There are no  "special tricks" needed there is just a  question of things being correct .

Compling with  /iface:cvf  is not the way to do it unless you are including some third party libraries that require this call convention. If your callbacks are using this cvf convention for IFLOGM then the call interfaces are wrong and your program will not behave correctly. Lori pointed out that at #3 but you never confirmed that you had corrected that. 

Why not do a full build and post the buildlog? Post some bits of code showing the dialog initialisation and the callbacks and then maybe help can be given.

 

 

arney
Beginner
80 Views

sorry my responses have gone "stale" last couple of days.  I boneheadedly decided to uninstall VS Studio 2015 Professional.  I had in mind that this would get me back to a time before the registration of IFDLG100.DLL using RegWoW64 gave me access violations. I have no clue how to use regedit, and felt uncomfortable messing with that.  Anyways, horrors ensued with the uninstall. I ultimately had to wipe it, and reinstall.  I'm still not all the way back to where I was when VS 2015 Pro was up and running. 

Before all this happened, I did implement #3/Lorri's instructions in the Grid Control (i.e., DEFAULT added to all !DEC$ ATTRIBUTES calls in the Grid Control routines, but this had no effect (access violation still occurring).  

There are no 3rd-party libraries I'm linking to, that I'm aware of.  So not sure if /iface:cvf is needed or not.  Like I said, none of the compiler switches made a difference with IVF12/VS2005/WinXP.  

I hope to have more feedback tomorrow if VS 2015 Pro installation comes back ok.  

arney
Beginner
80 Views

Essentially, after finally getting VS Studio 2015 Pro reloaded, I'm back at square 1, which is the message: "The Dynamic link library (IFDLGnnn.DLL) is missing or not registered".  

I looked via regedit and see the IFDLG100.DLL is registered both in 32-bit and 64-bit shared library directories, and these also are in the path. So, I have no clue why it can't find it.  Re-registering seems counter-intuitive, and I don't want to do the "syswow64" registration again, as I know this just ended up giving an access violation.

I will revisit some coding/interface suggestions, but, as I stated, these were not an issue for the IVF12/VS2005/WInXP config.  No compiler switch differences; it built clean and runs clean, as opposed to the "IFDLGnnn.DLL missing" issues I'm encountering with IVF16/VS2015/Win10.

andrew_4619
Valued Contributor III
80 Views

I presume the DLL does actually exist on the system? On mine it is in:

C:\Program Files (x86)\IntelSWTools\compilers_and_libraries_2016.3.207\windows\redist\ia32_win\compiler

and 

C:\Program Files (x86)\Common Files\Intel\Shared Libraries\redist\ia32_win\compiler

and also the equivalent 64 bit folders.

arney
Beginner
80 Views

Yes, IFDLG100.DLL is on my system and in the path, for both 32-bit and 64-bit shareable libraries.  It also is in the specific compiler and libraries for each upgrade (i have both upgrades 2 and 3 loaded).  

andrew_4619
Valued Contributor III
80 Views

I would download and run "Dependency walker" on the exe to see result does it gives.

 

arney
Beginner
80 Views

I downloaded and ran depends.exe.  I've not used this tool before so I'm not really sure what to look for.  I have *.dwi output.  I also ran it on the WinXP which successfully executes.  

Error: At least one required implicit or forwarded dependency was not found.
Error: At least one module has an unresolved import due to a missing export function in an implicitly dependent module.
Error: Modules with different CPU types were found.

No errors on WinXP run.  Just 2 warnings.

I do not see IFDLG100.DLL in the *.dwi for either program version (winXP, win10).

 

Steven_L_Intel1
Employee
80 Views

I think IFDLG100 is dynamically loaded, so it won't show in Dependency Walker.

I have sometimes found it necessary to register both the 32-bit and 64-bit versions of this DLL. Once I do that the issue goes away.

regsvr32 "C:\Program Files (x86)\Common Files\Intel\Shared Libraries\redist\ia32_win\compiler\ifdlg100.dll"

regsvr32 "C:\Program Files (x86)\Common Files\Intel\Shared Libraries\redist\intel64_win\compiler\ifdlg100.dll"

arney
Beginner
80 Views

Steve,

An honor to hear from you, I've been following you and the boards for years.  I'm a Fortran dinosaur going way back to MS PowerStation, to when it was purchased by Digitial, then HP, now Intel.  

I've been stumped by what I've encountered with this migration to IVF16, mostly because I already got this to work with IVF12/VS2005/WinXP.  I don't know if this has any role in this issue at all, but the "problematic" Win10 system configuration originally had Windows 8.1, and it's an AMD chip, not Intel.  The "successful" port system has an intel processor on the IVF12/VS2005/WinXP.

The loss of the Grid Control from the Compaq Array Visualizer (CAV) has been the biggest hurdle to overcome in the migration. I have just commented out these previous calls.  As I mentioned, all works fine on a WinXP development machine I have with IVF12.  The other dialogs are working fine, but when I get to the dialogs that formerly used the Grid Control (again, now are commented out), I get the IFDLGnnn message.  Not sure if its an API windows handle thing or what.  

I'm debating doing a complete system reset on the Win10, as I have been also experiencing slow response times with VS 2015 Pro.  I originally had VS 2015 Community.  After all is cleaned up and stabilized I'll try the registration again. 

Steven_L_Intel1
Employee
80 Views

I note that on my system I have two copies of the redist DLLs for each architecture - one under ia32 (or intel64) and one under ia32_win (intel64_win). You'll want to make sure that whichever of these is in your PATH is the one you register. 

arney
Beginner
80 Views

Looks like both 32-bit and 64-bit are n the path.

PATH=
C:\Program Files (x86)\Common Files\Intel\Shared Libraries\redist\intel64_win\compiler;
C:\Program Files (x86)\Common Files\Intel\Shared Libraries\redist\ia32_win\compiler;
 
 Directory of C:\Program Files (x86)\Common Files\Intel\Shared Libraries\redist\ia32_win\compiler
 
04/16/2016  07:04 AM           308,424 ifdlg100.dll
               1 File(s)        308,424 bytes
 
 Directory of C:\Program Files (x86)\Common Files\Intel\Shared Libraries\redist\intel64_win\compiler
 
04/16/2016  06:00 AM           393,416 ifdlg100.dll
               1 File(s)        393,416 bytes