The source was built with GCC 3.4.4 in a Cygwin/Mingw-32 environment. I cannot 
guarantee that it will compile with anything else. In fact, I'm pretty sure 
that it won't compile with anything else, not without serious surgery. 
Certainly the Makefile will only work with GNU make.

That said, I've made limited attempts to at least ease the pain in 
porting the code to other compilers. You can dump platform-specific 
ifdefs in lg/config.h, and most of the assembly hacks probably aren't 
needed when compiling with MSVC++.

MSVC treats aggregate return values from member functions in an incompatible 
way. The address for the return value is pushed before the class instance 
pointer. GCC and Borland BCC push the return address after the instance 
pointer. These compilers can be made to work with MSVC by making the return 
address an explicit argument to the member function. That is, a declaration 
written in MSVC as:
        object Named(const char*);
Is instead written:
        object* Named(object&, const char*);
And where MSVC can use a function like this:
        object oPlayer = pOS->Named("Player");
Must be done as:
        object oPlayer;
        pOS->Named(oPlayer, "Player");

Users of MSVC may revert the obfuscated declarations in these headers. I 
would appreciate if any code sent to me is written the compatible way.

The lg headers are complete enough to build most scripts. Certainly, 
everything that the original game scripts used has been accounted for.
Namely, all of the script services have at least been prototyped. The 
documentation I provide may not always be accurate, if existent. You are 
encouraged to double-check my conclusions and send any improvements you 
find back to me. The headers are updated when necessity and whimsy demand. 
I don't keep track of the changes I make, so be sure to check each release.

Heap data passed through interface functions should be allocated using the 
IMalloc interface provided at initialization. Many of the functions which 
return heap data expect you to free it when you are finished. If I haven't 
mentioned whether or not a pointer should be freed, then you should check 
it out yourself.

The script services are a higher-level interface to the Dark engine. Many of 
the functions provided by a script service can be achieved equally as well 
with a lower-level interface. The original justification for this -- that the 
low-level interfaces were subject to change, and would break any scripts that 
used them directly -- is long since irrelevant. There is no requirement that 
object scripts must use script services; and you need not feel obligated to 
do so. There isn't much reason not to, either. The difference in speed from 
using a low-level interface directly is insignificant. 

I've implemented a few scripts that sub-class existing scripts in gen.osm. To 
do this in GCC requires writing a bit of asm because the functions want to 
get the class instance pointer in ECX. (This is the __thiscall declaration 
that is specific to MSVC.) MSVC users could probably call these directly. 
Borland also needs to thunk it.

