A cut out and keep guide to the Firebird source code

<< High-level description of the InterBase 6.0 source code | Database technology articles | Character sets and Unicode in Firebird >>

A cut out and keep guide to the Firebird source code

By Ann Harrison and Paul Beach.

This document is a rough guide to the Firebird code tree. Parts of that code tree build the Firebird Server, parts build utilities, and parts provide additional elements of the Firebird kit, and a certain number of parts don't contribute anything, being specific to environments that no longer exist. In traditional ISC terminology, a component is equivalent to a directory and contains a number of related source and header files. Some components are independent programs, some are subsystems in a larger entity, and some are both. Within a component, the individual source files are called modules. Within a module, the individual functions are called routines and reference structures called blocks.

The major component of the server is JRD. Other components used exclusively in the server and client interfaces are DSQL, INTL, LOCK, UTILITIES, REMOTE, and WAL. Both LOCK and UTILITIES contain additional code that builds utilities to analyze the lock table and database contents, respectively. In addition, the components ALICE and BURP can be built either as part of the server, or standalone. The PYXIS and JOURNAL components are obsolete.

  • DSQL is the component that takes SQL language and transforms it into BLR, the native language of the server. It is always part of the ibserver.
  • JRD stands for Jim's Relational Database in respect [for the amazing ego] of InterBase®'s original author, Jim Starkey. In addition to the major data handling code, this component stores many of the common routines used by other components.
  • INTL is the component that handles non-ASCII character sets and collating sequences.
  • LOCK is the component that handles synchronization between transactions. It manages a lock table, allowing resources to be reserved, shared, released, etc.
  • The remote interface is stored in the REMOTE component (/REMOTE) and contains the basic routines for communicating with remote systems regardless of the communications protocol. The REMOTE component also contains the source for servers which communicate by a remote protocol. Three special types of servers are stored within their own components CSV (/CSV), PIPE (/PIPE), and IPSERVER (/IPSERVER).
  • The UTILITIES component contains several modules that don't really fit anywhere else.
  • CSV is no longer used. At one point it provided a shared access point for remote clients on systems which had trouble managing large numbers of client connections. PIPE, the pipe server, allowed individual clients to share the server code on operating systems that did not support shared libraries.
  • IPSERVER is a local communication method for Windows systems that uses shared memory to emulate communication through a remote protocol.

And the various tools are located in the following components:

  • ALICE (/ALICE), All-else. The name implies that it was a catch all for everything that didn't really fit anywhere else. Its production name is GFIX. It is embedded in the SuperServer architecture and standalone for both.
  • BURP (/BURP) for backup and restore, GBAK to you and me. It is a properly layered program that reads and serializes the metadata and data from a database or recreates a database from its backup format.
  • GPRE (/GPRE) is the source code pre-compiler for embedded C, Cobol, Pascal, Fortran, Ada and Basic programs. It is always built as a standalone program. GPRE processes both SQL and GDML, an earlier relational language.
  • DUDLEY (/DUDLEY), sounds like DDL (data definition language) and is the pre 4.0 data definition utility GDEF. It's actually named after Dudley Doright, a character from Rocky and Bullwinkle. GDEF accepts a data definition language based on GDML.
  • ISQL (/ISQL) is the command-line version of the interactive tools used in WISQL and the IBConsole.
  • JOURNAL (/JORNAL) is the after image journaling component, i.e. the first attempt before it was superceded by WAL.
  • PYXIS (/PYXIS) is an old forms editor and screen handling tool designed for the VT100. Does anybody remember the VT100?
  • QLI (/QLI) stands for Query Language Interpreter, an old pre 4.0 interface for InterBase® that supported GDML (the original InterBase® database manipulation language) and a subset of SQL. It provides a useful (though primitive) programming language with loops, conditionals, prompting, and report formatting.

Module names, TLAs, CFLAs, and other acronyms defined, by source directory structure, starting at the core of the engine (/JRD) and working outward.

back to top of page

/JRD

