callproc.c process.c process.h
These modules allow SXEmacs to spawn and communicate with subprocesses and network connections.
callproc.c implements (through the
primitive) what are called synchronous subprocesses. This means
that SXEmacs runs a program, waits till it’s done, and retrieves its
output. A typical example might be calling the ls program to get
a directory listing.
process.c and process.h implement asynchronous
subprocesses. This means that SXEmacs starts a program and then
continues normally, not waiting for the process to finish. Data can be
sent to the process or retrieved from it as it’s running. This is used
shell command (which provides a front end onto a shell
program such as csh), the mail and news readers implemented in
SXEmacs, etc. The result of calling
start-process to start a
subprocess is a process object, a particular kind of object used to
communicate with the subprocess. You can send data to the process by
passing the process object and the data to
send-process, and you
can specify what happens to data retrieved from the process by setting
properties of the process object. (When the process sends data, SXEmacs
receives a process event, which says that there is data ready. When
dispatch-event is called on this event, it reads the data from
the process and does something with it, as specified by the process
object’s properties. Typically, this means inserting the data into a
buffer or calling a function.) Another property of the process object is
called the sentinel, which is a function that is called when the
Process objects are also used for network connections (connections to a
process running on another machine). Network connections are started
open-network-stream but otherwise work just like
Process objects are used for network server connections (connections
to SXEmacs from processes running on the same or another
machine). Network server connections are composed of a listening
process started with
open-network-server-stream. When a inbound
connection comes, it is accepted and an individual process is created
for each connection accepted, which after that will work just like a
network connection started with
open-network-stream. In order
to gain control of the accepted connection process
open-network-server-stream accepts as parameters a defun that
is called upon accept for special connection setup, like setting up an
SSL layer or exchanging credentials; and the specifications for filter
and sentinel functions for the accepted connection.
These modules implement most of the low-level, messy operating-system interface code. This includes various device control (ioctl) operations for file descriptors, TTY’s, pseudo-terminals, etc. (usually this stuff is fairly system-dependent; thus the name of this module), and emulation of standard library functions and system calls on systems that don’t provide them or have broken versions.
sysdir.h sysfile.h sysfloat.h sysproc.h syspwd.h syssignal.h systime.h systty.h syswait.h
These header files provide consistent interfaces onto system-dependent header files and system calls. The idea is that, instead of including a standard header file like <sys/param.h> (which may or may not exist on various systems) or having to worry about whether all system provide a particular preprocessor constant, or having to deal with the four different paradigms for manipulating signals, you just include the appropriate sys*.h header file, which includes all the right system header files, defines and missing preprocessor constants, provides a uniform interface onto system calls, etc.
sysdir.h provides a uniform interface onto directory-querying functions. (In some cases, this is in conjunction with emulation functions in sysdep.c.)
sysfile.h includes all the necessary header files for standard
system calls (e.g.
read()), ensures that all necessary
stat() preprocessor constants are defined, and
possibly (usually) substitutes sugared versions of
write(), etc. that automatically restart interrupted I/O
sysfloat.h includes the necessary header files for floating-point operations.
sysproc.h includes the necessary header files for calling
execve(), socket operations, and
the like, and ensures that the
FD_*() macros for descriptor-set
manipulations are available.
syspwd.h includes the necessary header files for obtaining information from /etc/passwd (the functions are emulated under VMS).
syssignal.h includes the necessary header files for signal-handling and provides a uniform interface onto the different signal-handling and signal-blocking paradigms.
systime.h includes the necessary header files and provides uniform interfaces for retrieving the time of day, setting file access/modification times, getting the amount of time used by the SXEmacs process, etc.
systty.h buffers against the infinitude of different ways of controlling TTY’s.
syswait.h provides a uniform way of retrieving the exit status
wait()ed-on process (some systems use a union, others use
hpplay.c libsst.c libsst.h libst.h linuxplay.c nas.c sgiplay.c sound.c sunplay.c
These files implement the ability to play various sounds on some types of computers. You have to configure your SXEmacs with sound support in order to get this capability.
sound.c provides the generic interface. It implements various
Lisp primitives and variables that let you specify which sounds should
be played in certain conditions. (The conditions are identified by
symbols, which are passed to
ding to make a sound. Various
standard functions call this function at certain times; if sound support
does not exist, a simple beep results.
sgiplay.c, sunplay.c, hpplay.c, and linuxplay.c interface to the machine’s speaker for various different kind of machines. This is called native sound.
nas.c interfaces to a computer somewhere else on the network using the NAS (Network Audio Server) protocol, playing sounds on that machine. This allows you to run SXEmacs on a remote machine, with its display set to your local machine, and have the sounds be made on your local machine, provided that you have a NAS server running on your local machine.
libsst.c, libsst.h, and libst.h provide some additional functions for playing sound on a Sun SPARC but are not currently in use.
This module provides the ability to retrieve the system’s current load average. (The way to do this is highly system-specific, unfortunately, and requires a lot of special-case code.)
This module provides a small amount of code used internally at Sun to keep statistics on the usage of XEmacs.
broken-sun.h strcmp.c strcpy.c sunOS-fix.c
These files provide replacement functions and prototypes to fix numerous bugs in early releases of SunOS 4.1.
This module provides some terminal-control code necessary on versions of AIX prior to 4.1.