home *** CD-ROM | disk | FTP | other *** search
/ Tricks of the Windows Gam…ming Gurus (2nd Edition) / Disc2.iso / msdn_vcb / samples / vc98 / sdk / sdktools / winnt / dbmon / readme.txt < prev   
Text File  |  1994-10-07  |  2KB  |  42 lines
  1. DBMON notes
  2.  
  3. 10/7/94
  4.  
  5.  
  6. The first DWORD of the shared memory buffer contains the process ID of the
  7. client that sent the debug string.  DBMON will print the process ID if the
  8. previous line printed was from another process, or if the previous line was
  9. from the same process and ended in a newline.
  10.  
  11. The shared memory buffer must be 4096 bytes.  If it is larger, it won't do any
  12. good.  If it is smaller, nothing terrible will happen, but strings larger than
  13. the buffer will not be delivered, and a complaining message will be sent to the
  14. kernel debugger by the client.  Why is it this size?  Because shared memory
  15. comes in page-sized chunks, so we might as well ask for as much as will be used
  16. on the machines with the smallest pages.  On machines with larger pages, the
  17. remainder of the page will be wasted anyway.
  18.  
  19. Event DBWIN_BUFFER_READY must be an auto-reset event, so that only one client
  20. thread will use the buffer at a time.  Using a manual reset event with
  21. PulseEvent will not work.
  22.  
  23. Event DBWIN_DATA_READY need not be auto-reset, but it is simpler that way.
  24.  
  25. Allowing multiple copies of DBMON to run might be amusing, put not particularly
  26. useful.  As I originally wrote it, the messages were distributed randomly among
  27. the DBMON instances or be garbled.  I added a check for ERROR_ALREADY_EXISTS so
  28. it won't run twice.  The worst you can do to the client is cause it to print a
  29. message on the kernel debugger, as above.
  30.  
  31. If DBMON is broken and never calls SetEvent(AckEvent), it will cause a 10
  32. second delay in the client every time OutputDebugString is called, then the
  33. message will be printed on the kernel debugger.
  34.  
  35. OutputDebugString will force synchronization of client threads when DBMON is
  36. running.  Letting the kernel debugger catch the strings will also synchronize
  37. threads, but the timing effects may be different.  Caveat emptor.
  38.  
  39. In a GUI version of DBMON, use MsgWaitForMultipleObjects.
  40.  
  41.  
  42.