Category : Alternate Operating Systems - Quarterdeck DesqView, CP/M, etc
Archive   : QTEC9306.ZIP
Filename : PROTMAN.TEC

 
Output of file : PROTMAN.TEC contained in archive : QTEC9306.ZIP
ID:PM QEMM-386: Loading PROTMAN
Quarterdeck Technical Note #183 Filename: PROTMAN.TEC
by Quarterdeck Testing and Compatibility CompuServe: PROTMN.TEC
Last revised: 3/02/93 Category: NW

Subject: How to use PROTMAN, the Microsoft LAN Manager / NDIS protocol
manager, with Quarterdeck's QEMM-386 and OPTIMIZE.


LOADING PROTMAN WITH QEMM-386

NOTE: Users who only need to resolve problems between PROTMAN and QEMM'S
OPTIMIZE feature should skip the following and go directly to "USING OPTIMIZE
WITH PROTMAN" below.

NDIS is a network protocol that separates hardware from software. Any
network software that supports NDIS can work with any network card for which
an NDIS driver exists. In turn this allows the manufacturer of a network card
to write one NDIS driver which will then allow any network software that
supports NDIS to use their card. Microsoft's LAN Manager, 10Net, and DEC's
Pathworks are some examples of networks that support NDIS. Some network
software gives you a choice, writing specific drivers for their own cards and
accommodating other network cards through NDIS.

PROTMAN
Common to all NDIS network software is a program called PROTMAN. While
Microsoft calls this program PROTMAN.DOS, Tiara and Sitka call it 10PROT.DOS,
and DEC calls it PROTMAN.SYS. They are all the same program. You can tell
because device drivers have an internal name which they store beginning at
byte 0Ah and all of these programs have the same internal name: PROTMAN$.
PROTMAN is short for "protocol manager". It provides services to network
drivers that load after it to reconcile the protocol used by the network card
driver and network software.
PROTMAN does a curious thing: It writes some code and data into memory
at about 90K beneath the top of the region into which PROTMAN loads. Later
network drivers that use the services of PROTMAN while they load are
redirected to use the code and data in this area. Apparently PROTMAN'S
authors expected it to load into conventional memory, where 90K from the top
of conventional memory is 550K from the bottom of memory on a system with 640K
conventional memory.
When you load it high you may well load it into a region not large enough
to accommodate this stuff at 90K beneath the top of memory. For example, if
you load it into B000-B7FF, 90K beneath the top of memory is in the video
card's graphics address space. This causes the loading of subsequent network
programs that use the services of PROTMAN to fail when it points them into the
video card's memory when they try to use PROTMAN's services. If you load
PROTMAN into a region 90K large, PROTMAN will overwrite the code it loads low
with this stuff it loads into 90K beneath the top of its region.
With the advent of version 5 Microsoft's DOS began to load programs high
and users of networks that use PROTMAN would have suffered from the same
problem when they loaded PROTMAN with DEVICEHIGH. To "cure" this problem
Microsoft did not re-write PROTMAN to correct this programming mistake but
made DOS itself detect when it loaded a driver with an internal name of
PROTMAN$ and make Int 12 (the BIOS function that reports the top of memory)
report that the top of memory is at 575K (23F in hexadecimal) instead of the
real top-of-memory. You can find "PROTMAN$" embedded in IO.SYS (or IBMBIO.COM
for IBM DOS) of DOS 5 (These are one of the two hidden files that load
invisibly when you boot). When you load a device driver with LOADHI.SYS DOS
sees \LOADHI as the device name and does not change the number Int 12 reports
so PROTMAN may write the code/data it loads into 90K beneath the top-of-memory
into an inappropriate place.
Most programs use more memory to load than they need to remain resident.
Programs do not report how much memory they need to load, nor does DOS. For
LOADHI to load a program high, it must put it into a region where there is
enough memory to load the program, not just enough to accommodate its resident
size. Since neither the program itself nor DOS will report how much memory a
program needs to load, OPTIMIZE must figure it out for itself. In order to
figure out how much memory a program takes to load, OPTIMIZE, in its second
step, loads all programs in the CONFIG and AUTOEXEC with LOADHI /GS. With the
/GS parameter LOADHI writes "LOADHISIGNATURE!" all over conventional memory
(beginning on top of the currently available address) BEFORE it loads the
program it loads. Then after LOADHI has loaded its program it searches beyond
the resident portion of the just-loaded program to find where LOADHISIGNATURE!
begins again. The reasoning is that the program LOADHI just loaded must have
written over all the absent "LOADHISIGNATURE!"s beyond the memory it took to
stay resident, and thus needs that much more space to load.
DOS has no means of allocating memory from the top down. Thus PROTMAN
has no means of reserving the address space into which it has loaded its
code/data at 90K beneath the top-of-memory: they are orphan bytes at the
mercy of any program that has a legitimate use for this portion of the address
space. The first LOADHI/GS after PROTMAN loads wipes out this code/data when
it writes "LOADHISIGNATURE!" all over it. When a subsequent network program
that uses the services of PROTMAN loads this code/data is not in place and the
loading of the network program fails.
You can duplicate this problem without QEMM-386 or OPTIMIZE by loading
PROTMAN in the CONFIG then not loading the network drivers you load in the
AUTOEXEC. Then load some large program, like Wordperfect or Lotus or Quattro,
etc., which will load itself into all of your conventional memory, over-
writing the code/data PROTMAN has loaded into 90K beneath the top of
conventional memory. Then load the remainder of your network drivers and they
will fail in the same manner.

