-
Notifications
You must be signed in to change notification settings - Fork 2
/
overview.html
484 lines (482 loc) · 23.9 KB
/
overview.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
<!doctype html>
<style>
#toc_container
{
border: 2px solid #aaa;
display: table;
font-size: 95%;
}
#toc_title
{
font-weight: bold;
text-align: center;
}
#toc_list
{
padding-right: 20px;
}
</style>
<title>391OS-36 Technical Overview</title>
<h2 id="top">Technical Overview</h2>
<hr>
<div id="toc_container">
<p id="toc_title">Contents</p>
<p>
<ul id="toc_list">
<li><a href="#cmd">Shell Commands</a></li>
<li><a href="#combkey">Combinational Keys</a></li>
<li><a href="#fs">File System</a></li>
<li><a href="#fsabst">File System Abstraction</a></li>
<li><a href="#fsdir">File System Directory</a></li>
<li><a href="#linkage">Context Switch/Assembly Linkages</a></li>
<li><a href="#exception">Exception/Exception Handlers</a></li>
<li><a href="#int">Interrupt/Interrupt Handlers</a></li>
<li><a href="#dev">Supported Devices/Drivers</a></li>
<li><a href="#memaddr">Memory Addressing</a></li>
<li><a href="#pmem">Physical Memory Layout</a></li>
<li><a href="#vmem">Virtual Memory Layout</a></li>
<li><a href="#syscall">System Calls</a></li>
<li><a href="#proctrl">Process Control/Execute/Halt</a></li>
<li><a href="#scheduler">Process Switching/Scheduler</a></li>
<li><a href="#multerm">Background Switching/Multiterminals</a></li>
<li><a href="#sig">Signals</a></li>
<li><a href="#pmgr">Process Manager</a></li>
</ul>
</p>
</div>
<p>
<b>Note:</b> All <i>italic</i> words in this document are for extra credits or design specific, and are not required for your work.<br>
</p>
<h3 id="cmd">Shell Commands</h3>
<table border="2" cellpadding="5">
<tr>
<th bgcolor="#ccffff">Command</th>
<th bgcolor="#ccffff">Description</th>
</tr>
<tr>
<td>exit</td>
<td>Quit the current 391OS-36 Shell program.<br>Will try to restart if the last shell in the current terminal was terminated.</td>
</tr>
<tr>
<td>[Executable] [Arg]</td>
<td>Search and open the program in the current terminal.<br>Some program may require additional arguments (see <a href="#fsdir">File System Directory</a>).</td>
</tr>
</table>
<h3 id="combkey">Combinational Keys</h3>
<table border="2" cellpadding="5">
<tr>
<th bgcolor="#ccffff">Combination</th>
<th bgcolor="#ccffff">Action</th>
<th bgcolor="#ccffff">Description</th>
</tr>
<tr>
<td>Alt+F1</td>
<td>Switch to Terminal 1</td>
<td>(See <a href="#multerm">Background Switching/Multiterminals</a>)</td>
</tr>
<tr>
<td>Alt+F2</td>
<td>Switch to Terminal 2</td>
<td>(See <a href="#multerm">Background Switching/Multiterminals</a>)</td>
</tr>
<tr>
<td>Alt+F3</td>
<td>Switch to Terminal 3</td>
<td>(See <a href="#multerm">Background Switching/Multiterminals</a>)</td>
</tr>
<tr>
<td>Ctrl+C</td>
<td>Interrupt</td>
<td>Quit the active process in the current terminal.</td>
</tr>
<tr>
<td>Ctrl+L</td>
<td>Clear Screen</td>
<td>Clear the VRAM and reset the cursor position.</td>
</tr>
<tr>
<td><i>Ctrl+S</i></td>
<td><i>Enable/Disable Scheduler</i></td>
<td><i>(See <a href="#scheduler">Process Switching/Scheduler</a>)</i></td>
</tr>
<tr>
<td><i>Ctrl+V</i></td>
<td><i>Enable/Disable Verbose Mode</i></td>
<td><i>Print the verbose outputs (for debugging only).</i></td>
</tr>
<tr>
<td><i>Ctrl+P</i></td>
<td><i>Start 391OS-36 Process Manager</i></td>
<td><i>(See <a href="#pmgr">Process Manager</a>)</i></td>
</tr>
<tr>
<td><i>Ctrl+H</i></td>
<td><i>Start 391OS-36 Help Center</i></td>
<td><i>Show the combination keys and about info</i></td>
</tr>
</table>
<h3 id="fs">File System</h3>
<p>
The 391OS-36 File System has a total size of 8MB, and is divided into 4KB blocks of one boot block, several inodes, and data blocks.<br>
Each boot block can track up to 62 inodes and one root directory, and each inode can track up to 1023 data blocks.<br>
Thus, the limitations are up to 62 files of 4092KB size and 32 characters name length. Also, it does not support hierarchy and is read-only.
</p>
<h3 id="fsabst">File System Abstraction</h3>
<p>
The 391OS-36 treat any files, device (RTC), and directory as files (see <a href="#fsdir">File System Directory</a>). Each process has a dynamic File Descriptor (FD) that supports 8 open files.<br>
Each FD entry tracks inode, position, flags, and an operation jump table, according to the file type. They are directly utilized by system calls (see <a href="#syscall">System Calls</a>).<br>
</p>
<h3 id="fsdir">File System Directory</h3>
<table border="2" cellpadding="5">
<tr>
<th bgcolor="#ccffff">File Name</th>
<th bgcolor="#ccffff">File Kind</th>
<th bgcolor="#ccffff">Description</th>
</tr>
<tr>
<td>.</td>
<td>Directory</td>
<td>Holds the information and refers to the root directory itself.</td>
</tr>
<tr>
<td>sigtest</td>
<td>Executable</td>
<td><b>Argument: 0 or any.</b> Used to test signals.<br>Use argument "0" to generate a Page Fault (PF) without trying to install a handler.<br>
<i>Use any argument except "0" to install handlers for alarm and segfault, and then generate a PF.</i></td>
</tr>
<tr>
<td>shell</td>
<td>Executable</td>
<td>391OS shell, the underlying program running in each terminal.</td>
</tr>
<tr>
<td>grep</td>
<td>Executable</td>
<td><b>Argument: a pattern.</b> Prints lines that contain a match for the pattern in each files' contents.</td>
</tr>
<tr>
<td>syserr</td>
<td>Executable</td>
<td>Used to test illegal system call arguments.</td>
</tr>
<tr>
<td>rtc</td>
<td>Device</td>
<td>Giving user-level access to the Real-Time Clock (RTC).</td>
</tr>
<tr>
<td>fish</td>
<td>Executable</td>
<td>Used to test the vidmap system call and RTC. Display a fish animation on the current terminal.</td>
</tr>
<tr>
<td>counter</td>
<td>Executable</td>
<td>A numerical counter.</td>
</tr>
<tr>
<td>pingpong</td>
<td>Executable</td>
<td>Used to test RTC. Infiniately print a ping-pong animation on the current terminal.<br>
Can only be terminated by Ctrl+C (interrupt signal) or the Process Manager.</td>
</tr>
<tr>
<td>cat</td>
<td>Executable</td>
<td><b>Argument: a file name.</b> Try to open and read the content of a file (or directory/device).</td>
</tr>
<tr>
<td>frame0.txt</td>
<td>Regular File</td>
<td>A frame of the fish animation.</td>
</tr>
<tr>
<td>verylarge~.txt</td>
<td>Regular File</td>
<td>Used to test the very long file name handling of the terminal driver.</td>
</tr>
<tr>
<td>ls</td>
<td>Executable</td>
<td>List all files in the directory.</td>
</tr>
<tr>
<td>testprint</td>
<td>Executable</td>
<td>Used to test the standard printing of the terminal driver.</td>
</tr>
<tr>
<td>created.txt</td>
<td>Regular File</td>
<td>Author information left by ECE 391 staff.</td>
</tr>
<tr>
<td>frame1.txt</td>
<td>Regular File</td>
<td>Another frame of the fish animation.</td>
</tr>
<tr>
<td>hello</td>
<td>Executable</td>
<td>Used to test the input buffer of the terminal driver.</td>
</tr>
</table>
<p>
Unless specifically listed above, programs usually don't accept any argument.<br>
The contents of the file system were provided by the ECE 391 staff.
</p>
<h3 id="linkage">Context Switch/Assembly Linkages</h3>
<p>
Whenever an interruption, exception, or system call happened, the processor jumps to a specific assmebly linkage in the kernel space.<br>
This procedure is sometimes called a <b>"context switch"</b>. It is almost constantly happening with the scheduler enabled, as it is based on PIT interrupts.<br>
Assembly linkages for interruption, exception, and system calls are different, but they all construct a hardware context on the kernel stack for restoring or usage.<br>
They will also push/pass through arguments accordingly, and call the corresponding handlers (see <a href="#exception">Exception Handlers</a>, <a href="#int">Interrupt Handlers</a>, and <a href="#syscall">System Calls</a>).<br>
When returning back from the handler, assembly linkage will resume the hardware context saved before by IRET, then go back to the user space.<br>
Or, halt/execute/process switch (see <a href="#proctrl">Execute/Halt</a> and <a href="#scheduler">Switch</a>) constructs a custom context, then it will jump to the next program's Prgram Counter (PC) and stack.<br>
<i>When going back to the user space, it will also dispatches any pending signal (see <a href="#sig">Signals</a>, this is optional).</i><br>
<i>Now, you see the reason why context switch is <b>expensive</b>. The assembly linkage really needs to deal with a lot of stuff.</i>
</p>
<table border="2" cellpadding="5">
<tr>
<th bgcolor="#ccffff">Type</th>
<th bgcolor="#ccffff">Generated By</th>
<th bgcolor="#ccffff">Asynchronous</th>
<th bgcolor="#ccffff">Unexpected</th>
</tr>
<tr>
<td>Interrupts</td>
<td>External device needs attention</td>
<td>YES</td>
<td>YES</td>
</tr>
<tr>
<td>Exceptions</td>
<td>Kernel/user program behaving wildly</td>
<td>NO</td>
<td>YES</td>
</tr>
<tr>
<td>System Calls (see <a href="#syscall">System Calls</a>)</td>
<td>User program, deliberately via INT x80</td>
<td>NO</td>
<td>NO</td>
</tr>
</table>
<h3 id="exception">Exception/Exception Handlers</h3>
<p>
An exception happens when the user program (or even worse, kernel) did something wild, such as dividing by zero or accessing illegal pages.<br>
Exceptions are synchronised. When an exception was generated, the processor jumps to the specific assembly linkage (see <a href="#linkage">Assembly Linkages</a>).<br>
The exception assembly linkage pushes information and calls an unified exception handler.<br>
Then, the handler will display the error message, debug information, and <i>send a signal to the process if recoverable (see <a href="#sig">Signals</a>, this is optional)</i>.<br>
If no handler was installed, the default behavior is killing the offending program. The 391OS-36 is still alive.<br>
If an exception is detected in kernel mode, the exception is non-recoverable and 391OS-36 will halt. You will need to reset the emulator.
</p>
<h3 id="int">Interrupt/Interrupt Handlers</h3>
<p>
An interrupt happens when a piece of hardware needs processor's attention, such as keyboard input, RTC, and PIC.<br>
The 391OS-36 only contains essential drivers (see <a href="#dev">Supported Devices/Drivers</a>). Interrupt lines (IRQs) from non-supported hardware are masked and ignored.<br>
The IRQ lines are managed by two i8259 PICs just like any other mainstream IBM-compatible PC.<br>
Interrupts are non-synchronised. When an interrupt is raised and got processor's attention, it jumps to the specific assembly linkage (see <a href="#linkage">Assembly Linkages</a>).<br>
The interrupt assmebly linkage pushes information and calls an unified interrupt handler.<br>
Then, the handler will call the corresponding driver, and the driver will handle the remaining work (again, see <a href="#dev">Supported Devices/Drivers</a>).
</p>
<h3 id="dev">Supported Devices/Drivers</h3>
<p>
The 391OS-36 has drivers for the standard keyboard, Programmable Interval Timer (PIT), Real-Time Clock (RTC), and terminal.<br>
Keyboard, PIT, and RTC drivers are for real devices and contains handlers for their interrupts (see <a href="#int">Interrupt/Interrupt Handlers</a>).<br>
The standard keyboard driver is responsible servicing key presses, and it also has support for the capital letter and combinational key handling.<br>
The PIT and RTC all generates interrupts periodically.<br>
The PIT and PIT driver are used to handle the scheduling and can be turned off (see <a href="#scheduler">Process Switching/Scheduler</a>). It is only accessible by the 391OS-36 kernel.<br>
The RTC is user-level accessible and it is "virtualized" for each process by the RTC driver, so they all have its own instance and frenquency.<br>
<i>Now, you see why the OS should use PIT for its task scheduling only. You don't want an user program to tamper with the scheduler frequency.</i><br>
The terminal driver is for standard input and output and works as a bridge with each terminal, keyboard driver, and system calls.<br>
There are three terminals (see <a href="#multerm">Background Switching/Multiterminals</a>). The input buffer for each terminal is limited to 128-characters.<br>
</p>
<h3 id="memaddr">Memory Addressing</h3>
<p>
The 391OS-36 has bypassed segmentation just like any mainstream modern operation systems. Only paging was used for the memory addressing.<br>
The memory layout 391OS-36 used is fixed (see <a href="#pmem">Physical Memory Layout</a> and <a href="#vmem">Virtual Memory Layout</a>).<br>
</p>
<h3 id="pmem">Physical Memory Layout</h3>
<p>
From low to high, the 391OS-36 has utilized the following 32MB physical memory:<br>
<ul>
<li>4MB space with five 4KB space for the VRAM for the active terminal, 3 terminal backups, and an extra backup space (see <a href="#multerm">Multiterminals</a>)</li>
<li>4MB space for the kernel data (mostly Process Control Blocks (PCBs) and Terminal Info (TI) blocks) and kernel stack (see <a href="#proctrl">Process Control</a> and <a href="#multerm">Multiterminals</a>)</li>
<li>Six 4MB spaces for user applications' binary and stack (see <a href="#proctrl">Process Control</a>)</li>
</ul>
</p>
<h3 id="vmem">Virtual Memory Layout</h3>
<p>
From low to high, the 391OS-36 has mapped the 4GB virtual memory space for each user program as following:<br>
<ul>
<li>4MB managed by a superviser Page Table (PT), with five 4KB superviser pages, going through from the physical memory (see <a href="#pmem">Physical Memory Layout</a>)</li>
<li>4MB superviser jumbo page for the kernel, going through from the physical memory (see <a href="#pmem">Physical Memory Layout</a>)</li>
<li>4MB user page at address address 128MB, for the current running program only (see <a href="#proctrl">Process Control</a>)</li>
<li>4MB managed by a user PT, with a 4KB vidmap page for the current active program, controlled by the vidmap (see <a href="#syscall">System Calls</a> and <a href="#multerm">Multiterminals</a>)</li>
</ul>
</p>
<h3 id="syscall">System Calls</h3>
<table border="2" cellpadding="5">
<tr>
<th bgcolor="#ccffff">System Call</th>
<th bgcolor="#ccffff">Description</th>
</tr>
<tr>
<td>halt</td>
<td>Halt the current program (process). For the halt procedure, see <a href="#proctrl">Process Control/Execute/Halt</a>.</td>
</tr>
<tr>
<td>execute</td>
<td>Load and execute a new program. For the execute procedure, see <a href="#proctrl">Process Control/Execute/Halt</a>.</td>
</tr>
<tr>
<td>read</td>
<td>Read data from a opened file (see file system abstraction above).</td>
</tr>
<tr>
<td>write</td>
<td>Write data to a file (support terminal and device/RTC only).</td>
</tr>
<tr>
<td>open</td>
<td>Allocate a FD entry and open a file.</td>
</tr>
<tr>
<td>close</td>
<td>Close the FD entry and close a file.</td>
</tr>
<tr>
<td>getargs</td>
<td>Return the command line argument. It is extracted during the execute system call.</td>
</tr>
<tr>
<td>vidmap</td>
<td>Giving the user-level access to the current VRAM by mapping it to the vidmap page, which is user-level accessible.</td>
</tr>
<tr>
<td><i>set_handler</i></td>
<td><i>Set custom handler for a signal (see <a href="#sig">Signals</a>, this is optional).</i></td>
</tr>
<tr>
<td><i>sigreturn</i></td>
<td><i>Restore the hardware context from the signal handler (see <a href="#sig">Signals</a>, this is optional).</i></td>
</tr>
</table>
<p>
<i>Please note that the last two system calls are for extra credit; they are not required.</i><br>
System calls are generated deliberately by user programs by generating a "soft interrupt," INT x80 on x86 systems.<br>
When a system call was generated, the processor jumps to the system call assembly linkage (see <a href="#linkage">Context Switch/Assembly Linkages</a>).<br>
Arguments for system calls are carried by %EAX, %EBX, %ECX, and %EDX registers.<br>
The linkage will check if the arguments are valid, and then hand the job to the corresponding system call handler.
</p>
<h3 id="proctrl">Process Control/Execute/Halt</h3>
<p>
The 391OS-36 supports up to 6 processes. In the kernel space, each process holds a kernel stack and a <b>Process Control Block (PCB)</b>.<br>
In the user space, each process holds their own user page (see <a href="#vmem">Virtual Memory Layout</a>) which contains the executable binary and a user stack.<br>
By having their own kernel and user stacks, their hardware context and user stack data won't be overwritten by other programs.<br>
Each PCB tracks the allocated process ID (PID), parent PID, terminal ID, kernel/user stacks, FD, <i>signals and its handlers,</i> etc.<br>
The kernel manages the PCB allocation by a custom design called <i>PCB pool</i>.<br>
This custom design allows the 391OS-36 to allocate and free the PCB resources freely.<br>
When <b>creating a new process (execute system call, see <a href="#syscall">System Calls</a>)</b>, the OS will first run a sanity check, extract the program name and argument.<br>
Then, it will try to allocate a PCB, create the user page and copy the binary for the program, initialize the FD, and do the bookkeeping.<br>
Finally, it will switch the kernel stack, build a custom hardware context with the new PC and user stack, and return to the linkage (see <a href="#linkage">Assembly Linkages</a>).<br>
When <b>halting a process (halt system call, see <a href="#syscall">System Calls</a>)</b>, the OS will first free the resources, which will tear down the user page, vidmap, and purge the FD.<br>
Then, it will free the PCB, build the context with the parent process's information and return to the linkage. Current context will be discarded.
</p>
<h3 id="scheduler">Process Switching/Scheduler</h3>
<p>
The 391OS-36 supports a round-robin scheduler based on the PIT interrupt (see <a href="#dev">Supported Devices/Drivers</a>) that can be turned off.<br>
While 6 processes are supported, only 3 of them are actually multitasking, and 1 at each time is running/scheduled.<br>
The scheduler schedules 3 processes that is shown on each terminal, called active processes, so they are constantly switching, and thus can multitask.<br>
But only one program is "actually" running, called running process, as there are only one processor supported.<br>
The <b>program switching</b> begins in the kernel with the hardware context saved. It is pretty like a halt call, but it will preserve the current resources and context.<br>
Then, it will switch the kernel page, kernel and stack, build the context with the next scheduled process's information and return to the linkage (see <a href="#linkage">Assembly Linkages</a>).<br>
Turning off scheduler (CTRL+S) will disable the multitasking, but it mimics the environment for your work prior to CP5.<br>
In that case, program switching only happens when the user is switching the terminal in the foreground, thus limiting the multitasking features.
</p>
<h3 id="multerm">Background Switching/Multiterminals</h3>
<p>
The 391OS-36 supports up to 3 terminals. Each terminal holds a custom design called <i><b>terminal info (TI) block</b></i> in the kernel.<br>
Each <i>TI block</i> tracks the current active program, PCB pointer, coordinations, etc. Scheduler works on active programs, so it relys on these information.<br>
When <b>switching the running program in the background</b>, a lot of extra works were done. One of the big challenge is to do a switch with separate VRAMs.<br>
The background running process only prints to its terminal even it is not active. For 391OS-36, this is done by having 5 individual VRAM pages (see <a href="#pmem">Physical Memory Layout</a>).<br>
When <b>switching the active terminal</b>, 391OS-36 will backup the current VRAM, copy the corresponding VRAM to the display, and remap the vidmap if necessary.<br>
</p>
<i>
<h3 id="sig">Signals</h3>
<p>
Please note that signals are for extra credit; they are not required.
</p>
<table border="2" cellpadding="5">
<tr>
<th bgcolor="#ccffff">Signal</th>
<th bgcolor="#ccffff">Sender</th>
<th bgcolor="#ccffff">Default Handler</th>
<th bgcolor="#ccffff">User Installable</th>
</tr>
<tr>
<td>DIV_ZERO</td>
<td>Kernel Exception Handler</td>
<td>Kill the process.</td>
<td>YES</td>
</tr>
<tr>
<td>SEGFAULT</td>
<td>Kernel Exception Handler</td>
<td>Kill the process.</td>
<td>YES</td>
</tr>
<tr>
<td>INTERRUPT</td>
<td>Kernel Keyboard Driver (CTRL+C)</td>
<td>Kill the process.</td>
<td>YES</td>
</tr>
<tr>
<td>ALARM</td>
<td>Kernel RTC Driver</td>
<td>Ignored.</td>
<td>YES</td>
</tr>
<tr>
<td>USER1</td>
<td>N/A</td>
<td>Ignored.</td>
<td>YES</td>
</tr>
<tr>
<td>SYSKILL</td>
<td>Kernel Utilities</td>
<td>Kill the process.</td>
<td>NO</td>
</tr>
</table>
<p>
The first five signals supports a custom user-installed handler through set_handler system call.<br>
You will need to implement the first five to be eligible to receive extra credit for the signals in your MP assignment.<br>
Linkage is carefully engineered to construct the stack, so signals are checked and delivered during any context switch (see <a href="#linkage">Context Switch/Assembly Linkages</a>).<br>
Signal requires a lot of bookkeeping including masks, handlers, pending signals in the PCB of each process.
</p>
</i>
<i>
<h3 id="pmgr">Process Manager (CTRL+P)</h3>
<p>
The 391OS-36 Process Manager is a kernel utility that prints the current PCB Pool and TI block information:<br>
<ul>
<li>PID, the Process ID</li>
<li>TID, the Terminal ID</li>
<li>PPID, the Parent Process ID</li>
<li>KSP, the Kernel Stack Pointer</li>
<li>FD, the File Descriptor</li>
<li>ECHO, the echo flag</li>
<li>VMAP, the vidmap flag</li>
<li>COOR, the cursor coordination</li>
<li>... and also, the (active, for each terminal) program name</li>
</ul>
It is design specific to 391OS-36, so it is definiately not required.<br>
Please note this utility's kill function does not work with the scheduler (please check other known issues in the demo page).<br>
</p>
</i>
<hr>
<b><a href="#top">Back to Top</a></b>