When the InterBase sources are released, you will
find yourself facing a significant amount of code,
varying widely in sophistication and relevance.

1) Engine. The engine directory is "jrd" - Jim's Relational
Database" - not one to hide his light under a barrel is our
Jim. The external entry points are in isc.c. They generally
call a matching set of internal routines in JRD.C. JRD
calls off to CMP.C to compile requires, MET.C to find
metadata, and EXE.C to execute a compiled request. When
EXE.C wants data, it calls RSE.C (record source expression,
I think). It uses BTR.C (b-tree) for index lookups, VIO
(virtual I/O) to get records by record id, SORT.C for
sorting (surprise!). VIO gets its records from CCH.C, the
cache handler. CCH is the lowest level that has any concept
of page types or structured data. It calls PIO.C to do the
actual reading from disk.

MET.C is a preprocessed file. The actual file is "MET.E".
Other preprocessed modules are DPM (data page manager - it
works with VIO, getting records and cleaning up stuff),
DFW (deferred work. It creates indexes and actually makes
metadata changes when a transaction commits.)

EVL.C evaluates expressions. CMP.C performs comparisons.
FLU.C is the function look up module. GDS.C has service
routines, visible outside the server.

CODES.H is an interesting problem. It's created by CODES.E
(precompiled to CODES.C) from the message database. You need
codes.h before you can build the engine and the engine before
you can run CODES.C.

Another module worth looking at is ALL.C, the block allocation
(and deallocation routine). The old utilities also have an
ALL.C module.

Coding conventions. Externally visible routines are XXX_<name>
where XXX is the three (or four) letter module name. Routines
in a module start with the external routines in alphabetical
order, followed by the internal routines in alphabetical order.

2) Guardian

The guardian is in the ISCGUARD directory. It's a windows
thing.

3) Server-side client interface
4) Client-side client interface

Both these bits are in the directory REMOTE. It's a cute
architecture, which requires more explanation that I can
provide here. As far as I know, it can't be explained
without a whiteboard.

5) IBX
6) InterClient
7) InterServer
8) IBConsole
They'll show up, but they're a mystery to me at the moment.

9) ISQL
10) WISQL
ISQL directory.

11) qli
QLI directory. Query Language Interpreter. It's a command
line interactive query language with "procedures" which are
stored sections of QLI code that are invoked like macros
(without arguments, worse luck). Starts at DTR.C (Datatrieve,
its paternal ancestor). Commands and statements (they're
different) go through LEX.C (which breaks them into lexemes)
PAR.C (which parses them), COMPILE.C (which compiles them).
GENER.C generates BLR. QLI, like all the old utilities, uses
the BLR interface rather than DSQL. PICSTR interprets data
formatting instructions - lots of them. Jim objects strongly
to pronouncing it "pick stir".

12) gbak
BURP directory. (Back Up Restore Program). The main
modules are backup.e and restore.e. The entrypoint is
in BURP.C.

13) gfix
ALICE directory. (All Else).

14) marion (source code management system)

15) tcs (test control system for regression testing)
TCS will be provided with a small set of tests, orgainized
in series and metaseries.

16) fred - forms editor for a very creaky VT100 style forms package.
17) pixis - the aforementioned forms package.
18) pictor - an unsuccessful graphical query language.
These three gems seem to have disappeared. If I can find the
code and if I can convince Borland to release it, I'll expose
them to the light of day.

19) dudley.
DDL utility. Interpreted commands in the old data definition
language (declare relation, declare field - square brackets
where you want to put parentheses). Generates BLR for views
and triggers, GDML (non-SQL relational language) for metadata
updates.

20) gpre
Preprocessor for static SQL and GDML. Internally much like
QLI, except that it understands COBOL. Probably the best
BLR generator of the bunch.

21) dsql
The dynamic sql processing. Originally, DSQL was compiled into
BLR on the client side, requiring that the client have a copy
of the relevant metadata. Now, DSQL strings are passed and
interpreted on the server side and parsed into BLR there.

22) extlib
The predefined "user" defined functions.

23) Internationalization.
In the INTL directory. This will make a great deal more sense
when you've read Dave Schnepper's paper.

24) Lock Manager
In the lock directory. Used for classic architecture versions
to coordinate page access (and such things). Based on the
VMS distributed lock manager.

25) Msgs
Subsystem for creating, checking, and changing message text.

26) Utilities
Server manager appers to be here, and gsec.

27) WAL - write ahead log. Dead, to the best of my knowledge.

That's all I know about.

Ann