home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
The Fred Fish Collection 1.5
/
ffcollection-1-5-1992-11.iso
/
ff_disks
/
200-299
/
ff224.lzh
/
Who
/
Who.readme
< prev
next >
Wrap
Text File
|
1989-06-20
|
9KB
|
159 lines
WHO (what?)
This here program WHO is originally by -> GEORGE MUSSER Jr <-, but this
version is substantially enhanced (nearly rewritten) by Paul Kienitz. It
lists the currently active tasks on your Amiga, giving more useful
information about them than other competing hacks do. To use it, type "who"
into CLI (there are no command line arguments) or double click the icon.
It's not really a Workbench program; the icon just makes a big CON window
that it writes its output into as if it were in a CLI window, waiting for
you to press any key before removing the window when finished.
BEFORE READING FURTHER, try the program. If you understand the output, you
have little need to read the rest of this.
What you see when you run it is a list of tasks (or processes), with one line
of information about each. First come all the processes that are waiting for
some signal (or message) before continuing, then come those that are
currently ready to run (sharing time slices or waiting for something with
higher priority to get out of the way), and last some information about the
WHO process itself, which of course is the only one actually running at the
moment the information was gathered.
Each line starts with the type of task, either `task' if it's a simple Exec
task, `Process' if it's an AmigaDOS process (all processes are tasks but not
vice versa), or `CLI nn' (where nn is the CLI task number from 1 to 20) if it
is a CLI process (all CLI's are DOS processes but etc). If the CLI is
interactive (with prompts) there's a greater-than sign after the number, like
`CLI 3>'; if none, then this is probably a program started with RUN, or the
CLI is currently executing commands from a script file.
The next item is `ID xxxxxx' where xxxxxx is the six-digit hexadecimal
address (I hope that doesn't mess up those with 68020's) of its task control
block (struct Task, or struct Process which is an extended version of that).
Sometimes AmigaDOS refers to a "process ID" which is the address of a
process's message port. This is always equal to the task control block
address plus 92 bytes (5C hex).
Next is the priority of the task, from -128 to 127, given as `pri nnn'. Zero
is the typical priority for most user programs.
Then comes the task's name, which is a string in quotes, such as "Workbench"
or "File System". In the case of a CLI process, this name is replaced with
the name of the program currently being run within the CLI, because the name
of the CLI itself is usually uninformative. In this case, you see something
like `cmd. "utilities/palette"' instead of `name "Palette"'. Or, you'll see
`(no command)' in the case of a CLI that is prompting for a command to run.
This might be the end of the information about the task. But there are some
optional things that might come next:
If the CLI is executing commands from a script file that had a .key
directive in it, it will say something like `script "T:Command-00-T03"',
where the name in quotes is the temporary file that commands are being read
from. You could, for instance, type out this file to see what commands
resulted from argument substitution. Unfortunately, if it's reading
commands directly from a simple script file, WHO can't find that file's name.
If the task is a "trackdisk.device" driver task, it will then have `unit n',
where n is from 0 to 3, to tell you which floppy drive from DF0: to DF3: this
driver is attached to. Sorry, I couldn't give unit numbers for any other
devices, because the method of discovering it varies with each device.
If this is a DOS handler process, it will say `for NAME:' to tell what DOS
device it is handling, e.g. `name "File System" for DF1:'.
If this is a handler process (usually a CON: process) which is handling the
standard output of another process, it will say `for CLI nn' or `for ID
xxxxxx' to identify what other process(es) are sending their standard output
here. It will say `for this output' for the process that is handling the
output of WHO itself (usually the CON for either the current CLI window or
the window created when you double click the WHO icon). Multiple for's are
separated by `&', e.g. `name "RAM" for RAM: & CLI 3' (in this case CLI 3 has
it's standard output redirected to a ram disk file).
In rare cases, it will say `NODE TYPE nnn' after a task. Each task normally
contains a node type number which identifies it as being a task (value 1) or
a process (value 13). If the value is something else, Who will report it.
It will assume that it's a simple task, not a process, in such cases.
Output is sorted as follows: first tasks and then processes; within that, by
decreasing priority (the lower priority ones are probably the ones that
are of more interest), then alphabetically by name. If it puts out too much
to fit in the window, you'll just have to press the space bar in the middle
to make it wait for backspace, if you want to see the earlier entries.
------------------------------------------
If you care, here are what some of the typical mysterious entities you see in
its output are:
Non-CLI process named "CLI": if you double click the icon named CLI or
Shell, it runs a process that creates a CON window and a CLI process, and
then sits around waiting for the CLI to finish so it can close the window. A
bit inefficient. My CLImax program works the same way (but I'm going to
improve it someday), so you'll see a process called "CLImax" which is
distinct from the full-screen CLI itself.
"File System" process: This is the DOS handler for a floppy disk drive; it
translates things like "open file foo/bar/ralph" and "read the next 200
bytes" into IO requests like "read track 41 sector 5". There is one for each
drive in use; they are all the same program.
Things like "RAM" for RAM: or "PRT" for PRT: are other DOS handler
processes; in some cases (e.g. RAD:) they are the same as "File System". In
the case of a hard disk, it might be the Fast File System. For non-disks, it
might be something like the Port-Handler.
"trackdisk.device" task: the trackdisk device for a given drive receives IO
requests from the corresponding handler process and takes care of managing
the particular hardware of the disk. Simple devices like timer.device or
keyboard.device don't need separate tasks; they're just like shared
libraries. But complex devices like disks need to delegate difficult stuff
to separate tasks, which usually have the same name as the device itself. If
you have a hard disk, there's probably some task like "scsi.device"; if it is
SCSI there is probably only one task even if there are several disks.
"printer.device" task: this translates generic printer control codes into
the specific control sequences used by your brand of printer, which then get
sent to parallel.device or serial.device, depending.
"input.device" task: this is the source of "input events"; it merges
together input from the keyboard and mouse and feeds the resulting stream to
the back end of Intuition (which sends messages to the programs that use its
front end) and to console.device. Also any "hot key" programs. I think.
I might be a bit confused about this. Is the back end of Intuition just a
big event handler? Why would input.device need a separate task and
Intuition not? Is the input.device task what figures out, like, what gadget
the mouse is over and what menu item was picked?
"CON" process: handles DOS I/O with pseudo-terminal text windows (the
actual terminal emulation is done by console.device, I think.) Each text
window gets its own handler process. ConMan works by replacing the program
used by these handlers. NEWCON is another replacement; I call it "ConBoy".
"Workbench" is a program like any other, not something built into the system.
This distinguishes it from CLI, which isn't a separate program, but some-
thing that gets pieced together by other programs like NewCLI and RUN.
----------------------------------------
Differences between my Who and the original George Musser Who:
His was much larger (he used Lattice instead of Manx) and couldn't be run at
all from Workbench, and needed an expanded stack to avoid crashing, and
could only list a limited number of tasks. Also it Disable()d for a longer
interval. The output did not include: CLI task number, CLI command name or
script file or interactive flag, any "for" information for handlers, or
trackdisk unit numbers. The output was not sorted and not aligned in
columns.
If you're waiting for me to improve George Musser's other program, KILL
(which could certainly stand some help), don't hold your breath. Maybe
someday I'll try for a fancy Intuitionized Who/Kill which will hot-key into
existence at priority 127 to save the system.
(°¿°) <- Official Seal of Dorkiness certifies that Who was enhanced without
the use of ROM Kernel Manuals.