FWH 10.1 - DLL32 Function

[Enrico Maria Giordano]

Did you try to load/unload the dll for each call?

EMG

[don lowenstein]

Yes.

1st all DLL functions were constructed with the DLL handle value.
These constructs do not load/unload the library and I was required to do it at the beginning and FreeLibrary( ndll ) at the end.

Then, I changed the construct to use the DLL name, which forces the load/unload each time.

Code: Select all  Expand view

DLL STATIC FUNCTION I2PDF_GetDLLVersion( ) AS LONG;
    FROM "I2PDF_GetDLLVersion" LIB "F:\UTILITY\IMAGE2PDF.DLL"
 

this, obviously, took much longer to run, but, the results were identical.

I'm leaning towards the issue might possibly be within the CallDLL( ) function within FWH. I haven't tried the xHarbour DLLCall function yet. I'm hoping to get this resolved within the FWH world as I have many applications calling these types of DLL's and preservation of existing code would be nice.

[don lowenstein]

More Information

I instructed the DLL to output messages to the console.

It appears that the process was completed by the DLL and the GPF occurs upon the RETURN of control from the DLL back to the CallDLL( ) function.

retval := I2PDF_AddImage(alltrim( infile ) ) // processed ok
retval := I2PDF_MakePDF( outfile, 0, @cBuffer , 300 ) // processed ok - created the .PDF file, but control never returned back to my program.

Here is what was on the screen (also, the pdf file was successfully created!)

* Application successfully built *
15:56:37 Creating PDF structure in memory
15:56:37 0001: [testreport.emf]
15:56:37 Saving PDF (1 pages) to [DEBUG-report.pdf]
15:56:37 Save complete

T:\FWH10\samples>

The GPF occured AFTER the "Save complete" message appeared on the console screen - thus, I believe the commands are being processed to completion by the DLL but control is not being returned back to my program from the CallDLL() function.

I processed the DLL function "manually" with the following code and it had a GPF during the CallDLL() function call:

Code: Select all  Expand view

CALLPROC := "I2PDF_MakePDF"
PARM1 := outfile              // output file
PARM2 := 0                    // options
PARM3 := SPACE( BUFFER_SIZE ) // CBUFFER
PARM4 := buffer_size          // MAXTEXTERROR SIZE
RETURN_TYPE := LONG
CFARPROC := GetProcAdd(NDLL,CALLPROC, PASCAL_TYPE, RETURN_TYPE,  ;
                LPSTR, LONG, LPSTR, LONG  )
RETVAL := calldll( CFARPROC, PARM1, PARM2, @PARM3, PARM4 )
 

[Antonio Linares]

Don,

The licence function is pascal for sure:

Code: Select all  Expand view

#include "FiveWin.ch"

function Main()
   I2PDF_License( "Hello world" )
   MsgInfo( "ok" )
return nil

DLL STATIC FUNCTION I2PDF_License( cLicCode AS LPSTR) AS VOID PASCAL ;
FROM "I2PDF_License" LIB "Image2PDF.dll"
 

If you remove pascal from it, then it will GPF. Pascal means that the called function balances the calling C stack itself.

[Antonio Linares]

Don,

This code is working fine here. Please notice that the shown version is 252. Could it be that you are using a wrong DLL ?

Code: Select all  Expand view

#include "FiveWin.ch"

static hLIB

function Main()

   hLIB := LoadLibrary( "Image2PDF.dll" )

   I2PDF_License( "Hello world" )
   I2PDF_SetDPI( 123 )
   MsgInfo( I2PDF_GetDLLVersion() )
   MsgInfo( "ok" )
   
   FreeLibrary( hLIB )
   
return nil


DLL STATIC FUNCTION I2PDF_License( cLicCode AS LPSTR ) AS VOID PASCAL ;
FROM "I2PDF_License" LIB hLIB

DLL STATIC FUNCTION I2PDF_SetDPI( nDpi AS LONG ) AS LONG ;
   PASCAL FROM "I2PDF_SetDPI" LIB hLIB
   