Jim's Relational Database with reference to original author.

  • AIF, aif.c: MPE/XL Architected Interface Facility. MPE/XL was an HP operating system, "almost like Unix - but not quite" and now called HP/IX. Referenced in the build but never used.
  • AIL, ail.c: After Image Log, part of the Write Ahead Log. Not used but carried along.
  • ALIGN, align.c: Program stored in /JRD that determines the alignment and byte ordering rules for a platform.
  • ALL, all.c: Memory allocation routines. Used to allocate and deallocate data structures. Also manages the pool mechanism. Should really be renamed to ALLOC. It has relatives called ALLD (allocate in DSQL), ALLR (allocate in REMOTE) ALLI (allocate in IPSERVER), ALLQ (allocate in QLI).
  • ALT, alt.c: An ALTernative entry points. Over time, the prefix used for InterBase® external entry points has varied from gds_$ to gds__ to isc_. This is a translator for the "router" WHY. These start with isc_.
  • BKM, bkm.c: Bookmark. Part of the Dbase emulation code that placed markers in a record stream so the program could return directly to a point.
  • BLB, blb.c: Internal blob handling routines for the storage and retrieval of blobs.
  • BLF, blf.e, blf.c: Blob filter driver. Handles blob filters, if a blob filter for a blob then the blob is filtered through it. Contains therefore the code that handles the transformation of one blob type to another, possibly indirectly.
  • BLK blk.c: Block, the parent class of all the volatile storage handled by the various ALL modules. Blocks have a header which helps the system reuse them efficiently. Firebird has hundreds of block types, all essentially child classes of the parent block.
  • BLR: Binary Language Representation.
  • Blrtable.c: BLR to internal conversion table generator.
  • BTR, btr.c: B-Tree Manager, handles the storing and updating of index nodes and the other inner mechanisms of indexes.
  • BUILTIN, builtin.c: Entry points for poisonous built-in QA routines. Deprecated.
  • CCH, cch.c: Cache management code. Handles fetching and writing pages to disk. Handles database pages being maintained in memory for efficiency.
  • CMP, cmp.c: Request compiler, compiles a database request, which turns the relation BLR into executable blocks (aka nodes).
  • CODES, codes.e, codes.c: An independent program that creates a number of header files from the message database.
  • CVT, cvt.c: Converts (and moves) data from one type and location to another type or location.
  • CVT2, cvt2.c: The second half of CVT. It just got too big and messy.
  • DBG, dbg.c: Debugging code.
  • DBT, dbt.c: Templates for block printer included for debugging.
  • DFLOAT, dfloat_stub.c: The early VAX version of double precision float.
  • DFW, dfw.e: Deferred work. Operations on metadata objects (CREATE TABLE, ALTER TABLE, etc.) are completed when their transaction commits. This module catches and completes the work.
  • DLS, dls.c: Directory list services. Temporary files can be allocated in a number of directories. This module manages the list of directories for temporary files.
  • DMP, dmp.c: Page dump routine, part of the debugging subsystem.
  • DPM, dpm.e, dpm.c: Data Page Manager. Part of the I/O system that handles storing records on pages and retrieving records from pages. It sits between CCH (which gets and puts pages) and VIO.
  • DSC, dsc.c: Data elements (e.g. field values) are passed interally through blocks called descriptors which include a pointer to the data, its type, size, scale, subtype, and a null flag. This module handles descriptors.
  • DYN, dyn.e, dyn_def(ine).e, dyn_del(elete).e, dyn_mod(ify).e, dyn_util(ility).e: Originally when data defintion was done through direct system table updates. That turned out to be more complicated than anyone could deal with so a set of calls was added to create "higher level" data definition calls. "Static" data definition was handled through gdef which did direct system table updates. More modern utilities used dyn as a more dynamic way of updating metadata.
  • ENC, enc.c: Encryption routines. Cribbed from BSD.
  • ENVELOPE, envelope.e, envelope.c: Envelope generator, used at one time to create function declarations under various operating environments. Long since abandoned.
  • ERR, err.c: Generalized error handler for error processing, logging, etc.
  • EVENT, event.c: Event manager, implements database events, event registration, passing notification etc.
  • EVL, evl.c: Expression evaluation, part of the runtime environment. EVL takes an execution node (block) and produces its result. It adds, subtracts, compares etc, relying on CVT to produce comparable elements. It also evaluates more complex nodes l ike RSB's (Record Selection Blocks)
  • EXE, exe.c: Statement execution. "Runs" a database request doing the work specified. In this case, a "statement" corresponds to a call in the low-level API that fetches data or changes the state of the data in the database.
  • EXT, ext.c: External table access for flat files.
  • EXTVMS, extvms.c: External file access for VAX/VMS RMS files, supported sequential and ISAM files.
  • FILTERS, fliters.c: Built-in blob filters to create human readable versions of the system table blobs.
  • FLU, flu.c: Function Lookup. Used to dynamically look up UDF and blob filters.
  • FUN, fun.e, fun.c: Sorry, no fun at all. Function lookup mechanism. Handles external user-defined functions.
  • GDS, (Groton Database Systems, precursor to the slightly better named Interbase Software Corporation) gds.c: General purpose routines available to client programs that convert internal date formats to C tm structures, handle error reporting, and those used by GPRE to make pre-processing an embedded program easier etc.
  • GDWEP, gdswep.c: WEP stands (I think) for Windows Exit P. It's a required routine for windows (not win32) libraries to allow cleanup.
  • GRAMMAR, grammar.y, grammar.c, jlex.c: Part of the debugging code, probably quite neglected.
  • GRANT, grant.e, grant.c: Processes a SQL GRANT statement.
  • IBSTDIO, ib_stdio.c: Generally just a wrapper for standard I/O. On Solaris, it's the BSD standard io package. Solaris uses an eight bit file descriptor which really makes opening a lot of TCP connections difficult. This affects only buffered I/O.
  • IBERR, iberr.c, iberr.h: Code for managing the status vector, including two really spectacular macros.
  • IBINITDLL, ibinitdll.c: Win32 dll initialization routine.
  • IDX, idx.c: Index manager, updates indices to reflect which new records have been stored, or which records have been updated.
  • INF, inf.c: Information handler. Gathers information for gds_database_info() calls about database usage.
  • INI, ini.e, ini.c: Metadata initialization / population. Initializes an empty database and creates all the system tables.
  • INTL, intl.c: The code that calls the routines in the internationalization dlls. The actual code that handles a collating sequence or character set is in a separate dll. This module invokes the dll.
  • INUSE, inuse.c: INUSE marks objects (mutexes, rw_locks, and pages in cache) as in use and cleans up on thread switch.
  • ISC, isc.c: General purpose utilities that provide functions for the server like setting and clearing AST mode and reading the configuration file.
  • ISC_FILE, isc_file.c: Originally part of isc.c which became obese. This module contains routines that analyze filenames to avoid accidentally opening the same file twice, thinking it's two different databases, as well as other file services.
  • ISC_IPC, isc_ipc.c: Similar to ISC_FILE, but focused on issues of interprocess communication.
  • ISC_SYNC, isc_sync.c: Again, similar to ISC_FILE, but focused on process synchronization. ISC, ISC_FILE, ISC_IPC, and ISC_SYNC are all heavily conditionalized on operating system and might make more sense as something more like PIO, split by environment, not function.
  • JIO, jio.c: Journal I/O used to physically write to a pre WAL journal file.
  • JRD, jrd.c: Holds the entry points for local database access.
  • JRN, jrn.c: Journal handling (pre 4.0 and WAL), contains routines for logically putting records into a journal, see /JOURNAL component.
  • LAN, lan.c: gethostname for OS/2.
  • LCK, lck.c: Lock handler, contains high level routines for handling locks and interfaces with the real LOCK manager found in the /LOCK component.
  • LLIO, llio.c: Low level I/O for the WAL.
  • LOG, log.c: Logging facility for REPLAY, logs database calls and all their arguments, so a problem can be recreated in detail.
  • LOITER, loiter.c: LOITER_loiter yields control to the Windows non-pre-emptive "operating system." It returns TRUE if the calling function is to continue its processing, and FALSE if the calling function is to break out of what-ever it was doing and return to the master executable.
  • MAP, map.c: Data type mapper, matches internal data types with external. E.g maps RDB data types to InterBase® data types.
  • MATH, math.c: Floating point operations which are explicitly performed outside the module in which they are requested. This allows us to place a stack switching layer in order to guarantee that the EXE stack is in effect at the time the floating point operations are performed. This is necessary for the floating point co-processor to handle floating point errors correctly (instead of GPFing). Obsolete.
  • MBLR, mblr.c: Maps MBLR commands to DYN commands. MBLR is the metadata update language used by Rdb.
  • MEM, mem.c: memcmp, memcpy, memset - emulations for systems that don't have them.
  • MET, met.e, met.c: Metadata handling, fetches and caches current metadata, and performs the required maintenance tasks when metatdata is being modified.
  • MISC, misc.c: Internal service routines - pop and push, plus mktemp for netware.
  • MOV, mov.c: moves data around, primarily by calling cvt.c.
  • NAV, nav.c: Navigational index retrieval.
  • NOD, nod.h: Node types.
  • NODEBUG, nodebug.c: Non-debugging place holder for debugging routines.
  • OLD, old.c: On Line Dump for starting the WAL journalling system.
  • OPT, opt.c: Request optimizer. Evaluates an expanded parse tree against current indices etc. and attempts to produce an optimal access method for a given query.
  • PAG, pag.c: Page level formatting.
  • PAR, par.c: BLR parser - generates tree structure of node blocks.
  • PCMET, pcmet.e, pcmet.c: Code for handling the dBase emulation metadata - things like expression indexes...
  • PCSLEEP, pcsleep.c: With a call to sleep, the current program is suspended from execution for the number of seconds specified by the argument seconds. The interval is only accurate to the nearest hundredth of a second, or the accuracy of the MS-DOS clock, whichever is less accurate.
  • PERF, perf.c: Interface to performance monitoring tools.
  • PIO, pio.h, apollo.c, mpexl.c, unix.c, vms.c windows.c, winnt.c: Physical I/O, with a module for each type of operating system, used to physically read and write database pages to disk. Other types of I/O (e.g. journalling, sort temporary files, etc.) are handled in other routines. Because Unix I/O is quite consistent, unix.c handles all of them.
  • PRINT, print.c: Program to print the event table.
  • PWD, pwd.c: Password database handling.
  • QATEST, qatest.c: "Built in" UDF's for destructive testing.
  • QUAD, quad.c: Quad word emulation routines, all of which return errors except compare.
  • RDB, rdb.c, rdbint.c, rdbgpas.c: RDB Relational Database, after DEC's Rdb/VMS, a precursor to InterBase®, now owned by Oracle. InterBase® did support a direct interface/bridge to it via OSRI (Jim's Open Standard Relational Interface), a superset of DSRI (Digital Standard Relational Interface).
  • REC, rec.c: Recovery code for WAL.
  • RLCK, rlck.c: Record and relation locking.
  • RNG, rng.c: Refresh range handling for dBase emulation.
  • RSE, rse.c: Request Select Expression, this handles record stream retrieval and takes a RSB as input and produces a stream of records.
  • SBM, sbm.c: Sparse Bit Map handling, when records are accessed via an index, the RSE generates a sparse bitmap to indicate which records should be retrieved.
  • SCH, sch.c: SCH Voluntary thread scheduler for cooperative threading. Controls the running of threads in the database.
  • SCL, scl.e, scl.c: Performs security checks, compares the operation being performed with the access permissions that a user has on an object in the database.
  • SDL, sdl.c: Parses Slice Description Language, the array slice manipulator.
  • SDW, sdw.c: Handles database shadowing.
  • SEG, seg.c: Segmented memory mover.
  • SHRFINIT, shrfinit.c: Imported symbol initialization for shared UDF library.
  • SHRINIT, shrinit.c: Imported symbol initialization for shared library.
  • SORT, sort.c: Record sorting. Physically sorts a table for ORDER BY, DISTINCT, GROUP BY, and MERGE SORT, writing intermediate runs to disk if necessary.
  • SQZ, sqz.c: Compression and decompression of records.
  • STATS, stats.e, stats.c: Record statistics manager.
  • STUBS, stubs.c: emulate gethostid.
  • SVC, svc.c: Interface to the services API - access to various stuff.
  • SYM, sym.c: Symbol table, inserts objects in a symbol table and retrieves them.
  • THD, thd.c: Thread handling functions. Could also be pronounced "thud", but then takes on quite a different meaning.
  • TPC, tpc.c: TIP (transaction inventory page) cache.
  • TRA, tra.c: Transaction handling.
  • UTL, utl.c: Utilities for blob handling.
  • UTLSWEP, utlswep.c: Windows DDL cleanup.
  • VAL, val.c: Validates a database, does garbage collection of unused database pages, orphaned records and fragments.
  • VIO, vio.c: Virtual I/O manager, Does record manipulation things like retrieving and storing records, expanding back records, garbage collection etc.
  • VMSEVENT, vmsevent.c: Events are handled like locks, so they too need a separate VMS incarnation.
  • VMSLOCK, vmslock.c: Interface to the VMS Lock Manager. On VAX/VMS InterBase® used the Operating System Lock Manager rather than its own.
  • WHY why.c: Universal Y-valve. Obvious, isn't it? It's like a router. When you attach to a database InterBase® must decide which interface it will use to connect to the database. If the database is remote, then the remote interface is used, if it is local a number of other options are available. When a gds_attach_database call comes in the Y-valve calls a number of subsystems in an attempt to attach to the database. If a filename is passed and represents a database that a subsystem can open then the attachment will be successful. Current subsystems (entry points) are: JRD8, JRD5, REMOTE, CSI, RDB, PSI, PSI5 and IPI.
  • WINDOWS, windows.c: PIO (physical I/O) routines for 16 bit Windows.
  • WINNT, winnt.c: PIO (physical I/O) routines for Windows NT & WIN2K & Windows9x.

