Hello Henry,
> One of the steps of the
> howto says to edit autoexec.bat changing the line "REM LH PCNTPK
> INT=0x60" to "LH PCNTPK INT=0x60". This didn't work for me. Somehow the
> packet driver was never actually loaded on startup. What did work is
> changing the line to "PCNTPK INT=0x60" without the LH. I'm not much on
> batch scripting so I'm not totally sure what "LH" does, but some
> googling reveals that it means Load Highmem. Can anybody give me an
> explanation?
LH, "Load High", is a command to load a process into the Upper Memory
Area, UMA for short, if it is available. I'll quickly explain the involved
concepts and what LH does in the next four paragraphs, but it isn't
crucial to know all of that, so you may skip these if you want to.
---
The Lower Memory Area, LMA for short, is the first 640 KiB of memory
usually thought of as DOS's normal memory. This is not because of
restrictions that always were inherent to the 8086 architecture or DOS's
memory allocation, but because IBM when designing their first PC (which of
course went on to make early MS-DOS popular) decided that it would be
reasonable to reserve the entire upper 384 KiB (37.5 %) of the 1 MiB
address space of the 8086 exclusively for usage by the ROM BIOS and
memory-mapped I/O. Later, it became usual to map the video card's graphics
buffer at linear address A_h, or 655360. This is precisely at the 640
KiB boundary, which means that on machines potentially using the graphics
buffer there, continuous address space for DOS memory only ranges from ca.
0_0600h to this A_h address. This is the LMA.
MS-DOS 5 and later, as well as compatible systems such as FreeDOS, have
standardised a specific interface that lets DOS manage the mentioned UMA,
which is the in principle reserved 384 KiB from linear address A_h to
just below 10_h. DOS doesn't concern itself with insuring that usable
RAM is actually mapped in there; this is the responsibility of driver
software such as, most commonly, EMM386 (of which various variants exist
from several vendors). The configuration program built into DOS will,
during the processing of (fd)config.sys, query a specific (XMS) interface
for unused UMBs (Upper Memory Blocks, ie blocks of memory in the UMA), and
allocate all of them. All such allocated UMBs are then added to DOS's
memory management.
However, by default, DOS only will let a program see the default (LMA) DOS
memory, that is, continuous memory inside the first 640 KiB. This is for
compatibility with programs that do not know of the existence of UMBs,
especially as they might expect most of the available DOS memory to be in
a single continuous block, which is not generally the case if considering
both the UMA and the LMA on systems where DOS grabbed UMBs. Hence, there
is a special way in which application programs must tell DOS to make DOS
UMBs visible if they wish to allocate them.
This is where LH comes in: by default, loading a DOS process by entering
its program's name after the COMMAND.COM (or FreeCOM) prompt will only use
the LMA, consequently placing the process itself entirely inside the LMA.
Prefixing the program's name with the LH statement will effectively first
tell DOS to make its UMBs visible (if there are any), and then load the
newly created process while preferring UMBs to LMBs (= memory blocks in
the LMA). This means that the process itself will be loaded into a UMB if
it fits. This is especially useful for TSR programs, unless the program's
installer has special code to relocate into a UMB automatically, in which
case additionally using LH would be useless. (Most older TSR programs do
not have that sort of code, so LH is necessary if you want the resident
portion to end up inside the UMA.) If there are no available DOS UMBs,
then prefixing a program invocation by the LH statement should effectively
be the same as just invoking the program without the LH statement.
---
I would speculate that in your case the problem was that apparently,
loading the PCNTPK program to install the packet driver using LH failed in
some way, while attempting the same without LH succeeded. As I have
indicated in the last sentence of the previous paragraph, this should not
occur. It is possible that your system does not offer any DOS UMBs. It is
further possible that LH as implemented by FreeCOM (FreeDOS's COMMAND.COM)
might be broken here in that situation, or that regardless of DOS UMB
availability some other unexpected circumstance occurred which lead to
this unexpected outcome.
In any case, loading the driver without LH doesn't cause any harm apart
from a possibly slightly disadvantaged memory usage layout. However, what
you have described does seem to point to an error in FreeCOM or possibly
in other FreeDOS components, so thank you for reporting this irregularity.
The FreeDOS developers might ask for your future assista