DLL STATIC FUNCTION I2PDF_GetDLLVersion( ) AS LONG;
   PASCAL FROM "I2PDF_GetDLLVersion" LIB hLib  
 

[don lowenstein]

I'm also using version 252. The DLL is dated
04/11/2009 11:17 PM 1,003,520 Image2PDF.dll

I get the exact same results with an older version 240 which has worked perfectly for us in the past.
05/15/2008 10:20 PM 865,792 Image2PDF.dll

I tried your code snippet and it GPF's here. I put the debugger in the program and it behaved exactly the same as I described in a prior posting.

Can you show me the compile and link scripts you used? Maybe I'm not using correct libraries or compile switches?

[Antonio Linares]

Don,

I tested it using Harbour and Borland C. Used standard FWH samples buildh.bat

Are you using Harbour or xHarbour ?

[don lowenstein]

I used xHarbour and Harbour with the buildx.bat and buildh.bat supplied with FiveWin

both got gpf.

here is the Harbour link script from b32.bc using Harbour 2.0 shipped with FWH

c:\borland\bcc55\lib\c0w32.obj +
dllpdf.obj, +
dllpdf.exe, +
dllpdf.map, +
.\..\lib\FiveH.lib .\..\lib\FiveHC.lib +
t:\harb20\lib\win\bcc\hbrtl.lib +
t:\harb20\lib\win\bcc\hbvm.lib +
t:\harb20\lib\win\bcc\gtgui.lib +
t:\harb20\lib\win\bcc\hblang.lib +
t:\harb20\lib\win\bcc\hbmacro.lib +
t:\harb20\lib\win\bcc\hbrdd.lib +
t:\harb20\lib\win\bcc\rddntx.lib +
t:\harb20\lib\win\bcc\rddcdx.lib +
t:\harb20\lib\win\bcc\rddfpt.lib +
t:\harb20\lib\win\bcc\hbsix.lib +
t:\harb20\lib\win\bcc\hbdebug.lib +
t:\harb20\lib\win\bcc\hbcommon.lib +
t:\harb20\lib\win\bcc\hbpp.lib +
t:\harb20\lib\win\bcc\hbcpage.lib +
t:\harb20\lib\win\bcc\hbwin.lib +
t:\harb20\lib\win\bcc\hbcplr.lib +
c:\borland\bcc55\lib\cw32.lib +
c:\borland\bcc55\lib\uuid.lib +
c:\borland\bcc55\lib\import32.lib +
c:\borland\bcc55\lib\psdk\odbc32.lib +
c:\borland\bcc55\lib\psdk\nddeapi.lib +
c:\borland\bcc55\lib\psdk\iphlpapi.lib +
c:\borland\bcc55\lib\psdk\msimg32.lib +
c:\borland\bcc55\lib\psdk\rasapi32.lib,
dllpdf.res

here is link script using xHarbour 1.2 shipped with FWH

C:\Borland\BCC55\lib\c0w32.obj +
dllpdf.obj, +
dllpdf.exe, +
dllpdf.map, +
.\..\lib\Fivehx.lib .\..\lib\FiveHC.lib +
T:\XHARB12\lib\rtl.lib +
T:\XHARB12\lib\vm.lib +
T:\XHARB12\lib\gtgui.lib +
T:\XHARB12\lib\lang.lib +
T:\XHARB12\lib\macro.lib +
T:\XHARB12\lib\rdd.lib +
T:\XHARB12\lib\dbfntx.lib +
T:\XHARB12\lib\dbfcdx.lib +
T:\XHARB12\lib\dbffpt.lib +
T:\XHARB12\lib\hbsix.lib +
T:\XHARB12\lib\debug.lib +
T:\XHARB12\lib\common.lib +
T:\XHARB12\lib\pp.lib +
T:\XHARB12\lib\pcrepos.lib +
C:\Borland\BCC55\lib\cw32.lib +
C:\Borland\BCC55\lib\import32.lib +
C:\Borland\BCC55\lib\uuid.lib +
C:\Borland\BCC55\lib\psdk\odbc32.lib +
C:\Borland\BCC55\lib\psdk\rasapi32.lib +
C:\Borland\BCC55\lib\psdk\nddeapi.lib +
C:\Borland\BCC55\lib\psdk\msimg32.lib +
C:\Borland\BCC55\lib\psdk\iphlpapi.lib,
dllpdf.res

