10.9 Modules for Interfacing with the Operating System

callproc.c
process.c
process.h

These modules allow SXEmacs to spawn and communicate with subprocesses and network connections.

callproc.c implements (through the call-process 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 for the 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 terminates.

Process objects are also used for network connections (connections to a process running on another machine). Network connections are started with open-network-stream but otherwise work just like subprocesses.

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.

sysdep.c
sysdep.h

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 open() and stat() preprocessor constants are defined, and possibly (usually) substitutes sugared versions of read(), write(), etc. that automatically restart interrupted I/O operations.

sysfloat.h includes the necessary header files for floating-point operations.

sysproc.h includes the necessary header files for calling select(), fork(), 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 from a wait()ed-on process (some systems use a union, others use an int).

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.

getloadavg.c

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

sunpro.c

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.

hftctl.c

This module provides some terminal-control code necessary on versions of AIX prior to 4.1.