USING OPTIMIZE WITH PROTMAN
As discussed in the PROTMAN section above you must resort to a
"trick" to use OPTIMIZE with PROTMAN. The trick is to make PROTMAN load high
into a sufficiently large region during the second step of OPTIMIZE and load
low in the third step.

1) Place the RAM parameter on QEMM386.SYS in the CONFIG.SYS file. Reboot
and make sure that the biggest High RAM region (as reported on Manifest's
First Meg/Overview screen) is at least 96K in size.
If you do not have a High RAM region at least 96K big you cannot run
OPTIMIZE with PROTMAN and you should NOT proceed to step 2. Instead you
must manually place LOADHI.SYS and LOADHI.COM on every line in the
CONFIG.SYS and AUTOEXEC.BAT file that contains a program that you want to
load high. (See the LOADHI chapter in your QEMM-386 manual for more
details.) Do not, however, place LOADHI on the PROTMAN line. Then
reboot without running OPTIMIZE. This configuration should let you
successfully load most of your programs high.

2) If you have any programs that allocate Upper Memory Blocks (UMBs)
through the Extended Memory Specification you must stop them from doing
so (by using the programs' own parameters) before proceeding further.
Such programs can interfere with OPTIMIZE's calculations under any
circumstances; with the procedure that we are about to use a program that
allocates a UMB may overwrite the code/data that PROTMAN writes into
90K below top-of-memory. Although this is a temporary precaution for
running OPTIMIZE with PROTMAN it is a good practice generally because
LOADHI can load a program into a specific region, allowing OPTIMIZE to
configure the programs loaded into High RAM in the most efficient manner.
If you desire you can revert to letting programs load themselves high
after the completion of OPTIMIZE.

3) If your biggest High RAM region is 96K or larger start OPTIMIZE. Let
OPTIMIZE modify your CONFIG.SYS and AUTOEXEC.BAT files in preparation for
the Detection Phase. When you see the OPTIMIZE screen titled "DETECTION
PHASE," (before the first re-boot) hit Esc, then F1, to break out of
OPTIMIZE.

4) Use an editor to edit the PROTMAN line in the CONFIG.SYS file. Remove
all the parameters to LOADHI.SYS on that line. (There should be two: a
/GS parameter that directs the /GETSIZE data to LOADHI.OPT, and a LABEL
parameter.) Leave LOADHI.SYS and all PROTMAN's parameters on the line;
leave all the other lines alone.

For example if the PROTMAN line in the CONFIG.SYS says:

DEVICE=C:\QEMM\LOADHI.SYS /GS:C:\QEMM\LOADHI.OPT /LABEL:AB
...C:\LANMAN\PROTMAN.DOS /I:C:\LANMAN\PROTOCOL.INI

(the above is all one line in the CONFIG.SYS) then change the line to:

DEVICE=C:\QEMM\LOADHI.SYS C:\LANMAN\PROTMAN.DOS /I:C:\LANMAN\PROTOCOL.INI

5) Reboot and let OPTIMIZE complete normally.

When you're all done, PROTMAN will be loaded low, but it only uses
100 bytes or so (the newer PROTMAN may use about 6K). All other programs
will be OPTIMIZEd.

************************************************************************
* Trademarks are property of their respective owners. *
*This technical note may be copied and distributed freely as long as it*
*is distributed in its entirety and it is not distributed for profit. *
* Copyright (C) 1992-3 by Quarterdeck Office Systems *
************************ E N D O F F I L E *************************


  3 Responses to “Category : Alternate Operating Systems - Quarterdeck DesqView, CP/M, etc
Archive   : QTEC9306.ZIP
Filename : PROTMAN.TEC

  1. Very nice! Thank you for this wonderful archive. I wonder why I found it only now. Long live the BBS file archives!

  2. This is so awesome! 😀 I’d be cool if you could download an entire archive of this at once, though.

  3. But one thing that puzzles me is the “mtswslnkmcjklsdlsbdmMICROSOFT” string. There is an article about it here. It is definitely worth a read: http://www.os2museum.com/wp/mtswslnk/