[Antonio Linares]

Don,

Please download my test files and run them in your computer, thanks
http://www.mediafire.com/?zjmntm3rk2n

[don lowenstein]

your test.exe file works fine here.

I recompiled with my version of buildx.bat and buildh.bat and both created GPF's.

can you show me the b32.bc output you used from both the compile and link step?

[Antonio Linares]

Don,

c:\bcc55\lib\c0w32.obj +
C:\test.obj, +
C:\test.exe, +
C:\test.map, +
c:\fwh\lib\FiveH.lib c:\fwh\lib\FiveHC.lib +
c:\harbour\lib\hbrtl.lib +
c:\harbour\lib\hbvm.lib +
c:\harbour\lib\gtgui.lib +
c:\harbour\lib\hblang.lib +
c:\harbour\lib\hbmacro.lib +
c:\harbour\lib\hbrdd.lib +
c:\harbour\lib\rddntx.lib +
c:\harbour\lib\rddcdx.lib +
c:\harbour\lib\rddfpt.lib +
c:\harbour\lib\hbsix.lib +
c:\harbour\lib\hbdebug.lib +
c:\harbour\lib\hbcommon.lib +
c:\harbour\lib\hbpp.lib +
c:\harbour\lib\hbcpage.lib +
c:\harbour\lib\hbwin.lib +
c:\harbour\lib\hbcplr.lib +
c:\harbour\lib\hbct.lib +
c:\harbour\lib\xhb.lib +
c:\bcc55\lib\cw32.lib +
c:\bcc55\lib\uuid.lib +
c:\bcc55\lib\import32.lib +
c:\bcc55\lib\psdk\odbc32.lib +
c:\bcc55\lib\psdk\nddeapi.lib +
c:\bcc55\lib\psdk\iphlpapi.lib +
c:\bcc55\lib\psdk\msimg32.lib +
c:\bcc55\lib\psdk\rasapi32.lib,

I email you a copy of FiveH.lib and FiveHC.lib

[don lowenstein]

I noticed that xHarbour also has a function named CallDLL().

Is it possible my environment is mistakenly calling the xHarbour CallDLL() version and the parm passing convention is different.

does your CallDLL and xHarbour CallDLL maybe get mixed up in my environment?

[don lowenstein]

I used the xHarbour and Harbour DLLCALL() FUNCTION and it seems to work fine.

I suspect the problem is within CALLDLL() function - perhaps I'm invoking the harbour CallDLL() and not the FWH CallDLL() ???


This Works

Code: Select all  Expand view

#include "FiveWin.ch"

#define DC_CALL_STD            0x0020

static hLIB

function Main()
local retval

   hLIB := LoadLibrary( "Image2PDF.dll" )

retval := dllcall( hlib, DC_CALL_STD, "I2PDF_License", "Hello World" )
msginfo( retval, 'retval1-license' )
retval := dllcall( hlib, DC_CALL_STD, "I2PDF_SetDPI", 1 )
msginfo( retval, 'retval2-setdpi' )
retval := dllcall( hlib, DC_CALL_STD, "I2PDF_GetDLLVersion" )
msginfo( retval, 'retval3-version' )


   FreeLibrary( hLIB )


return nil


 

[Antonio Linares]

Don,

In the libs that I have sent you CallDll() has been renamed to FWCallDll() to avoid conflicts with Harbour/xHarbour.

Simply call FWCallDll() from your code or modify DLL.ch to call FWCallDll(), thanks

[vilian]

Don,

I use Image2PDF with xHarbour.

One thing I noticed is that you renamed the dll to Image2PD.dllF and this generates a lot of problems.

Make the call and keep the dll with its default name - Image2PDF StdCall.dll.