This archive contains Protocol Manager files of version 2.0, developed
by 3Com and Microsoft. Protocol Manager is used to interface the NDIS
(Network Device Interface Specification) adapter drivers with appropriate
transport protocols (NetBIOS, TCP/IP, OSI, etc). This software supports
all the functionality as specified in NDIS version 2.01.

PROTOCOL.INI

The PROTOCOL.INI file stores configuration and binding information for all
the protocol and MAC modules in the system. The file uses the same general
format as the LANMAN.INI file.  It consists of a series of named sections,
where the section name is in fact the module name from a module
characteristics table. Below the bracketed module name is a set of
configuration settings for the module in name=value format.  For example:

  [MYNetBIOS]
     Drivername = NetBIOS$
     Bindings = ETHERCARD
     MaxNCBs = 16
     MaxSessions = 32
     MaxNames = 16

The rules for PROTOCOL.INI contents are:

- Bracketed module name.  Must be the name of a protocol or MAC
  module, e.g. [MYNetBIOS].  This is the name of the module as
  defined in that module's characteristics table.  The name must
  be 15 characters or less (not counting the brackets).  Mixed
  case may be used but the Protocol Manager will convert it to
  uppercase when it reads the file into memory.

- Drivername = <device driver name>.  This parameter is required
  for all device driver modules.  It defines the name of the OS/2
  or DOS device driver that the module is contained in.  Note
  that a single device driver name may be mentioned by several
  sections of the PROTOCOL.INI file, if the driver contains
  multiple logical modules.  The Drivername parameter is the
  recommended method by which a module searches for its module
  section in the PROTOCOL.INI file to get its configuration
  parameters.  This allows the module to find all relevant module
  sections based on a single name intrinisic to the module
  independent of the particular bracketed module name used in the
  PROTOCOL.INI file.  This keyword is also required for DOS
  dynamic modules like TSRs or transient application modules.
  Although there is no driver name instrinsically assigned to
  such modules it is required that a unique name be assigned to
  this keyword for such modules anyway.  In this way the same
  search mechanism used by device drivers can be used by dynamic
  DOS modules to find their relevant module sections in
  PROTOCOL.INI.

- Bindings = <module name> | <module name>,<module name>, . . .
  This parameter is optional for protocol modules.  It is not
  valid for MAC modules.  If present, it is used by the protocol
  module to determine what MAC modules it will ask to bind to.
  (In other words, changing this parameter in the PROTOCOL.INI
  file can reconfigure a protocol to bind to a different MAC.).
  The Bindings parameter may be omitted if the protocol driver
  software is preconfigured to bind to a particular MAC, or if      
  the system will only contain one MAC and one static protocol
  module.  In the latter case (only in static mode), the Protocol
  Manager by default will ask the one static protocol to bind to
  the one MAC.

- Other keywords and parameters.  Any other keyword=value
  statements are module specific.  Keyword names must be 15
  characters or less.  They may be mixed case but are converted
  to uppercase when read by the Protocol Manager.  Note that
  keyword names are unique within the scope of each <module name>
  section and can appear within the section in any order.

- Whitespace around the equals sign is not significant, nor is
  trailing white space on the line.  Except for this leading and
  trailing white space, all other characters of the value string
  are taken verbatim.

- A list of 0 or more parameters can appear to the right of the
  equals sign.  If there are no parameters the equals sign can be
  optionally omitted.  A parameter is terminated by a space, tab,
  comma, or semicolon.  No parameters are interpreted by the
  Protocol Manager.

- A parameter can either be up to a 31-bit signed numeric value
  or a string of any length.

- A numeric parameter can be expressed either in decimal or
  hexadecimal format.  All numeric parameters must start with the
  characters '0' through '9' or by a + or - followed by the '0'
  to'9' character.  A hexadecimal parameter must start with '0x'
  or '0X' and use valid hexadecimal digits.  A non-hexadecimal
  numeric parameter is treated as decimal integer.  A parameter
  not surrounded by quotes and starting with 0 to 9 or + and -
  followed by 0 to 9 will be assumed to be a numeric parameter.

- A string is a parameter which either starts with a non-numeric
  character or is surrounded with quotes ("....").  The string is
  preserved in the memory image as it appears in PROTOCOL.INI.

- A line starting with a semicolon in column 1 is a comment and
  is ignored.  Blank lines are ignored too.

- Lines may be as long as required.  Continuation lines are not
  supported.  Lines end with CR LF.

- Tabs, formfeeds, and spaces are considered to be white space.

The Protocol Manager supports an optional section with optional
keywords defined below:

  [PROTMAN]
    Drivername = PROTMAN$
    Dynamic = YES or NO
    PRIORITY = prot1, prot2, ...
    Bindstatus = YES or NO

The bracketed module name can be any valid name as long as it is
unique within this PROTOCOL.INI.  Drivername is required and must
be assigned PROTMAN$, identifying the section as belonging to the
Protocol Manager.  None of the entries are case-sensitive.

The DYNAMIC keyword is optional.  It defaults to NO if not
present.  If set to NO, the Protocol Manager operates only in the
static mode and does not support dynamic protocol drivers.  If
set to YES, the Protocol Manager operates in the dynamic mode and
supports both static and dynamic binding.

