home *** CD-ROM | disk | FTP | other *** search
/ OS/2 Shareware BBS: 10 Tools / 10-Tools.zip / dosqproc.zip / proc2.doc < prev    next >
Text File  |  1994-08-13  |  3KB  |  75 lines
  1. Since beta versions of OS/2 2.0 became widely available, it really
  2. started to bother people (me too) that the programs did not work
  3. any longer which used DosQProcStatus to display informations about
  4. running processes.
  5.  
  6. Finally, I found some spare time to decode the buffer returned by
  7. the 2.0 version of DosQProcStatus. Unfortunately, only a day later
  8. I got a program posted to comp.binaries.os2 called "killem20" (by
  9. Rick Fishman) which contained almost all of the information I
  10. needed and decoded the evening before. However, a few differences
  11. exist so my work was not all lost.
  12.  
  13. And, yes, even in the time of OOP and GUI it was real fun again to
  14. analyse a hex dump printout! Nice opportunity to practise that.
  15.  
  16. Included is a sample program (PROC2.C) which displays the data in
  17. the buffer returned by DosQProcStatus.
  18.  
  19. A few notes (see also the sample program):
  20.  
  21. - DosQProcStatus does only exist as a 16-bit API. There are no
  22.   problems calling it from a 16-bit program under OS/2 2.0 and it
  23.   is also easy to call it from a 32-bit program if the compiler
  24.   supports such calls. It only has to be declared properly and
  25.   imported directly via a linker definition file.
  26.  
  27. - The structure of the returned buffer is *completely* different
  28.   from OS/2 2.x and in my opinion much better usable by a user
  29.   program. Under 1.x, one better parsed the buffer completely and
  30.   built own data structures before using them. Under 2.0 it is not
  31.   difficult to use the buffer directly if the right structs are
  32.   declared and used.
  33.  
  34. - The DosQProcStatus call may not yet be completely bugfree even
  35.   in the beta version 6.304E of OS/2 2.0. For example, the pointer
  36.   to the semaphore list in the header does point 16 bytes *before*
  37.   the actual beginning of the list. I don't know if this has some
  38.   deeper meaning or is just a bug.
  39.  
  40. - The 16-bit DosGetPrty API even in 32-bit mode in the sample
  41.   program is only used because of my lazyness. Using the 2.0 info
  42.   blocks is much more *ugly* in this simple case where only the
  43.   priority of the process is wanted.
  44.  
  45. - The pointers in the returned buffer from DosQProcStatus are
  46.   always 0:32-bit pointers even if called from a 16-bit program.
  47.   They have to be converted properly, but this is easy in this
  48.   special case.
  49.  
  50. The sample program can be compiled with a 16-bit compiler such as
  51. Microsoft C 6.00 (which I used) or 5.1 or Zortech C++ (not tested)
  52. in both small and large data memory models if the symbols M_I86x
  53. where x is one of SMCL are defined (default in MS C).
  54.  
  55. A 32-bit compiler such as IBM C Set/2 (tested) can also be used to
  56. compile the program. Other compilers such as Watcom can be used if
  57. they support calling 16-bit far pascal API's and __32BIT__ is
  58. defined. EMX/GCC does not yet support this calling method.
  59.  
  60.  
  61.  
  62. Kai Uwe Rommel                                      Wed 25-Mar-1992
  63.  
  64. E-Mail:   rommel@ars.muc.de, rommel@informatik.tu-muenchen.de
  65. Fax:      +49 89 324 4524
  66.  
  67.  
  68. ------------
  69.  
  70. IBM recently release a document about the DosQProcStatus() system call
  71. so I could make a few minor corrections and the addition of the CPU
  72. time usage fields.
  73.  
  74. Kai Uwe Rommel                                      Sat 13-Aug-1994
  75.