🚀 go-pugleaf

From article <VyT2wB4w165w@shakala.com>, by donh@shakala.com (Don Hackler):
> dmurdoch@mast.queensu.ca (Duncan Murdoch) writes:
> 
>> In article <1993Jan7.184304.3453@scf.loral.com> andres@scf16.scf.loral.com (J
>> >        Windows, likewise vendors and programmers, often supply .DLLs
>> >for use by others. Is there a convient way to find out what the calling
>> >convention is to utilize the procedures/functions contained ?  Is there
>> >a way to get like a "directory" listing of available calls ? 
>> 
>> There's a list of external entry points in the .DLL, but no information 
>> there about calling conventions.  You could use a disassembler to try to 
>> figure it out (e.g. my Dumpprog, on garbo.uwasa.fi as 
>> /pc/turbopas/dmpprg20.zip) by looking at the code following the entry points,
>> but it's not easy.  
>> 
> 
> Or get Undocumented Windows by Andrew Shulman...  which
> includes the utilities to dump the DLL entry points, and lots
> of other good stuff...

This doesn't help in the case of 3rd party DLLs. For these, there are a few
ways of finding the calling convention. The easiest is to assume the C calling
convention, and no parameters for all exported functions of the DLL (which you
have discovered by using IMPLIB or the MS equivalent). You then make calls to
each of them from a WinMain in a dummy program, and run that program in your
debugger. Before each call, note the value of the stack pointer, then step
over the call. Compare the stack pointer after the call to that before the
call. If they differ, the Pascal calling convention is being used. This is
the case in about 90% of 3rd party DLLs, and has the advantage that the
difference between the before and after stack pointers tells you how many
bytes were expected as parameters.

Alternatively, you can trace one level into the DLL (you'll need to do so
in "CPU" or assembly language level in the debugger, and look for the RET
statement for the function. If it is a RET n, where n is a number, that
call is a Pascal call with n bytes of parameters.
--
_______________________________________________________________________________
troy@cbme.unsw.EDU.AU	      Overworked, overcommited and always multitasking.
Opinions expressed are not those of the CBME or UNSW, but are my opinions only.
You are free to adopt them.   I suggest you adopt them.    You will adopt them!