back to top of page

/LOCK

Code for handling the lock table

  • DRIVER, driver.c: Test driver for the lock manager.
  • LOCK, lock.c: Lock handling code.
  • MANAGER, manager.c: Obsolete module to start standalone lock manager.
  • PLS, pls.c: Page lock server interface - the "client" side of a very stripped down server.
  • PLSERVER, plserver.c: Page lock server - a very stripped down server for cross node databases.
  • PRINT, print.c: Lock table printer.
  • PRINTV3, printv3.c: Lock table printer for earlier lock table.
  • PRINTV3S4, printv3s4.c: Lock table printer for some other lock table.
  • RESET, reset.c: Reset semaphores.
  • ULIMIT, ulimit.c: Emulate ulimit.

/ALICE

GFIX

  • ALICE, alice.c: Does everything.
  • ALL, all.c: Block allocator.
  • EXE, exe.c: Database calls.
  • MET, met.e, met.c: Metadata lookup.
  • TDR, tdr.c: Contains routines for automated transaction recovery.

back to top of page

/BURP

GBAK BackUp and Restore Program.

  • BACKUP, backup.e, backup.c: Backs up a database, recording the state of the metadata and saving the data.
  • BURP, burp.c: Central control module for backup/restore.
  • BURWEP, burpwep.c: Windows initialization.
  • CANONICAL, canonical.c: Converts data to XDR format for transportable backup... and back.
  • MISC, misc.c: Utility routines - alloc, free, & null terminate.
  • MVOL, mvol.c: Confusingly, the I/O for backup/restore. Stands for multi-volume.
  • RESTORE, restore.c: Read a backup file and create a new database full of old data.
  • SPIT, spit.c: Command-line interpreter for backup file split/join utility program.

