Readme file for building user DLLs for Mathcad

Please read the appendix on how to build user DLLs in the Mathcad 
manual.  In the following readme file we discuss issues, including 
compiler specific ones which are not addressed in the manual.  
We assume here that you have installed Mathcad in the recommended 
directory C:\WINMCAD.  If this is not true please substitute the 
correct path wherever C:\WINMCAD appears.

Every time you start Mathcad it loads any user DLLs that might exist 
in the USEREFI directory under MATHCAD's home directory, e.g. 
C:\WINMCAD\USEREFI.  So please remember that once you build a 
DLL, you have to place it in the USEREFI directory before you start 
Mathcad.  Once you start Mathcad, to check if your DLL has been 
successfully loaded you can use the "Insert function ..." option under 
Math menu option to see if your user defined functions are listed.  If 
not then either the DLL was not placed in the USEREFI directory or 
there was a problem loading the functions.

You need a compiler capable of building Windows NT DLLs.  We 
have tested four compilers:

1. Microsoft compilers (WIN32 SDK, Visual C++ for NT)
2. Borland C/C++ compiler 4.0
3. Symantec C/C++ 6.0
4. Watcom C/C++ 9.5

Under the subdirectory C:\WINMCAD\USEREFI you will find four 
subdirectories named MICROSFT, BORLAND, SYMANTEC, and 
WATCOM.  In each directory there are 3 subdirectories named 
INCLUDE, LIB, and, SOURCES.   WATCOM directory does not have 
a LIB subdirectory.

To build a user DLL you need to use the include file MCADINCL.H 
and, except for Watcom, you need to link with the import library 
MCADUSER.LIB.  These two files are provided in the subdirectories 
INCLUDE and LIB, respectively, for each compiler.

The SOURCES subdirectory includes examples of source code for 
three different user DLLs.  Each example is in its own directory.  They 
are CMPLXSUM, SIMPLE, and USERPACK.  SIMPLE for Microsoft 
is the one covered in the manual.  For each example there are also 
compiler specific project or batch files included to be used to build the 
DLL.  You might have to edit these if your MATHCAD home 
directory path is not the default C:\WINMCAD.

The best approach to beginning a new user DLL for Mathcad is to start 
with one of the samples in the directory for your compiler and build it 
using the provided project files.  Then you should modify the sample 
by adding your own functions.  This involves defining the functions, 
creating error messages, registering the error messages and registering
the functions.  If your code is in C++ you must declare your functions 
as using the C language calling convention.  You can do this by using 
extern "C" before your function declarations.

If you have trouble building the sample projects then consult the 
readme file in the directory for your compiler.  If you have installed 
Mathcad in a directory other than C:\WINMCAD you may have to 
modify the project files.  The main thing is to make sure the compiler 
search path for include files includes the INCLUDE subdirectory for 
your compiler under the USEREFI subdirectory.  Also, except for 
Watcom, make sure the linker can find the import library file 
MCADUSER.LIB in the LIB subdirectory for your compiler.  If after 
reading the readme file you still have trouble building the sample 
project or a modified version of it then read the following general 
comments regarding compiler specific issues.


General comments for compiling and linking: 

1) Make sure the compiler-specific include file MCADINCL.H is in 
the compiler's include files   search path.

2) Use 4 byte or 8 byte alignment for the compiler.

3) You need to link your DLL to the DLL called MCADUSER.DLL.  
You can do this on demand  as in the WATCOM samples or by 
generating an import library and linking with it as in   the samples for 
the other three compilers.  

4) Each Mathcad user DLL needs to have a DLL initialization 
function.  This function, which  is called a DLL entry point has to be 
specified to the linker.  This is done differently  by different linkers.  
Some force you to call it a special name like DllEntryPoint or LibMain 
and some allow you to call it anything you want but you have to 
declare the   name either in a linker directive or by a pragma directive. 

5) If your DLL uses C runtime libraries you may have to arrange for 
its initialization  whenever the DLL entry point is called.  Different 
compilers do this differently.