home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / os / mswindo / programm / misc / 4800 < prev    next >
Encoding:
Internet Message Format  |  1993-01-09  |  2.8 KB
  1. Xref: sparky comp.os.ms-windows.programmer.misc:4800 comp.lang.pascal:8002
  2. Newsgroups: comp.os.ms-windows.programmer.misc,comp.lang.pascal
  3. Path: sparky!uunet!munnari.oz.au!metro!usage!news
  4. From: troy@cbme.unsw.EDU.AU (Troy Rollo)
  5. Subject: Re: DLL Procedure/Function Calls ???
  6. Message-ID: <1993Jan8.201223.21740@usage.csd.unsw.OZ.AU>
  7. Sender: news@usage.csd.unsw.OZ.AU
  8. Nntp-Posting-Host: plod.cbme.unsw.edu.au
  9. Organization: University of New South Wales
  10. References: <VyT2wB4w165w@shakala.com>
  11. Date: Fri, 8 Jan 1993 20:12:23 GMT
  12. Lines: 41
  13.  
  14. From article <VyT2wB4w165w@shakala.com>, by donh@shakala.com (Don Hackler):
  15. > dmurdoch@mast.queensu.ca (Duncan Murdoch) writes:
  16. > 
  17. >> In article <1993Jan7.184304.3453@scf.loral.com> andres@scf16.scf.loral.com (J
  18. >> >        Windows, likewise vendors and programmers, often supply .DLLs
  19. >> >for use by others. Is there a convient way to find out what the calling
  20. >> >convention is to utilize the procedures/functions contained ?  Is there
  21. >> >a way to get like a "directory" listing of available calls ? 
  22. >> 
  23. >> There's a list of external entry points in the .DLL, but no information 
  24. >> there about calling conventions.  You could use a disassembler to try to 
  25. >> figure it out (e.g. my Dumpprog, on garbo.uwasa.fi as 
  26. >> /pc/turbopas/dmpprg20.zip) by looking at the code following the entry points,
  27. >> but it's not easy.  
  28. >> 
  29. > 
  30. > Or get Undocumented Windows by Andrew Shulman...  which
  31. > includes the utilities to dump the DLL entry points, and lots
  32. > of other good stuff...
  33.  
  34. This doesn't help in the case of 3rd party DLLs. For these, there are a few
  35. ways of finding the calling convention. The easiest is to assume the C calling
  36. convention, and no parameters for all exported functions of the DLL (which you
  37. have discovered by using IMPLIB or the MS equivalent). You then make calls to
  38. each of them from a WinMain in a dummy program, and run that program in your
  39. debugger. Before each call, note the value of the stack pointer, then step
  40. over the call. Compare the stack pointer after the call to that before the
  41. call. If they differ, the Pascal calling convention is being used. This is
  42. the case in about 90% of 3rd party DLLs, and has the advantage that the
  43. difference between the before and after stack pointers tells you how many
  44. bytes were expected as parameters.
  45.  
  46. Alternatively, you can trace one level into the DLL (you'll need to do so
  47. in "CPU" or assembly language level in the debugger, and look for the RET
  48. statement for the function. If it is a RET n, where n is a number, that
  49. call is a Pascal call with n bytes of parameters.
  50. --
  51. _______________________________________________________________________________
  52. troy@cbme.unsw.EDU.AU          Overworked, overcommited and always multitasking.
  53. Opinions expressed are not those of the CBME or UNSW, but are my opinions only.
  54. You are free to adopt them.   I suggest you adopt them.    You will adopt them!
  55.