/CSV

Central SerVer Precursor to Superserver. (Can be confusing, since another well known meaning is Comma Separated Values.)

  • CSI, csi.c: Client interface to the central server.
  • CSS, css.c: Central server services.
  • CSU, csu.c: Central server management utility.
  • CSV, csv.c: Central server itself.
  • PRINT, print.c: Utility to print the global region of a central server.

back to top of page

/DSQL

(/DSQL) Dynamic Sequel Query Language.

  • ALLD, alld.c: Block allocation.
  • ARRAY, array.e, array.c: Special handling for arrays.
  • BLOB, blob.e, blob.c: Special handling for blobs.
  • DDL, ddl.c: Data definition language handling.
  • DSQL, dsql.c: Main module and traffic cop.
  • DSQLWEP, dsqlwep.c: Windows startup/cleanup code.
  • ERRD, errd.c: Error handling.
  • GEN, gen.c: Generate BLR.
  • HSH, hsh.c: Hash table manager.
  • MAKE, make.c: Make blocks of various types for processing after parse and before generate.
  • METD, metd.e, metd.c: Metadata manager.
  • MOVD, movd.c: Mover and converter.
  • PARSE, parse.c parse.y: Parser with a little bit of lex thrown in.
  • PASS1, pass1.c: First step of the compilation.
  • PREPARSE, perparse.c: The real lexical analyzer.
  • USER_DSQL, user_dsql.c: DSQL was originally on the client side. These are client-side interfaces for compatibility.
  • UTLD, utld.c: Various utility routines.