The PRIORITY keyword is optional.  If absent, then the VECTOR
uses default demultiplexing priority if multiple protocol drivers
are bound to the same MAC (see Vector Demultiplexing in Chapter
7 of the NDIS 2.01 specification document).  If present, the
parameters on the right-hand side are presumed to be a list of
protocol module names, highest priority first.  The VECTOR
prioritizes protocol drivers for demultiplexing (if necessary)
according to their order in the list, and packets are offered to the
first protocol driver listed first.  Protocol drivers not listed are
assigned default priority AFTER those listed.  It is not necessary
that a protocol driver ever bind for it to be listed here.

The BINDSTATUS keyword is optional.  If absent, then the
BindStatus command is not supported by the Protocol Manager.  If
set to YES, then BindStatus is supported by the Protocol Manager.
The default disable condition is a memory optimization feature
primarily for DOS environments.

When syntax errors are detected in processing the PROTOCOL.INI
commands, by convention, all NDIS drivers should:

     1)     Display a error message detail exact syntax problem.
     2)     Assume some non-fatal value for the parameter associated
            with the error and complete processing. 



Utilities Provided with the Protocol Manager

To save system integrators the effort to read and parse the
PROTOCOL.INI file, to register it with the Protocol Manager, to
invoke the binding and unbinding Protocol Manager primitives, and
to report various Protocol Manager error conditions, 3 utilities
are provided with the Protocol Manager in both the DOS and OS/2
environments and one utility is provided exclusively for the OS/2
environment:

1.  NETBIND.EXE - Initiates the binding and operational
                  startup of a set of modules previously loaded.
                  It issues to the Protocol Manager the
                  BindAndStart primitive and reports to the console
                  any binding/initialization errors detected by the
                  modules bound.  This utility can be used in
                  either the static or dynamic Protocol Manager
                  modes of operation.  In the static mode it should
                  be invoked after all device driver modules are
                  loaded (e.g. from AUTOEXEC.BAT in DOS or
                  STARTUP.CMD in OS/2).  In the dynamic mode it can
                  be invoked either at system startup time as in
                  static mode or after a set of dynamically
                  loadable modules have been loaded and are ready
                  to be run.  There are no command line parameters
                  associated with this utility.

2. UNBIND.EXE -    Initiates the unbinding and termination
                   sequence of a set of dynamically loadable modules
                   previously loaded and bound.  It issues to the
                   Protocol Manager the UnbindAndStop primitive and
                   reports to the console any unbinding/termination
                   errors detected by the modules being unbound.
                   The utility can be used only in the dynamic
                   Protocol Manager mode of operation.  Invocation
                   in the static mode will generate an error.  It
                   should be invoked when it is desired to terminate
                   (and release from memory) a set of dynamically
                   loadable modules that have been previously loaded
                   and bound.  In DOS each invocation will terminate
                   and unbind the last set of modules previously
                   bound via the NETBIND.EXE utility.  Modules can
                   be bound and unbound in groups if required by
                   invoking NETBIND.EXE for each group of modules to
                   be bound together and later invoking UNBIND.EXE.
                   UNBIND.EXE  will unbind the groups only in the
                   reverse order in which the groups were
                   previsoulsy bound.  If protocols are implemented
                   so that they free themsleves from memory at the
                   end of the unbind sequence, then this utility
                   will free up the memory of all such protocols
                   unbound.  This utility has no effect on MAC
                   drivers which are always static device drivers.
                   In OS/2 the utility takes an argument string
                   specifying the name of the module being unbound.
                   In DOS there are no command line parameters
                   associated with this utility.

3.  READPRO.EXE -  Reads the PROTOCOL.INI file, parses it into
                   a memory image and registers this memory image
                   with the Protocol Manager so that the image is
                   available to dynamically loadable protocols when
                   they request their configuration memory image
                   information.  By invoking the GetProtocolIniPath
                   Protocol Manager primitive, this utility assures 
                   that the PROTOCOL.INI file is read from the
                   same subdirectory as that used by the Protocol
                   Manager when it had initialized.  The memory
                   image is registered with the Protocol Manager via
                   the RegisterProtocolManagerInfo primitive.  This
                   utility can be used only in the Protocol Manager
                   dynamic mode of operation.  The utility reports
                   any detected error condtions on the console.  It
                   should be invoked prior to the loading of any
                   dynamic modules.  There are no command line
                   parameters associated with this utility.

4.  RELOAD.EXE -   Initiates the prebind initialization of
                   an OS/2 dynamically loadable module.  It issues
                   to the Protocol Manager the InitAndRegister
                   primitive containing the module name that was
                   given as a command line parameter.  The Protocol
                   Manager calls the system entry point of the named
                   module with the InitiatePrebind system function.
                   The module is required to reinitialize, which
                   may include locking down swappable segments,
                   requesting and parsing the PROTOCOL.INI image,
                   and reregistering with the Protocol Manager in
                   preparation for a subsequent NETBIND.EXE
                   invocation.  This utility reports any detected
                   error to the console.  It applies only to OS/2.

If the system integrator requires more functionality than that
provided by these utilities, the integrator can write an
application utility directly that performs the desired
functionality and invokes the required Protocol Manager
primitives described in Chapter 5 of the NDIS 2.01 specifications
document.  For example if in DOS a more flexible unbind facility to
unbind in a user specified order is required, UNBIND.EXE can be
replaced by a user written utility that invokes the UnbindAndStop primitive
in which Pointer2 points to the name of the module to be unbound.


