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_0000h, 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_0000h 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_0000h to just below 10_0000h. 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 assistance about this. Regards, Chris ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user