back to top of page

/DUDLEY

(/DUDLEY) GDEF - old fashioned data definition language processor.

  • DDL, ddl.c: Central module and traffic cop.
  • EXE, exe.e, exe.c: Execution engine - actually makes the changes.
  • EXPAND, expand.c: Expand references to various things - fields to global fields, etc.
  • EXPR, expr.c: Evaluate expressions.
  • EXTRACT, extract.e, extract.c: Extract metadata.
  • GENERATE, generate.c: Generate the calls etc. to make the changes requested.
  • HSH, hsh.c: Hash table manager.
  • LEX, lex.c: Lexical analyzer.
  • PARSE, parse.c: Parser - turn a stream of lexemes into a tree of nodes.
  • TRN, trn.c: Translate the structures set up for direct system table updates to use dyn.

/EXAMPLE4, /EXAMPLE5, /EXAMPLES

Directories of examples & databases.

/EXTLIB

Modules for building the default UDF library.

  • IBUDF, ibudf.c: The standard set of UDFs.
  • IBUTIL, ibutil.c: A MALLOC just for UDFs.

back to top of page

/GPRE

Pre-compiler, pre-processor. Converts ESQL to its destination language (e.g. 'C').

  • ADA, ada.c: Code generator for ADA.
  • C_CXX, c_cxx.c: Code generator for C & C++.
  • CMD, cmd.c: Command interpreter (e.g. START TRANSACTION, COMMIT, ATTACH ...).
  • CMP, cmp.c: Compile - expand references and massage the node tree into something from which code will be generated.
  • COB, cob.c: Code generator for COBOL.
  • DYNTABLE, dyntable.c: Program to generate dyntable.h - structures for generating dynamic DDL.
  • EXP, exp.c: Expression compiler.
  • FORM, form.c: Antique forms package.
  • FORM_TRN, form_trn.c: Form translation (?).
  • FTN, ftn.c: Code generator for Fortran.
  • GPRE, gpre.c: Central control module and traffic cop.
  • HSH, hsh.c: Hash table management.
  • INT, int.c: Code generator for internal engine modules - uses internal entry points and structures.
  • JRDMET, jrdmet.c: Copy of the core metatdata? used to preprocess when a database is not available - bootstrapping, for example.
  • MET, met.e, met.c: Metadata handler.
  • MOVG, movg.c: Move and convert.
  • MSC, msc.c: Useful stuff.
  • NOFORM, noform.c: Placeholder for forms when they aren't implemented.
  • PAR, par.c: Parse.
  • PAS, pas.c: Code generator for Pascal.
  • PAT, pat.c: General pattern expansion.
  • SQE, sqe.c: SQL expression analyzer.
  • SQL, sql.c: SQL language compiler.

