home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
OS/2 Shareware BBS: 11 Util
/
11-Util.zip
/
RUNNING.ZIP
/
RUNNING.DOC
< prev
next >
Wrap
Text File
|
1990-02-12
|
17KB
|
501 lines
RUNNING: Shows Processes Running in OS/2
----------------------------------------
** Version 1.02 has changed the output format and removed the -p flag **
This program is released to the public domain and may be distributed
freely by any means.
I have included the source code to RUNNING and to SLAY. Please feel
free to use them as long as the code is not used for commercial
profit. I would appreciate receiving copies of modifications at any
of the below addresses.
RUNNING is a simple program which provides a listing of all processes
currently being used by OS/2. It provides information about the
processes such as their PID, their PARENT PID, the internal module ID
#, the number of children processes, the number of threads currently
running in each process, and dependency links to resources.
Resources are DLL's or font files.
Here is a sample of a listing of processes (not resources):
┌──────── Threads ────────┐
PID PPID Mod# Process Name Chld Str Rdy Blk Fzn Crt Bkd Oth
---- ---- ---- -------------------- ---- --- --- --- --- --- --- ---
00c1 0012 025c BRIEF 1 2
000f 0005 0457 CLOCK2 0 1
001c 0005 0271 CMD 0 1
000d 0005 0494 DESK 0 2
000e 0005 0476 FREEMEM 0 1
0006 0005 01fb HARDERR 0 3
000c 0005 03b7 PMEXEC 0 1
0005 0000 016a PMSHELL 11 12
0008 0005 02d7 PMSPOOL 2 2
0004 0000 0174 QH 0 8
000b 0008 0393 SPLDVWRK 0 2
000a 0008 0259 SPLPRM 0 6
0007 0005 0304 VIOHELP 0 1
The PID is the process ID which might be used by a program such as
SLAY (Included with RUNNING) or KILL (Copyright (c) 1988, Ed Braaten and
available on many BBSs - inconvenient because it accepts PIDs in
decimal format instead of hexadecimal format) to totally remove a
process from the system. The PPID is the parent process' PID and
the module # is a number used internally to identify the process.
The process name is the NAME name from the DEF file when the process is
linked. The number of child processes are followed by the number of
threads categorized by state as follows:
Str - Start Crt - Critical Section
Rdy - Ready Bkd - Background
Blk - Blocked Oth - Other (Zombie, boost)
Frz - Frozen
If you invoke RUNNING with the -r flag, you will get a listing of the
module dependencies and the resource module listing. It will look like
this:
PID PPID Mod# Process Name Chld Str Rdy Blk Fzn Crt Bkd Oth
---- ---- ---- -------------------- ---- --- --- --- --- --- --- ---
00c1 0012 025c BRIEF 1 2
**** Depends on: 0084 0085 007b 0046 0178
007c 008f
000f 0005 0457 CLOCK2 0 1
**** Depends on: 0084 0153 0154 0158
0006 0005 01fb HARDERR 0 3
**** Depends on: 0084 007b 0058 008f 0085
0072 007c
000c 0005 03b7 PMEXEC 0 1
**** Depends on: 0158 0084 0153 0154 0157
015c
0007 0005 0304 VIOHELP 0 1
**** Depends on: 031a 0084 0153 015c
Resources (DLLs) In Use:
Handle Resource Name Dependencies
------ -------------------- -----------------------------------------------
0057 ANSICALL 0084 007b 007c
0037 BKSCALLS 0057 0084 007b 0085 007c
0204 BMSCALLS 0084 0058 007c
0071 BVSCALLS 0057 0084 0058 0085 007c
02a8 COURIER <None>
0116 DISPLAY 007c 0084 0058 0085 0153 013f
0084 DOSCALL1 0000 007b 0085 007c
00c0 DOSCALLS <None>
0154 PMGPI 0084 0085 013f 012f 0153
0158 PMSHAPI 0084 0085 0157 0153
02e8 PMSPL 0084 0153
0153 PMWIN 0116 0084 0085 0154 013f 0157 0158
....
We can see that CLOCK2 above uses DOSCALL1, PMWIN, PMGPI, and PMSHAPI as
its resources (0084, 0154, 0158, 0153).
RUNNING has the following command line flags:
-r causes resources to be shown
-n supresses sorting by name.
-? shows the options (as does -h)
SLAY is a program which simply attempts to kill the process that you
indicate on the command line. The PID that you pass to SLAY MUST BE
HEXIDECIMAL (e.g. slay b3 or slay 18d) NOT DECIMAL!
RUNNING uses the undocumented function DosQProcStatus() which is
used by the programs PSTAT.EXE and PS.EXE which are provided with
OS/2. This function was brought to my attention by Franz Krainer in
a message in the OS2 echo (10-19-89), and helped fulfil a need that I
have had for a long time (since I moved over to OS/2 from QNX) to
know what exactly is running in my system at any moment. The
function works with OS/2 1.1 and should also work with version 1.2.
Some folks have had problems with RUNNING when using IBM's OS/2 1.1 EE
which seems to be cleared up when they installed IBM's patches dated
9 Feb 1989.
If you have questions or comments, you can send them to me Netmail at
my BBS, The Programmer's Oasis (1:151/402). You can also call the
BBS at (919)-226-6984 (North Carolina). You can drop me a line through
BIX (ID=laforet) or GEnie (ID=XTX74591). Finally, you can Email me
through Compuserve (ID 76120,110).
February 12, 1990
--------------------------------------------------------------------
Information for DosQProcStatus()
--------------------------------------------------------------------
The following information is derived from key messages in the OS/2
echomail available on many fine BBS's and may help to explain more
about the underlying function in RUNNING:
Date: 10-19-89 00:29
From: Franz Krainer
To: All
Subj: More About The Function Behind Ps.exe And Pstat.exe
The undocumented function in OS/2 v1.2 which is used by PSTAT.EXE and PS.EXE
to get system information about processes, threads etc. has to be declared in
the following way:
--------------------------------------------------------------------------
/*** DosQProcStatus
*
* Fills a buffer with system information about threads, processes,
* dynylink-libraries, system semaphores and named shared segments.
*
*/
USHORT APIENTRY DosQProcStatus(
PVOID pBuf, /* address of a transfer buffer */
USHORT cbBuf); /* size of buffer in bytes */
--------------------------------------------------------------------------
pBuf is the adress of a buffer, cbBuf is the size of the buffer.
OS/2 fills this buffer with system information. The amount of information you
will get depends on how many system resources are actually used.
The size of the buffer (and therefore the value of cbBuf) should be around 4
kBytes. This should be enough, even in the case of a heavy loaded system.
The data you will get back is structured as a linked list. Each entry starts
with a 16-bit code (0001 = thread information entry, 0004 = named shared
segment etc.). The second 16-bit value is the pointer to the next entry
followed by specific information about the entry.
Franz.
--- FD 2.00
* Origin: Ockham's Razor (Vienna/Austria) (2:310/11.17)
-------------------------
Date: 10-21-89
From: Chris Laforet
To: All
Subj: Re: More About The Function Behind Ps.exe And Pstat.exe
In a message by Franz Krainer dated 10-19-89 @ 0:29:
> The undocumented function in OS/2 v1.2 which is used by PSTAT.EXE and
> PS.EXE to get system information about processes, threads etc. has to
> be declared in the following way:
>
> USHORT APIENTRY DosQProcStatus(
> PVOID pBuf, /* address of a transfer buffer */
> USHORT cbBuf); /* size of buffer in bytes */
>
> pBuf is the adress of a buffer, cbBuf is the size of the buffer.
> OS/2 fills this buffer with system information.
I have been searching for a way to discover the processes running on an OS/2
system for quite a while and was happy to find this information. I have been
playing with it and have put together a simple program to help dump the
information:
--------------- Start -----------------
/* Compile with -AS -Lp */
#define INCL_DOS
#include <stdio.h>
#include <os2.h>
extern USHORT APIENTRY DosQProcStatus(PVOID pBuf,USHORT cbBuf);
BYTE bBuf[0x2000];
int main(void)
{
USHORT count;
USHORT kount;
USHORT fold;
USHORT type;
USHORT next = 0;
PIDINFO pid;
DosGetPID(&pid);
printf("Process ID = 0x%04x\n",pid.pid);
printf("Process TID = 0x%04x\n",pid.tid);
printf("Parent ID = 0x%04x\n",pid.pidParent);
if (!DosQProcStatus(bBuf,sizeof(bBuf)))
{
printf("Buffer address is %p:\n\n",bBuf);
do
{
printf("[Buffer + 0x%04x] : ",next);
if ((type = *(unsigned short *)(bBuf + next)) != 0xffff)
{
next += 2;
printf("Type = %u\n",type);
count = next + 2;
next = *(unsigned short *)(bBuf + next);
next -= (USHORT)(bBuf) & 0xffff;
printf("Next @ Buffer + 0x%04x\n",next);
switch (type)
{
case 0:
printf("Dump:\n\t");
for (fold = 0; count < next; count++, fold++)
{
if (fold && !(fold % 16))
printf("\n\t");
printf("%02x ",bBuf[count]);
}
break;
case 1:
printf("Thread Dump:\n\t");
for (fold = 0; count < next; count++, fold++)
{
if (fold && !(fold % 16))
printf("\n\t");
printf("%02x ",bBuf[count]);
}
break;
case 2:
kount = *(unsigned short *)(bBuf + (count + 2));
kount <<= 1;
kount += (count + 8);
printf("Process Dump:\n\t");
for (fold = 0; count < kount; count++, fold++)
{
if (fold && !(fold % 16))
printf("\n\t");
printf("%02x ",bBuf[count]);
}
printf("\nProcess Name: ");
for ( ; count < next; count++)
{
if (!bBuf[count])
break;
printf("%c",bBuf[count]);
}
break;
case 3:
kount = count + 6;
printf("System Semaphore Dump:\n\t");
for (; count < kount; count++)
printf("%02x ",bBuf[count]);
printf("\nSemaphore Name: ");
for ( ; count < next; count++)
{
if (!bBuf[count])
break;
printf("%c",bBuf[count]);
}
break;
case 4:
kount = count + 6;
printf("Shared Segment Dump:\n\t");
for (; count < kount; count++)
printf("%02x ",bBuf[count]);
printf("\nShared Segment Name: ");
for ( ; count < next; count++)
{
if (!bBuf[count])
break;
printf("%c",bBuf[count]);
}
break;
default:
printf("Unknown Dump:\n\t");
for (fold = 0; count < next; count++, fold++)
{
if (fold && !(fold % 16))
printf("\n\t");
printf("%02x ",bBuf[count]);
}
break;
}
printf("\n\n");
}
}
while (type != 0xffff);
printf("End of Chain\n\n");
}
return(0);
}
--------------- Stop -----------------
> Each entry starts with a 16-bit code (0001 = thread information
> entry, 0004 = named shared segment, etc.)
Type 0 appears to link threads with parents (?!)
Type 1 IS thread information
Type 2 is process information
Type 3 is system semaphore information
Type 4 IS named dhared segment information
I believe that in type 2 records (process), the second byte is the process-
type (see typeProcess in the LINFOSEG structure). The third and fourth
bytes seem to be a word which indicates how many extra words to add before
the name (if this is 0, then there are 2 words AFTER that word before the
name, if 1 then there are 3 words, etc.). I suspect that these extra words
*might* somehow indicate child processes(?)...
It is my hope that someone else might be able to figure out more on this
elusive information.
---------------------
Date: 10-21-89
From: Chris Laforet
To: All
Subj: Re: More About The Function Behind Ps.exe And Pstat.exe
Here is more information that I have figured out on the return from this
function:
Here are the following interpretations of the 16-bit codes:
0 Links PID's with their parents
1 Thread Information
2 Process Information
3 System Semaphore information
4 Named Shared Segment Information
0xffff End of Chain
For Type 0:
----------
word[0] - Type (0)
word[1] - Offset to next type
word[2] - PID
word[3] - Parent PID
word[4] - Unknown
word[5] - Module ID number (for want of a better term)
...
For Type 1:
----------
word[0] - Type (1)
word[1] - Offset to next type
word[2] - Handle number - probably used by scheduler (?)
word[3] - PID of thread
word[4] - Thread ID
...
For Type 2:
----------
word[0] - Type (2)
word[1] - Offset to next type
word[2] - Module ID number (links this to type 0 records and dependents)
(If NO link to a PID record, then this is a resource (DLL, font))
word[3] - Number of dependencies
word[4] - Offset to list of dependencies
word[5] - Offset to process name
word[6 to (6 + word[3]))]
- Dependent Module ID numbers
- Process name (nul-terminated string);
For Type 3:
----------
word[0] - Type (3)
word[1] - Offset to next type
word[2] - Unknown
word[3] - Unknown
word[4] - Unknown
- System semaphore name (nul-terminated string)
For Type 4:
----------
word[0] - Type (4)
word[1] - Offset to next type
word[2] - Unknown
word[3] - Unknown
word[4] - Unknown
- Named Shared Segment name (nul-terminated string)
I have created a simple little program which uses this information and which
lists all processes running on your machine with their PID's and Parent PIDs
as well as the dependencies. It is called RUNNING.EXE and is available at
The Programmer's Oasis and I will try to get it over to Fernwood tonight.
If anyone comes up with any more information on some of the unknowns above,
please keep this thread going!
----- Structures from QPS.C (Available through Programmer's Oasis) ------
typedef union _ps_info PS_info;
struct _reference_info
{ /* type 0 */
unsigned TYPE;
PS_info *NEXT;
unsigned PID;
unsigned PARENT_PID;
unsigned SGID;
unsigned MODULE_HANDLE;
unsigned *MODULE_REFS; /* points to modules handle numbers */
unsigned MODULE_REF_COUNT;
unsigned *SHARED_MEM_REFS; /* points to shared mem handle numbers */
unsigned SHARED_MEM_COUNT;
unsigned *SEMAPHORE_REFS; /* points to semaphore handle numbers */
unsigned SEMAPHORE_COUNT;
};
struct _thread_info
{ /* type 1 */
unsigned TYPE;
PS_info *NEXT;
unsigned PD_INDEX;
unsigned PID;
unsigned TID;
unsigned PRIORITY;
unsigned STATE;
unsigned long BLOCK_ID;
};
struct _module_info
{ /* type 2 */
unsigned TYPE;
PS_info *NEXT;
unsigned HANDLE;
unsigned NUM_DEPENDENCIES; /* number of imported modules */
unsigned DEPENDENCIES_PTR;
char *MODULE_NAME_PTR;
unsigned DEPENDENT_HANDLE_LIST; /* imported handle list */
};
struct _semaphore_info
{ /* type 3 */
unsigned TYPE;
PS_info *NEXT;
unsigned FLAGS;
unsigned REF;
unsigned HANDLE;
char SEM_NAME;
};
struct _shared_mem_info
{ /* type 4 */
unsigned TYPE;
PS_info *NEXT;
unsigned HANDLE;
unsigned SELECTOR;
unsigned REF;
char SEG_NAME;
};
typedef union _ps_info
{
struct _reference_info t0;
struct _thread_info t1;
struct _module_info t2;
struct _semaphore_info t3;
struct _shared_mem_info t4;
} PS_info;
----------------------------