Version 1.1b, Library version "5"

Please read the README.txt and INSTALL.txt files in the same directory
with this file before continuing. More general information is available
there. This file documents the particulars of building from source on
Windows NT/2000/XP.

Visual C++ 6.0 on Windows is currently supported. The OpenSAML.dsw workspace
file is located in the root of the distribution with the DLL project and a test
EXE project. For Windows, the hard part is just downloading all the libraries
you'll need. However, my built source trees of each dependency can be downloaded
from https://shibboleth.internet2.edu/downloads/win32

All the libraries listed in the Unix install docs are needed, except for gcc,
of course. The project files assume that these libraries and headers are located
in typical places one would find them on a PC, in directories below the root
of the same drive that the OpenSAML source tree is expanded. The build settings
reference them with paths such as \openssl-0.9.7e or \curl-7.14.0

The build files assume that, when possible, include and lib paths are set in
the VC++ Directories option tab. The exception is that some of the libraries
have the same names when built in debug mode vs. release mode, so those paths
are manually set in the projects.

If you prefer to create a common Unix-style include and lib location and
manually copy your libraries and headers in, you'll need to make the appropriate
changes to the project files.

NOTE ON DEBUG/RELEASE LIBRARIES

As with most newer projects, we use the Microsoft DLL-based C/C++ runtimes.
It is important that all the component libraries and processes be built with
the same runtime switch (/MDd or /MD). You cannot mix these, or you'll get lots
of assertions or crashes, usually when freeing memory.

Often, libraries have different names (such as lib.dll vs. libD.dll), but
many projects don't, like OpenSSL. You end up with the same library name
but a different library path, so the settings must be different for the
linker on the Debug and Release sides.

You should be able to diagnose what version of something you have by using
Microsoft's "depend.exe" utility and make sure that only one of MSVCRT.dll
and MSVCRTD.dll are being pulled in by the library in question.


NOTE ON NAMING AND LINKING

For now, I've embedded the major library version (which has no connection
to the OpenSAML package version) inside the name of the DLL and import library.
This should help distinguish between versions and force people to consciously
upgrade to a newer version in their Makefiles. Versions with the same
filename always have a common ABI and should be runtime compatible.

I also embed a D on the end of the filename for the Debug build.

Your project should link to saml_<libversion>[D].lib where libversion
is listed at the top of this file and D controls debug or non-debug.

A version resource is now included in the DLL to clearly identify which
minor revision you have.