This README file is an explanation of the files contained in the root
directory of this diskette and their usage. More information can be obtained
about most of these files in the "NetWare Workstation for DOS" manual.
---------------------------------
AUTOEXEC.BAT:
This is an example of a file that will load your driver and the
other files necessary to bring up your workstation. It should be
on your workstation boot diskette or hard disk along with the LAN
driver for your adapter, NETX, and any other files you wish to load
when booting. This AUTOEXEC file should work fine for most
situations, but you can modify it as necessary.
!NVL1501.CFG:
This is a configuration file for the LAN adapter, and is to be used with
EISA machines only. It should be available when running the configuration
utility for your machine. The configuration utility uses configuration
files to resolve conflicts in assignment of system resources such as
interrupt levels and DMA channels.
You should run the configuration utility after installing your LAN
adapter(s) to avoid hardware conflicts with other adapters or
components in your EISA machine. See the user manuals for your
machine for instructions on how to use this file in running the
configuration utility supplied with the machine.
NETX.EXE:
The NetWare shell, NETX, is a TSR that is loaded after the driver
and protocol stack, and enables you to login to the network file
server. It functionally lies on top of the workstation operating
system, and between the application layer and DOS. It handles
requests made by the application, and determines whether to pass
them to DOS or the NetWare operating system to be serviced.
EMSNETX.EXE:
This file is the NetWare Expanded Memory shell. It can be loaded in place of
the NETX shell after the LAN driver and an EMS-compatible memory manager are
loaded.
Expanded memory refers to memory in addition to the 640KB limit of
conventional memory. An expanded memory manager swaps memory that exists
between the 640KB and the 1MB range into a window, or memory page.
This allows DOS applications to access up to 32KB of expanded memory.
The NetWare Expanded Memory shell moves most of the shell out
of conventional DOS memory and puts it in expanded memory.
This frees up 33KB of memory. The remaining 7KB of the shell must
remain in conventional memory to handle interrupts and some
data.
The NetWare Expanded Memory shell was written to the specifications
of LIM/EMS (Lotus/Intel/Microsoft Expanded Memory Specification)
v4.0 memory manager.
Expanded memory manufacturers provide Expanded Memory Specification
(EMS)-compatible driver programs. You must load an EMS-compatible
driver before loading the NetWare Expanded Memory shell.
To install the NetWare Expanded Memory shell, you need to
* Load a third-party EMS-compatible driver;
* Copy the NetWare Expanded Memory shell file, EMSNETX.EXE,
to the workstation boot diskette;
* Include the filename EMSNETX.EXE in the AUTOEXEC.BAT file
Because the Expanded Memory Shell operates in expanded memory,
larger applications can run in the conventional memory space.
This approach is faster than disk swapping and overlays.The NetWare
Expanded Memory shell works with NetWare v2.1 and above.
All the shell configuration (NET.CFG) parameters work with the
NetWare Expanded Memory shell. EMSNETX.EXE can only be used with DOS
3.0 and above. The expanded memory shell is not designed to work on
a machine running non-dedicated NetWare.
XMSNETX.EXE:
This file is the NetWare Extended Memory shell. It can be loaded in place of
the NETX shell after the LAN driver and an XMS-compatible memory manager are
loaded. Extended memory refers to memory above the 1MB range. Up to 15MB of
extended memory is addressable.
The NetWare Extended Memory shell moves most of the shell out of
conventional DOS memory and puts it in extended memory. This frees
up 34KB of conventional memory. 640KB of the extended memory shell
must remain in conventional memory to handle interrupts and some data.
The extended memory shell requires the support of an XMS (Extended Memory
Specification) v2.0 memory manager (or compatible), such as Microsoft's
HIMEM.SYS. The memory manager makes the first 64KB (beginning at the 1MB
address) of extended memory directly available to DOS-based applications.
To install the NetWare Extended Memory shell, you need to
* Install a third-party extended memory manager;
* Copy the NetWare Extended Memory shell file, XMSNETX.EXE, to the
workstation boot disk;
* Include the filename XMSNETX.EXE in the AUTOEXEC.BAT file
Because the Extended Memory shell operates in extended memory, larger
applications can run in the conventional memory space. This approach is
faster than disk swapping and overlays. The NetWare Extended Memory shell
works with all versions of NetWare v2.1x and above.
All the shell configuration (NET.CFG) parameters work with the NetWare Extended
Memory shell. XMSNETX.EXE can be used only with DOS 3.0 and above. The current
VDISK.SYS from IBM is not compatible with HIMEM.SYS, so do not use the extended
memory shell with VDISK.SYS. Do not use the extended memory shell on a machine
running non-dedicated NetWare.
This shell requires a high degree of IBM compatibility. Depending on the brand
of IBM compatible you are using, you may experience keyboard sluggishness or
other hardware problems.
RPLFIX.COM:
RPLFIX.COM is used to allow workstations to remote program load (RPL) properly
with DOS 5.x and above. It must be run after the boot image file (usually
NET$DOS.SYS) has been created. RPLFIX will modify the boot image file once. The
utility detects attempts to run RPLFIX against an already modified boot image
file, and will make no further modifications.
The remote workstation may hang during the reset process if you are using
DOS 5.x or above and the boot image file has not been modified by RPLFIX.
After you have located RPLFIX.COM, map a drive to the LOGIN subdirectory on the
file server you wish to remote reset from. The DOSGEN procedure instructed you
to create a boot image file in that subdirectory (usually named NET$DOS.SYS).
If the drive you mapped to SYS:LOGIN was drive F, then you would enter the
following:
RPLFIX F:NET$DOS.SYS <ENTER>
RPLFIX needs to be run if the version of DOS loaded on the floppy disk used
with DOSGEN is 5.x or greater. Earlier versions of DOS do not require that
this utility be run.
NOTE: If you renamed your boot image file, then you must use
the new filename with RPLFIX:
RPLFIX [d:]<boot image file> <ENTER>
[d:] is the drive letter where the image file is located
<boot image file> is the name of the file created with
the DOSGEN utility.
TBMI2.COM:
The Task-Switched Buffer Manager for IPX/SPX (TBMI2) allows IPX and SPX
programs to work in a multitasking environment (such as Microsoft Windows
3.0 or Microsoft DOS 5.0).
The multitasking environment in real and standard modes allows application task
switching (swapping). Each application runs in a separate DOS session
(DOS Prompt) in 640K of memory. Global memory--available to all--contains
drivers and TSRs such as COMMAND.COM and, if you are running NetWare, IPX.COM
and NETX.COM. Local memory, only available to the current DOS session,
contains the application and application data.
This program provides the data buffers needed to virtualize the IPX and SPX
requests made from applications running in a DOS session. Because these buffers
need to be allocated before the DOS v5.0 DOSSHELL starts, TBMI2 must be run
before starting the DOSSHELL.
Only the local memory is switched; the global memory with its drivers and TSRs
stays intact and is used with the new session. This means that separate local
memory segments exist, one for each DOS session, while only one global memory
segment exists. You do not need to use TBMI2 if:
1. The application goes through the NetWare shell (NETX) to
access IPX or SPX, or
2. You will not be switching between sessions.
You must use TBMI2 if:
1. You will be switching between sessions, and
2. The application bypasses the NetWare shell (NETX) and
accesses IPX or SPX directly.
If your application requires TBMI2 and you don't use it, the session will fail.
Note: If you aren't sure your application needs TBMI2, go ahead and
run it, it will use only a small amount of memory. After
running the application for a period of time, enter the command
TBMI2 /D, and look at the number in the Far Call Usage field.
If this number is zero, then your application is not using
TBMI2; you can run your application without TBMI2.
You must update to IPX v3.02 before you can use TBMI2.
The following are valid command line parameters:
/? or /H Display help or usage information.
/C=<filename> Load TBMI2 using this configuration file.
For example, enter "TBMI2 /C=TBMI2.CFG"
on the command line.
/D Display diagnostic information and
current allocation limits.
/I Display version information.
/U Unload TBMI2 from memory after exiting
Windows.
This program reads configuration information from a configuration file in
the current directory. One parameter is entered on each line in the
configuration file. This file's name is NET.CFG by default; a different name
can be specified using the /C= parameter on the command line.
The following are valid configuration file parameters:
INT 64 This is similar to the IPX configuration parameter; it specifies
that TBMI2 should support interrupt 64h IPX and SPX calls. This should
be set to either OFF or ON. For example, enter the line "INT 64 = ON"
in the configuration file. The default is ON for maximum compatibility.
INT 7A This is similar to the IPX configuration parameter; it specifies
that TBMI2 should support interrupt 7Ah IPX and SPX calls. This should
be set to either OFF or ON. For example, enter the line "INT 7A = ON"
in the configuration file. The default is ON for maximum compatibility.
ECB COUNT This specifies how many non-data event control blocks (ECBs) will
be allocated for use by DOS programs needing virtualization. These ECBs
apply to most AES events. If TBMI2 runs out of non-data ECBs, data ECBs
can be allocated for use. If no ECB can be allocated from TBMI2's pool
of ECBs, a failure will result with a completion code of FEh (or -2).
The minimum allowed value for this parameter is 10, the maximum is 255,
and the default is 20. For example, enter the line "ECB COUNT = 20" in
the configuration file. Each allocated ECB requires 52 bytes of memory;
the 20 ECB default will require 1040 bytes. The maximum allocation also
depends upon available memory, and the total size of all ECBs must be
less than 64K, which will normally limit the ECB count to less than 255.
Use the /D command line parameter to verify actual allocations.
DATA ECB
COUNT This specifies how many data ECBs will be allocated for use by DOS
programs needing virtualization. These ECBs apply to most IPX and SPX
send-and-receive packets. If a non-data ECB request is made when none
are available, a data ECB will be used. If no ECBs are available from
TBMI2's pool of ECBs, a failure will result with a completion code of
FEh (or -2).
The minimum allowed value for this parameter is 10, and the default is
60. The theoretical maximum is 255, but 89 is the practical limit. For
example, enter the line "DATA ECB COUNT = 60" in the configuration file.
Each allocated data ECB requires 628 bytes of memory; the 60 ECB
default will require 37680 bytes. The maximum allocation also depends
upon available memory, and the total size of all ECBs must be less than
64K, which will normally limit the data ECB count to less than 255. Use
the /D command line parameter to verify actual allocations.
TBMI2 Usage
Do the following to start TBMI2:
1. Start TBMI2 by entering the command "TBMI2" on the command line, followed by
optional command line parameters listed above.
2. Start the DOSSHELL program normally.
TBMI2 could be included in a batch file starting DOSSHELL to ensure that it is
always started before DOSSHELL and unloaded afterwards. For example, the batch
file could include the following:
TBMI2
DOSSHELL
TBMI2 /U
Troubleshooting TBMI2
If while using TBMI2 you encounter problems, you may need to troubleshoot the
TBMI2 configuration. Use the /D option with TBMI2 to display diagnostic
information and the current allocation limits.
Check the values associated with "Max Buffers Used," which tells you how many
buffers are used, and "Configured Data ECBs," which tells you how many are
available. If the number of buffers used approaches or equals the number of
buffers available, then you should increase the number of buffers available
using the ECB COUNT and DATA ECB COUNT parameters in the configuration file.
If the "Unavail buffer count" is ever more than zero, you should also increase
the number of buffers available using the ECB COUNT and DATA ECB COUNT
parameters in the configuration file.
The COMCHECK and RCONSOLE utilities are known to use too many buffers and
cannot be used with TBMI2.
Download Driver Pack
After your driver has been downloaded, follow these simple steps to install it.
Expand the archive file (if the download file is in zip or rar format).
If the expanded file has an .exe extension, double click it and follow the installation instructions.
Otherwise, open Device Manager by right-clicking the Start menu and selecting Device Manager.
Find the device and model you want to update in the device list.
Double-click on it to open the Properties dialog box.
From the Properties dialog box, select the Driver tab.
Click the Update Driver button, then follow the instructions.
Very important: You must reboot your system to ensure that any driver updates have taken effect.
For more help, visit our Driver Support section for step-by-step videos on how to install drivers for every file type.