Updated: Thu May 28 1998 - MudOSa4DGD-1.1 | DriverLib for DGD-1.1xx
======================================================================
This document will try to explain the internals of this DriverLib
package. It is created in the hope understanding of its internals,
might help programmers make better use of it. It is not nescessary
to know all of this, but it helps.


--- STRUCTURE ---

Structure of directories: (all under ../mudlib/)
/dgd/                 - base directory for all /dgd/-files.
/dgd/doc/             - some basic DGD documentation.
/dgd/lib/             - core directory for the DriverLib.
/dgd/log/             - contains output for the DriverLib logs.
/dgd/sfun/            - some examples of mudlib-related funs.
/dgd/src/             - contains hacks to further simulate MudOS
                        by altering DGD drivercode directly.
/dgd/lib/include/     - include-directory for DriverLib objects.
/dgd/lib/include/dgd/ - include files created by the driver.
/dgd/lib/std/         - blueprints for user and editor objects
                        being cloned by the  objects.
/dgd/lib/sys/         - system directory holding core DriverLib
			objects.
/dgd/lib/kfun/        - files with kernel functions
/dgd/lib/efun/        - files with "external" functions

The mudlib structure under ../mudlib/* is totally configurable
and does not concern the core DriverLib objects (under /dgd/lib/).


--- CORE ---

The /dgd/- or DriverLib objects are what this package is all
about. They are separated from the rest of the mudlib by
being stored in /dgd/, and most of them communicate directly
with the DGD driver itself. Therefore all access to these
objects are very restricted. Each and one of them does a slightly
different job, so they are separated, although you could
theoretically merge them all together, and get a mess. The
objects under /dgd/lib/ is the ones being closest to the driver:

/dgd/lib/sys/
    driver.c     - responds directly to driver events, it has
                   absolutely no interface with the mudlib.
    auto.c       - this object is inherited by all objects of
                   the mudlib, it defines the basis of kfuns
                   and efuns accessible to all objects.
    global.c     - this object holds all global data, and gives
                   services to the other DriverLib objects
                   through functions.
/dgd/lib/std/
    editor.c     - controls an editor for each user object
    user.c       - this object is the bridge between the telnet
		   connection of a user and the interactive
                   mudlib object, e.g. a player object.

_All_ interaction with these objects should be through functions
defined in the auto object, which can be called locally by all
objects. All files under /dgd/lib/ should if possible, remain
unaltered. This is to ensure compability and avoid confusion and
havoc, by having thousands (in my dreams!) of versions of the
core out on the net.

Kfuns and efuns are stored in /dgd/lib/kfun/ and /dgd/lib/efun/
respectively, and then included in the auto object.

Under the /dgd/lib/include/ directory you will find the include
files used by the DriverLib. They can not be voluntarily
inherited by the mudlib.

/dgd/lib/include/
    ansi.h       - some ANSI code defintions
    auto.h       - automatically included in all objects
    dgd_dirs.h   - directories for DriverLib objects
    driver.h     - include file for DriverLib objects
    get_dir.h    - defines return indexes by get_dir() kfun
    math.h       - some math constants for you not faint of heart
    mudos.h      - quick implementations of some MudOS features
    objects.h    - defines paths to the different DGD objects


--- BRIDGE ---

Next we have the bridge-objects between the DriverLib objects
and the current mudlib. Only master() should be called from the
mudlib, since simul_efun.c is just included in the auto object.
They lie directly under /dgd/ and should be modified to suit
the current mudlib:

/dgd/
    master.c     - serves as the object doing all mudlib-related
                   decisions about security, logging, validation
	           of different things etc etc, it is accessible
                   to mudlib objects through the master() function 
                   (a macro really).
    simul_efun.c - defines mudlib-relevant functions called sfuns,
                   inherited by all object by being included in
                   the auto object.
    preloads     - file read by master to perform preloading of
                   mudlib objects (if wanted).

All sfuns should be stored separately under /dgd/sfun/, and will
be included (if wanted) in simul_efun.c. Calling previous_object()
in sfuns will return the previous object and not this_object() to
an object doing a local call to simul_efun. This is unlike MudOS,
and is so because it would undermine the whole purpose of DGD to
emulate MudOS on this, instead of inheritance.


Also directly under /dgd/, we have some include files:
    config.h     - configurationfile for your desired DriverLib
		   setup. Here you can change many DGD and MudOS-
                   related values and switches to obtain the
                   behaviour you want, and optimize for
                   efficiency, both in memory and cpu overhead.
    userdefined.h- mudlib specifics included by all objects.
                   Usually empty, but special things that are
                   wanted can be added here.


--- NOTICE ---

I have mostly only looked at the man-pages in MudOS when coding
this. And I have spent no effort to create an "absolute MudOS"
environment. With all its bugs and flaws. Wherever I could, I
have improved the way things were dealt with. However I have
not yet tested all the functions I have made, so bugs is very
likely to occur some odd places. Much effort has been put in
avoiding too many defined functions, and certainly local
variables (almost none). Macros for short MudOS functions have
been used alot. Additionally much of the MudOS features can be
turned off if wanted (inventory, actions etc, etc), in the
config.h file.


Thanks for your time, please send comments and suggestions to me.
Any response will make me feel creating this worthwhile.


Frank Schmidt (Simone@VikingMUD)
EMAIL: franks@idb.hist.no