ActiveNet SDK - Source
Activision Confidential
Last updated: 26 July 1997
Source Tree
The source for the ActiveNet SDK sits in the src subdirectory of
the SDK itself, and references the same h directory as the SDK.
The core source code files in src/dp are used for all platforms
(DOS, Win32, Unix, Mac). Platform-specific but network-independent
source is usually kept in src/PLATFORM/dp or src/PLATFORM/main.
Network-specific source is usually kept in src/PLATFORM/NETWORK,
for example, src/DOS/IPX.
For a description of the public part of the SDK,
please go to the SDK packing list.
The private part of the SDK is the SRC directory tree, which looks like this:
- src -- Source code
- doc -- Activenet Source Documentation
- buildall.bat -- Batch file to compile the whole SDK from scratch and make ANETSDK.ZIP
- makefile -- Makefile to create anetsdk.zip once dos\build.bat and win\build.bat have been run
- test -- Regression tests run during the build process
- dp -- platform-independent source files (plus a few DOS-specific ones)
- dos -- DOS-specific source files
- mac -- Macintosh-specific source files
- win -- Win32-specific source files
- src/win/build.bat -- Batch file to compile Win32 library and DLL's
- src/win/makefile -- Only knows how to clean up uneeded files
- win/src/out -- Temporary resting place for Win32 library and DLL's. Deleted by 'make clean'. (Note: this should go away. There's no reason to have this.)
- unix -- Unix-specific source files (e.g. for use with game servers)
- demo -- Internal Demo source (mostly
obsolete demos moved here from the public demo directory)
Compiling the SDK
The batch file BUILDALL.BAT compiles the whole SDK for DOS and Win32.
It requires PCPATH.BAT to be installed in the
root of C:\ to set up environment variables for the various compilers.
Please take a minute to copy pcpath.bat to C:\ and edit it to reflect
where Watcom C++ and Visual C++ are installed on your system, as well
as how your path should normally be set. Also, if you haven't already,
expand your environment variable space by adding
shell=c:\command.com c:\ /e:2048 /p
to C:\CONFIG.SYS and rebooting.
Mostly, PCPATH.BAT is used to switch between Watcom C (for DOS)
and Visual C (for Windows). If you're not compiling the DOS version
of the SDK, all you need in PCPATH.BAT are
Rem Visual C
CALL C:\MSDEV\BIN\VCVARS32.BAT
Rem Get Watcom's WMAKE.EXE
PATH %PATH%;c:\watcom\bin
Compiling the SDK on the Mac
First, install both
Stuffit Expander
and
Expander Enhancer.
This will let you unpack .zip files.
Second, run Stuffit Expander, and use it to unpack the ANETSRC.ZIP
source archive; then use it to unpack demo/macbuild.sit and
src/mac/macbuild.sit. Codewarrior Pro projects can be found in
demo/macbuild and src/mac/macbuild. Compile src/mac/macbuild/dp v2.mac
and src/mac/IPX v2.mac first; then to test it, compile
demo/macbuild/gtest v2.mac and see if you can list sessions created by
PC copies of gtest. There are scripts to do all this-
see the Applescript files "SDK Unpack and Build" and "SDK Build"
in the src/mac/macbuild.sit archive.
Adding new network drivers
To add a new network driver, copy the source for one of the existing
drivers, e.g. dos/DWANGO, into a new folder named after the network
or service you want to add, e.g. dos/TEN, and modify it to use the
new network's API. Once it's working, you need to modify the parent
directories' build.bat and makefile to refer to the new driver.
Note on Makefiles and Visual C++
Yes, Virginia, there is a way to use Visual C++
from the commandline. In fact, it even creates makefiles (named xxxx.mak)
automatically. These can be used either inside Visual C++'s IDE,
or from the commandline with Microsoft's NMAKE.EXE (in which case
you need to set up your environment variables by running the VCVARS32.BAT
created by the Visual C++ setup).
Both Watcom and Visual C++ share at least one environment variable: INCLUDE.
That's the reason for the batch file PCPATH.BAT (see above); if %C% is set to VC,
pcpath sets up for Visual C++; otherwise it sets up for Watcom C.
It clears out the PATH, LIB, and INCLUDE environment variables, then sets
them properly for the compiler of interest.
To test whether you can compile Watcom C properly from the commandline,
create the famous HELLO.C, then run wcl386 hello.c.
If you get a good executable HELLO.EXE, you're all set.
To test whether you can compile Visual C++ properly from the commandline,
create the famous HELLO.C, then run cl hello.c.
If you get a good executable HELLO.EXE, you're all set.
Here's a simple HELLO.C you can use if you want to be sure about what
compiler was used to create it:
#include
main()
{
printf("Hello, World!\n");
#ifdef _WIN32
printf("I was compiled for Win32\n");
#endif
#ifdef _MSC_VER
printf("I was compiled by version %d.%d of Microsoft C\n", _MSC_VER / 100, _MSC_VER % 100);
/* Note: Visual C++ 4.x uses Microsoft C version 10.x */
#endif
#ifdef __WATCOMC__
printf("I was compiled by Watcom C\n");
#endif
}
Up to public packing list
Dan Kegel
dank-anet@kegel.com
All files copyright 1997 Activision