back to top of page

/INTL

Depending on context, either International (i.e. I18n) or Internal (as in Internal Work/Release).

/IPSERVER

Single client TCP/IP server.

  • ALLI, alli.c: Allocate/free.
  • IPCEVENT, ipcevent.c: Event handler.
  • IPCLIENT, ipclient.c: Client-side interface.
  • IPSERVER, ipserver.c: Main server code.

/ISCGUARD

Guardian process to restart server as necessary.

  • CNTL_GUARD, cntl_guard.c: Control panel thingy for Windows.
  • ISCGUARD, iscguard.c: Guardian process.
  • ISCGUARD_UTILS, issguard_utils.c: Read registry entries.

back to top of page

/ISQL

  • EXTRACT, extract.c: Metadata extract - make a DDL file from a database.
  • ISQL, isql.e, isql.c: Main routine - does entirely too much IMHO.
  • ISQL_WIN, isql_win.c: Window management.
  • SHOW, show.e, show.c: Show tables, show table, stuff like that.

/JOURNAL

Journalling, the version before the most recently abandonned effort.

  • ARCHIVE, archive.c: Make a journal file inactive and allow it to be copied to safe storage.
  • CONSOLE, console.c: Journal management.
  • GJRN, gjrn.c: Journalling itself.
  • MISC, misc.c: Miscellaneous useful stuff.
  • OLDR, oldr.c: On-Line Dump to start the journal.

back to top of page

/MSGS

Stuff for managing the message database.

  • BUILD_FILE, build_file.e, build_file.c: Build the various header files from the message database.
  • CHANGE_MSGS, change_msgs.e, change_msgs.c: Simple changes allowed.
  • CHECK_MSGS, check_msgs.e, check_msgs.c: Look for any change in the messages so the headers can be rebuilt.
  • ENTER_MSGS, enter_msgs.e, enter_msgs.c: Store new messages.
  • MODIFY_MSGS, modify_msgs.e, modify_msgs.c: More elaborate modifications to messages.

/PIPE

Ancient configuration for systems that didn't handle shared libraries.

  • ALLP, allp.c: Alloc/Free routines.
  • FOOT, foot.c: The server end of the pipe.
  • HEAD, head.c: The client end of the pipe (or is it the other way around?).

back to top of page

/PYXIS

Archaic forms package.

  • ADM, adm.c: Apollo display manager.
  • ALLP, allp.c: Allocate/Free.
  • ALTP, altp.c: Alternative entry points.
  • BLK, blk.c: Block size tables.
  • CDM, cdm.c: Cursor Display Manager.
  • CURSES_PLAY, curses_play.c: Tool for working with cursors.
  • DEBUG, debug.c: Debugging tools.
  • EDIT, edit.e, edit.c: Form editor back end.
  • FRED, fred.e: Forms editor.
  • MENU, menu.c: Menu manipulation routines.
  • PHASE2, phase2.c: High-level form oriented primitives.
  • PHASE3, phase3.c: Routines for preprocessor generator stuff.
  • PYXIS, pyxis.c: Central routine.
  • SAVE, save.e: Save forms to the database.
  • SCR, scr.c: Logical Screen Handler.
  • SUN_FTN_PYXIS, sun_ftn_pyxis.c: "Wrapper" module which compensates for the Sun Fortran compiler appending an underscore to external entry points. (Each function in this module is an InterBase® entry point with an underscore appended to it which calls the real InterBase® function).
  • VDM, vdm.c: VMS Display Manager.
  • VT100, vt100.c: VT100 Terminal Manager (more like VT220).

back to top of page

/QLI

