home *** CD-ROM | disk | FTP | other *** search
/ OS/2 Shareware BBS: 11 Util / 11-Util.zip / WHATFN.ZIP / WHATFUNC.DOC < prev    next >
Text File  |  1989-01-22  |  5KB  |  128 lines
  1. ***** WHATFUNC.EXE *****
  2.  
  3.     WHATFUNC is a utility for OS/2 programmers.  Given one or more
  4. hexadecimal function addresses on the command line, it will attempt to
  5. provide the ASCIIZ name for each function.
  6.  
  7.     Often when debugging code in CodeView (CVP), you are faced with
  8. raw unassembled code like:
  9.  
  10.         CALL 01B7:0C7C
  11.  
  12. Like, how are you supposed to know this is a call to VioGetMode?
  13. CodeView may be called a symbolic debugger, but apparently that
  14. doesn't extend to the symbolic names of dynamically-linked functions
  15. even though, as WHATFUNC demonstrates, these names are readily
  16. available under OS/2.
  17.  
  18.     Even when you are debugging your own program, for which you
  19. presumably have the source code, often the routines you call in turn
  20. make calls to functions in DLL's.  For instance, you're tracing
  21. through fopen(), and you see
  22.  
  23.         CALL 10AB:0000
  24.  
  25. How are you supposed to know this is a call to DosQHandType?
  26.  
  27.     WHATFUNC.EXE, that's how.  From the CVP command-line, you could
  28. type:
  29.  
  30.         > ! whatfunc 01b7:0c7c 10ab
  31.  
  32. and WHATFUNC.EXE (which you might rename WF.EXE to save typing) will
  33. reply:
  34.  
  35.         01B7:0C7C   VIOGETMODE
  36.         10AB:0000   DOSQHANDTYPE
  37.  
  38.     WHATFUNC doesn't have to be run from the CVP command-line, of
  39. course.  It can of course be run from"straight" CMD.EXE.  It is known
  40. to run within an Epsilon process buffer.  It's been linked with the
  41. WINDOWCOMPAT statement, so it should run in a PM window.
  42.  
  43.     In the example above, note that if the offset of the function 
  44. you're looking for is zero, then you can just type the selector (which
  45. is probably a DOSCALLS call gate).
  46.  
  47.     Wait a minute!  You're in one process, you have a function pointer
  48. like 01B7:0C7C, and you expect WHATFUNC.EXE, which is running in an
  49. entirely separate process, to also know about 01B7:0C7C?  This works
  50. because OS/2 maps dynamic-link routines into the same selectors for
  51. each process.  (This isn't a very good explanation, but it'll have to
  52. do for now.  For further details, read Gordon Letwin's book INSIDE OS/2.)
  53.  
  54.     
  55.     Theory of Operation
  56.     -------------------
  57.  
  58.     WHATFUNC.C is just a rehash of some code I'd already written in
  59. ENUMDLL.LSP and ENUMPROC.C.  The way WHATFUNC tries to match an ASCIIZ
  60. string against an address is:
  61.  
  62.         for each module in system (ENUMDLL)
  63.             for each function in module (ENUMPROC)
  64.                 does procaddr(function) == procaddr we're looking for?
  65.  
  66.     We can rely on the OS/2 function DosGetModName to provide us with
  67. the ASCIIZ names of all DLL's currently loaded.  We then open each of
  68. these files and read through its name table.  For each ASCIIZ
  69. function name we find in the DLL, we call DosGetProcAddr.  If the
  70. resulting function pointer is equal to the one we're looking for, we're
  71. done.
  72.  
  73.     Notice how OS/2 makes it easy to do this sort of thing, since
  74. practically everything in OS/2 has an ASCIIZ name attached to it: a
  75. very powerful concept.
  76.  
  77.     Unfortunately, there's one special case: the OS/2 kernel, whose
  78. exported functions masquerade under the name DOSCALLS.DLL. This isn't
  79. really a DLL, and the ASCIIZ names for its functions are not
  80. available through normal OS/2 channels.  For this reason, the names
  81. of all DOSCALLS routines through version 1.1 are hard-wired into
  82. WHATFUNC.C.  Yuk!
  83.  
  84.     Speaking of special cases, before entering the ENUMDLL loop, we
  85. first check the most common cases: DOSCALLS, VIOCALLS, KBDCALLS, and
  86. MOUCALLS.
  87.  
  88.     WHATFUNC.EXE has one command-line option: the -v verbose switch.
  89. This will print out the mod.func names (e.g., VIOCALLS.VIOGETMODE)
  90. and addresses of all functions found until WHATFUNC succeeds. Therefore,
  91. passing WHATFUNC a bogus address:
  92.  
  93.         C>whatfunc -v 1
  94.  
  95. will print out _all_ DLL routines currently loaded in your system.
  96. This is either exciting or incredibly stupid, depending on how you
  97. look at it.
  98.  
  99.     A few things remain to be done with WHATFUNC:
  100.  
  101.     Because ploughing through each DLL is kinda slow, WHATFUNC ought
  102. to maintain some kind of in-memory tables when there is more than one
  103. command-line argument, and/or it ought to launch a separate thread for
  104. each command-line argument.  Separate threads seems like a good idea:
  105. assuming each thread proceeds through each DLL at more or less the same
  106. rate, each thread should find that the file blocks it's looking for
  107. are already in memory.
  108.  
  109.     Secondly, WHATFUNC ought to be rewritten as a monitor (an OS/2
  110. "TSR").  In that case, there would be a great benefit to maintaining
  111. in-memory symbol tables for each DLL.
  112.  
  113.     Please feel free to send comments, criticisms, or suggestions.
  114.  
  115.                                         -- Andrew Schulman
  116.                                            32 Andrews St. #2
  117.                                            Cambridge MA 02139
  118.                                            (617) 876-2102 (h)
  119.                                            (617) 577-8500 x7148 (w)
  120.                                            CIS 76320,302
  121.                                            
  122.                                            14 January 1989
  123.  
  124.  
  125. p.s.  Thanks for Charles Petzold for finding a bug in enumproc() (22jan89).
  126.  
  127.  
  128.