Szakáts Viktor wrote:
I'll check what it takes (like dependencies)
to port dllcall.c to Harbour.
I would appreciate this. I use it and have simply copied it across
from xHarbour.
I made some changes to support strings with embedded nulls and
committed it to xHarbour CVS. However, Peter Rees pointed out that it
would be preferable to use hb_xgrab,hb_xfree rather than malloc, free.
I made the changes on my local copy but never committed them. Perhaps
you could do it.
Note also that there is no .PRG level interface to specify return
types as far as I can see. I have a horrible kludge called CALLDLLBOOL
which specifies return type as CTYPE_BOOL. (I added HB_FUNC( CALLDLL )
as there was no interface when you had a pointer to the function
already and did not wish to load the dll and get the function pointer
for each call).
The current version on CVS has this signature for DllExec:
static void DllExec( int iFlags, LPVOID lpFunction, int iParams, int
iFirst, int iArgCnt, PEXECSTRUCT xec )
The one I use has:
static void DllExec( int iFlags, int iRtype, LPVOID lpFunction, int
iParams, int iFirst, int iArgCnt, PEXECSTRUCT xec )
Someone now assumes that iRtype data can be extracted from iFlags but
looking at the DC_* defines and the CTYPE_* defines I don't see how
this could be ( I could *easily* be wrong).
There is also a line:
iRtype = iFlags & 0x0f00; // Return type - An additional flag over
XBase++
which I commented out, it makes no sense to me.
Finally, when I moved to Harbour, I did comment out the structure
support so I assume that I had a compiling/linking problem there, but
I made no notes.
Regards
Alex
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
