%
% GNO Kernel Reference Manual
%
% $Id: kern.tex,v 1.3 1997/11/30 06:49:42 gdr Exp $
% 

\documentclass{report}
\usepackage{html}
\usepackage{makeidx}
\makeindex
\bodytext{bgcolor=#ffffff}
\begin{document}

\title{GNO Kernel Reference Manual}
\author{By Jawaid Bazyar \\ Edited by Andrew Roughan and Devin Reade}
\date{19 November 1997}
\maketitle

\begin{latexonly}
\tableofcontents
\end{latexonly}

\parindent=0pt
\parskip=1pc

%
%	CHAPTER:  Introduction
%

\begin{latexonly}
\chapter{Introduction}
\end{latexonly}
\begin{htmlonly}
\chapter{Chapter 1:  Introduction}
\end{htmlonly}

The GNO kernel is the heart of the GNO Multitasking Environment
(GNO/ME).  The GNO kernel provides a
layer of communication between the shell (and shell-based
programs) and the operating system, GS/OS. The kernel handles
such things as multitasking, 
\index{background} 
background processes, foreground
processes and many other features that were not previously
available on the Apple IIGS. It is these features which make
GNO/ME very powerful.

This reference manual is highly technical
in nature and is provided to help programmers develop utilities
for the GNO Multitasking Environment. The beginner has no need to
read this manual and is certainly not expected to understand its
contents. However, Chapter 5 \bf Process Management \rm and
Chapter 6 \bf Interprocess Communication \rm provide a good
background discussion for anyone who is interested in the
internal workings of the kernel.

%
%	CHAPTER:  GNO Compliance
%

\begin{latexonly}
\chapter{GNO Compliance}
\end{latexonly}
\begin{htmlonly}
\chapter{Chapter 2:  GNO Compliance}
\end{htmlonly}

For a program to work effectively under
GNO/ME, certain rules must be followed. Most of these rules boil
down to one underlying concept --- 
\bf never directly access features of the machine\rm .
Always use GS/OS, the ToolBox, or
GNO/ME to accomplish what you need. We have taken great care to
provide the sorts of services you might need, such as checking
for input without having to wait for it. GNO/ME compliance isn't
just a matter of trying to make applications work well under the
environment; it ensures that those applications stay compatible,
no matter what changes the system goes through. Below are
summarized the points you must consider when you're writing a
GNO/ME compliant application.

\section{Detecting the GNO Environment}

If your application requires the GNO Kernel
to be active (if it makes any kernel calls), you can make sure of
this by making a \bf kernStatus \rm  call at the beginning of your
program. The call will return no error if the kernel is active,
or it will return an error code of \$0001 (Tool locator --- tool not
found), in which case the value returned will be invalid. The
call actually returns a 1 if no error occurs, but the value
returned will be indeterminate if the kernel is not active, so
you should only check for an error (the function  
\index{toolerror} \bf toolerror\rm (3) or the variable 
\index{\_{}toolErr} \bf \_{}toolErr \rm in C,
\index{assembly language programs}
the value in the A register in assembly).

You can also determine the current version
of the GNO Kernel by making the \bf kernVersion \rm call. The
format of the version number returned is the same as the standard
ToolBox calls. For example a return value of \$0201 indicates a
version of 2.1.

\bf kernStatus \rm and \bf kernVersion \rm 
are defined in the \tt <gno/gno.h> \rm
header file.

\section{Terminal I/O}

The Apple II has always been lacking in
standardized methods for reading keyboard input and controlling
the text screen. This problem was compounded when Apple stopped
supporting the TextTools in favor of the GS/OS 
\index{driver!console} console driver.
The console driver has a number of problems that prevent it from
being a good solution under GNO/ME. There is high overhead
involved in using it. It is generally accessed like a regular
file, which means any I/O on it must filter through several
layers before being handled. Even though in System 6.0.1 there is
a provision for patching the low-level routines the special
high-level user input features of the driver cannot be used over
a modem or in a desktop program. And GS/OS must be called to
access it, which means that while a console driver access is
occurring, no other processes can execute. See Chapter 3 \bf Mutual
Exclusion in GS/OS and ToolBox calls\rm .

GNO/ME ignores the GS/OS 
\index{.CONSOLE}
\tt .CONSOLE \rm driver and replaces
the TextTools with a high performance, very flexible
generic terminal control system.  GNO/ME directly supports the
console (keyboard and screen), as well as the serial ports, as
terminals. In order for a user program to take advantage of these
features and to be GNO/ME compliant, you must do terminal I/O
only through the TextTools, or through stdin, stdout, and stderr
(refNums 1,2, and 3 initially) via GS/OS. By its very nature
TextTools is slow, so we recommend using them only for small and
simple tasks. Calls to the GS/OS console driver will not crash
the system, but they will make other processes stop until the
call is completed.

You must not get input directly from the
keyboard latch (memory location \$E0/C000,
nor may you write directly to the screen memory.
GNO/ME's terminal I/O system has been designed so you don't have
to do either of these things. If you need to check for keyboard
input without stopping your application, you can make the
appropriate  \bf ioctl\rm(2) call to do what you need.

In the future, GNO/ME may provide a
GNO/ME-friendly version of the GS/OS 
\index{.CONSOLE}
\tt .CONSOLE \rm driver.

\section{Stack Usage}

Stack space is at a premium on the Apple IIgs.  Process
stacks can only be located in \index{bank zero}
Bank 0 --- a total of 64k. This
theoretical limit doesn't apply, however, as GS/OS and other bits
of system software reserve a large chunk of this without any way
to reclaim it. There is approximately 48K of usable stack space.
This space also has to be shared with direct page space for Tools
and certain types of device drivers, however. For a program to be
GNO compliant, stack usage analysis must be done and acted upon.
Use of the stack should be minimized so that many processes can
coexist peacefully. From experience we've found that 1K usually
suffices for well-written C applications, and at a maximum 4K can
be allocated.

\index{assembly language programs}
Assembly language programs tend to be very
efficient when it comes to use of the stack. The 4K provided by
default to applications is usually more than enough for assembly
language programs. C programs can use up tremendous amounts of
stack space, especially if recursion is employed or string
manipulation is done without concern for stack usage; however,
even assembly programs can be written poorly and use a lot of
stack space. Below are some hints to keep stack usage at a
minimum.

\begin{enumerate}
\item
Avoid use of large local arrays and character strings. 
Instead, dynamically allocate large structures such as 
GS/OS strings with  \bf malloc\rm (3) or
the Memory Manager. Alternatively, you can designate such
items as \tt ''static''\rm , which causes the C compiler to
allocate the space for the variable from main memory.


\item
Try not to use recursion unless absolutely necessary. All recursive
functions can be rewritten using standard loops and creative programming.
This is a good general programming rule because your program will run
faster because setting up stack frames is expensive in terms of
time and memory.

\item
ORCA/C 1.3 (and older) generates 8K of
stack by default, in case the desktop is started up.
Since GNO/ME compliant programs generally will not be
desktop-based, make sure you judge how much stack your
program will require and use the \tt \#pragma stacksize \rm directive 
(or the \bf occ\rm (1) \bf -S \rm flag)
to limit how much stack space ORCA/C tries to
allocate for your program. Also, since ORCA/C 1.3 programs
don't use the stack given them by GNO/ME and GS/OS, when
you link your program include a small (256 bytes) stack
segment. See the utilities sources for examples of this.
ORCA/C 2.0.x (and later) allocates stack via the GS/OS supported
method, so ORCA/C 2.0 programs use exactly the amount of
stack specified by \tt \#pragma stacksize\rm .

\end{enumerate}

\section{Disk I/O}

Since the Apple IIgs doesn't have
coprocessors to manage disk access and the serial ports, either
of these requires the complete attention of the main 
\index{65816 processor}
65816 processor.
This can wreak havoc in an environment with slow disks
or high-speed serial links, as accessing disks usually results in
turning off interrupts for the duration of the access. This
situation is lessened considerably with a DMA disk controller,
such as the Apple High Speed SCSI or CV Technologies RamFAST. But
this isn't as bad as it sounds; the IBM PC and Apple Macintosh
also suffer from this problem, and the solution is robust
programming. Make sure your communications protocol can handle
errors where expected data doesn't arrive quite on time, or in
full. The best solution would be an add-on card with serial ports
and an on-board processor to make sure all serial data was
received whether or not the main processor was busy (this is a
hint to some enterprising hardware hacker, by the way).

Yet another concern for GNO/ME applications
is file sharing. GS/OS provides support for file sharing, but it
is up to the application author to use it via the requestAccess
field in the \tt OpenGS \rm call.
GS/OS only allows file sharing if all current
references to a file (other instances of the file being opened)
are read-only. GNO/ME authors should use read-only access as much
as possible. For example, an editor doesn't need write permission
when it's initially reading in a file. Note that the  \bf fopen\rm (3)
library routine in ORCA/C 1.2 does NOT support read-only mode
(even if you open the file with a 'r' specificier), but it does
in ORCA/C 1.3 and later.

\section{Non-Compliant Applications}

GNO/ME wasn't really designed with the
intention of making EVERY program you currently run work under
GNO/ME; that task would have been impossible. Our main goal was
to provide a UNIX-based multitasking environment; that we have
done. We made sure as many existing applications as we had time
to track and debug worked with GNO/ME. The current list of
compatible and non-compatible applications can be found in the
file ''RELEASE.NOTES'' on the GNO/ME disk.

However, due to the sheer number of
applications and authors, there are some programs that just plain
don't work; and some that mostly work, except for annoyances such
as two cursors appearing, or keyboard characters getting 'lost'.
The problem here is that some programs use their own text drivers
(since TextTools output was very slow at one time); since GNO/ME
doesn't know about these custom drivers, it goes on buffering
keyboard characters and displaying the cursor. There is a way,
however, to tell GNO/ME about these programs that break GNO/ME's
rules.

\index{auxType}
We've defined an auxType for S16 and EXE
files, to allow distinction between programs that are GNO/ME
compliant and those that are not. Setting the auxType of an
application to \$DC00 disables the interrupt driven keyboard
buffering and turns off the GNO/ME cursor. Desktop programs use
the GNO/ME keyboard I/O via the Event Manager, and thus should \em not \rm
have their auxType changed.

You can change a program's auxType with the
following shell command:

\index{chtyp}
\begin{verbatim}
    chtyp -a \$DC00 filename
\end{verbatim}

where filename is the name of the
application. As more programmers become aware of GNO/ME and work
to make their software compatible with it, this will become less
of a problem, but for older applications that are unlikely to
ever change (like the America OnLine software), \$DC00 is a
reasonable approach.

%
%	CHAPTER:  Modifications to GS/OS
%

\begin{latexonly}
\chapter{Modifications to GS/OS}
\end{latexonly}
\begin{htmlonly}
\chapter{Chapter 3:  Modifications to GS/OS}
\end{htmlonly}

The GNO system modifies the behavior of a
number of GS/OS calls in order to allow many programs to execute
concurrently, and to effect new features. The changes are done in
such a way that old software can take advantage of these new
features without modification. Following is a complete
description of all the changes made. Each section has details in
text, followed by a list of the specific GS/OS or ToolBox calls
affected.

\section{Mutual Exclusion in GS/OS and ToolBox Calls}

The Apple IIGS was not designed as a
multitasking machine, and GS/OS and the Toolbox reflect this in
their design. The most notable problem with making multitasking
work on the Apple IIgs is the use of global (common to all
processes) information, such as prefixes and direct page space
for tool sets which includes information like SANE results,
QuickDraw drawing information, etc. In most cases we've corrected
these deficiencies by keeping track of such information on a
per-process basis, that is, each process has its own copy of the
information and changes to it do not affect any other process'
information.

However, there were many other situations
where this could not be done. Therefore, there is a limit of one
process at a time inside either GS/OS or the ToolBox. GNO/ME
automatically enforces this restriction whenever a tool or GS/OS
call is made.

The method and details of making GS/OS
calls does not change! The calls listed below have been expanded
transparently. There are no new parameters and no new parameter
values. In all cases, the corresponding ProDOS-16 interface calls
are also supported, except ExpandPath and other calls which do
not exist in ProDOS-16.

\section{Pathnames and Prefixes}

Normally under GS/OS there are 32 prefixes,
and these are all under control of the current application.
GNO/ME extends this concept to provide each process with it's own
copies of all prefixes. When a process modifies one of these
prefixes via the GS/OS SetPrefix call, it modifies only it's own
copy of that prefix --- the same numbered prefixes of any other
processes are not modified. 

Pathname processing has been expanded in
GNO/ME. There are now two new special pathname operators that are
accepted by any GS/OS call that takes a pathname parameter:

\begin{verbatim}
    .    current working directory
    ..   parent directory
\end{verbatim}

For example, presume that the current
working directory (prefix 0) is \tt /foo/bar/moe\rm.
``\tt./ls\rm'' refers to the file ``\tt/foo/bar/moe/ls\rm'',
and since a pathname was specified, this overrides the shell's hash table. 
``\tt../ls\rm`` refers to ``\tt/foo/bar/ls\rm''.
The operators can be combined, also, as in
``\tt../../ls\rm'' (``\tt/foo/ls\rm''), and
``\tt./.././ls\rm'' (``\tt/foo/bar/ls\rm'').
As you can see, the '.' operator is simply
removed and has no effect other than to force a full expansion of
the pathname.

Shorthand 
\index{device!names}
device names (.d2, .d5, etc) as are used in the ORCA/Shell
are available only under System Software 6.0 and later.
The common pathname operator '\~' (meaning the home
directory) is handled by the shell; if the character appears in a
GS/OS call it is not treated specially.

\index{ChangePath}
\index{ClearBackupBit}
\index{Create}
\index{Destroy}
\index{ExpandPath}
\index{GetFileInfo}
\index{GetPrefix}
\index{Open}
\index{SetFileInfo}
\index{SetPrefix}

\begin{tabular}{ll}
\$2004 & ChangePath \\
\$200B & ClearBackupBit \\
\$2001 & Create \\
\$2002 & Destroy \\
\$200E & ExpandPath \\
\$2006 & GetFileInfo \\
\$200A & GetPrefix \\
\$2010 & Open \\
\$2005 & SetFileInfo \\
\$2009 & SetPrefix \\
\end{tabular}


\section{Named Prefixes}

In order to allow easy installation and
configuration of third-party software into all systems, GNO/ME
provides a feature called named prefixes. These prefixes are
defined in the 
\index{/etc/namespace}
/etc/namespace file. Basically, since all UNIX
systems have /bin, /usr, /etc, and other similar standard
partitions, but Apple IIgs systems generally do not have these
partitions, named prefixes provide a way to simulate the UNIX
directories without forcing GNO/ME users to rename their
partitions (an arduous and problem-filled task).

Named prefixes are handled by the GNO
kernel in the same GS/OS calls described in Chapter 3 \bf Pathnames
and Prefixes\rm.

\section{Open File Tracking}

Previously, a major problem with the way
GS/OS handled open files was that unrelated programs could affect
each other's open files. For example, a Desk Accessory (or a
background program of any sort) could open a file and have it
closed without it's knowledge by the main application program.
This presented all kinds of problems for desk accessory authors.
Apple presented a partial solution with System Software 5.0.4,
but it wasn't enough for a true multitasking environment. GNO/ME
keeps track of exactly which process opened which file. It also
discontinues the concept of a global File Level, opting instead
for a per-process File Level. Any operations a process performs
on a file (opening, closing, etc.) do not affect any other
process' files.

In addition to this behavior, when a
process terminates in any manner all files that it currently has
opened will be closed automatically. This prevents problems of
the sort where a program under development terminates abnormally,
often leaving files open and formerly necessitating a reboot.

The Flush GS/OS call is not modified in
this manner as its effects are basically harmless.

\index{Close}
The Close call accepts a refNum parameter
of 0 (zero), to close all open files. This works the same way
under GNO/ME, except of course that only the files of the process
calling Close are in fact closed.

\begin{tabular}{ll}
\$2010 & Open \\
\$2014 & Close \\
\$201B & GetLevel \\
\$201A & SetLevel \\
\end{tabular}

\section{Quitting Applications}

The QUIT and QuitGS calls have been
modified to support the GNO/ME process scheme. Quitting to
another application, whether by specifying a pathname or by
popping the return stack, is accomplished with \bf execve\rm(2).
When there are no entries on the return stack, the process is
simply killed. See the \it GS/OS Reference Manual \rm for more
details on how the Quit stack works.

\section{Refnums and File Descriptors}

GS/OS tells you about open files in the
form of refNums (reference numbers). UNIX's term for the same
concept is ``file descriptor''. From a user's or programmer's view
of GNO/ME, these terms are identical and will be used as such;
which one depends on what seems most appropriate in context.

For each process, GNO/ME keeps track of
which files that particular process has opened. No other process
can directly access a file that another process opened (unless
programmed explicitly), because it doesn't have access to any
file descriptors other than its own. This is different from GS/OS
in that GS/OS allows access to a file even if a program guessed
the refNum, either deliberately or accidentally. This is one of
the aspects of process protection in GNO/ME.

All of the various I/O mechanisms that
GNO/ME supports (files, pipes, and TTYs) are handled with the
same GS/OS calls you are familiar with. When you create a pipe,
for example, you are returned file descriptors which, because of
synonymity with refNums, you can use in GS/OS calls. Not all
GS/OS calls that deal with files are applicable to a particular
file descriptor; these are detailed in the sections on pipes and
TTYs.

GNO/ME sets no limit on the number of files
a process may have open at one time. (Most UNIX's have a set
limit at 32).

\section{GNO/ME Character Devices}

\index{device!character|(}
GNO/ME supports a new range of character
device drivers. These drivers are not installed like normal GS/OS
drivers, but they are accessed the same way. There are the
following built-in drivers:

\begin{rawhtml}
<!-- cleantable-start -->
\end{rawhtml}
\begin{tabular}{ll}
\bf .TTYCO \rm	& 
\begin{minipage}[t]{8cm}
% latex2html gets confused here
\begin{rawhtml}
</b>
\end{rawhtml}
	This is the GNO/ME console driver. The driver supports
	the TextTools Pascal control codes, plus a few GNO/ME
	specific ones. These are documented in Chapter 4
	\bf TextTools Replacement\rm. This driver is highly
	optimized both through the GS/OS and TextTools interfaces.
\end{minipage} \hfill \\

\index{.pty}
\index{.tty}
\bf .TTYA[0-9,A-F] \rm	\\
\bf .PTYQ[0-9,A-F] \rm &
\begin{minipage}[t]{8cm}
	Pseudo-terminal devices; PTYs are used for interprocess
	communication and in network activities.
\end{minipage} \hfill \\

\index{.NULL}
\bf .NULL \rm	& 
\begin{minipage}[t]{8cm}
	This driver is a bit bucket. Any data written	to it is
	ignored, and any attempt to read from it results in an
	end-of-file error (\$4C).
\end{minipage} \hfill \\
\end{tabular}
\begin{rawhtml}
<!-- cleantable-end -->
\end{rawhtml}

Just as with GS/OS devices, these GNO/ME
drivers are accessed with the same 
\index{Open}
\index{Read}
\index{Write}
\index{Close}
Open, Read, Write, and Close
calls that are used on files. Unlike GS/OS character devices, the
characteristics of GNO/ME drivers are controlled through the 
\bf ioctl\rm(2) system call. The GS/OS Device calls (like DInfo, DStatus)
are not applicable to GNO/ME drivers. See the \bf ioctl\rm(2) and 
\bf tty\rm(4) man pages for details.

Some GS/OS calls will return an error when
given a refNum referring to a GNO/ME character driver or pipe
because the concepts simply do not apply. The error returned will
be \$58 (Not a Block Device), and the calls are as follows:

\begin{tabular}{ll}
\$2016 & SetMark \\
\$2017 & GetMark \\
\$2018 & SetEOF \\
\$2019 & GetEOF \\
\$2015 & Flush \\
\$201C & GetDirEntry \\
\end{tabular}

GNO/ME loaded drivers (generally for serial
communications, but other uses are possible) are configured in the 
\index{/etc/tty.config} \bf /etc/tty.config \rm file.
Each line in \index{/etc/tty.config}
\bf /etc/tty.config \rm describes one driver. The format of each line is:

\begin{verbatim}
    filename slot devname
\end{verbatim}

\bf devname \rm is the name of the device as
it will be accessed (for example, 
\index{.ttya}
\bf.ttya\rm). \bf slot \rm is the slot in the
device table from where the device will be accessed; it may refer
to one of the physical expansion slots, as TextTools will use the
specified driver when redirecting output to a slot. The \bf modem \rm
and \bf printer \rm port drivers are configured for slots 2 and 1,
respectively.

Pseudo-terminals are pre-configured into
the kernel. PTYs are discussed further in Chapter 6 \it Psuedo-Terminals
PTYs\rm.

Since .ttyco and the pseudo-terminals are
preconfigured in the GNO kernel, entries for these devices do
not appear in \index{/etc/tty.config} \bf /etc/tty.config\rm.
\index{device!character|)}

\section{Restartability}

GS/OS supports the concept of program
``restartability''. This allows programs which are written in a
certain way to remain in memory in a purgeable state so that if
they are invoked again, and their memory has not been purged,
they can be restarted without any disk access. This greatly
increases the speed with which restartable programs can be
executed.

The ORCA environment specifies whether or
not a program is restartable via a flag character in the SYSCMND
file. The GS/OS standard method, however, is to set the
appropriate flags bit in the GS/OS Quit call. This is the method
that GNO/ME supports. Provided with the GNO/ME standard library
is a routine \bf rexit\rm(3). \bf rexit\rm (3) only works with
ORCA/C 2.0. \bf rexit\rm(3) works just like the normal C \bf exit\rm(3)
call but it sets the restart flag when calling QuitGS.

The standard ORCA/C 1.3 libraries are not
restartable, but the ORCA/C 2.0 libraries are.

\section{Miscellaneous}

The following miscellaneous GS/OS calls have also been modified for GNO/ME:

\begin{rawhtml}
<!-- cleantable-start -->
\end{rawhtml}
\begin{tabular}{ll}
\$2027 GetName	  &
\begin{minipage}[t]{8cm}
	\begin{rawhtml}
	</b>
	\end{rawhtml}
	Returns the name on disk of the process. This only
	returns valid information after an \bf execve\rm(2).
\end{minipage} \hfill \\

\$2003 OSShutdown & 
\begin{minipage}[t]{8cm}
	This call has been modified to kill all processes before
	performing the actual shutdown operation.
\end{minipage} \hfill \\
\end{tabular}
\begin{rawhtml}
<!-- cleantable-end -->
\end{rawhtml}


%
%	CHAPTER:  Modifications to the Toolbox
%

\begin{latexonly}
\chapter{Modifications to the ToolBox}
\end{latexonly}
\begin{htmlonly}
\chapter{Chapter 4:  Modifications to the ToolBox}
\end{htmlonly}

Several changes have been made to the
ToolBox, the most major of which is the replacement of the entire
TextTools tool set. The TextTools were replaced for a number of
reasons --- better control over text I/O, increased speed, and
emulation of ORCA's redirection system with as little overhead as
possible. Other changes were made to modify the behavior of some
tool calls to be more consistent with the idea of a multitasking
environment.

\section{TextTools Replacement}

The changes to the TextTools have turned it
into a much more powerful general I/O manager. The TextTools now
intrinsically handle pipes and redirection, and you can install
custom drivers for TextTools to use. Also, the TextTools have had
their old slot-dependence removed; the parameter that used to
refer to 'slot' in the original texttools calls now refers to a
driver number. A summary of driver numbers (including those that
come pre-installed into GNO) are as follows:

\index{device!driver}
\begin{tabular}{ll}
\bf{0}		& null device driver \\
\bf{1}		& serial driver (for printer port compatibility) \\
\bf{2}		& serial driver (for modem port compatibility) \\
\bf{3}		& console driver (Pascal-compatible 80-column text screen) \\
\bf{4--5}	& user installed \\
\end{tabular}

See Chapter 3 \bf GNO/ME Character Devices\rm,
for information on configuring these drivers.

There are also new device types in the
TextTools; the complete list of supported device types and what
their slotNum's (from SetInputDevice, SetOutputDevice, etc) mean
is as follows:

\index{device!types|(}

\begin{rawhtml}
<!-- cleantable-start -->
\end{rawhtml}

\begin{tabular}{rll}
\begin{minipage}[t]{1cm}
	\sloppy
	\bf Type \rm
\end{minipage} \hfill &
\begin{minipage}[t]{5cm}
	\sloppy
	\begin{center}
	\bf Use \rm 
	\end{center}
\end{minipage} \hfill &
\begin{minipage}[t]{5cm}
	\sloppy
	\bf slotNum \rm
\end{minipage} \hfill \\ \cline{1-3}


\begin{minipage}[b]{1cm}
	\sloppy 
	\bf 0 \rm
\end{minipage} \hfill &
\begin{minipage}[t]{5cm}
	\sloppy
	Used to be \index{BASIC} BASIC text drivers. These
	are no longer supported under GNO/ME, and setting I/O to
	a BASIC driver actually selects a Pascal driver.
\end{minipage} \hfill &
\begin{minipage}[t]{5cm}
	\sloppy
	Not applicable.
\end{minipage} \hfill \\


\begin{minipage}[b]{1cm}
	\sloppy 
	\bf 1 \rm
\end{minipage} \hfill &
\begin{minipage}[t]{5cm}
	\sloppy
	Pascal text driver. This is one of the drivers specified in 
	\index{/etc/ttys} /etc/ttys or built-in to GNO/ME.
\end{minipage} \hfill &
\begin{minipage}[t]{5cm}
	\sloppy
	Driver number as listed above.
\end{minipage} \hfill \\


\begin{minipage}[b]{1cm}
	\sloppy 
	\bf 2 \rm
\end{minipage} \hfill &
\begin{minipage}[t]{5cm}
	\sloppy
	RAM-based Driver (documented in \it ToolBox Reference Volume 2\rm)
\end{minipage} \hfill &
\begin{minipage}[t]{5cm}
	\sloppy
	Pointer to the RAM-based driver's jump table.
\end{minipage} \hfill \\


\begin{minipage}[b]{1cm}
	\sloppy 
	\bf 3 \rm
\end{minipage} \hfill &
\begin{minipage}[t]{5cm}
	File redirection
\end{minipage} \hfill &
\begin{minipage}[t]{5cm}
	refNum (file descriptor) of the file to access through TextTools.
\end{minipage} \hfill \\
\end{tabular}
\begin{rawhtml}
<!-- cleantable-end -->
\end{rawhtml}

% This is an attempt to do without the kludge below.  Just comment it
% out for now
\begin{comment}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%
% This is a really annoying kludge-fuck.
%
% latex2html doesn't currently seem to handle \parbox correctly.
% On the other hand, using \begin{verbatim} mode makes this table
% look ugly in postscript.  Piece of crap.
%
% So instead we resort to duplicating this information.  Be careful
% to update both versions, please.
%

\begin{latexonly}
\begin{tabular}{rll}
\parbox[b]{1cm}{
	\sloppy 
	\bf Device Type \rm
} &
\parbox[t]{5cm}{
	\sloppy
	\bf Use \rm
} &
\parbox[t]{5cm}{
	\sloppy
	\bf slotNum \rm
} \\ \cline{1-3}

\parbox[t]{1cm}{
	\sloppy 
	\bf 0 \rm
} &
\parbox[t]{5cm}{
	\sloppy
	Used to be BASIC text drivers. These
	are no longer supported under GNO/ME, and set-\\ting I/O to
	a BASIC driver actually selects a Pascal driver.
} &
\parbox[t]{5cm}{
	\sloppy
	Not applicable.
} \\

\parbox[t]{1cm}{
	\sloppy 
	\bf 1 \rm
} &
\parbox[t]{5cm}{
	\sloppy
	Pascal text driver. This is one of
	the drivers specified in /etc/ttys or built-in to GNO/ME.
} &
\parbox[t]{5cm}{
	\sloppy
	Driver number as listed above.
} \\


\parbox[t]{1cm}{
	\sloppy 
	\bf 2 \rm
} &
\parbox[t]{5cm}{
	\sloppy
	RAM-based Driver (documented in \it ToolBox Reference Volume 2\rm)
} &
\parbox[t]{5cm}{
	\sloppy
	Pointer to the RAM-\\based driver's jump table.
} \\


\parbox[t]{1cm}{
	\sloppy 
	\bf 3 \rm
} &
\parbox[t]{5cm}{
	\sloppy
	File redirection
} &
\parbox[t]{5cm}{
	\sloppy
	refNum (file descriptor) of the file to access through TextTools.
} \\
\end{tabular}
\end{latexonly}

%
% This is the html version.  The tables look strange because of the
% formatting commands.  They actually line up if those commands are 
% removed.
%

\begin{htmlonly}
\begin{rawhtml}
<pre>
<b>Device
 Type			Use			slotNum
-------------------------------------------------------------------</b>
<b>0</b>	Used to be BASIC text drivers. These	Not Applicable
	are no longer supported under GNO/ME,
	and setting I/O to a BASIC driver
	actually selects a Pascal driver.

<b>1</b>	Pascal text driver. This is one of	Driver number as
	the drivers specified in /etc/ttys	listed above.
	or built-in to GNO/ME.

<b>2</b>	RAM-based Driver (documented in 	Pointer to the RAM-
	<em>ToolBox Reference Volume 2</em>.		based driver's jump
						table.

<b>3</b>	File redirection.			refNum (file desc-
						riptor) of the file
						to access through
						TextTools.
</pre>
\end{rawhtml}
\end{htmlonly}
%
% kludge-fuck ends
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\end{comment}

\index{device!types|)}
\index{driver!console}

The new console driver supports all the
features of the old 80-column Pascal firmware, and adds a few
extensions, with one exception --- the codes that switched between
40 and 80 columns modes are not supported. It is not compatible
with the GS/OS 
\index{.CONSOLE}
``.console'' driver. The control codes supported are as follows:

\index{\^{}C}
\index{\^{}Z}
\begin{tabular}{lll}
        Hex & ASCII & Action \\ \cline{1-3}
	01 & CTRL-A & Set cursor to flashing block \\
        02 & CTRL-B & Set cursor to flashing underscore \\
        03 & CTRL-C & Begin ``Set Text Window'' sequence \\
        05 & CTRL-E & Cursor on  \\
        06 & CTRL-F & Cursor off \\
        07 & CTRL-G & Perform FlexBeep \\
        08 & CTRL-H & Move left one character \\
        09 & CTRL-I & Tab \\
        0A & CTRL-J & Move down a line \\
        0B & CTRL-K & Clear to EOP (end of screen) \\
        0C & CTRL-L & Clear screen, home cursor \\
        0D & CTRL-M & Move cursor to left edge of line \\
        0E & CTRL-N & Normal text \\
        0F & CTRL-O & Inverse text \\
        11 & CTRL-Q & Insert a blank line at the current cursor position \\
        12 & CTRL-R & Delete the line at the current cursor position. \\
        15 & CTRL-U & Move cursor right one character \\
        16 & CTRL-V & Scroll display down one line \\
        17 & CTRL-W & Scroll display up one line \\
        18 & CTRL-X & Normal text, mousetext off \\
        19 & CTRL-Y & Home cursor \\
        1A & CTRL-Z & Clear entire line \\
        1B & CTRL-[ & MouseText on \\
% This is a CTRL-\
        1C & CTRL-\symbol{92} & Move cursor one character to the right \\
        1D & CTRL-] & Clear to end of line \\
        1E & CTRL-\^{} & Goto XY \\
        1F & CTRL-\_{} & Move up one line \\
\end{tabular}


(\bf Note\rm: the \it Apple IIgs Firmware Reference \rm
incorrectly has codes 05 and 06 reversed. The codes listed here
are correct for both GNO/ME and the Apple IIgs 80-column
firmware.)

FlexBeep is a custom beep routine that
doesn't turn off interrupts for the duration of the noise as does
the default Apple IIgs beep. This means that the beep could sound
funny from time to time, but it allows other processes to keep
running. We also added two control codes to control what kind of
cursor is used. There are two types available as in most
text-based software; they are underscore for 'insert' mode, and
block for 'overstrike'. You may, of course, use whichever cursor
you like. For example, a communications program won't have need
of insert mode, so it can leave the choice up to the user.



The Set Text Window sequence (begun by a \$03 code) works as follows:

\begin{verbatim}
    CTRL-C '[' LEFT RIGHT TOP BOTTOM
\end{verbatim}

CTRL-C is of course hex \$03, and '[' is the
open bracket character (\$5B). TOP, BOTTOM, LEFT, and RIGHT are
single-byte ASCII values that represent the margin settings.
Values for TOP and BOTTOM range from 0 to 23; LEFT and RIGHT
range from 0 to 79. TOP must be numerically less than BOTTOM;
LEFT must be less than RIGHT. Any impossible settings are
ignored, and defaults are used instead. The extra '[' in the
sequence helps prevent the screen from becoming confused in the
event that random data is printed to the screen.

After a successful Set Text Window
sequence, only the portion of the screen inside the 'window' will
be accessible, and only the window will scroll; any text outside
the window is not affected.

The cursor blinks at a rate defined by the 
\index{control panel}
\bf Control Panel/Options/Cursor Flash \rm setting. Far left is no blinking
(solid), and far right is extremely fast blinking.

\tt ReadLine \rm (\$240C) now sports a complete line editor unlike the old
TextTools version. Following is a list of the editor commands.

\begin{tabular}{ll}
\index{\^{}D}
EOL 	    & Terminates input (EOL is a parameter to the \_{}ReadLine call). \\
LEFT-ARROW  & Move cursor to the left. \\
RIGHT-ARROW & Move cursor to right. It won't go past rightmost character. \\
DELETE      & Delete the character to the left of the cursor. \\
CTRL-D      & Delete character under the cursor. \\
OA-D        & Delete character under the cursor. \\
OA-E        & Toggles between overwrite and insert mode. \\
\end{tabular}


\tt ReadChar \rm (\$220C) has also been changed. The character returned may now
contain the key modification flags (\$C025) in the upper byte and
the character typed in the lower byte. This is still compatible
with the old TextTools ReadChar. To get the keyMod flags, call
\tt SetInGlobals \rm (\$090C) and
set the upper byte of the AND mask to \$FF. Typical parameters for
\tt SetInGlobals \rm to get this information are:
\index{ANDmask}
ANDmask\ =\ \$FF7F, ORmask\ =\ \$0000.


The default I/O masks have also been
changed. They are now 
\index{ANDmask}
ANDmask\ =\ \$00FF, ORmask\ =\ \$0000. They are
set this way to extend the range of data that can be sent through
TextTools. GNO/ME Character drivers do not, like the previous
TextTools driver, require the hi-bit to be set.

The new TextTools are completely reentrant.
This means that any number of processes may be executing
TextTools calls at the same time, increasing system performance
somewhat. The TextTools are also the only toolset which is not
mutexed.

\index{driver!console}
The GNO/ME console driver also supports
flow-control in the form of Control-S and Control-Q. Control-S is
used to stop screen output, and Control-Q is used to resume
screen output.

\section{SysFailMgr}


The MiscTool call SysFailMgr (\$1503) has been
modified so that a process calling it is simply killed, instead
of causing system operation to stop. This was done because many
programs use SysFailMgr when a simple error message would have
sufficed. There are, however, some tool and GS/OS errors which
are truly system failure messages, and these do cause system
operation to stop. These errors are as follows:

\begin{tabular}{ll}
\$0305	& Damaged heartbeat queue detected. \\
\$0308	& Damaged heartbeat queue detected. \\
\$0681	& Event queue damaged. \\
\$0682	& Queue handle damaged. \\
\$08FF	& Unclaimed sound interrupt. \\
\end{tabular}

What the system does after displaying the
message is the same as for a system panic.


\section{The Resource Manager}

The Resource Manager has been modified in
some subtle ways. First, GNO/ME makes sure that the
CurResourceApp value is always correct before a process makes a
Resource Manager call. Second, all open resource files are the
property of the Kernel. When a GetOpenFileRefnum call is made, a
new refnum is \bf dup\rm(2)'d to allow the process to access the
file. Having the Kernel control resource files also allows all
processes to share SYS.RESOURCES without requiring each process
to explicitly open it.

\section{The Event Manager}


GNO/ME starts up the Event Manager so it is
always available to the kernel and shell utilities. Changes were
made so that the Event Manager obtains keystrokes from the GNO/ME
\index{driver!console}
console driver (.ttyco). This allows UNIX-style utilities and
desktop applications to share the keyboard in a cooperative
manner. This also makes it possible to suspend desktop
applications; see Chapter 7, \bf Suspend NDA\rm.

EMStartUp sets the GNO console driver to
RAW mode via an \bf ioctl\rm(2) call, to allow the Event Manager
to get single keystrokes at a time, and to prevent users from
being able to kill the desktop application with \^C or other
interrupt characters. The four ``GetEvent'' routines,
GetNextEvent, GetOSEvent, EventAvail, and OSEventAvail now poll
the console for input characters instead of using an interrupt
handler.

\section{The Control Panel}

\index{CDA}
\index{control panel}
In most cases, the CDA menu is executed as
an interrupt handler. Since the Apple IIgs interrupt handler
firmware isn't reentrant, task switching is not allowed to occur
while the control panel is active. This basically means that all
processes grind to a halt. In many ways, however, this is not
undesirable. It definitely eases debugging, since a static system
is much easier to deal with than a dynamic system. Also, CDAs
assume they have full control of the text screen; multitasking
CDAs would confuse and be confused in terms of output.

During the execution of the Control Panel,
the original non-GNO/ME TextTools tool is reinstalled to prevent
compatibility problems. Another step, taken to maintain user
sanity, makes CDAs run under the kernel's process ID.

All the changes were made to two tool
calls: \tt SaveAll \rm (\$0B05) and \tt RestAll \rm (\$0C05).

\section{QDStartup}

The \tt QDStartup \rm (\$0204)
call has been modified to signal an error and
terminate any process that tries to make the call when it's
\index{controlling terminal}
controlling terminal is not the Apple IIgs console. This prevents
a user on a remote terminal from bringing up a desktop
application on the console, an operation he could not escape from
and one that would greatly annoy the user at the console.

Another change ensures that an attempt to
execute two graphics-based applications concurrently will fail;
the second process that tries to call 
\tt QDStartUp \rm is killed and a diagnostic message is displayed
on the screen.

%
%	CHAPTER:  Process Management
%

\begin{latexonly}
\chapter{Process Management}
\end{latexonly}
\begin{htmlonly}
\chapter{Chapter 5:  Process Management}
\end{htmlonly}

Before discussing process management using
Kernel calls, it would be wise to define just exactly what we
refer to when we say \it process\rm. A process is generally
considered to be a program in execution. ``A program is a
passive entity, while a process is an active entity.''
(Operating Systems Concepts p.73, Silberschatz and Peterson,
Addison-Wesley, 1989). The concept of process includes the
information a computer needs to execute a program (such as the
program counter, register values, etc).

In order to execute multiple processes, the
operating system (GNO/ME and GS/OS in this case) has to make
decisions about which process to run and when. GNO/ME supports
what is termed \it preemptive multitasking\rm, which means that
processes are interrupted after a certain amount of time (their
time slice), at which point another process is allowed to run.
The changing of machine registers to make the processor execute a
different process is called a \index{context switch}
\it context switch\rm, and the
information the operating system needs to do this is called its
\it context\rm.
The GNO kernel maintains a list of all active processes, and
assigns time slices to each process according to their order in
the list. When the kernel has run through all the processes, it
starts again at the beginning of the list. This is called \it round-robin
scheduling\rm. Under certain circumstances, a process can
actually execute longer than its allotted time slice because task
switches are not allowed during a GS/OS or ToolBox call. In these
cases, as soon as the system call is finished the process is
interrupted.

Processes can give up the rest of their
time slice voluntarily (but not necessarily explicitly) in a
number of ways, terminal input being the most common. In this
case, the rest of the time slice is allocated to the next process
in line (to help smooth out scheduling). A process waiting on
some event to happen is termed \index{blocked processes} \it blocked\rm.
There are many ways this can happen, and each will be mentioned in its place.

An important item to remember is the \it process
ID\rm. This is a number which uniquely identifies a process. The
ID is assigned when the process is created, and is made available
for reassignment when the process terminates. A great many system
calls require process IDs as input. Do not confuse this with a
userID, which is a system for keeping track of memory allocation
by various parts of the system, and is handled (pardon the pun)
by the Memory Manager tool set. Also, do not confuse Memory
Manager userID's with Unix user ID's --- numbers which are assigned
to the various human users of a multiuser machine.

There are two methods for creating new
processes: the system call \bf fork\rm(2) 
(or \bf fork2\rm(2))
and the library routine \bf exec\rm(3)
(specifics for calling these functions and others is in Appendix
A \it Making System Calls\rm). \bf fork \rm starts up a process
which begins execution at an address you specify. \bf exec \rm
starts up a process by loading an executable file (S16 or EXE). \bf fork \rm
is used mainly for use inside a specific application, such as
running shell built-ins in the \index{background} background, or setting up
independent entities inside a program. Forked processes have some
limitations, due to the hardware design of the Apple IIgs. The
parent process (the process which called fork) must still exist
when the 
\index{process!child|(}
children die, either via \bf kill \rm or by simply
exiting. This is because the forked children share the same
memory space as the parent; the memory the children execute from
is tagged with the parent's userID. If the parent terminated
before the children, the children's code would be deallocated and
likely overwritten. A second caveat with \bf fork \rm is the
difference between it's UNIX counterpart. UNIX \bf fork \rm
begins executing the child at a point directly after the call to \bf fork\rm.
This cannot be accomplished on the Apple IIgs because virtual
memory is required for such an operation; thus the need to
specify a \bf fork \rm child as a C function. Note that an
appropriately written 
\index{assembly language programs}
assembly language program need not
necessarily have these restrictions. When a process is forked,
the child process is given it's own direct page and stack space
under a newly allocated userID, so that when the child terminates
this memory is automatically freed.

\bf exec\rm(3) is used when the process you
wish to start is a GS/OS load file (file type S16 and EXE). \bf exec \rm
follows the procedure outlined in the \it GS/OS Reference Manual \rm
for executing a program, and sets up the new program's
environment as it expects. After \bf exec \rm has loaded the
program and set up it's environment, the new process is started
and \bf exec \rm returns immediately. 

Both \bf fork\rm(2) and \bf exec\rm(3) return
the process ID of the child. The parent may use this process ID
to send \it signals \rm to the child, or simply wait for the child
to exit with the \bf wait\rm(2) system call; indeed, this is the
most common use. Whenever a child process terminates or is
stopped (See Chapter 6 \it Interprocess Communication\rm),
the kernel creates a
packet of information which is then made available to the
process' parent. If the parent is currently inside a wait call,
the call returns with the information. If the parent is off doing
something else, the kernel sends the parent process a 
\tt SIGCHLD \rm signal. The default is to ignore \tt SIGCHLD\rm,
but a common technique is to install a handler for \tt SIGCHLD\rm,
and to make a \bf wait \rm call inside the handler to retrieve
the relevant information.

\bf exec\rm(3) is actually implemented as
two other system calls: \bf fork\rm(2), and one called \bf execve\rm(2).
\bf execve \rm loads a program from an executable file, and
begins executing it. The current process' memory is deallocated.
The shell uses a \bf fork\rm/\bf execve \rm pair explicitly,
so it can set up redirection and handle job control.

\index{process!child|)}

\section{Process Table}

Information about processes is maintained
in the process table, which contains one entry for each possible
process (\bf NPROC\rm, defined in the C header file \tt <gno/conf.h>\rm.
There is other per-process information spread about the kernel, but
those are usually used for maintaining compatibility with older
software, and thus are not described here. Please note that the
data in this section is informational only (e.g. for programs
like \bf ps\rm(1)). Do not attempt to modify kernel data
structures or the GNO Kernel will likely respond with a
resounding crash. Only 'interesting' fields are documented.

Copies of process entries should be
obtained by using the Kernel Virtual Memory (KVM) routines
(\bf kvm\_{}open\rm(2), and so forth).
These are documented in the electronic manual pages.

\begin{description}

\item[processState]
Processes have a
state associate with them. The state of the process is a
description of what the process is doing. The possible process
states (as listed in 
\tt <gno/proc.h> \rm
and described here) are:

\begin{rawhtml}
<!-- cleantable-start -->
\end{rawhtml}

\begin{tabular}{ll}

RUNNING 	&
\begin{minipage}[t]{8cm}
	The process is currently in execution.
\end{minipage} \hfill \\

READY 	&
\begin{minipage}[t]{8cm}
	The process is not currently executing, but is ready to be
	executed as soon as it is assigned a time slice.
\end{minipage} \hfill \\

BLOCKED	&
\begin{minipage}[t]{8cm}
	\index{blocked processes}
	The process is waiting for a slow I/O operation to
	complete (for instance, a read from a TTY).
\end{minipage} \hfill \\

NEW 	&
\begin{minipage}[t]{8cm}
	The process has been created, but has not executed yet.
\end{minipage} \hfill \\

SUSPENDED  &
\begin{minipage}[t]{8cm}
	The process was stopped with SIGSTOP, SIGTSTP,
	SIGTTIN, or SIGTTOU.
\end{minipage} \hfill \\

WAITING  &
\begin{minipage}[t]{8cm}
	The process is waiting on a semaphore ``signal'' operation.
	Programs waiting for data from a pipe have this state.
\end{minipage} \hfill \\

WAITSIGCH  &
\begin{minipage}[t]{8cm}
	The process is waiting to receive a SIGCHLD signal.
\end{minipage} \hfill \\

PAUSED  &
\begin{minipage}[t]{8cm}
	The process is waiting for any signal.
\end{minipage} \hfill \\

\end{tabular}

\begin{rawhtml}
<!-- cleantable-end -->
\end{rawhtml}


\item[ttyID]
\index{device!number}
\index{device!names}
The device number of the 
\index{controlling terminal}
controlling TTY for this process.
This is not a GS/OS refnum; rather, it is an index into the kernel's internal
character device table.
The value of this field can be interpreted as follows:

\index{.pty}
\index{.tty}
\index{.ttya}
\index{.ttyb}
\begin{tabular}{rl}
\bf{0}	&	.null \\
\bf{1}	&	.ttya \\
\bf{2}	&	.ttyb \\
\bf{3}	&	.ttyco \\
\bf{6}	&	.ptyq0 pty0 master side \\
\bf{7}	&	.ttyq0 pty0 slave side \\
\end{tabular}

Other values may be appropriate depending
on the 
\index{/etc/tty.config}
\tt /etc/tty.config \rm file. Namely, \bf 1 \rm and \bf 2 \rm
(by default the modem and printer port drivers), and \bf 4 \rm and 
\bf 5 \rm (unassigned by default) may be assigned to different devices.


\item[ticks]
The number of full ticks this process has executed. If a process gives up
it's time slice due to an I/O operation, this value is not incremented.
A tick is 1/60 second.

\item[alarmCount]
\index{alarmCount}
If an 
\index{alarm}
\bf alarm\rm(2) request was made, this is the number of seconds
remaining until the process is sent SIGALRM.

\item[openFiles]
This is a structure which stores information about the files a
process has open. See \tt struct ftable \rm and \tt struct fdentry \rm
in \tt <gno/proc.h> \rm.

\item[irq\_{}A, irq\_{}X, irq\_{}Y, irq\_{}S, irq\_{}D, irq\_{}B, 
irq\_{}P, irq\_{}state, irq\_{}PC, irq\_{}K]
\index{context switch}
Context information for the process. These fields are the values of the
\index{65816 registers}
65816 registers 
at the last context switch. They only truly represent the
machine state of the process if the process is not RUNNING.

\item[args]
\index{args}
This is a NULL-terminated (C-style) string that contains the command line
with which the process was invoked.  This string begins with
\index{BYTEWRKS}
``BYTEWRKS'', the shell identifier.

\end{description}

For more details and an example of how to
investigate process information, look at the source code for the 
\index{CDA}
``GNO Snooper CDA''.

\section{Task Switching}

\index{context switch|(}

As mentioned earlier, user code can often
unwittingly initiate a context switch by reading from the console
(and other miscellaneous things). There are a few situations
where this can cause a problem, namely inside interrupt handlers.
While the kernel makes an attempt to prevent this, it cannot
predict every conceivable problem. The kernel attempts to detect
and prevent context switches inside interrupt handlers by
checking for the following situations.

\begin{itemize}
\item	Is the system busy flag non-zero?  (The busy flag is located at
	address \tt \$E100FF\rm.)

\item	Is the ``No-Compact'' flag set? (Located at \tt\$E100CB\rm.)

\item	Does the stack pointer point to anything in thr range 
	\tt \$0100-\$01FF\rm?

\item	Is the interrupt bit in the processor status register set?
\end{itemize}

If any of these conditions are met, a
context switch will not take place. This can cause problems in
certain circumstances. The basic rule is to avoid making Kernel
calls that might cause a context switch or change in process
state from inside an interrupt handler. This includes the
following:

\begin{itemize}
\item	reading from the console
\item	accessing a pipe
\item	any of the following kernel traps:
	\bf \_{}execve\rm(2) (or other calls in the \bf exec \rm family),
	\bf fork\rm(2),
	\bf fork2\rm(2),
	\bf kill\rm(2),
	\bf pause\rm(2),
	\bf procreceive\rm(2),
	\bf sigpause\rm(2),
	or
	\bf wait\rm(2).
\end{itemize}

Calls such as \bf procsend\rm(2), however, may be used from inside
an interrupt handler, and in fact are very useful in such situations.

\index{context switch|)}

\section{Job Control}

Job control is a feature of the kernel that
helps processes orderly share a terminal. It prevents such
quandaries as ``What happens when two processes try to read
from the terminal at the same time?''. 

Job control works by assigning related
processes to a \it process group\rm. For example, all of the
processes in a pipeline belong to one process group. Terminal
\index{device!driver}
device drivers also belong to process groups, and when the
process group of a job does not match that of its 
\index{controlling terminal}
\it controlling terminal \rm
the job is said to be in the \index{background} background.
Background jobs have access to their controlling terminal restricted in
certain ways.

\begin{itemize}
\item	If a background job attempts to read from the terminal, the
	kernel suspends the process by sending the \tt SIGTTIN \rm signal.

\item	The interrupt signals \tt SIGTSTP \rm and \tt SIGINT\rm,
	generated by \^Z and \^C respectively, are sent only to the
	foregound job. This allows backgrounded jobs to proceed without
	interruption.

\item	Certain \bf ioctl\rm(2) calls cannot be made by a background job;
	the result is a \tt SIGTTIN \rm signal.
\end{itemize}

Job control is accessed by software through the \bf tcnewpgrp\rm,
\bf tctpgrp, and \bf settpgrp\rm(2) system calls. 
See the \bf jobcontrol\rm(2) and \bf ioctl\rm(2) man pages.

%
%	CHAPTER:  Interprocess Communication
%

\begin{latexonly}
\chapter{Interprocess Communication}
\end{latexonly}
\begin{htmlonly}
\chapter{Chapter 6:  Interprocess Communication}
\end{htmlonly}

\tiny

\begin{verse}
Oh, give me a home \\
Where the semaphores roam, \\
and the pipes are not deadlocked all day ... \\

--- unknown western hero
\end{verse}

\normalsize

The term Interprocess Communication (\it IPC\rm)
covers a large range of operating system features. Any time a
process needs to send information to another process some form of
IPC is used. The GNO Kernel provides several basic types:
semaphores, signals, pipes, messages, ports, and
pseudo-terminals. These IPC mechanisms cover almost every
conceivable communication task a program could possibly need to
do.

\section{Semaphores}

In the days before radio, when two ships
wished to communicate with each other to decide who was going
first to traverse a channel wide enough only for one, they used
multicolored flags called semaphores. Computer scientists, being
great lovers of anachronistic terms, adopted the term and meaning
of the word semaphore to create a way for processes to
communicate when accessing shared information.

GNO/ME, like other multitasking systems,
provides applications with semaphore routines. Semaphores
sequentialize access to data by concurrently executing processes.
You should use semaphores whenever two or more processes want to
access shared information. For example, suppose there were three
processes, each of which accepted input from user terminals and
stored this input into a buffer in memory. Suppose also that
there is another process which reads the information out of the
buffer and stores it on disk. If one of the processes putting
information in the buffer (writer process) was in the middle of
storing information in the buffer when a 
\index{context switch} 
context switch occurred,
and one of the other processes then accessed the buffer, things
would get really confused. Code that accesses the buffer should
not be interrupted by another process that manipulates the
buffer; this code is called a 
\index{critical section}
\it critical section\rm; in order to operate properly, this code 
must not be interrupted by any other attempts to access the buffer.

To prevent the buffer from becoming
corrupted, a semaphore would be employed. As part of it's
startup, the application that started up the other processes
would also create a semaphore using the \bf screate\rm(2) system
call with a parameter of 1. This number means (among other
things) that only one process at a time can enter the critical
section, and is called the \it count\rm.

When a process wishes to access the buffer,
it makes a \bf swait\rm(2), giving as argument the semaphore
number returned by \bf screate\rm(2). When it's done with the
buffer, it makes an \bf ssignal\rm(2) call to indicate this fact.

This is what happens when \bf swait \rm is
called: the kernel first decrements the count. If the count is
then less than zero, the kernel suspends the process, because a
count of less than zero indicates that another process is already
inside a critical section. This suspended state is called
'waiting' (hence the name of \bf swait\rm). Every process that
tries to call \bf swait \rm with count < 0 will be suspended;
a queue of all the processes currently waiting on the semaphore
is associated with the semaphore.

Now, when the process inside the critical
section leaves and executes \bf ssignal\rm, the kernel
increments the count. If there are processes waiting for the
semaphore, the kernel chooses one arbitrarily and restarts it.
When the process resumes execution at its next time slice, its 
\bf swait \rm
call will finish executing and it will have exclusive control of
the critical section. This cycle continues until there are no
processes waiting on the semaphore, at which point its count will
have returned to 1.

When the semaphore is no longer needed, you
should dispose of it with the \bf sdelete\rm(2) call. This call
frees any processes that might be waiting on the semaphore and
returns the semaphore to the semaphore pool.

One must be careful in use of semaphores or
\index{deadlock}
\it deadlock \rm can occur.

There are (believe it or not) many
situations in everyday programming when you may need semaphores,
moreso than real UNIX systems due to the Apple IIgs's lack of
virtual memory. The most common of these is your C or Pascal
compiler's stdio library; these are routines like \bf printf\rm(3)
and \bf writeln\rm(3). In many cases, these libraries use global
variables and buffers. If you write a program which forks a 
\index{process!child}
child process that shares program code with the parent process (i.e.
doesn't \bf execve\rm(2) to another executable), and that child
and the parent both use \it non-reentrant \rm library calls, the
library will become confused. In the case of text output
routines, this usually results in garbaged output.

Other library routines can have more
disastrous results. For example, if a parent's 
\bf free\rm(3) or \bf dispose\rm(3)
memory management call is interrupted, and the child makes a
similar call during this time, the linked lists that the library
maintains to keep track of allocated memory could become
corrupted, resulting most likely in a program crash.

GNO/ME provides \it mutual exclusion \rm
(i.e., lets a maximum of one process at a time execute the code)
automatically around all Toolbox and GS/OS calls as described in
Chapter 3, and also uses semaphores internally in many other
places. Any budding GNO/ME programmer is well advised to
experiment with semaphores to get a feel for when and where they
should be used. Examples of semaphore use can be found in the
sample source code, notably \tt dp.c \rm
(Dining Philosophers demo) and \tt pipe*.c \rm 
(a sample implementation of pipes written entirely in C).

\section{Signals}


Another method of IPC is software signals.
Signals are similar to hardware interrupts in that they are
asynchronous; that is, a process receiving a signal does not have
to be in a special mode, does not have to wait for it. Also like
hardware interrupts, a process can install signal handlers to
take special action when a signal arrives. Unlike hardware
interrupts, signals are defined and handled entirely through
software.

Signals are generally used to tell a
process of some event that has occurred. Between the
system-defined and user-defined signals, there is a lot of things
you can do. GNO/ME currently defines 32 different signals. A list
of signals and their codes can be found in \bf signal\rm(2) and
the header file \tt <gno/signal.h>\rm.

There are three types of default actions
that occur upon receipt of a signal. The process receiving the
signal might be terminated, or stopped; or, the signal might be
ignored. The default action of any signal can be changed by a
process, with some exceptions. Not all of the defined signals are
currently used by GNO/ME, as some are not applicable to the Apple
IIgs, or represent UNIX features not yet implemented in GNO/ME .
Here is a list of the signals that are used by GNO/ME.

\begin{description}
\item[SIGINT]
	This signal is sent to the
        foreground job when a user types \^C at the terminal
        keyboard.
\item[SIGKILL]
	The default
	action of this signal (termination) cannot be changed.
	This provides a sure-fire means of stopping an otherwise
	unstoppable process.
\item[SIGPIPE]
	Whenever a process tries to
        write on a pipe with no readers, it is sent this signal.
        SIGALRM SIGALRM is sent when an
        alarm timer expires (counts down to zero). An application
        can start an alarm timer with the
	\index{alarm}
	\bf alarm\rm(2) 
	\begin{rawhtml}
	</b>
	\end{rawhtml}
	\rm system call.
\item[SIGTERM]
	This is the default signal
        sent by \bf kill\rm(1). Use of this signal allows
        applications to clean up (delete temporary files, free
        system resources like semaphores, etc) before terminating
        at the user's bequest. 
\item[SIGSTOP]
	This signal is used to stop
        a process' execution temporarily. Like SIGKILL, processes
        are not allowed to install a handler for this signal. 
\item[SIGCONT]
	To restart a stopped process, send this signal. 
\item[SIGTSTP]
	This is similar to SIGSTOP,
        but is sent when the user types \^Z at the keyboard.
        Unlike SIGSTOP, this signal can be ignored, caught, or
        blocked. 
\item[SIGCHLD]
	\index{process!child}
	A process receives this
        signal whenever a child process is stopped or terminates.
        \bf gsh \rm uses this to keep track of jobs, and the wait
        system call waits for this signal to arrive before
        exiting. 
\item[SIGTTIN]
	This signal also stops a process. It is sent to \index{background} 
	background jobs that try to get input from the terminal. 
\item[SIGTTOU]
	Similar to SIGTTIN, but is
        sent when a background process tries to write to the
        terminal. This behavior is optional and is by default
        turned off. 
\item[SIGUSR1, SIGUSR2]
	These two signals are
        reserved for application authors. Their meaning will
        change from application to application.
\end{description}

As you can see, signals are used by many
aspects of the system. For detailed information on what various
signals mean, consult the appropriate electronic manual page ---
see \bf tty\rm(4), \bf wait\rm(2), and \bf signal\rm(2).

For an example of signal usage, consider a
print spooler. A print spooler takes files that are put in the
spool directory on a disk and sends the data in the files to a
printer. There are generally two parts to a print spooler: The 
\index{daemon}
\it daemon\rm,
a process that resides in memory and performs the transfer of
data to the printer in the background; and the spooler. There can
be many different types of spoolers, say one for desktop
printing, one for printing source code, etc. To communicate to
the daemon that they have just placed a new file in the spool
directory, the spoolers could send the daemon SIGUSR. The daemon
will have a handler for SIGUSR, and that handler will locate the
file and set things up so the print will begin. Note that the
actual implementation of the print spooling system in GNO/ME,
\bf lpr\rm(1) and \bf lpd\rm(8), 
is somewhat more complex and uses messages and
ports instead of signals. However, an earlier version of the
spooler software \it did \rm use signals for communication.

Signals should not be sent from inside an
interrupt handler, nor from inside a GS/OS or Toolbox call.
Window Manager update routines are a prime example of code that
should not send signals; they are executed as part of a tool
call. The GS/OS aspect of this limitation is a little harder to
come up against. GS/OS does maintain a software signal facility
of it's own, used to notify programs when certain low-level
events have occurred. Do not confuse these GS/OS signals with
GNO/ME signals, and above all, don't send a GNO/ME signal from a
GS/OS signal handler.

When a process receives a signal for which
it has installed a handler, what occurs is similar to a 
\index{context switch}
context switch. The process' context is saved on the stack, and the
context is set so that the signal handler routine will be
executed. Since the old context is stored on the stack, the
signal handler may if it wishes return to some other part of the
program. It accomplishes this by setting the stack pointer to a
value saved earlier in the program and jumping to the appropriate
place. Jumps like this can be made with C's 
\bf setjmp\rm(3) and \bf longjmp \rm(3)
functions. The following bit of code demonstrates this ability.

\begin{verbatim}
    void sighandler (int sig, int code)
    {
        printf("Got a signal!");
        longjmp(jmp_buf);
    }

    void routine(void)
    {
        signal(SIGUSR, sighandler);
        if (setjmp(jmp_buf)) {
            printf("Finally done! Sorry for all that...\n");
        } else {
            while(1) {
                printf("While I wait I will annoy you!\n");
            }
        }
    }
\end{verbatim}

% gdr: this is the spot where I left off reviewing the postscript output

This program basically prints an annoying
message over and over until SIGUSR is received. At that point,
the handler prints ``Got a Signal!'' and jumps back to
the part of the if statement that prints an apology. If the
signal handler hadn't made the \bf longjmp\rm, when the handler
exited control would have returned to the exact place in the \bf while \rm
loop that was interrupted.

\index{assembly language programs}
Similar techniques can be applied in assembly language.

\section{Pipes}

This third form of IPC implemented in
GNO/ME is one of the most powerful features ever put into an
operating system. A pipe is a conduit for information from one
process to another. Pipes are accessed just like regular files;
the same GS/OS and ToolBox calls currently used to manipulate
files are also used to manipulate pipes. When combined with
GNO/ME standard I/O features, pipes become very powerful indeed.
For examples on how to use \bf gsh \rm to connect applications
with pipes, see the \it GNO Shell Reference Manual\rm.

Pipes are unidirectional channels between
processes. Pipes are created with the \bf pipe\rm(2) system call,
which returns two GS/OS refNums; one for the write end, and one
for the read end. An attempt to read from the write end or
vice-versa results in an error.

Pipes under GNO/ME are implemented as a
circular buffer of 4096 bytes. Semaphores are employed to prevent
the buffer from overflowing, and to maintain synchronization
between the processes accessing the pipe. This is done by
creating two semaphores; their counts indicate how many bytes are
available to be read and how many bytes may be written to the
buffer (0 and 4096 initially). If an I/O operation on the pipe
would result in the buffer being emptied or filled, the calling
process is \index{blocked processes} blocked until the data (or space)
becomes available.

The usual method of setting up a pipeline
between processes, used by \bf gsh \rm and utilities such as
script, is to make the \bf pipe \rm call and then \bf fork\rm(2)
off the processes to be connected by the pipe.

\begin{verbatim}

    /* No error checking is done in this fragment.  This is
     * left as an exercise for the reader.
     */

    int fd[2];
    int 
    testPipe(void)
    {
        pipe(fd);      /* create the pipe */
        fork(writer);  /* create the writer process */
        fork(reader);  /* create the reader process */
        close(fd[0]);  /* we don't need the pipe anymore, because */
        close(fd[1]);  /*    the children inherited them          */
    
        { wait for children to terminate ... }
    }

    void 
    writer(void) {
        /* reset the standard output to the write pipe */
        dup2(STDOUT_FILENO, fd[1]);
    
        /* we don't need the read end */
        close(fd[0]);
        { exec writer process ...}
    }

    void 
    reader(void) {
        /* reset the standard input to the write pipe */
        dup2(STDIN_FILENO, fd[0]);
    
        /* we don't need the write end */
        close(fd[1]);
        { exec reader process ...}
    }

\end{verbatim}

Recall that when a new process is forked,
it inherits all of the open files of it's parent; thus, the two
children here inherit not only standard I/O but also the pipe.
After the forks, the parent process closes the pipe and each of
the child processes closes the end of the pipe it doesn't use.
This is actually a necessary step because the kernel must know
when the reader has terminated in order to also stop the writer
(by sending \tt SIGPIPE\rm.
Since each open refNum to the read end of the
pipe is counted as a reader, any unnecessary copies must be
closed.

For further examples of implementing and
programming pipes, see the sample source code for \tt pipe.c\rm.

\section{Messages}

GNO's Message IPC is borrowed from the XINU
Operating System, designed by Douglas Comer. It is a simple way
to send a datum (a message) to another process. Messages are
32-bit (4-byte) longwords.

The Message IPC is centered around two
calls, \bf procsend\rm(2) and \bf procreceive\rm(2).
The \bf procsend \rm call sends a
message to a specified process ID. To access that message, a
process must use \bf procreceive\rm. If no message is waiting for a
process when it calls \bf procreceive\rm, the process will 
\index{blocked processes} block until a message becomes available.

Since a process can only have one pending
message, the Message IPC is useful mostly in applications where
two or more cooperating processes only occasionally need to
signal each other; for example, the \bf init\rm(8) program
communicates with the \bf initd \rm
\index{daemon}
daemon by sending messages. Various
attributes are encoded in the 32-bit value sent to \bf initd\rm(8)
to instruct it on how to change its state.

If a process doesn't want to indefinitely block waiting for a message,
it can call \bf procrecvtim\rm(2). The \bf procrecvtim \rm call
accepts a timeout parameter which indicates the maximum amount of
time to wait for a message. 

\section{Ports}

GNO/ME Ports IPC can be thought of as an
extended version of Messages. Whereas only one message can be
pending at once, a port can contain any number of pending
messages (up to a limit defined when an application creates a
port).

Like Messages, Ports transmit 32-bit values
between processes. The calls \bf psend\rm(2) and \bf preceive\rm(2)
work similarly to their Message counterparts.

A Port is created with the \bf pcreate\rm(2)
call. The application specifies the size of the port in this
call. When the application is done with the port, it should call
\bf pdelete\rm(2) to free up the resources used by the port.

One of the most important aspects of ports
is the ability to bind a \it name \rm to a port. Whereas many of
GNO/ME IPC mechanisms require the communicating processes to be
related in some way (common children of the same parent, for
instance) being able to give a port a name means that totally
unrelated processes can communicate. For example, the GNO/ME
print spooling system uses a named port for communicating
information about the addition of new jobs to the print queue.
The printer 
\index{daemon}
daemon, \bf lpd\rm(8), creates a port with a specific
name; the name is defined by the author of the print daemon; any
application that wishes to have the daemon print a spool file
also knows this name. (The standard print daemon uses the name
``LPDPrinter''). The name allows an application to find
lpd's port regardless of the actual numeric port ID (which might
be different from system to system, or even from session to
session on the same machine).

Names are bound to ports with the \bf pbind\rm(2) call.
The numeric port ID can be obtained by passing a name to
\bf pgetport\rm(2).

\section{Pseudo-Terminals (PTYs)}

Pseudo-terminals are a bi-directional
communication channel that can be used to connect two processes
(or more correctly, a process group to another process). You may
(correctly) ask why two pipes would not do the same thing; the
answer is that a lot of modern UNIX software relies on the way
the terminal interface works, and thus would malfunction when
presented with a pipe as standard input. What PTYs provide is a
lot like two pipes, but with a TTY interface.

PTYs can be used in a number of important
and exciting applications, such as windowing systems and
'script-driven' interfaces.

Windowing systems like the UNIX X windowing system (known as just
``\bf X\rm'')
use PTYs to give a process group an interface that looks exactly
like a real terminal; however, the 'terminal' in this case is
actually a window in a graphics-based system. The program that
manages the window ('xterm' in \bf X\rm) is called the \it master\rm.
It is responsible for setting up the PTY, and starting up the
process with redirection (usually a shell) that is to run in the
window. The process running in the window is called the \it slave\rm.

\index{device!character}
To allocate a PTY, the master opens in turn
each PTY device starting with
\index{.pty}
.ptyq0. If a PTY is already in use,
the open call will return an error (the kernel uses the EXCL flag
internally). When an open succeeds, the master then has exclusive
access to that PTY. At this point, the master opens the
corresponding TTY file 
\index{.tty}
(.ttyq0 --- .ttyqf), or the slave device. It
then forks off a process, which sets redirection up in the normal
fashion and then exec's the program to run on the PTY.

The following code fragment is taken from the source code for the
Graphical Shell Interface (GSI) NDA.
\tt initPipe \rm
scans the PTY devices, looking for a free one as
discussed above. Note that the master side of a PTY does \em not \rm
have (by default) a terminal interface; it is a very raw device,
with only a few \bf ioctl\rm's to be able to send signals and handle
other such low-level tasks.

\index{.pty}
\begin{verbatim}

    char buffer[1024];
    int ptyno, master;
    
    int 
    initPipe(void)
    {
        int cl[2];
        struct sgttyb sb;
        char *ptyname = ".ptyq0";
    
        unsigned i;
    
        /* We have to open the master first */
        for (i = 0; i<2; i++) {
            /* generate a PTY name from the index */
            ptyname[5] = intToHex(i);
            master = open(ptyname,O_RDWR);
            if (master > 0) {
                break; /* successful open */
            }
        }
    
        if (master < 1) {
            return -1;
        }
    
        ptyno = i;
        pid1 = fork(producer);
        return 0;
    }
\end{verbatim}

\tt producer() \rm
sets up redirection for the shell, and also opens
the slave side of the PTY. The slave processes must not have any
access whatsoever to the master side of the PTY, so \bf close(0) \rm
is used to close all open files (which includes, at this point,
the master PTY file descriptor from initPipe). Note that as in
many pipe applications, the file descriptor that will be assigned
to a newly opened file is assumed, and that can be safely done in
this case because it is clear that with no files open the next
file descriptor will be 1.

\index{.tty}
\begin{verbatim}
    /* the shell is executed here */
    
    #pragma databank 1
    void 
    producer(void)
    {
        char *ptyname = ".ttyq0";
    
        /* we must not have access to ANY other ttys */

        close(0); /* close ALL open files */
        ptyname[5] = intToHex(ptyno); 

        /* modify the tty slave name to correspond
         * to the master */

        slave = open(ptyname,O_RDWR); /* file descriptor 1 */
        dup(slave);                   /* fd 2 */
        dup(slave);                   /* fd 3 */

        /* Set up the TextTools redirection */
        SetOutputDevice(3,2l);
        SetErrorDevice(3,3l);
        SetInputDevice(3,1l);

        WriteCString("Welcome to GNO GSI\r\n");
        _execve(":bin:gsh","gsh -f");

        /* If we get here, we were unable to run 
         * the shell.
         *
         * GDR note: printf should not be used here,
         * since we're in the child process */
        printf("Could not locate :bin:gsh : %d", errno);
    }
    #pragma databank 0
\end{verbatim}

\tt consume() \rm
is called as part of GSI's event loop. It simply
checks to see if there is any data for the master by using the
FIONREAD ioctl, one of the few ioctl's supported by the master
side. See PTY(4) for details. Any data that is available is sent
to the window via a routine toOut, which inserts the new data
into a TextEdit record.

\begin{verbatim}
    void 
    consume(CtlRecHndl teH)
    {
        char ch;
        int fio, fio1, i;
    
        ioctl(master,FIONREAD,&fio);
        if (fio) {
            if (fio > 256) {
                fio = 256;
            }
            fio1 = read(master,buffer,fio);
            buffer[fio] = 0;
            toOut(buffer,fio,teH);
            updateWind1(fio,fio1);
        }
    }
\end{verbatim}

When the user types a key, the keypress is
sent to the slave by simply writing the data with a write call.

\begin{verbatim}
    void
    writedata(char k)
    {
        write(master, &k, 1);
    }
\end{verbatim}

When the user is done with the window and
closes it, GSI closes the master end of the PTY.

\begin{verbatim}
    void
    closePipe(void)
    {
        int cl[2];
        close(master);
    }
\end{verbatim}

When this is done, the slave process
receives a SIGHUP signal, to indicate that the connection was
lost. Since the standard behavior of SIGHUP is to terminate the
process, the slave dies and either the slave or the kernel closes
the slave end. At this point, the PTY is available for re-use by
another application.

As you can see, PTYs are very simple to
program and use. The simplicity can be misleading, for PTYs are a
very powerful method of IPC. As another example of the use of
PTYs, we point out that PTYs can be used to drive programs with
'scripts'. These scripts are a series of 'wait-for' and 'print'
operations, much like auto-logon macros in communications
programs such as ProTERM. Script-driving a program can be used to
automate testing or use of an application.

PTYs can be used to test software that
would normally work over a regular terminal (such as a modem).
Since PTYs are identical (to the slave) to terminals, the
application being tested doesn't know the difference. What this
means to the programmer is incredible power and flexibility in
testing the application. For example, a communications program
could be nearly completely tested without ever dialing to another
computer with a modem!

There are so many applications of PTYs that
to attempt to discuss them all here would be impossible; as PTYs
are discovered by more GNO/ME programmers we expect that more
useful PTY applications will become available.

\section{Deadlock}

\index{deadlock|(}
With interprocess communication comes the
problem of \em deadlock\rm. If a situation arises where two or
more processes are all waiting for an signal from one of the
other waiting processes, the processes are said to be deadlocked.

The best way to explain deadlock is to give
an example. Suppose that two processes are connected with two
pipes so that they can communicate bidirectionally. Also suppose
that each of the pipes are full, and that when each process
writes into one of the pipes they are blocked. 
\index{blocked processes}
Both processes are blocked waiting for the other to unblock them.

There is no way for the operating system to
detect every conceivable deadlock condition without expending
large amounts of CPU time. Thus, the only way to recover from a
deadlock is to kill the processes in question. Responsibility for
preventing deadlock situations is placed on the programmer.
Fortunately, situations where deadlock can occur are infrequent;
however, you should keep an eye out for them and try to work
around them when they do occur.

\index{deadlock|)}

\appendix

%
%	Appendix: Making System Calls
%

\begin{latexonly}
\chapter{Making System Calls}
\end{latexonly}
\begin{htmlonly}
\chapter{Appendix A:  Making System Calls}
\end{htmlonly}

\begin{latexonly}
\end{latexonly}
\begin{htmlonly}
\end{htmlonly}

The GNO Kernel is accessed through system
calls. The actual procedure is very simple from C: simply
\#include the appropriate header file as noted in the synopsis of
the call's manual page, and call it as you would any other C
function. From 
\index{assembly language programs}
assembly language the procedure is no more
difficult, using the advanced macros provided for the \index{APW} APW and
ORCA assemblers. Make sure, however, that you have defined a word
variable \bf errno\rm. Lowercase is important, use the 'case on'
and 'case off' directives to ensure that the definition of \bf errno \rm
is case-sensitive. The system call interface libraries store any
error codes returned by the kernel in this variable.

If you are going to be accessing the kernel
from a language other than those for which interfaces are
provided, then the following information is for you.

\section{System Call Interface}

The system calls are implemented as a user toolset, tool number 3.
These tools are called the same way regular system tools (such as QuickDraw)
are called, except that you must \tt JSL \rm to \bf \$E10008 \rm
instead of to \bf \$E10000 \rm (or to \bf \$E1000C \rm instead of
to \bf \$E10004 \rm  for the alternate entry point). The function
numbers for the currently defined tools are as follows:

\index{alarm}
\index{alarm10}
\begin{tabular}{llll}
	getpid *		& \$0903	&
	kill			& \$0A03	\\
	fork			& \$0B03	&
	swait			& \$0D03	\\
	ssignal			& \$0E03	&
	screate			& \$0F03	\\
	sdelete			& \$1003	&
	kvm\_{}open		& \$1103	\\
	kvm\_{}close		& \$1203	&
	kvm\_{}getproc		& \$1303	\\
	kvm\_{}nextproc		& \$1403	&
	kvm\_{}setproc		& \$1503	\\
	signal			& \$1603	&
	wait			& \$1703	\\
	tcnewpgrp		& \$1803	&
	settpgrp		& \$1903	\\
	tctpgrp			& \$1A03	&
	sigsetmask		& \$1B03	\\
	sigblock		& \$1C03	&
	execve			& \$1D03	\\
	alarm			& \$1E03	&
	setdebug *		& \$1F03	\\
	setsystemvector *	& \$2003	&
	sigpause		& \$2103	\\
	dup			& \$2203	&
	dup2			& \$2303	\\
	pipe			& \$2403	&
	getpgrp			& \$2503	\\
	ioctl			& \$2603	&
	stat			& \$2703	\\
	fstat			& \$2803	&
	lstat			& \$2903	\\
	getuid			& \$2A03	&
	getgid			& \$2B03	\\
	geteuid			& \$2C03	&
	getegid			& \$2D03	\\
	setuid			& \$2E03	&
	setgid			& \$2F03	\\
	procsend		& \$3003	&
	procreceive		& \$3103	\\
	procrecvclr		& \$3203	&
	procrecvtim		& \$3303	\\
	setpgrp			& \$3403	&
	times			& \$3503	\\
	pcreate			& \$3603	&
	psend			& \$3703	\\
	preceive		& \$3803	&
	pdelete			& \$3903	\\
	preset			& \$3A03	&
	pbind			& \$3B03	\\
	pgetport		& \$3C03	&
	pgetcount		& \$3D03	\\
	scount			& \$3E03	&
	fork2			& \$3F03	\\
	getppid			& \$4003	&
	SetGNOQuitRec		& \$4103	\\
	alarm10			& \$4203	\\
\end{tabular}

The following system calls are new to GNO v2.0.6:

\begin{tabular}{llll}
	select			& \$4303	&
	InstallNetDriver	& \$4403	\\
	socket			& \$4503	&
	bind			& \$4603	\\
	connect			& \$4703	&
	listen			& \$4703	\\
	accept			& \$4903	&
	recvfrom		& \$4A03	\\
	sendto			& \$4B03	&
	recv			& \$4C03	\\
	send			& \$4D03	&
	getpeername		& \$4E03	\\
	getsockname		& \$4F03	&
	getsockopt		& \$5003	\\
	setsockopt		& \$5103	&
	shutdown		& \$5203	\\
	setreuid		& \$5303	&
	setregid		& \$5403	\\
\end{tabular}

Parameters should be pushed onto the stack
in the same order as defined by the C prototypes outlines in the
synopsis section of the manual pages; that is, left-to-right. In
addition to those parameters, all of the functions (except those
denoted by a \bf *\rm) take an integer pointer parameter \bf errno\rm.
This is a pointer to a word value which will contain the \bf errno \rm
code returned by the function if an error occurs, and should be
pushed onto the stack after all the other parameters. The calls
do not clear this code to 0 if no error occurs; thus, you must
check the return value of the function to see if an error
occurred, and then check errno to get the actual error code.

Do not forget to also push space on the
stack (before the parameters) for the call to store its return
value.

These low-level system call interfaces are
not to be used in general programming. It is assumed the
programmer will use the libraries provided, or use this
information to create a new library. The system call interface is
subject to change without notice; any changes will, of course, be
documented in future versions of GNO/ME.

\section{System Call Error Codes}

The following codes are taken from \tt <sys/errno.h>\rm. The
codes up to EPERM are the same values as those defined by ORCA/C
for compatibility reasons. Error conditions are usually reported
by system calls by returning a -1 (word) or NULL (long) value.
Which error codes can be expected from a particular call are
detailed in the errors section in the appropriate manual page.

\begin{description}
\item[EDOM]
	Domain error. Basically an undefined error code.
\item[ERANGE]
	Range error. A value passed to a system call was too large,
	too small, or illegal. 
\item[ENOMEM]
	Not enough memory. The kernel could not allocate enough
	memory to complete the requested operation.
\item[ENOENT]
	No such file or directory. The file specified could not be found.
\item[EIO]
	I/O error. An error occurred trying to perform an I/O operation,
	such as that caused by bad media.  It also refers to a disk
	error not covered by the other errno codes.
\item[EINVAL]
	Invalid argument. An argument to a system call was invalid in some way.
\item[EBADF]
	Bad file descriptor. The file descriptor passed to the kernel does not
	represent an open file.
\item[EMFILE]
	Too many files are open.  The kernel cannot open any more files
	for this process; it's open file table is full. Close some other
	open files and retry the operation.
\item[EACCESS]
	Access bits prevent the operation. One of the access bit settings
	(delete, rename, read, write) associated with the file does not allow
	the requested operation.
\item[EEXIST]
	The file exists. An attempt to create a new file with the same name
	as an existing file results in this error.
\item[ENOSPC]
	No space on device. There is not enough room on the requested
	device to complete the operation.  This is usually indicative
	of a full disk. 
\item[EPERM]
	Not owner. Not yet used in GNO.
\item[ESRCH]
	No such process. The process ID specified does not refer to an active
	process. Possibly the process terminated earlier.
\item[EINTR]
	Interrupted system call.  Certain system calls can be interrupted by
	signals. In cases where the user has specified that those calls not be
	automatically restarted, the call will return this error.
\item[E2BIG]
	Arg list too long. Too many arguments were specified in an 
	\bf \_{}execve\rm(2) call.
\item[ENOEXEC]
	Exec format error. The file specified is not in an executable format
	(OMF load file).
\item[ECHILD]
	No children. This error is returned by \bf wait\rm(2) when there
	are no child processes left running.
\item[EAGAIN]
	No more processes. The process table is full, the \bf fork\rm(2)
	cannot complete.
\item[ENOTDIR]
	Not a directory. One of the elements in a pathname refers to a file
	which is not a directory.
\item[ENOTTY]
	Not a terminal. The file descriptor passed to an \bf ioctl\rm(2)
	or job control call does not refer to a terminal file.
\item[EPIPE]
	Broken pipe. If a process attempts to write on a pipe with no
	readers, and has blocked or ignored SIGPIPE, this error is
	returned by the write operation.
\item[ESPIPE]
	Illegal seek. Similar to ENOTBLK, but specific for pipes.
\item[ENOTBLK]
	Not a block device. An attempt to perform an operation on a character
	device that only makes sense on a block device.
\end{description}



\section{System Panics}

In most cases, if the kernel detects an
error in operation an appropriate error code is returned by the
function in question (GS/OS calls, ToolBox calls, or system calls
as described above). However, there are rare circumstances where
the kernel detects what should be an impossible condition. This
can happen due to bugs in the kernel, because the kernel was
overwritten by a buggy program, or for any number of other
reasons.

When the kernel does come across such an
error, system operation cannot continue and what ensues is called
a \em system panic\rm. Panics are very easily noticed- the kernel
will print an error message on the screen and ensure that the
text screen is visible, turning off any graphics mode if
necessary. The kernel then sets the text and background colors to
red on white - a very noticeable condition. At that point, the
kernel turns off 
\index{context switch}
context switching to prevent any background
process or other interrupt driven code from further confusing the
system. This is done mainly to prevent damage to disk directory
structures by a bad system.

When a system panic does occur, the only
thing you can do is reboot your system. If you can reliably
reproduce a system panic, please record the panic message and the
sequence of events necessary to evoke the panic and report the
information to Procyon, Inc.

%
%	Appendix: Miscellaneous Programming Issues
%

\begin{latexonly}
\chapter{Miscellaneous Programming Issues}
\end{latexonly}
\begin{htmlonly}
\chapter{Appendix B:  Miscellaneous Programming Issues}
\end{htmlonly}

\section{Option Arguments}

The Free Software Foundation (also known as the
FSF), invented user friendly long format option arguments, and
defined the ``\bf +\rm>'' character for interpretation
that a long format follows. This interpretation is generally
followed in the UNIX community. There are two files which will assist
you in programming GNO/ME utilities with both short and long
format options, \tt <getopt.h> \rm for short options, and
\tt <getopt1.h> \rm for long options.

\section{Pathname Expansion}

Those of you familiar with programming in
the ORCA environment should be familiar with the shell calls
\tt InitWildcard \rm and \tt NextWildcard\rm.
These shell calls, while supported by \bf gsh\rm,
are no longer necessary. All shell utilities that work with
multiple filenames do not need to provide support for file
globbing, as this is taken care of transparently to the command.

%
%	Glossary
%

\chapter{Glossary}

\begin{description}
\item[Asynchronous]
	An event that may take place at any time. See synchronous.
\item[BASIC]
	\index{BASIC}
	Beginners All-purpose Symbolic Instruction Code. A simple computer
	language.
\item[Blocked]
	\index{blocked processes}
	Refers to a process waiting for some event to occur. Processes can
	block on terminal I/O, signals, and other IPC and I/O functions.
\item[Console]
	The terminal which represents the IIGS's keyboard and monitor.
\item[Context]
	The attributes which  define the state of a process. This includes
	the program counter, stack pointer, and other machine registers (both
	CPU and other computer hardware).
\item[Controlling terminal]
	\index{controlling terminal}
	The terminal which ``controls'' a process or process group;
	processes can receive keyboard signals (such as SIGTSTP, or 
	\index{\^{}Z} \^{}Z)
	only from their controlling terminal.
\item[Critical Section]
	A piece of code inside which only one process at a time may
	be allowed to execute. Critical sections are usually protected by
	semaphores.
\item[Daemon]
	\index{daemon}
	A process that runs in the \index{background} background and
	waits to act on an
	asynchronous event. These can be anything: waiting for a caller
	on a modem, waiting for spooled files to print, etc. Daemons
	are usually started at boot time by the \bf initd\rm(8)
	process.
\item[Deadlock]
	\index{deadlock}
	A situation where two or more communicating processes are blocked,
	waiting on each other. See Chapter 5, ``Deadlock''.
\item[Errno]
	A variable which holds a descriptive numeric error code,
	returned from C libraries and system calls.
\item[Foobar, foo, bar]
	Foobar derives from an old military acronym FUBAR. In it's politest
	interpretation it stands for Fouled Up Beyond All Recognition.
	Computer scientists borrowed the term and created foobar.
	When a name for an object in a code fragment is needed but the
	name itself is not important, foo and bar are first choice among
	computing science types.  They should not be used in production
	code.
\item[Executable]
	A program as it resides on disk. Executables can be compiled or
	assembled programs, or shell scripts. Executables are run by
	typing their name on the shell's command line and frequently take
	paramters to determine what data they operate on and particulars
	of how they do it.
\item[GNO/ME]
	GNO Multitasking Environment. The complete package including the GNO
	kernel and the GNO Shell.
\item[GNO Kernel]
	Heart of GNO/ME. Executes processes when asked by the GNO Shell.
\item[GNO Shell]
	Provides an interface between the user and the GNO kernel.
\item[gsh]
	GNO Implementation of a UNIX-like shell.
\item[GS/OS]
	A 16 bit Operating System for the Apple IIgs.
\item[IPC]
	``Inter-Process Communication''. Any method by which processes
	can pass information to other processes.
\item[Job]
	\index{controlling terminal}
	A set of related processes. Jobs are generally composed of
	processes with a common parent and the same controlling terminal.
\item[Manpage]
	Refers to the system call and utility documentation provided with GNO.
	Manpages exist on disk as either \bf nroff\rm(1) or \bf aroff\rm(1)
	source.  They can also be preformatted by \bf catman\rm(1).  They
	can be viewed by various utilites on a variety of output devices.
\item[Master]
	\index{.pty}
	Refers to the .PTYxx side of a pseudo-terminal, and also
	the process controlling that device. The master is usually responsible
	for setting up the PTY and running a process on it.
\item[Message]
	A 32-bit value that is passed via the Messages IPC mechanism to
	another process.
\item[Mutex]
	\index{critical section}
	Short for mutual exclusion, a term that refers to protecting a
	critical section.
\item[Panic]
	An unrecoverable kernel error, usually indicating that an
	internal data structure has become corrupted.
\item[Parent]
	When talking about a process, the parent of a process is the one that
	spawned it; i.e., made the \bf fork\rm(2) system call.
\item[Pipe]
	A unidirectional IPC mechanism. Pipes transmit binary 8-bit data.
\item[Pipeline]
	Two or more processes connected by pipes.
\item[Port]
	A flow-controlled IPC mechanism that can pass longwords of data.
\item[Process]
	A program in execution.
\item[Process Group]
	An identifying code for a job. Process groups are also assigned
	to TTYs, which allows the TTY to differentiate \index{background} 
	background jobs	from foreground jobs when sending interrupt signals.
\item[Pseudo-terminal]
	A bidirectional communications channel, normally used in windowing
	systems or for advanced control and testing applications.
\item[PTY]
	See 'pseudo-terminal'.
\item[Semaphore]
	A data object used to synchronize concurrent processes.
\item[Sequentialization]
	\index{critical section}
	The task of ensuring that critical sections are only executed by one
	concurrent process at a time.
\item[Signal]
	A software interrupt and IPC mechanism.
\item[Slave]
	1. A good term to describe the relationship of Joe Citizen to the IRS.
	2. The \index{.tty} .TTYxx side of a pseudo-terminal; the slave
	is usually an application program of some kind, like a shell.
\item[Suspended]
	Refers to a process whose execution has been stopped.
\item[Synchronous]
	An event that takes place at a predetermined time or sequence of times.
	Also used to indicate the act of waiting for an event to happen. See
	asynchronous.
\item[Terminal]
	Any device that looks like a terminal; this includes pseudo-ttys. By
	definition, a terminal supports all of the \bf tty\rm(4)
	ioctl calls.
\item[Tty]
	Short for Teletype. TTY is an anachronistic term; in modern usage
	it is taken to mean ``terminal''.
\item[UNIX]
	Popular operating system which has growing use in education and
	business.  One of the first operating systems to support multitasking.
\end{description}

\begin{comment}
\printindex
\end{comment}

\chapter{Index}

Sorry, the index is not yet complete.  Stay tuned ...

\end{document}