home *** CD-ROM | disk | FTP | other *** search
/ Power-Programmierung / CD2.mdf / c / library / os2 / running / running.doc < prev    next >
Encoding:
Text File  |  1989-11-01  |  13.9 KB  |  396 lines
  1. RUNNING: Shows Processes Running in OS/2
  2. ----------------------------------------
  3.  
  4. This program is released to the public domain and may be distributed
  5. freely by any means.
  6.  
  7. I have included the source code to RUNNING and to SLAY.  Please feel
  8. free to use them as long as the code is not used for commercial
  9. profit.  I would appreciate receiving copies of modifications at any
  10. of the below addresses.
  11.  
  12. RUNNING is a simple program which provides a listing of all processes
  13. currently being used by OS/2.  It provides information about the
  14. processes such as their PID, their PARENT PID, the internal module ID
  15. #, the number of children processes, the number of threads currently
  16. running in each process, and dependency links to resources. 
  17. Resources are DLL's or font files.
  18.  
  19. Here is a sample of a listing of processes (not resources):
  20.  
  21. PID   PPID  Mod#  Process Name          Thds  Chld  Resource Module #s
  22. ----  ----  ----  --------------------  ----  ----  -------------------------
  23. 000e  0005  0332  CLOCK2                  1     0   0084 0151 0152 0156 
  24. 0011  0005  028b  CMD                     1     1   0072 0084 007b 008f 0085 
  25.                                                     0046 007c 
  26. 000c  0005  0380  FREEMEM                 1     0   0084 0151 0152 
  27. 0006  0005  01f4  HARDERR                 3     0   0084 007b 0058 008f 0085 
  28.                                                     0072 007c 
  29. 000a  0005  0273  PMEXEC                  1     0   0156 0084 0151 0152 0155 
  30.                                                     0159 
  31. 0005  0000  016a  PMSHELL                12     8   0151 0152 0155 0156 0159 
  32.                                                     0084 
  33.  
  34.  
  35. The PID is the process ID which might be used by a program such as
  36. SLAY (Included with RUNNING) or KILL (Copyright (c) 1988, Ed Braaten and 
  37. available on many BBSs - inconvenient because it accepts PIDs in
  38. decimal format instead of hexadecimal format) to totally remove a 
  39. process from the system.  The PPID is the parent process' PID and 
  40. the module # is a number used internally to identify the process.  
  41. The process name is the NAME or LIBRARY name from the DEF file when 
  42. the process is linked.  The number of threads and number of children 
  43. are followed by the module numbers of all of the resources currently 
  44. in use by the process.  Here is a sample of the resource listing:
  45.  
  46. PID   PPID  Mod#  Process Name          Thds  Chld  Resource Module #s
  47. ----  ----  ----  --------------------  ----  ----  -------------------------
  48. *Resource*  02a0  COURIER                           
  49. *Resource*  0114  DISPLAY                           007c 0084 0085 0151 013b 
  50. *Resource*  0084  DOSCALL1                          0000 007b 0085 007c 
  51. *Resource*  00c0  DOSCALLS                          
  52. *Resource*  02b6  HELV                              
  53. *Resource*  0406  IBMNULL                           013b 0084 0151 0156 02e0 
  54. *Resource*  007b  KBDCALLS                          0084 
  55. *Resource*  0178  MONCALLS                          0084 
  56. *Resource*  0058  MOUCALLS                          0084 007c 
  57. *Resource*  0152  PMGPI                             0084 0085 013b 012b 0151 
  58. *Resource*  0156  PMSHAPI                           0084 0085 0155 0151 
  59. *Resource*  0151  PMWIN                             0114 0084 0085 0152 013b 
  60.                                                     0155 0156 
  61.  
  62. We can see that CLOCK2 above uses DOSCALL1, PMWIN, PMGPI, and PMSHAPI as
  63. its resources.
  64.  
  65. RUNNING has the following command line flags:
  66.  
  67.     -p   causes only processes to be shown (no resource info)
  68.     -r   causes only resources to be shown (no processes)
  69.     -n   supresses sorting by name.
  70.     -?   shows the options (as does -h)
  71.  
  72.  
  73. SLAY is a program which simply attempts to kill the process that you
  74. indicate on the command line.  The PID that you pass to SLAY MUST BE
  75. HEXIDECIMAL (e.g. slay b3 or slay 18d) NOT DECIMAL!
  76.  
  77. RUNNING uses the undocumented function DosQProcStatus() which is
  78. used by the programs PSTAT.EXE and PS.EXE which are provided with
  79. OS/2.  This function was brought to my attention by Franz Krainer in
  80. a message in the OS2 echo (10-19-89), and helped fulfil a need that I
  81. have had for a long time (since I moved over to OS/2 from QNX) to
  82. know what exactly is running in my system at any moment.  The
  83. function works with OS/2 1.1 and should also work with version 1.2.
  84.  
  85. Some folks have had problems with RUNNING when using IBM's OS/2 1.1 EE
  86. which seems to be cleared up when they installed IBM's patches dated
  87. 9 Feb 1989.
  88.  
  89. If you have questions or comments, you can send them to me Netmail at
  90. my BBS, The Programmer's Oasis (1:151/402).  You can also call the
  91. BBS at (919)-226-6984 (North Carolina).  Finally, you can Email me
  92. through Compuserve (ID 76120,110).
  93.  
  94. November 1, 1989.
  95.  
  96.  
  97. --------------------------------------------------------------------
  98. Information for DosQProcStatus()
  99. --------------------------------------------------------------------
  100.  
  101. The following information is derived from key messages in the OS/2
  102. echomail available on many fine BBS's and may help to explain more
  103. about the underlying function in RUNNING:  
  104.  
  105.  
  106. Date:  10-19-89  00:29
  107. From:  Franz Krainer
  108. To:    All
  109. Subj:  More About The Function Behind Ps.exe And Pstat.exe
  110.  
  111. The undocumented function in OS/2 v1.2 which is used by PSTAT.EXE and PS.EXE
  112. to get system information about processes, threads etc. has to be declared in
  113. the following way:
  114. --------------------------------------------------------------------------
  115. /***   DosQProcStatus
  116.  *
  117.  *   Fills a buffer with system information about threads, processes,
  118.  *   dynylink-libraries, system semaphores and named shared segments.
  119.  *
  120.  */
  121. USHORT APIENTRY DosQProcStatus(
  122.         PVOID pBuf,               /* address of a transfer buffer  */
  123.         USHORT cbBuf);            /* size of buffer in bytes       */
  124. --------------------------------------------------------------------------
  125. pBuf  is the adress of a buffer, cbBuf  is the size of the buffer.
  126. OS/2 fills this buffer with system information. The amount of information you
  127. will get depends on how many system resources are actually used.
  128. The size of the buffer (and therefore the value of cbBuf) should be around 4
  129. kBytes. This should be enough, even in the case of a heavy loaded system.
  130. The data you will get back is structured as a linked list. Each entry starts
  131. with a 16-bit code (0001 = thread information entry, 0004 = named shared
  132. segment etc.). The second 16-bit value is the pointer to the next entry
  133. followed by specific information about the entry.
  134. Franz.
  135. --- FD 2.00
  136.  * Origin: Ockham's Razor (Vienna/Austria) (2:310/11.17)
  137.  
  138.  
  139. -------------------------
  140. Date:  10-21-89
  141. From:  Chris Laforet
  142. To:    All
  143. Subj:  Re: More About The Function Behind Ps.exe And Pstat.exe
  144.  
  145. In a message by Franz Krainer dated 10-19-89 @ 0:29:
  146.  
  147. > The undocumented function in OS/2 v1.2 which is used by PSTAT.EXE and 
  148. > PS.EXE to get system information about processes, threads etc. has to 
  149. > be declared in the following way:
  150. >
  151. > USHORT APIENTRY DosQProcStatus(
  152. >         PVOID pBuf,               /* address of a transfer buffer  */
  153. >         USHORT cbBuf);            /* size of buffer in bytes       */
  154. >
  155. > pBuf  is the adress of a buffer, cbBuf  is the size of the buffer.
  156. > OS/2 fills this buffer with system information. 
  157.  
  158. I have been searching for a way to discover the processes running on an OS/2
  159. system for quite a while and was happy to find this information.  I have been
  160. playing with it and have put together a simple program to help dump the
  161. information:
  162.  
  163. --------------- Start -----------------
  164. /* Compile with -AS -Lp */
  165.  
  166. #define INCL_DOS
  167. #include <stdio.h>
  168. #include <os2.h>
  169.  
  170. extern USHORT APIENTRY DosQProcStatus(PVOID pBuf,USHORT cbBuf);
  171. BYTE bBuf[0x2000];
  172.  
  173. int main(void)
  174.   {
  175.   USHORT count;
  176.   USHORT kount;
  177.   USHORT fold;
  178.   USHORT type;
  179.   USHORT next = 0;
  180.   PIDINFO pid;
  181.  
  182.   DosGetPID(&pid);
  183.   printf("Process ID  = 0x%04x\n",pid.pid);
  184.   printf("Process TID = 0x%04x\n",pid.tid);
  185.   printf("Parent ID   = 0x%04x\n",pid.pidParent);
  186.   if (!DosQProcStatus(bBuf,sizeof(bBuf)))
  187.     {
  188.     printf("Buffer address is %p:\n\n",bBuf);
  189.     do
  190.       {
  191.       printf("[Buffer + 0x%04x] : ",next);
  192.       if ((type = *(unsigned short *)(bBuf + next)) != 0xffff)
  193.         {
  194.         next += 2;
  195.         printf("Type = %u\n",type);
  196.         count = next + 2;
  197.         next = *(unsigned short *)(bBuf + next);
  198.         next -= (USHORT)(bBuf) & 0xffff;
  199.         printf("Next @ Buffer + 0x%04x\n",next);
  200.  
  201.         switch (type)
  202.           {
  203.           case 0:
  204.             printf("Dump:\n\t");
  205.             for (fold = 0; count < next; count++, fold++)
  206.               {
  207.               if (fold && !(fold % 16))
  208.                 printf("\n\t");
  209.               printf("%02x ",bBuf[count]);
  210.               }
  211.             break;
  212.           case 1:
  213.             printf("Thread Dump:\n\t");
  214.             for (fold = 0; count < next; count++, fold++)
  215.               {
  216.               if (fold && !(fold % 16))
  217.                 printf("\n\t");
  218.               printf("%02x ",bBuf[count]);
  219.               }
  220.             break;
  221.           case 2:
  222.             kount = *(unsigned short *)(bBuf + (count + 2));
  223.             kount <<= 1;
  224.             kount += (count + 8);
  225.             printf("Process Dump:\n\t");
  226.             for (fold = 0; count < kount; count++, fold++)
  227.               {
  228.               if (fold && !(fold % 16))
  229.                 printf("\n\t");
  230.               printf("%02x ",bBuf[count]);
  231.               }
  232.             printf("\nProcess Name: ");
  233.             for ( ; count < next; count++)
  234.               {
  235.               if (!bBuf[count])
  236.                 break;
  237.               printf("%c",bBuf[count]);
  238.               }
  239.             break;
  240.           case 3:
  241.             kount = count + 6;
  242.             printf("System Semaphore Dump:\n\t");
  243.             for (; count < kount; count++)
  244.               printf("%02x ",bBuf[count]);
  245.             printf("\nSemaphore Name: ");
  246.             for ( ; count < next; count++)
  247.               {
  248.               if (!bBuf[count])
  249.                 break;
  250.               printf("%c",bBuf[count]);
  251.               }
  252.             break;
  253.           case 4:
  254.             kount = count + 6;
  255.             printf("Shared Segment Dump:\n\t");
  256.             for (; count < kount; count++)
  257.               printf("%02x ",bBuf[count]);
  258.             printf("\nShared Segment Name: ");
  259.             for ( ; count < next; count++)
  260.               {
  261.               if (!bBuf[count])
  262.                 break;
  263.               printf("%c",bBuf[count]);
  264.               }
  265.             break;
  266.           default:
  267.             printf("Unknown Dump:\n\t");
  268.             for (fold = 0; count < next; count++, fold++)
  269.               {
  270.               if (fold && !(fold % 16))
  271.                 printf("\n\t");
  272.               printf("%02x ",bBuf[count]);
  273.               }
  274.             break;
  275.           }
  276.         printf("\n\n");
  277.         }
  278.       }
  279.     while (type != 0xffff);
  280.     printf("End of Chain\n\n");
  281.     }
  282.   return(0);
  283.   }
  284. --------------- Stop -----------------
  285.  
  286. > Each entry starts with a 16-bit code (0001 = thread information 
  287. > entry, 0004 = named shared segment, etc.)
  288.  
  289. Type 0 appears to link threads with parents (?!)
  290. Type 1 IS thread information
  291. Type 2 is process information
  292. Type 3 is system semaphore information
  293. Type 4 IS named dhared segment information
  294.  
  295. I believe that in type 2 records (process), the second byte is the process-
  296. type (see typeProcess in the LINFOSEG structure).  The third and fourth
  297. bytes seem to be a word which indicates how many extra words to add before
  298. the name (if this is 0, then there are 2 words AFTER that word before the
  299. name, if 1 then there are 3 words, etc.).  I suspect that these extra words
  300. *might* somehow indicate child processes(?)...
  301.  
  302. It is my hope that someone else might be able to figure out more on this 
  303. elusive information.  
  304.  
  305.  
  306.  
  307. ---------------------
  308. Date:  10-21-89
  309. From:  Chris Laforet
  310. To:    All
  311. Subj:  Re: More About The Function Behind Ps.exe And Pstat.exe
  312.  
  313. Here is more information that I have figured out on the return from this 
  314. function:
  315.  
  316. Here are the following interpretations of the 16-bit codes:
  317.     
  318.     0      Links PID's with their parents
  319.     1      Thread Information
  320.     2      Process Information
  321.         3      System Semaphore information
  322.     4      Named Shared Segment Information
  323.       0xffff   End of Chain
  324.  
  325.  
  326. For Type 0:
  327. ----------
  328.  
  329. word[0] - Type (0)
  330. word[1] - Offset to next type
  331. word[2] - PID
  332. word[3] - Parent PID
  333. word[4] - Unknown
  334. word[5] - Module ID number (for want of a better term)
  335. ...
  336.  
  337.  
  338. For Type 1:
  339. ----------
  340.  
  341. word[0] - Type (1)
  342. word[1] - Offset to next type
  343. word[2] - Handle number - probably used by scheduler (?)
  344. word[3] - PID of thread
  345. word[4] - Thread ID
  346. ...
  347.  
  348.  
  349. For Type 2:
  350. ----------
  351.  
  352. word[0] - Type (2)
  353. word[1] - Offset to next type
  354. word[2] - Module ID number (links this to type 0 records and dependents)
  355.           (If NO link to a PID record, then this is a resource (DLL, font))
  356. word[3] - Number of dependencies
  357. word[4] - Offset to list of dependencies
  358. word[5] - Offset to process name
  359. word[6 to (6 + word[3]))] 
  360.         - Dependent Module ID numbers
  361.         - Process name (nul-terminated string);
  362.  
  363.  
  364. For Type 3:
  365. ----------
  366.  
  367. word[0] - Type (3)
  368. word[1] - Offset to next type
  369. word[2] - Unknown
  370. word[3] - Unknown
  371. word[4] - Unknown
  372.         - System semaphore name (nul-terminated string)
  373.  
  374.  
  375.  
  376. For Type 4:
  377. ----------
  378.  
  379. word[0] - Type (4)
  380. word[1] - Offset to next type
  381. word[2] - Unknown
  382. word[3] - Unknown
  383. word[4] - Unknown
  384.         - Named Shared Segment name (nul-terminated string)
  385.  
  386.  
  387. I have created a simple little program which uses this information and which
  388. lists all processes running on your machine with their PID's and Parent PIDs
  389. as well as the dependencies.  It is called RUNNING.EXE and is available at
  390. The Programmer's Oasis and I will try to get it over to Fernwood tonight.
  391.  
  392. If anyone comes up with any more information on some of the unknowns above,
  393. please keep this thread going!
  394.  
  395.  
  396.