config.h
This is automatically generated from config.h.in based on the results of configure tests and user-selected optional features and contains preprocessor definitions specifying the nature of the environment in which SXEmacs is being compiled.
paths.h
This is automatically generated from paths.h.in based on supplied configure values, and allows for non-standard installed configurations of the SXEmacs directories. It’s currently broken, though.
emacs.c signal.c
emacs.c contains main() and other code that performs the most
basic environment initializations and handles shutting down the SXEmacs
process (this includes kill-emacs, the normal way that SXEmacs is
exited; dump-emacs, which is used during the build process to
write out the SXEmacs executable; run-emacs-from-temacs, which can
be used to start SXEmacs directly when temacs has finished loading all
the Lisp code; and emergency code to handle crashes [SXEmacs tries to
auto-save all files before it crashes]).
Low-level code that directly interacts with the Unix signal mechanism, however, is in signal.c. Note that this code does not handle system dependencies in interfacing to signals; that is handled using the syssignal.h header file, described in section J below.
unexaix.c unexalpha.c unexapollo.c unexconvex.c unexec.c unexelf.c unexelfsgi.c unexencap.c unexenix.c unexfreebsd.c unexfx2800.c unexhp9k3.c unexhp9k800.c unexmips.c unexnext.c unexsol2.c unexsunos4.c
These modules contain code dumping out the SXEmacs executable on various different systems. (This process is highly machine-specific and requires intimate knowledge of the executable format and the memory map of the process.) Only one of these modules is actually used; this is chosen by configure.
ecrt0.c lastfile.c pre-crt0.c
These modules are used in conjunction with the dump mechanism. On some
systems, an alternative version of the C startup code (the actual code
that receives control from the operating system when the process is
started, and which calls main()) is required so that the dumping
process works properly; crt0.c provides this.
pre-crt0.c and lastfile.c should be the very first and very last file linked, respectively. (Actually, this is not really true. lastfile.c should be after all Emacs modules whose initialized data should be made constant, and before all other Emacs files and all libraries. In particular, the allocation modules gmalloc.c, alloca.c, etc. are normally placed past lastfile.c, and all of the files that implement Xt widget classes must be placed after lastfile.c because they contain various structures that must be statically initialized and into which Xt writes at various times.) pre-crt0.c and lastfile.c contain exported symbols that are used to determine the start and end of SXEmacs’ initialized data space when dumping.
alloca.c free-hook.c getpagesize.h gmalloc.c malloc.c mem-limits.h ralloc.c vm-limit.c
These handle basic C allocation of memory. alloca.c is an emulation of
the stack allocation function alloca() on machines that lack
this. (SXEmacs makes extensive use of alloca() in its code.)
gmalloc.c and malloc.c are two implementations of the standard C
functions malloc(), realloc() and free(). They are
often used in place of the standard system-provided malloc()
because they usually provide a much faster implementation, at the
expense of additional memory use. gmalloc.c is a newer implementation
that is much more memory-efficient for large allocations than malloc.c,
and should always be preferred if it works. (At one point, gmalloc.c
didn’t work on some systems where malloc.c worked; but this should be
fixed now.)
ralloc.c is the relocating allocator. It provides
functions similar to malloc(), realloc() and free()
that allocate memory that can be dynamically relocated in memory. The
advantage of this is that allocated memory can be shuffled around to
place all the free memory at the end of the heap, and the heap can then
be shrunk, releasing the memory back to the operating system. The use
of this can be controlled with the configure option --rel-alloc;
if enabled, memory allocated for buffers will be relocatable, so that if
a very large file is visited and the buffer is later killed, the memory
can be released to the operating system. (The disadvantage of this
mechanism is that it can be very slow. On systems with the
mmap() system call, the SXEmacs version of ralloc.c uses
this to move memory around without actually having to block-copy it,
which can speed things up; but it can still cause noticeable performance
degradation.)
free-hook.c contains some debugging functions for checking for invalid
arguments to free().
vm-limit.c contains some functions that warn the user when memory is getting low. These are callback functions that are called by gmalloc.c and malloc.c at appropriate times.
getpagesize.h provides a uniform interface for retrieving the size of a page in virtual memory. mem-limits.h provides a uniform interface for retrieving the total amount of available virtual memory. Both are similar in spirit to the sys*.h files described in section J, below.
blocktype.c blocktype.h dynarr.c
These implement a couple of basic C data types to facilitate memory
allocation. The Blocktype type efficiently manages the
allocation of fixed-size blocks by minimizing the number of times that
malloc() and free() are called. It allocates memory in
large chunks, subdivides the chunks into blocks of the proper size, and
returns the blocks as requested. When blocks are freed, they are placed
onto a linked list, so they can be efficiently reused. This data type
is not much used in SXEmacs currently, because it’s a fairly new
addition.
The Dynarr type implements a dynamic array, which is
similar to a standard C array but has no fixed limit on the number of
elements it can contain. Dynamic arrays can hold elements of any type,
and when you add a new element, the array automatically resizes itself
if it isn’t big enough. Dynarrs are extensively used in the redisplay
mechanism.
inline.c
This module is used in connection with inline functions (available in some compilers). Often, inline functions need to have a corresponding non-inline function that does the same thing. This module is where they reside. It contains no actual code, but defines some special flags that cause inline functions defined in header files to be rendered as actual functions. It then includes all header files that contain any inline function definitions, so that each one gets a real function equivalent.
debug.c debug.h
These functions provide a system for doing internal consistency checks
during code development. This system is not currently used; instead the
simpler assert() macro is used along with the various checks
provided by the ‘--error-check-*’ configuration options.
universe.h
This is not currently used.