install.nw

mediastreamer2是开源的网络传输媒体流的库

   perl util\mkfiles.pl >MINFO
      generates a listing of source files (used by mk1mf)

   perl util\mk1mf.pl no-asm [other config opts] [netware-clib|netware-libc|netware-libc-bsdsock >netware\nlm.mak
      generates the makefile for NetWare

   gmake -f netware\nlm.mak
      build with the make tool (nmake.exe also works)

NOTE:  If you are building using the assembly option, you must also run the
various Perl scripts to generate the assembly files.  See build.bat
for an example of running the various assembly scripts.  You must use the
"no-asm" option to build without assembly.  The configure and mk1mf scripts
also have various other options.  See the scripts for more information.


The output from the build is placed in the following directories:

   CLIB Debug build:
      out_nw_clib.dbg     - static libs & test nlm(s)
      tmp_nw_clib.dbg     - temporary build files
      outinc_nw_clib      - necessary include files

   CLIB Non-debug build:
      out_nw_clib         - static libs & test nlm(s)
      tmp_nw_clib         - temporary build files
      outinc_nw_clib      - necesary include files

   LibC Debug build:
      out_nw_libc.dbg     - static libs & test nlm(s)
      tmp_nw_libc.dbg     - temporary build files
      outinc_nw_libc      - necessary include files

   LibC Non-debug build:
      out_nw_libc         - static libs & test nlm(s)
      tmp_nw_libc         - temporary build files
      outinc_nw_libc      - necesary include files


TESTING:
--------
The build process creates the OpenSSL static libs ( crypto.lib, ssl.lib,
rsaglue.lib ) and several test programs.  You should copy the test programs
to your NetWare server and run the tests.

The batch file "netware\cpy_tests.bat" will copy all the necessary files
to your server for testing.  In order to run the batch file, you need a
drive mapped to your target server.  It will create an "OpenSSL" directory
on the drive and copy the test files to it.  CAUTION: If a directory with the
name of "OpenSSL" already exists, it will be deleted.

To run cpy_tests.bat:

   netware\cpy_tests [output directory] [NetWare drive]

      output directory - "out_nw_clib.dbg", "out_nw_libc", etc.
      NetWare drive    - drive letter of mapped drive

      CLIB ex: netware\cpy_tests out_nw_clib m:
      LibC ex: netware\cpy_tests out_nw_libc m:


The Perl script, "do_tests.pl", in the "OpenSSL" directory on the server
should be used to execute the tests.  Before running the script, make sure
your SEARCH PATH includes the "OpenSSL" directory.  For example, if you
copied the files to the "sys:" volume you use the command:

   SEARCH ADD SYS:\OPENSSL


To run do_tests.pl type (at the console prompt):

   perl \openssl\do_tests.pl [options]

      options:
         -p    - pause after executing each test

The do_tests.pl script generates a log file "\openssl\test_out\tests.log"
which should be reviewed for errors.  Any errors will be denoted by the word
"ERROR" in the log.

DEVELOPING WITH THE OPENSSL SDK:
--------------------------------
Now that everything is built and tested, you are ready to use the OpenSSL
libraries in your development.

There is no real installation procedure, just copy the static libs and
headers to your build location.  The libs (crypto.lib & ssl.lib) are
located in the appropriate "out_nw_XXXX" directory 
(out_nw_clib, out_nw_libc, etc).  

The headers are located in the appropriate "outinc_nw_XXX" directory 
(outinc_nw_clib, outinc_nw_libc).  

One suggestion is to create the following directory 
structure for the OpenSSL SDK:

   \openssl
      |- bin
      |   |- openssl.nlm
      |   |- (other tests you want)
      |
      |- lib
      |   | - crypto.lib
      |   | - ssl.lib
      |
      |- include
      |   | - openssl
      |   |    | - (all the headers in "outinc_nw\openssl")


The program "openssl.nlm" can be very useful.  It has dozens of
options and you may want to keep it handy for debugging, testing, etc.

When building your apps using OpenSSL, define "NETWARE".  It is needed by
some of the OpenSSL headers.  One way to do this is with a compile option,
for example "-DNETWARE".



NOTES:
------

Resource leaks in Tests
------------------------
Some OpenSSL tests do not clean up resources and NetWare reports
the resource leaks when the tests unload.  If this really bugs you,
you can stop the messages by setting the developer option off at the console
prompt (set developer option = off).  Or better yet, fix the tests to
clean up the resources!


Multi-threaded Development
---------------------------
The NetWare version of OpenSSL is thread-safe however, multi-threaded
applications must provide the necessary locking function callbacks.  This
is described in doc\threads.doc.  The file "openssl\crypto\threads\mttest.c"
is a multi-threaded test program and demonstrates the locking functions.


What is openssl2.nlm?
---------------------
The openssl program has numerous options and can be used for many different
things.  Many of the options operate in an interactive mode requiring the
user to enter data.  Because of this, a default screen is created for the
program.  However, when running the test script it is not desirable to
have a seperate screen.  Therefore, the build also creates openssl2.nlm.
Openssl2.nlm is functionally identical but uses the console screen.
Openssl2 can be used when a non-interactive mode is desired.

NOTE:  There are may other possibilities (command line options, etc)
which could have been used to address the screen issue.  The openssl2.nlm
option was chosen because it impacted only the build not the code.


Why only static libraries?
--------------------------
Globals, globals, and more globals.  The OpenSSL code uses many global
variables that are allocated and initialized when used for the first time.

On NetWare, most applications (at least historically) run in the kernel.
When running in the kernel, there is one instance of global variables.
For regular application type NLM(s) this isn't a problem because they are
the only ones using the globals.  However, for a library NLM (an NLM which
exposes functions and has no threads of execution), the globals cause
problems.  Applications could inadvertently step on each other if they
change some globals.  Even worse, the first application that triggers a
global to be allocated and initialized has the allocated memory charged to
itself.  Now when that application unloads, NetWare will clean up all the
applicaton's memory.  The global pointer variables inside OpenSSL now
point to freed memory.  An abend waiting to happen!

To work correctly in the kernel, library NLM(s) that use globals need to
provide a set of globals (instance data) for each application.  Another
option is to require the library only be loaded in a protected address
space along with the application using it.

Modifying the OpenSSL code to provide a set of globals (instance data) for
each application isn't technically difficult, but due to the large number
globals it would require substantial code changes and it wasn't done.  Hence,
the build currently only builds static libraries which are then linked
into each application.

NOTE:  If you are building a library NLM that uses the OpenSSL static
libraries, you will still have to deal with the global variable issue.
This is because when you link in the OpenSSL code you bring in all the
globals.  One possible solution for the global pointer variables is to
register memory functions with OpenSSL which allocate memory and charge it
to your library NLM (see the function CRYPTO_set_mem_functions).  However,
be aware that now all memory allocated by OpenSSL is charged to your NLM.


CodeWarrior Tools and W2K
---------------------------
There have been problems reported with the CodeWarrior Linker
(mwldnlm.exe) in the PDK 2.1 for NetWare when running on Windows 2000.  The
problems cause the link step to fail.  The only work around is to obtain an
updated linker from Metrowerks.  It is expected Metrowerks will release
PDK 3.0 (in beta testing at this time - May, 2001) in the near future which
will fix these problems.


Makefile "vclean"
------------------
The generated makefile has a "vclean" target which cleans up the build
directories.  If you have been building successfully and suddenly
experience problems, use "vclean" (gmake -f netware\nlm.mak vclean) and retry.


"Undefined Symbol" Linker errors
--------------------------------
There have been linker errors reported when doing a CLIB build.  The problems
occur because some versions of the CLIB SDK import files inadvertently 
left out some symbols.  One symbol in particular is "_lrotl".  The missing
functions are actually delivered in the binaries, but they were left out of
the import files.  The issues should be fixed in the September 2001 release 
of the NDK.  If you experience the problems you can temporarily
work around it by manually adding the missing symbols to your version of 
"clib.imp".