Added public files
Roughly added all public files. Probably missed some, though.
diff --git a/doc/concepts/native b/doc/concepts/native
new file mode 100644
index 0000000..13cf008
--- /dev/null
+++ b/doc/concepts/native
@@ -0,0 +1,170 @@
+CONCEPT
+ driver modes / native driver mode
+
+DESCRIPTION
+ During the evolution of LPMud there has been a hiatus as the
+ old driver became too restricting for the demands of modern
+ muds: it did a lot of things the mudlib could do better or
+ completely different. Removing these things from the driver
+ weren't a problem, but to keep compatible with the existing
+ mudlibs (namely the well-known 2.4.5 lib), it was possible to
+ undo these changes. First by setting a runtime option, then
+ by compiling the driver either in 'compat' or in 'native' mode.
+
+ Starting with 3.2.1, the distinction between compat and native
+ mode is more and more transferred into the mudlib, with the
+ future goal of having a modeless driver.
+
+ Starting with 3.2.7, native mode no longer exists as such,
+ only 'plain' (quasi a superset of 'native' and 'compat')
+ and 'compat' mode, and since 3.2.9 the mode selection can be
+ made via commandline option.
+
+ The main mode of the driver is determined at compile time
+ by preprocessor symbols to be defined/undefined in config.h:
+
+ COMPAT_MODE: when defined, the compat mode specifics are activated
+ by default.
+
+ Additional modifications can be achieved by the specification
+ of commandline arguments (most of them have a default setting
+ entry in config.h as well):
+
+ strict-euids: when active, euid usage is enforced.
+ compat: when active, the compat mode is used.
+
+ Following is the description of the changes (de) activated by
+ these defines. A shorthand notation is used: 'compat' means
+ 'if compat mode is active' and '!compat' means 'if
+ compat mode is not active', etc.
+
+
+ Predefined Preprocessor Symbols
+ If compat, the symbols COMPAT_FLAG and __COMPAT_MODE__ are
+ defined for all LPC programs.
+ If strict-euids, the symbol __STRICT_EUIDS__ is defined
+ for all LPC programs.
+ For compatibility reasons, the symbol __EUIDS__ is defined
+ for all LPC programs all the time.
+
+
+ Preloading Of Objects
+ The driver has the possibility to preload objects before the
+ game is actually opened to the world. This is done by
+ calling master->epilog(), which has to return 0 or an array.
+ If its an array, its elements (as long as they are strings)
+ are given one by one as argument to master->preload() which
+ may now preload the objects (or do anything else).
+
+
+ Initialisation Of Objects
+ It is task of the mudlib (through the driver hooks) to call
+ the initialisation lfuns in newly created objects. The
+ following table shows the traditional calls:
+
+ mode : init call : reset call
+ --------------------------------------------
+ !compat & !native : create() : reset(1)
+ !compat & native : create() : reset()
+ compat & !native : reset(0) : reset(1)
+ compat & native : reset(0) : reset(1)
+
+ If INITIALIZATION_BY___INIT was defined, the lfun __INIT()
+ is called first on creation to initialize the objects
+ variables.
+
+
+ Movement Of Objects
+ The efun move_object() is implemented in the mudlib through
+ driver hooks and the set_environment() efun.
+ move_object() itself exists just for convenience and
+ compatibility.
+
+ In original native mode, move_object() could applied only to
+ this_object() as the object to move, and it called the lfun
+ exit() in the old environment if in compat mode. As a side
+ effect, the lfun exit() may not be target of add_action()s
+ in compat mode.
+
+ In compat mode, objects may be moved using the transfer()
+ efun. It does make assumptions about the design of the
+ mudlib, though, as it calls the lfuns query_weight(),
+ can_put_and_get(), get(), prevent_insert() and add_weight().
+
+
+ Efuns In General
+ creator(), transfer()
+ These exist only in compat mode (creator() is
+ identical with getuid()).
+
+ object_name(),function_exists()
+ In !compat mode, the returned filenames start with a
+ leading '/', in compat mode they don't.
+
+ parse_command()
+ This command exists in two versions: the old is used with
+ compat, the new with !compat. However,
+ SUPPLY_PARSE_COMMAND must be defined in config.h in both
+ cases (this efun is not very useful at all).
+
+ process_string()
+ If this_object() doesn't exist, it defaults to this_player()
+ and receives the backbone uid (returned by master->get_bb_uid())
+ as euid. If strict-euids, this uid must not be 0.
+
+ Userids and Effective Userids
+ This is probably the most important difference between the
+ modes.
+
+ LPMud always had userids (uids) attributing the objects,
+ though they were called 'creator names' in compat mode.
+ Internally, the compat mode uses the 'creator names' as
+ (e)uid.
+
+ With the introduction of native/plain mode, additionally
+ 'effective userids' (euids) were introduced to improve
+ security handling (which was only a partial success).
+ The hardcoded handling of euids and uids was quite complex
+ and too mudlib-insensitive, so most of it got moved from the
+ driver into the mudlib with 3.2.1.
+
+ In strict-euids mode, only objects with a non-zero euid may load
+ or create new objects.
+
+ --- In Detail ---
+
+ Userids of the Master
+ The masters (e)uid is determined by a call to
+ master->get_master_uid().
+ In strict-euids mode, the result has to be a string,
+ otherwise the driver won't start up at all. If the result is
+ valid it is set as the masters uid and euid.
+ In !strict-euids mode, the result may be any value: 0 or a
+ string are treated as the uid to set, a non-zero integer
+ leads to the use of the uid set in the default 'global'
+ wizlist entry, and any other value defaults to 0.
+ The euid is either set to the returned string (if any),
+ or to 0.
+ The masters uid is determined only on startup this way,
+ at runtime the uids of a reloaded master determined as
+ for every object by a call to the appropriate driver
+ hooks.
+
+ Userids of New Objects
+ To determine the (e)uids for a new object (loaded or
+ inherited, or cloned), the appropriate driver hook is
+ evaluated (H_LOAD_UIDS, H_CLONE_UIDS) and the result set
+ as (e)uid. The result may be a single value, in which case the
+ euid is set to 0, or an array ({ uid, euid }).
+ In strict-euids mode, both uid and euid must be 0 or a string,
+ any other value causes the load/clone to fail.
+ In !strict-euids mode, the uid (however returned) may also be
+ a non-zero integer to use the uid of the global
+ wizlist entry as uid. The euid is then
+ set to either 0 or the second entry of the returned
+ array if it's a string.
+
+ --- ---
+
+SEE ALSO
+ hooks(C), uids(C), move_object(E), initialisation(LPC)