OS/2 Shareware BBS: 11 Util

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 | 17.1 KB | 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; ----------------------------