Introduction

I. Introduction

• I.1. Preface
• I.2. Special directories
• I.3. Background processes
• I.4. Pipes
• I.5. Job control

I.1. Preface

MiNT is a replacement for GEMDOS. It is designed to provide the same kind of services as GEMDOS (file and process management, primarily) but with extensions to permit such things as multitasking, interprocess communication, job control, and a flexible file system interface that permits loadable file systems and device drivers.

This document does not discuss the new, multitasking Desktop or utility programs such as MINIWIN or tcsh. Refer to other documents for descriptions of these programs. MiNT exists to make your job as a developer easier. You can use MiNT system calls to do things like run background processes, to set up interprocess communication, to examine files on disk, or in more advanced applications to install new kinds of device drivers or file systems. Your programs generally don't need to know about MiNT unless they want to take advantage of new MiNT features; the old GEMDOS calls are still supported for backwards compatibility.

Our discussion of MiNT will begin with some of the changes visible to all users, and then continue with tips about programming MiNT.

I.2. Special directories

MiNT provides a fake disk drive called u: (for unified). There are directories in the root of this drive which contain files special to MiNT. These files are not real files, but may represent other objects such as devices or executing programs. Ordinary file-access calls are used to deal with them; for instance, writing to u:\dev\con is like writing to the console (as distinct from stdout).

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. The following devices are available by default in u:\dev (additional device drivers may be installed by applications):

The std* file handles are useful for providing I/O redirection to programs that normally require file names on the command line, so you can run such a program in a pipeline.

 u:\pipe

Contains files which are FIFO queues (e.g. pipes). All files created in u:\pipe 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. See the section on FIFOs later in this guide.

 u:\proc

Contains special files that represent all currently executing processes, and their states (such as whether they're running, ready, or waiting, their process ID numbers, and the amount of memory they've taken.) The files will have names like GEM.001; this means that the process name is GEM (usually because it was started from a file like GEM.SYS), and its process ID is 1. You can rename processes just as if they were files, except that any extension you give is always replaced with the process ID (e.g. if you rename GEM.001 to FOO.BAR, it will really become FOO.001). The size of a process file is the amount of memory that is allocated to it. Note that this is the sum of all memory that the process may access. The entire size of a shared memory block will be added to every process which has access to the block. The date and time stamp of a process file is the data and time that the process was started. A process' current state is reflected by the attribute bits of the file; most of these are not visible from the Desktop, but can be checked by programs such as ps or top. Here are the attribute byte combinations for process files on u:\proc and their meanings:

The zombie state is for processes which have exited, but whose parents haven't yet learned their exit codes. 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 TSR or zombie processes.

u:\shm

u:\shm is a place for shared memory. Processes may create files in this directory which represent blocks of memory that they wish to share with other processes. This provides a very fast method of interprocess communication. See the section on Shared Memory later in this guide.

Other directories on drive u: are actually other drives. u:\c is drive c:, so the file c:\mint\mw.prg, for instance, is also visible as u:\c\mint\mw.prg

I.3. Background processes

Programs may be started in the background. The easiest way to do this is with the MultiTOS desktop. It can also be done with CLIs such as tcsh or a similar shell. In tcsh you can say something like:

% cd \foo\src
% make >& errors &

This runs make and redirects both its standard output and its error output to a file called errors. The final & means in the background. The shell starts the program, then comes back for another command without waiting for the program to finish running. A background process that tries to write to the console will stop, which is why the example redirects the output of make. In the shell, the command fg will bring a stopped process to the foreground. In addition, the command stty -tostop (read that as set tty, no terminal-output stop) turns off the stop-on-output feature. The maximum number of processes MiNT can manage simultaneously is 1000.

I.4. 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 a limited amount of data can be held in a pipe at once; when a process tries to write more data, it is suspended until another process empties the pipe by reading some data. If there are no more readers, a process writing on a pipe is terminated. Writes of 1K or less to a pipe are atomic, that is, if you make an Fwrite call with 1024 or fewer bytes, these bytes are guaranteed to be written together; if you try to write more than 1024 bytes to a pipe, it's possible that your data will be interleaved with the data of some other process writing to the same pipe, or for a process reading from the pipe to get your data in chunks, rather than all at once. Again, with tcsh it is easy to demonstrate the use of pipes:

% ls -lt | head

This is a pipeline. The first stage of the pipeline is the program ls which has -lt as its argument. That is, list directory, long form, sorted by date (most recent first). The output of ls is passed as input to the next stage of the pipeline, head. This program displays only the first 10 lines of its input. The resulting output from this pipeline, then, is a listing of the 10 most recent files in the current directory.

I.5. Job control

MiNT supports 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. tcsh sends this signal when you use the fg command. tcsh's bg command restarts stopped processes, too, but does so in the background, so they'll stop again if they attempt input or output. 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.

More sophisticated job control facilities can be provided by shells that are specifically written with MiNT in mind. tcsh demonstrates this. Jobs run in the background from such shells are automatically stopped when they attempt to read from the terminal or write to it. Thus, you can run a long compile in the background, and if an error occurs and the compiler attempts to write on the screen, it will be stopped. Some other special keys that MiNT interprets are:

Ctrl-Alt-Del
Provides a (warm) boot, as in TOS >= 1.4; with the right shift key, you get a cold boot.

Some other keys are recognized by MiNT if the process is doing I/O in cooked mode:

^C (CTRL-C)
Interrupt the 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.

^\ (quit)
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.

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, e.g. Ctrl-Alt-C will always send SIGINT to 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.