home *** CD-ROM | disk | FTP | other *** search
/ OS/2 Shareware BBS: 10 Tools / 10-Tools.zip / proc.zip / proc.doc < prev    next >
Text File  |  1994-08-13  |  4KB  |  135 lines
  1. Some information about the DosQProcStatus() under OS/2 1.x
  2.  
  3. Kai Uwe Rommel, rommel@lan.informatik.tu-muenchen.dbp.de
  4. 08/19/90
  5.  
  6. This is a message which I found in some PD software from
  7. listserv@blekul11.bitnet:
  8.  
  9. Date:  10-19-89  00:29
  10. From:  Franz Krainer
  11. To:    All
  12. Subj:  More About The Function Behind Ps.exe And Pstat.exe
  13.  
  14. The undocumented function in OS/2 v1.2 which is used by PSTAT.EXE and PS.EXE
  15. to get system information about processes, threads etc. has to be declared in
  16. the following way:
  17.  
  18. /***   DosQProcStatus
  19.  *
  20.  *   Fills a buffer with system information about threads, processes,
  21.  *   dynylink-libraries, system semaphores and named shared segments.
  22.  *
  23.  */
  24. USHORT APIENTRY DosQProcStatus(
  25.         PVOID pBuf,               /* address of a transfer buffer  */
  26.         USHORT cbBuf);            /* size of buffer in bytes       */
  27.  
  28. pBuf is the adress of a buffer, cbBuf is the size of the buffer. OS/2
  29. fills this buffer with system information. The amount of information
  30. you will get depends on how many system resources are actually used.
  31. The size of the buffer (and therefore the value of cbBuf) should be
  32. around 4 kBytes. This should be enough, even in the case of a heavy
  33. loaded system. The data you will get back is structured as a linked
  34. list. Each entry starts with a 16-bit code (0001 = thread information
  35. entry, 0004 = named shared segment etc.). The second 16-bit value is
  36. the pointer to the next entry followed by specific information about
  37. the entry. Franz. --- FD 2.00 * Origin: Ockham's Razor
  38. (Vienna/Austria) (2:310/11.17)
  39.  
  40. [End of message]
  41.  
  42. There was other information about the structure of the buffer.
  43. I had to correct it at some points. Here is a summary of what I know.
  44.  
  45. The buffer is a sequence of USHORT values, a (varying) number of them
  46. builds each record. These records are ordered in a linked list. The
  47. first USHORT of each records is it's type:
  48.  
  49.   0      process record
  50.   1      thread record
  51.   2      module record
  52.   3      system semaphore record
  53.   4      shared memory record
  54.   FFFF   end of buffer
  55.  
  56. The buffer contains records for each process, thread, module, semaphore
  57. and shared memory segment currently known by the system. The term
  58. module refers to a EXE or DLL module here.
  59.  
  60. The second USHORT of each record is the offset of the next record and
  61. thus establishes the forward link in the list. The offset is NOT from
  62. the beginning of the buffer but is the offset of the next record from
  63. the beginning of the segment in which the buffer is located!
  64.  
  65. All other USHORT's contain information specific to the record types.
  66. The offset in the structures listed below is the number of the USHORT
  67. from the beginning of the record.
  68.  
  69.  
  70. type 0 (process record):
  71.  
  72. 0 - type (process = 0)
  73. 1 - offset to next record
  74. 2 - PID
  75. 3 - parent PID
  76. 4 - screen session ID
  77. 5 - module handle of the EXE running for this process
  78. (other unknown information)
  79.  
  80.  
  81. type 1 (thread record)
  82.  
  83. 0 - type (thread = 1)
  84. 1 - offset to next record
  85. 2 - some handle number ?
  86. 3 - PID of process to which this thread belongs
  87. 4 - thread ID
  88. (other unknown information)
  89.  
  90.  
  91. type 2 (module record)
  92. These are records for modules (EXE and DLL) loaded either by
  93. DosExecPgm (EXE) or DosLoadModule(DLL).
  94.  
  95. 0 - type (module = 2)
  96. 1 - offset to next record
  97. 2 - module handle
  98. 3 - number of dependencies
  99. 4 - offset to list of dependencies (offset of the 6th word below)
  100. 5 - offset to module name
  101. 6 - list of dependent module handles
  102. ..
  103.   - module name (null-terminated string)
  104. (other unknown information)
  105.  
  106.  
  107. type 3 (systen semaphore record)
  108.  
  109. 0 - type (semaphore = 3)
  110. 1 - offset to next record
  111. 2 - index ? (seems to refer to owner)
  112. 3 - two bytes (low = number of references, high = number of requests)
  113. 4 - flag ?
  114. 6 - semaphore name (null-terminated string)
  115.  
  116.  
  117. type 4 (shared memory record)
  118.  
  119. 0 - type (shared memory = 4)
  120. 1 - offset to next record
  121. 2 - handle
  122. 3 - segment selector
  123. 4 - number of references
  124. 6 - name of segment (null-terminated string)
  125. (other unknown information)
  126.  
  127.  
  128. Semaphore information is still a bit unclear.
  129.  
  130.  
  131. The following sample program demonstrates how to use the information
  132. about processes, threads and modules. The analyzing code in
  133. parse_processes() was based on the code of the program RUNNING which I
  134. got from listserv@blekul11 but I corrected and rearranged the code.
  135.