Why Eliminate LOADHIGH ?

RYBS Electronics invented the original LOADHIGH program to load programs above 640K. This is the basic technology still used by all other memory managers. We hate to knock a technology we invented, but ...

LOADHIGH was acceptable when DOS was simple. Terminate and Stay Resident Applications (TSRs) such as Borland's Sidekick rarely interrupt the PC compared to network drivers, disk caches and mouse drivers. The complex, high performance requirements of DOS and Windows environments today however, are more susceptible to LOADHIGH-related interrupt problems.

The method DOS uses to load and then access programs in conventional memory is shown in Figures 1 and 2.

The DOS loader is called upon to load, execute, and again, every time an access to that program is required.

Figure # 1 Shows the steps DOS uses to load programs in conventional memory.

Figure # 2 Shows the steps DOS uses to access programs it loaded in conventional memory.

The method LOADHIGH uses to load and then access programs in upper memory is shown in figures 3 and 4. DOS passes control to LOADHIGH to move programs above 640K, and again every time DOS needs to access that program. This additional interrupt processing required by LOADHIGH can confuse DOS at a critical point, where DOS fails to correctly process the request. When this occurs, the operating system becomes unstable and eventually generates an error or crash.

Figure # 3 Shows the steps used by LOADHIGH to get TSRs above 640K.

Figure # 4 Shows the steps used by LOADHIGH to access TSRs that LOADHIGH put above 640K

The method ATLast uses to load programs into memory is shown in figures 5 and 6. ATLast binds a program information file [pif] load table, to the native DOS loader. This table provides the DOS loader with multiple pointers into both conventional and upper memory blocks, which allows DOS itself to load and access programs above 640K directly. Using the same method it uses to load and access programs in conventional memory eliminates many cross compatibility problems.

Figure # 5 Shows the steps ATLast! uses to load TSRs above 640K.

Figure #6 Shows the steps needed to access a TSR loaded by ATLast! above 640K.

Why eliminate LOADHIGH?

As shown in figures 3 and 4 above, access to any Device Driver and TSR program loaded into upper memory through the use of the LOADHIGH program loader, must process an additional two interrupts. This additional interrupt processing is multiplied by the number of accesses to any given program in upper memory.

The end result is a cascading effect in the interrupt handling process that will eventually cause the operating system to generate a non-reproducible error and crash. These errors are unnecessary and waste significant time and money.

As seen in figures 5 and 6, using the ATLast (PIF) program information file, DOS handles all upper memory loading directly, using the same method and shown in figures 1 and 2. As a result, the additional interrupt processing of LOADHIGH is eliminated.

How many time wasting problems do you have to experience before you get serious about the real costs of poor memory management. Fix the problems today with ATLast!.

"Back to the Future" aka RYBS' Home Page