Query Language Interpreter that preceded the ISQL utility.

  • ALL, all.c: Allocate/Free.
  • COMMAND, command.c: Command interpreter - COMMIT, START TRANSACTION, etc.
  • COMPILE, compile.c: Statement compiler.
  • DTR, dtr.c: Main module and traffic cop.
  • ERR, err.c: Error handling.
  • EVAL, eval.c: Expression evaluator.
  • EXE, exe.c: Execution engine.
  • EXPAND, expand.c: Expand a syntax tree - compile phase 1.
  • FORM, form.c: Interface for forms.
  • FORMAT, format.c: Format output.
  • GENER, gener.c: Generate BLR.
  • HELP, help.e, help.c: Help subsystem.
  • HSH, hsh.c: Hash table management.
  • LEX, lex.c: Lexical analyzer.
  • META, meta.e, meta.c: Metadata manager.
  • MOV, mov.c: Move and convert.
  • NOFORM, noform.c: Stub for places where pyxis isn't.
  • NOUNIX, nounix.c: Emulation routines.
  • PARSE, parse.c: Parse.
  • PICSTR, picstr.c: Picture String handling - user controlled output formats.
  • PROC, proc.e, proc.c: QLI procedure handling - a QLI procedure is more like a macro that doesn't take arguments.
  • REPORT, report.c: Report writer.
  • SHOW, show.e, show.c: Show version, show database, show all, show ...

back to top of page

/REMOTE

The remote interface to access databases on a remote system. This includes all the platform/transport specific code. For each, there is a server side and a client side.

  • ALLR, allr.c: Allocate.
  • AMBX, ambx.c: Apollo mailbox protocol, client side.
  • AMBX_SERVER, ambx_server.c: Apollo mailbox protocol, server side.
  • CHOP, chop.c: Function to nicely truncate a long path/filename to a specified length.
  • CHUSER, chuser.c: Chuser for VMS.
  • CNTL, cntl.c: Windows NT service control panel interface.
  • DECNET, decnet.c: DECnet interface for VMS, client side.
  • DECNET_SERVER, decnet_server.c: DECnet interface for VMS, server side.
  • DIVORCE, divorce.c: Divorce process from controlling terminal. Clean up everything in preparation to become an independent process. Close all files except for those marked by the input mask.
  • DLLSHELL, dllshell.c: Windows DLL entry and exit functions.
  • DNET, dnet.c: DECnet Communications module for ULTRIX, client side.
  • DNET_SERVER, dnet_server.c: DECnet Communications module for ULTRIX, server side.
  • FAUX, faux.c: TCP/IP stub function substitution. Determine if TCP/IP is loaded. If TCP/IP is loaded, set up the FAUX calls to call directly to the appropriate functions. If TCP/IP is NOT loaded, point all calls to dummy functions and return -1 to indicate the lack of TCP/IP.
  • IBCONFIG, ibconfig.c: IB Configuration implementation for both Server Manager and Server Property sheet.
  • INET, inet.c: TCP/IP interface, client side.
  • INET_SERVER, inet_server.c: TCP/IP interface server side.
  • INTERFACE, interface.c: The code that routes the actual calls to the next server - local or another remote.
  • IPC, ipc.c: TCP/NETipc Communications module (mpe/xl, client side).
  • IPC_SERVER, ipc_server.c: TCP/NETipc Communications module (mpe/xl, client side).
  • MAPPER, mapper.c: Program run on Apollo rings to lock a database to a particular CPU.
  • MERGE, merge.c: Merge server / remote interface / Y-valve information (i.e. version, platform, etc.) into database block. Return the actual length of the packet.
  • MGR, mgr.c: Another Apollo utility - this ond establishes a protocol.
  • MSLAN, mslan.c: Microsoft LanManager communications module, client side.
  • MSLANSRV, mslansrv.c: Microsoft LanManager communications module, server side.
  • MULTIVX, multivx.c: Interface to Wollongong TCP on VMS.
  • NETWCON, netwcon.c: Control console for netware.
  • NT_SERVER, nt_server.c: Pre-superserver for windows.
  • NTOH, ntoh.c: Emulation for windows.
  • NWSERV, nwserv.c: Server for netware.
  • PARSER, parser.c: Parse BLR strings to find messages and transfer data.
  • PROPERTY, property.c: Property sheet implementation for WIN32 server.
  • PROTOCOL, protocol.c: Protocol data structure mapper - calls xdr.
  • REMOTE, remote.c: Generic client-side code.
  • SERVER, server.c: Generic server-side code.
  • SPXESR, spxesr.c: Windows SPX communications callback function.
  • SPXNET, spxnet.c: SPX Communications module.
  • SPXNET32, spxnet32.c: SPX 32 bit Windows Client Communications module.
  • SPXWIN, spxwin.c: SPX for PC Client Communications module.SPX for PC Client Communications module.
  • SVR_W32, svr_w32.c: Windows NT remote server. Probably the server side of XNET.
  • UCX, ucx.c: TCP/UCP/IP Communications module, VMS.
  • WFWNP, wfwnp.c: Windows for Workgroups Named Pipe Support module.
  • WINDOW, window.c: This function registers the main window class, creates the window and it also contains the message loop. This function is a substitute for the regular WinMain() function.
  • WINMAIN, winmain.c: Windows Main server routine for router testing (16 bit Windows).
  • WINVX, winvx.c: Interface to Wollongong TCP (VMS).
  • WNET, wnet.c: Interface to Wollongong TCP.
  • XDR, xdr.c: Translates local representation to SUN's XDR and back.
  • XNET, xnet.c: The memory based "remote" protocol for local windows connections.

