GEMini Atari

home *** CD-ROM | disk | FTP | other *** search

/ GEMini Atari / GEMini_Atari_CD-ROM_Walnut_Creek_December_1993.iso / files / mint / mint095b / mint.doc < prev next >

Wrap

Text File | 1993-08-03 | 31.0 KB | 645 lines

MiNT is Not TOS: A Multitasking Operating System Extension for the Atari ST Copyright 1990,1991,1992 Eric R. Smith. All rights reserved. See the file "copying" for conditions of redistribution. WARNING: This program does some very low level things to your computer. MiNT works well on my machine, and I trust my data to it. But then, I make regular backups, so even if a horrible bug in MiNT that I haven't found yet trashes my hard drive, I won't lose much. You'll have to decide for yourself about trusting your data to MiNT. I would certainly recommend regular backups in any event. MiNT COMES WITH ABSOLUTELY NO WARRANTY, NOR WILL I BE LIABLE FOR ANY DAMAGES INCURRED FROM THE USE OF IT. USE ENTIRELY AT YOUR OWN RISK!!! Introduction MiNT is an extension of (and eventually, I hope, a replacement for) TOS. It provides extra services such as multitasking and pipes. If you don't know what those terms mean, MiNT is probably not for you -- at this stage, MiNT is still very incomplete and should be regarded as "experimental". MiNT will run a great number of ("most", I hope) TOS programs, including GEM. As the name says, though, MiNT is not TOS, so it can't be expected to run all TOS programs, or even all well-behaved TOS programs (although I hope that it will run "almost all" of the latter!). There are two classes of incompatibilities with TOS: bugs and features. Bugs are undoubtedly present; if you find any please report them to me. There are also some features of MiNT that may cause incompatibilites. Most of these are listed in the accompanying "features" file. MiNT tries to emulate TOS 1.4 very closely. If you have TOS 1.0 or 1.2, you may think you can use MiNT instead of buying TOS 1.4. This isn't really a very good idea, because MiNT calls TOS, and so having the newer version of TOS will really speed things up. Besides, the GEM that comes with TOS 1.4 is a lot better than the old GEM. Using MiNT MiNT can be started from an AUTO folder, by setting it as a BOOT program on the desktop (TOS 1.4 or higher only) or by running it. I prefer the AUTO folder way myself. If you put it in an AUTO folder, it should be the last thing in the folder (since any later programs in the folder will run only after MiNT is finished, and MiNT should never finish). MiNT will try to run a program called "init.prg" in the current directory (which is the root directory if MiNT was started from an AUTO folder). If this program isn't found, MiNT will boot up GEM. You can change the name of the initial program to run via the "mint.cnf" file (see below). Once MiNT is running, the computer should behave just as it does under TOS, except that some new drives (U, Q, V, and X) will be available, background processes can be started, and programs can use the new features of MiNT. MiNT can be asked to provide a trace of the currently executing programs. Hitting CTRL-ALT-F1 increases the debugging level; hitting CTRL-ALT-F2 decreases it, and hitting CTRL-ALT-F3 changes where the debugging output goes; pressing it once changes it from the screen to the printer, pressing it again changes it to the RS232 port, pressing a third time sends debugging output to the MIDI port. Pressing CTRL-ALT-F4 resets output to the screen. This feature was designed to aid in debugging MiNT itself, but can also be useful in finding problems with user programs. Debugging level 0 (the normal) prints messages only when something goes seriously wrong inside of MiNT itself. Debugging level 1 prints a message when any system call fails. Debugging level 2 provides a (sickeningly) exhaustive trace of what's going on in the system. CTRL-ALT-F5 shows what memory is being used in the system CTRL-ALT-F6 prints a list of all processes in the system CTRL-ALT-DEL provides a (warm) boot, as in TOS >= 1.4, and CTRL-ALT-SHIFT-DEL provides a cold boot. Some other keys are recognized by MiNT if the process is doing I/O in "cooked" mode: ^C (CTRL-C): interrupt running program with signal SIGINT. This (usually) will kill the process, unless it has made arrangements to catch it. Note that ^C takes effect immediately under MiNT, whereas under TOS it only takes effect when the process reads or writes. ^\: send a QUIT signal to a process; usually the same end result as ^C, but it is guaranteed to kill a TOS program (only MiNT specific programs know how to catch it). Use with caution. ^Z: suspend the current process These keys do *not* have any effect on processes operating in "raw" mode, such as editors. However, you can force these to work even on such programs by holding down the ALT key as well, i.e. CTRL-ALT-Z will always suspend the process. You should use caution when doing this, since some programs will function incorrectly and/or lose data if interrupted when they aren't expecting it. The MiNT Configuration File If MiNT finds a file called "mint.cnf" in the directory that it was started from, it will read some configuration information from it. This file is an ordinary ASCII text file; it can be created with any editor that will produce plain ASCII files (if you're using a fancy word processor, make sure you save the file as "plain ASCII text" or "unformatted text" or whatever). The commands in mint.cnf are placed one per line, and may be of the following forms: INIT=d:\foo\bar.prg This specifies the drive and full path name to the program you want MiNT to run at boot up time. The default is try ".\init.prg", if that file exists, otherwise to run the GEM desktop. HARDSCROLL=25 This specifies that hardware scrolling should be used for the u:\dev\fasttext text accelerator. This dramatically speeds up text operations, but may interfere with GEM and graphics programs. Put this line *before* any use of u:\dev\fasttext. CON=u:\dev\fasttext Specifies the use of MiNT's built in text accelerator instead of the normal BIOS console. This speeds up text output quite a bit (more than 300%) but may not be completely compatible; in particular, the escape codes for setting foreground/background character colors are not supported. PRN=d:\foo\bar Specifies a file that should be used for all printer output. (The default is u:\dev\centr, which is the device corresponding to the centronics port.) cd d:\foo Change the current drive and directory. This isn't terribly useful, unless your initial program (see above) expects to run with some particular directory as the current one. exec d:\bin\prog.prg arg1 arg2 ... Execute a program, with some arguments. The full path name and extension (.prg, .tos, .ttp, or whatever) of the program to execute must be given. ren d:\nm1 d:\nm2 Rename a file or directory. This is useful mainly on the pseudo-drive v:, which refers to devices. For example, the RS232 port on the ST is called "v:\modem1". Earlier versions of MiNT called this "v:\rs232", so if your programs care about this you might want to put "ren v:\modem1 v:\rs232" to maintain compatibility. Similarly, if your software has been ported from Unix and expects terminals to be called "tty*", then you might want to put "ren v:\modem1 v:\tty1" instead. setenv FOO BAR Set the environment variable FOO to the value BAR. NOTE: If any setenv commands are given in mint.cnf, an entirely new environment is constructed; this means that any environment variables set by a program in the AUTO folder will be ignored by programs run under MiNT. This allows you to have two default environments, one for running under MiNT set in mint.cnf, and one for normal TOS set by an AUTO folder program. sln d:\foo\bar u:\baz Create a symbolic link called "u:\baz" for the file (or directory) d:\foo\bar. Only drive u: supports symbolic links, so the second name *must* be on drive u:; the first name can be anything. A symbolic link is just an alias or nickname for a file; if the sample line is included in your mint.cnf file, then references to u:\baz are automatically translated by the kernel so that they "really" refer to d:\foo\bar. If d:\foo\bar is actually a subdirectory, with the file "frob.txt" in it, then that file can be accessed either through the name "d:\foo\bar\frob.txt" or "u:\baz\frob.txt". Symbolic links are often used to tell programs where to look for files; in this respect they're somewhat like environment variables. Some "standard" links are: u:\bin directory to find programs in u:\etc directory to find certain general configuration files (e.g. passwd and termcap) u:\local directory to find node-specific files in (for networked systems) u:\lib directory to find C libraries in u:\include directory to find C header files in You can use whatever of these are convenient, or add some others of your own. Pseudo Drives MiNT provides some fake "disk drives"; if the contents of these drives are listed, various "files" are shown. These "files" are not necessarily real files, but may represent other objects such as executing programs or regions of memory. The most important of these pseudo drives is drive U:. This is a "unified" file system that has all other drives as subdirectories. For example, U:\A\FOO\BAR is another name for the file A:\FOO\BAR. Symbolic links can also be created from drive U: to other drives; e.g. if the line sln U:\ETC C:\UNIX\ETC appears in mint.cnf, then the file U:\ETC\TERMCAP will be another name for the file C:\UNIX\ETC\TERMCAP, and so on. Finally, drive U: contains some special subdirectories, as follows: U:\PIPE contains files which are FIFO queues (e.g. pipes). All files created in this directory are temporary; when the last program using a FIFO closes it, it is erased. Normally, U:\PIPE will be empty, but it will have items on it when you're running a window manager, print spooler, or similar program that uses FIFOs or pseudo-ttys for communication. U:\DEV contains files which correspond to the BIOS devices; this allows you to access these devices from within programs. For example, saving an ASCII text file to "U:\DEV:\PRN" should cause it to be printed on your printer. Of course, this will work *only* with ASCII data, so don't expect to get anything meaningful printed if you try to save your spreadsheet to "U\DEV\PRN"! The following devices are available: CENTR: the centronics printer port MODEM1: the RS232 serial port MIDI: midi port KBD: intelligent keyboard controller PRN: printer device (not necessarily the real printer if redirected) AUX: auxiliary terminal (usually, but not always, the rs232 port) CON: current control terminal (NOT necessarily the keyboard/screen!) TTY: same as above STDIN: current file handle 0 (standard input) STDOUT: current file handle 1 (standard output) STDERR: current file handle 2 (standard error) CONSOLE: (physical console) the keyboard/screen FASTTEXT: an alternate, faster text device for the console screen MOUSE: a Sun compatible mouse device. Don't use this directly; use the AES/VDI functions instead. NULL: a null device (like Unix's /dev/null) The "STD*" file handles are useful for providing I/O redirection to programs that normally require file names on the command line; for example, if you want to run such a program in a pipeline. U:\PROC has special files that represent all currently executing processes, such as whether they're running, ready, or waiting, their process i.d. numbers, and the amount of memory they've taken. Deleting one of the "files" kills the corresponding process. (Killing MiNT is impossible; killing GEM is a very bad idea). The "files" will have names like "INIT.001"; this means that the process name is "INIT" (presumably because it was started from a file like "INIT.PRG"), and its process i.d. is 1. You can rename processes just as if they were files, except that any extension you give is always replaced with the process i.d. (e.g. if you rename INIT.001 to FOO.BAR, it will really become FOO.001). The size of a process is the amount of memory that is allocated to it. Its date/time stamp indicates when it started executing. A process' current state is reflected by its attribute bits; most of these are not visible from the desktop, alas, but here are the combinations and their meanings: attribute process state 0x00 currently running 0x01 ready to run 0x20 waiting for an event (e.g. for a child to finish) 0x21 waiting for I/O 0x22 zombie (exited, but parent doesn't know yet) 0x02 terminated and resident 0x24 stopped by a signal Deleting a "file" in U:\PROC will send a SIGTERM signal to the corresponding process, which will usually result in that process being terminated. It is not possible to delete processes which are terminated and resident, or zombie processes. U:\SHM is a place for shared memory. A program may create a file in U:\SHM and attach a block of memory to it. Thereafter, other programs may open that file and use the memory. This provides a fast way to transfer large amounts of data between processes. Other pseudo drives that are available are Q:, V:, and X:. These are just aliases for U:\PIPE, U:\DEV, and U:\PROC, respectively, and exist for backwards compatibility. Don't use them in new applications; they will go away soon. Note that the TOS 1.0 desktop won't recognize drives above P. Other versions of TOS will, though, so you can use the Install Drive menu selection to install the pseudo drives so that the desktop can recognize them. File Handles and Devices File handle -1 refers to the current control terminal, NOT necessarily the console (this is where it points by default). BIOS handle 2 also refers to the control terminal, so that e.g. Bconout(2, c) outputs a character to the control terminal. Thus, Fforce(-1, Fopen("U:\DEV\MODEM1", 3)); r = Bconin(2); reads a character from the RS232 port under MiNT. This is done so that programs that use the BIOS for I/O will be able to run in windows or over the modem. Similarly, the DOS device CON: refers to the current control terminal, so Fopen("CON:", 3) is normally equivalent to Fdup(-1). To access the physical console, use device U:\DEV\CONSOLE. In a similar fashion, file handle -2 and bios device 1 (DOS device AUX:) may be redirected away from the RS232 port (device U:\DEV\MODEM1), and file handle -3 and bios device 0 (DOS device PRN:) may be directed away from the Centronics printer port (device U:\DEV\CENTR). Since both the DOS handles and BIOS device numbers are redirected, any program at all will obey the redirection unless it accesses the hardware directly (or unless it was written for MiNT and specifically uses the new device names like U:\DEV\CENTR; this should be done only if *absolutely* necessary!). See also the PRN= and CON= commands for mint.cnf, which provide another way to redirect the printer and console (actually, it's just another interface to the same method of redirection). File handles -4 and -5 are new with MiNT, and refer to the MIDI input and output devices respectively. Redirecting these handles will affect BIOS operations on bios device 4 (the MIDI port). Background Processes (Note that the programs bg.ttp and pipe.ttp, along with some other sample MiNT utilities, are found in a separate file called "mntutl.zoo"). Programs may be started in the background. A sample program ("bg.ttp") is provided that will do this for you. It works best from a shell; for example, to make foo.ttp in the background from gulam, type: cd \foo\src bg.ttp -o make.out make foo.ttp The "-o make.out" tells "bg" to redirect the command's standard tty, output, and error output (handles -1, 1, and 2) to "make.out". You might also want to redirect the standard input from an empty file, or from a file that will never have input waiting (like V:\NUL) so that "make" won't try to read anything from your console. Shells designed to work with MiNT (for example, the "mintshel.ttp" that is provided with the MiNT utilities) may use the Unix "&" notation for running processes in the background; with this notation, the job above would be: cd \foo\src make foo.ttp >make.out & (here the ">make.out" is the notation for redirecting the standard output of a process). Note that the sample shell does not provide a way of redirecting the standard error output; however, it does provide job control, and processes that try to write on the terminal will be stopped automatically. See "Job Control" below. Pipes Pipes are special files that are used to communicate between processes. The data in a pipe is always in memory, so using a pipe instead of a temporary file is usually faster; it also doesn't consume disk space. Only 2048 bytes can be held in a pipe at once; when a process tries to write more data, it is suspended until another process reads some data, thus "emptying" the pipe. If there are no more readers, a process writing on a pipe is terminated. A simple "pipe" program is provided to run two programs concurrently, passing data between them in a pipe. The syntax is pipe.ttp cmd1 cmd2 which is equivalent to the Unix "cmd1 | cmd2". Note that if cmd1 or cmd2 contain arguments, then you must run the "pipe" program from a shell that supports the Atari standard extended argument convention, and that you must enclose the commands in quotes, e.g. in gulam: set env_style mw # extended arguments pipe 'ls.ttp -l foo' 'fgrep.ttp myfile' does the same as the Unix command ls -l foo | fgrep myfile or using a temporary file ls -l foo >junk; fgrep myfile <junk; rm junk Shells designed to work explicitly with MiNT will probably not need the external "pipe" command, and instead will use the Unix notation for pipelines. This second method is preferable, as it provides a way of joining more than two programs in a pipeline. Job Control MiNT supports a terminal access protocol for job control. The ^Z (control-Z) key can be used to suspend a process. The process can be restarted again if it is sent the appropriate signal. There is also a "delayed" suspend key, ^Y, that takes effect only when a process attempts to read it. Some programs written for TOS put the terminal in "raw" mode, where no control characters are interpreted. You can use CTRL-ALT-Z to achieve the effect of ^Z for such programs. However, this feature should be used with caution -- it's possible that the TOS program had a good reason for not wanting to be interrupted! Once a program has been suspended, it must be restarted again. MiNT aware shells (e.g. mintshel.ttp) usually provide some sort of "fg" command that restarts the suspended process and brings it to the foreground. This suspend-restart cycle may be performed any number of times. If the terminal mode "tostop" is set (this is the default), then any background program that tries to write to the console will be suspended automatically; it must then be brought to the foreground with the "fg" command before the write continues. This behavior may be changed with the "stty" utility; after an "stty -tostop" command is issued, background programs will no longer be suspended when they write to the terminal. Background programs that try to read input from the console will also be automatically suspended until brought into the foreground. This happens regardless of the setting of the "tostop" flag. Programming with MiNT A file (mintbind.h) is provided that gives a C interface to the new MiNT system calls. Users of other programming languages will have to write the interfaces themselves; it should be relatively straightforward, as long as your compiler provides a way to call GEMDOS directly. Testing for the presence of MiNT: There are several ways to check to see if MiNT is active. The best way is to check the cookie jar; MiNT installs a cookie of 0x4d694e54 (in ASCII, 'MiNT'), with a value consisting of the major/ minor version numbers in the high/low bytes of the low word. Thus, MiNT version 1.2 will have a cookie value of 0x00000102L. (This isn't the place to explain the cookie jar, but basically it's a list of (cookie, value) pairs of longwords, terminated by cookie 0; a pointer to the jar is found at 0x5a0. MiNT always installs a cookie jar; versions of TOS prior to 1.6 don't always, in which case 0x5a0 will contain 0). A "quick and dirty" way to see if MiNT is active is to make a system call that only exists under MiNT (preferably one with no side effects!). Pgetpid() or Syield() are good choices. If MiNT is not active, these calls will fail, returning -32 (invalid function). This method has the disadvantage that future versions of TOS, or other multitasking programs, may use the same trap numbers as MiNT, but have different meanings. For this reason, the "cookie jar" method is preferred. Interprocess Communication: MiNT provides 5 forms of interprocess communication (IPC): signals, fifos, shared memory, message passing, and semaphores. Signals: Signals are a way of notifying a process of an event. The Pkill(pid, sig) system call is used to send signal number "sig" to the process with process id "pid". It is called "Pkill" because the default action of most signals is to terminate the process. If a process wishes to catch a signal and do processing, it can use the Psignal(sig, func) system call to arrange to have function "func" called when signal "sig" is received. If func is 0, then the default action is restored. If func is 1, then the signal will be ignored. Processes can temporarily block receipt of signals via the Psigblock() and Psigsetmask() system calls. See the file "signal.doc" for a more complete explanation of signals. Fifos: Fifos are "first in first out" message queues. Pipes are a special kind of (unidirectional) fifo. Fifos are represented by files in the subdirectory "PIPE" on drive "U:". They are created with the Fcreate(name, flags) system call. "name" will be the name under which the fifo is known (maximum 13 characters); "flags" is explained below. The returned file handle is treated just like an ordinary file, and may be written to and read from (unless the fifo is unidirectional, in which case it may only be written to). The program that creates the fifo is normally called the "server". Other programs ("clients") may use the Fopen(name, mode) system call to open the other end of the fifo and read the data that the server writes, or write data for the server to read. When the last program (either client or server) using a fifo closes it, the fifo is deleted automatically. Note that one program can be both client and server, if it creates a fifo with Fcreate and then opens it again with Fopen. Also, children of the server can inherit the Fcreate'd file handle and thus have access to the "server" side of the fifo. The bits in the "flags" argument to Fcreate have the following meanings: 0x01: make fifo unidirectional (server can write, clients can read) 0x02: cause reads to return EOF if no other processes are writing, and writes to raise the SIGPIPE signal if no other processes are reading. The default action (if this flag is not given) is to block waiting for reads and writes 0x04: make the fifo a pseudo-tty; to client processes, the fifo will act just like a terminal with the server "typing" the characters; for example, if the server writes a ^C, SIGINT will be sent to clients Attempting to Fcreate() a fifo with the same name as an already existing one will result in an access error (i.e. the Fcreate will fail). Pipes may be created through the Fpipe() system call as well as through the Fcreate/Fopen pair; the former method is easier, since the kernel takes care of name conflicts, etc. Fifos may be locked by processes via the Fcntl system call, as follows: struct flock { short l_type; /* type of lock */ #define F_RDLCK 0 #define F_WRLCK 1 #define F_UNLCK 3 short l_whence; /* what is the lock relative to? */ /* 0 == start of file, 1 == current pos. in file, 2 == EOF */ long l_start; /* start of locked region */ long l_len; /* 0 for rest of file */ short l_pid; /* set by F_GETLK */ }; Fcntl(fd, &lock, F_SETLK): set a lock as specified by the lock structure. The current version of MiNT only understands locks on the whole FIFO, so lock.l_start and lock.l_len should both be 0. If lock.l_type is F_UNLCK, then the lock is released. Otherwise, the file whole file is locked (future versions of MiNT may distinguish between read and write locks, but for now all locks are treated as write locks (F_WRLCK) and block both reads and writes). If another process has locked the fifo, returns -36 (access denied). If a process holding a lock terminates, the fifo is automatically unlocked. Fcntl(fd, &lock, F_GETLK): if a lock exists on the fifo, set lock to indicate what kind of lock it is; otherwise, set lock.l_type to F_UNLCK. Locks are only "advisory"; that is, programs may ignore locks if they choose to do so. However, they are a good way to insure that two clients' data are not mixed together in a fifo. NOTE: file locking will eventually be implemented for all files, but for now only fifos support file locking. See the sample LPR and LPD utilites for a demonstration of how to use fifos. Shared memory: Children created with the Pexec(4,...) or with Pexec(104,...) share all of their parent's memory, as do children created with the Pvfork() system call. Hence, they may communicate with their parent (or with each other) via global variables. A more general shared memory mechanism is provided by U:\SHM. Files in that directory represent blocks of memory. A program may offer to share its memory by creating a file in U:\SHM and executing an Fcntl call (SHMSETBLK) to associate a block of memory with the file. Other programs may then open the file and do a SHMGETBLK call to gain access to that memory. Rendezvous: The Pmsg() system call provides a simple message based form of IPC. See the manual page for Pmsg for further details. The use of FIFOs is generally to be preferred to Pmsg(), since they are more flexible. Semaphores: Semaphores may be created and otherwise accessed via the Psemaphore system call. See the manual page for Psemaphore for more details. MiNT extensions to GEMDOS calls: Fsfirst/Fsnext: MiNT domain processes (see the Pdomain()) system call below) get lower case filenames from Fsfirst/Fsnext on a TOS filesystem. This is because most programs end up converting them to lowercase anyways, to be more Unix-like. *Please* don't do this translation yourself, let MiNT handle it -- some filesystems (e.g. the minix one) are case sensitive! If you really, truly, prefer uppercase filenames, run in the TOS domain. Pexec(100, name, cmdline, environment): Similar to Pexec(0, ...), except the calling program does not wait for the child to finish. Returns a negative error code, or the (positive) process I.D. of the child. Pexec(104, name, basepage, 0L): Similar to Pexec(4, ...); starts executing a basepage previously set up by Pexec mode 3, 5, or 7. The caller does not wait for the child to finish. Returns a negative error code, or the process I.D. of the child. Note that the child's environment and basepage are owned by both the child and the parent (indeed, the child shares all memory owned by the parent). "name" is a pointer to a string to be used to supply a name for the new process; if it is NULL, then the parent's name is used. Pexec(106, name, basepage, 0L): Similar to Pexec(104,...) except that the child's environment and basepage are *not* owned by the parent; nor does the child share any memory allocated to the parent. Pexec(200, name, cmdline, environment): As with Pexec(0,...) and Pexec(100,...) this runs a program. However, with this variant the caller is completely replaced with the executing program. The process retains its process i.d. and most other attributes, but all of its memory is freed and a new address space is set up for it containing the code from the indicated program. Whereas Pexec(0,...) is like a subroutine call, Pexec(200,...) is like a "goto". It returns only if an error occurs that makes it impossible to run the indicated program (e.g. if not enough memory is available, or the file is not found). New MiNT calls: See the manual pages in the man/ subdirectory for descriptions of these calls. void Syield(): [ GEMDOS 0xff ] word Fpipe( word *ptr ): [ GEMDOS 0x100 ] long Fcntl( word f, long arg, word cmd): [ GEMDOS 0x104 ] long Finstat( word f ): [ GEMDOS 0x105 ] long Foutstat( word f ) [ GEMDOS 0x106 ] long Fgetchar(word f, word mode): [ GEMDOS 0x107 ] long Fputchar( word f, long c, word mode ): [ GEMDOS 0x108 ] long Pwait(): [ GEMDOS 0x109 ] word Pnice( word delta ): [ GEMDOS 0x10a ] word Pgetpid(): [ GEMDOS 0x10b ] word Pgetppid(): [ GEMDOS 0x10c ] word Pgetpgrp(): [ GEMDOS 0x10d ] word Psetpgrp(pid, newgrp): [ GEMDOS 0x10e ] word Pgetuid(): [ GEMDOS 0x10f ] word Psetuid( word id ): [ GEMDOS 0x110 ] word Pkill( word pid, word sig ): [ GEMDOS 0x111 ] long Psignal(word sig, long handler): [ GEMDOS 0x112 ] word Pvfork(): [ GEMDOS 0x113 ] word Pgetgid(): [ GEMDOS 0x114 ] word Psetgid(word id): [ GEMDOS 0x115 ] long Psigblock(long mask): [ GEMDOS 0x116 ] long Psigsetmask(long mask): [ GEMDOS 0x117 ] long Pusrval(long arg): [ GEMDOS 0x118 ] word Pdomain(word newdom): [ GEMDOS 0x119 ] void Psigreturn(): [ GEMDOS 0x11a ] word Pfork(): [ GEMDOS 0x11b ] long Pwait3(word flag, long *rusage): [ GEMDOS 0x11c ] word Fselect(word timeout, long *rfds, long *wfds, long *xfds): [ GEMDOS 0x11d ] void Prusage( long r[8] ): [ GEMDOS 0x11e ] long Psetlimit(word lim, long value): [ GEMDOS 0x11f ] long Talarm( long secs ): [ GEMDOS 0x120 ] void Pause(): [ GEMDOS 0x121 ] long Sysconf( word n ): [ GEMDOS 0x122 ] long Psigpending() [ GEMDOS 0x123 ] long Dpathconf( char *name, word n ): [ GEMDOS 0x124 ] long Pmsg( word mode, long mbox, void *msg ): [ GEMDOS 0x125 ] long Fmidipipe( word pid, word in, word out ): [ GEMDOS 0x126 ] word Prenice( word pid, word delta ): [ GEMDOS 0x127 ] long Dopendir( char *name, word flag ): [ GEMDOS 0x128 ] long Dreaddir( word buflen, long dir, char *buf):[GEMDOS 0x129 ] long Drewinddir( long dir ): [ GEMDOS 0x12a ] long Dclosedir( long dir ): [ GEMDOS 0x12b ] long Fxattr( word flag, char *name, void *buf ):[ GEMDOS 0x12c ] long Flink( char *oldname, char *newname ): [ GEMDOS 0x12d ] long Fsymlink( char *oldname, char *newname ): [ GEMDOS 0x12e ] long Freadlink( word siz, char *buf, char *name):[GEMDOS 0x12f ] long Dcntl( word cmd, char *name, long arg ): [ GEMDOS 0x130 ] long Fchown( char *name, word uid, word gid): [ GEMDOS 0x131 ] long Fchmod( char *name, word mode ): [ GEMDOS 0x132 ] word Pumask( word mask ): [ GEMDOS 0x133 ] long Psemaphore(word mode, long id, long timeout): [ GEMDOS 0x134 ] word Dlock( word mode, word drive ): [ GEMDOS 0x135 ] void Psigpause( long sigmask ): [ GEMDOS 0x136 ] long Psigaction( word sig, long act, long oact):[ GEMDOS 0x137 ] long Pgeteuid(): [ GEMDOS 0x138 ] long Pgetegid(): [ GEMDOS 0x139 ]