Return to mint.doc CVS log

Up to [Atari MiNT] / MiNT / doc

MiNT 0.96 pl14

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.)



alias d: c:\path

	Creates a "fake" drive (with letter d:) which actually points

	to the directoy "c:\path". Access to files on d: are translated

	appropriately (e.g. "d:\foo" is the same as "c:\path\foo").

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.



MiNT provides a fake "disk drive", drive U:, which 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.



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 drive U: so that the desktop can recognize it. Otherwise, you

can use the "alias" command in your mint.cnf file to set up aliases for

drive U:, and (if you like) for the special subdirectories of U:, e.g.

	alias o: u:

	alias p: u:\proc



Some older MiNT programs may expect the aliases:

	alias q: u:\pipe

	alias v: u:\dev

	alias x: u:\proc





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", 2));

	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:", 2) 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.



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 ]

long Pwaitpid( word pid, word flag, long *rusage): [GEMDOS 0x13a ]

This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.