back to top of page

/UTILITIES

  • ANALYSE, analyse.c: I/O trace analysis.
  • CACHE, cache.c: Run the (experimental) (abandoned) shared cache manager.
  • CMD_UTIL, cmd_util.c: Append error codes to the status vector.
  • DBA, dba.e, dba.c: Data Base Analysis aka GSTAT.
  • DROP, drop.c: Drop Lock Table and associated semaphores.
  • DROPV3, dropv3.c: Earlier version of drop.
  • GSEC, gsec.c: User manager.
  • GUARD, guard.c: Old verson of guardian.
  • IBMGR, ibmgr.c: V5 InterBase® server manager main routine and parser.
  • INSTALL_REG, install_reg.c: Registry installation program.
  • INSTALL_SVC, install_svc.c: Service control panel installation program (obsolete).
  • PPG, ppg.c: Database page printer (reasonably up to date).
  • PRINT_POOL, print_pool.c: This utility uses the InterBase® services API to inform the server to print out the memory pool information into a specified file. This utilitiy is for WIN_NT only, In case of UNIX the IBMGR utility should be used.
  • REBUILD, rebuild.c: Prototype database recovery utility.
  • REGISTRY, registry.c: Windows NT registry installation program.
  • RELAY, relay.c: UNIX signal relay program - for systems that did not allow signalling across process groups, this ran privileged and relayed signals.
  • RMET, rmet.e: Prototype database recovery utility - metadata.
  • RSTORE, rstore.e: Prototype database recovery utility - stores page type information.
  • RUN_SERVICE, run_service.c: Run a utility as an InterBase® service.
  • SBC_PRINT, sbc_print.c: Shared Cache printer.
  • SECURITY, security.e, security.c: Process a command line for the security data base manager. This is used to add and delete users from the user information database (ISC.GDB). It also displays information about current users and allows modification of current users' parameters. Returns 0 on success, otherwise returns a GSEC message number and the status vector containing the error info.
  • SERVICES, services.c: Functions which update the Windows service manager for InterBase®.
  • SRVMGR, srvmgr.c: InterBase® server manager server manager's routines.
  • UTIL, util.c: Utility routines for IBGUARD and IBSERVER.

back to top of page

/WAL

Write Ahead Log, second failed attempt (after journaling).

  • DRIVER, driver.c: Driver for WAL routines.
  • WAL, wal.c: Write Ahead Log subsystem interface.
  • WAL_PRNT, wal_prnt.c: Main routine for printing WAL segment status.
  • WALC, walc.c: Write Ahead Log co-ordinator.
  • WALF, walf.c: Write Ahead Log File utilities.
  • WALR, walr.c: Write Ahead Log Reader.
  • WALW, walw.c: Write Ahead Log Writer.
  • WSTATUS, wstatus.c: Displays shared Write Ahead Log information.

back to top of page

Other useful definitions

  • BID: Blob identification block. Block used internally and in UDF's to handle blob stuff.
  • BUG: Little ugly critter that we aim for killing on sight.
  • CSI: Central Server Interface. Interface to the deprecated earlier server for remote clients.
  • DBA: Usually the name for the DataBase Administrator, but here tends to mean DB analysis.
  • DPG: Data page.
  • ESQL: Embedded SQL, the language variant accepted by GPRE.
  • GSTAT: (Genome?) Program that generates statistics about the database.
  • NOD: Node block - the basic element of everything.
  • PSI: Pipe server interface.
  • PIP: Space management page.
  • PPG: Pointer Page.
  • TIP: Transaction inventory page.
  • VAX: A DEC computer, but here really means LITTLE_ENDIAN.

This paper was written by Ann Harrison and Paul Beach in October 2001, and is copyright Ann Harrison, Paul Beach and IBPhoenix Inc. You may republish it verbatim, including this notation. You may update, correct, or expand the material, provided that you include a notation that the original work was produced by Ann Harrison, Paul Beach and IBPhoenix Inc.

See also:
Conceptual architecture for InterBase®/Firebird
High-level description of the InterBase® 6.0 source code
Multi-generational architecture (MGA) and record versioning

back to top of page
<< High-level description of the InterBase 6.0 source code | Database technology articles | Character sets and Unicode in Firebird >>