How to compile MSGLIB:

1. Save the directory context, because many temporary files will be created
	during the following process
2. compile global binary message catalogue file
	e.g.: ..\..\bin\MSGCOMP2 /! /f=2 ..\..\include english yerror.h
3. compile global messge definition files for access method #1
	e.g.: ..\..\bin\MSGCOMP2 /! ..\..\include english yerror.h
4. compile all *.c --> *.obj
	e.g.: BCC +bccdos.cfg -m? -c *.c 
5. archive any *.OBJ --> ?_english.lib
	e.g.: LIB /c ?_englis.lib + .\*

Perform step 4. & 5. for all required memory models & substitute '?' by
the memory model.

Save the resulting files:
+ ?_englis.lib		-- libraries
+ msglib.id			-- mapper symbolic <-> numeric message IDs
+ english.ms2		-- binary catalogue file for the English tongue

The beta release will contain a complete "make" support via DMake v4.1.
The beta release will also have the "default messages" specified as
strings rather than the cryptic "Message #XXXX" autogenerations. I realized
that the autogenerated message strings are dumb -- they would work only, if
one completely sticks to non-argumented informative messages, e.g.:
	+ Message #0001: The specified server does not respond.
	+ Message #4ff7: Windows is going to crash.
	+ Message #1239: Cannot find specified user.
	+ Message #9999: Same as message #6666.
If the message strings cannot be found, only the number is displayed and
the user could look up within a message number description file. Well,
Novell's and other's Netware programs behave that way.

In contrast to the HP-style catgets() function, the default message will
be encoded with help of the symMsgID, e.g.:
#define msgLock(id) msg3Lock(id, E##id)

"id" is the symbolic message ID, e.g. "E_noMem", and is a number;
"E##id" would expand to, e.g. "EE_noMem", and is a string within the data
segment. The "EE_*" variant is the default, if the retrieval of "E_noMem"
failed. One could say it is a combination of access method #1 and #2.

Strictly speaking the code is already pre-implemented, but I haven't found
the ultimative place to keep all the information, incl. message files and
MSGLIB.ID, and how to manage the message files themselves, as the name of
the library must specify at least three information:
1. Memory model,
2. Language implemented,
3. Supported character set (code page).
Well, I should keep to a length of the filename of eight characters,
shouldn't I?
I'm planning to fix some kind of places, e.g. global *.MSG files into
%FDINC%\msglib and *.MS2 into %FDLIB%\msglib. Where %FDINC% expands to
the globally shared FreeDOS include directory, and %FDLIB% to the FreeDOS
LIB directory. Well, those directories are similar to Linux's
/usr/include and /usr/lib.


I'll keep the separation of global and local information and will keep the
way that global and local information are named identically. Though that
gives some management overhead, because one must keep both kind of
information in different directories and cannot simply copy all into
one directory and perform some easy-looking command lines. However,
it simplifies automatic processing.

