Please report all bugs, errors, or things you'd like to have changed
directly to Steffen.Kaiser@fh-rhein-sieg.de

The following conditions I'm interested in particular:
+ A linker could not found some publics, but does, when the library
  is created with another librarian. 
  Check out the list file if the symbol is listed there. If not,
  send me the OBJ file. Otherwise, send me the list file.
+ LLIB caused some strange behaviour because of its different command
  line syntax. Tell me why.

The debug files (dbug.*) are Public Domain (see their headers). I alterred
the db_print function to use the "..." syntax and replaced DB_VOID_RETURN
by DB_EXIT and use NDEBUG to determine whether or not to activate the
debug macros. Note: If NDEBUG is not set, the debug macros become active
and the error report goes into the file LIB.ERR. LLIB logs all calls to
malloc(), free(), realloc(),& strdup(); the by-packed perl script TST_MEM.PL
checks the error report for invalid calls. It assumes that the line prefix
consists only of file name, line number, and nesting level.

Information:
In order to compiler LLIB you'll need the message library and the
	supplemental library (either prepared or in source text).
	The first one is available as: MSGLIB2.ZIP
	The second one as: SUPPL22.ZIP

To use the Makefile you'll need the additional STARTUP.MK, FD_INIT.MK,
	FD_EXIT.MK and the DMAKE patchlevel 2 (modified by myself).
	These files should be available in the package: DMAK-SK2.ZIP

The far memory support is hand-made. I choosed this way because the
	destination compilers are Micro-C and Borland C++, but Micro-C
	does not know about the Compact memory model.
	Because of this, the far data memory models of other compilers won't
	(I think) coexist with my implementation. More information about that
	is available in the source file LIST.C.

	The UMBs are not chained into the available memory, because I suppose
	that there is not much memory free.

	With the far memory support approx. 17,000 items (files in the
	current directory and multiply defined symbols) can be handled,
	assuming that 500,000 bytes are free.

The module names are also placed in the library directory, with an 
	appended '!'. This is the behaviour of Borland's TLIB, which is
	my only comparative.
	With v4.52 this has been changed; the module names are stored
	in a name definition record now. LLIB has been fixed to handle
	both cases.

While generating the library directory, an informative "Failed.
	Recreating ..." might be displayed. This is simply the information,
	that the amount of library directory pages had to be increased.

If the '/M' option is NOT given, the module is named after the file
	it is stored in (upper-cased name without extension, path,& drive).
	Already stored modules are named according the OBJ record.

	This is because the original contents varys between the origin
	of the OBJ module, e.g. Borland C++ places the source file name
	incl. extension there, Arrowsoft assembler always stores "A" there.

	That also causes the difference in size when adding & subtracting
	the same OBJ module.

	If a module name contains a '\0' character, all characters behind
	that character become invalid (random, or stripped) unless the '/M'
	option is given.
	
The detection of the optimal page size is a straight forward method by
	counting how many pages are necessary to create the library with the
	particular page size. Because the optimal page size cannot exceed
	the maximal page size, the brute force method (/i=0, or /i=65535)
	will check the range from the minimal to the maximal page.

	Otherwise, the range is # (/i=#) wide and starts with the minimal
	page size.

	Don't expect to see too many differences when the library directory
	alignment is not disabled (/X option).

Borland sucks. First they surprised my LLIB with the bad Check Sums, then
	you enable stack checking, but you will never actually be noticed that
	the heap and the stack collides, neither by the run-time code for
	stack checking nor by malloc() == 0 nor by checkheap(), then the debugger
	sometimes places a (word)0 into the code segments (each time the
	debugger shall execute an instruction).

	This behaviour caused me to waste much time before I started to
	implement the far memory storage for the module name list, thus,
	separating the heap, the stack, and the space consuming the name list,
	hoping that a memory underrun is more easily detected than by random
	crashes; and to add the debug macro package.