I was just reading a thread on Vogons about OnTrack and EZ-Drive setup, and it occurred to me that I have no idea how they work.
Please explain why the barrier existed and then how the overlay programs circumvented them.
The reference for this is DEW Associates’ pages on the topic.
Multiple barriers have existed in the history of hard drives on PC compatibles. The main ones are the barriers at 528 MB (504 MiB) barrier, 2.1 GB, 4.2 GB and 8.4 GB. They stem from various limitations in the interfaces used to talk to hard drives. Originally, these interfaces were based on an addressing scheme involving cylinders, heads and sectors (CHS). Early IDE supported up to 65536 cylinders, 16 heads, and 256 sectors, for up to 128 GiB; but the PC BIOS (see for example interrupt 0x13 function 2) supported 1024 cylinders, 256 heads, and 63 sectors, and the intersection of these capabilities led to a limit of 504 MiB (1024 cylinders, 16 heads, and 63 sectors). The other limits have similar causes. The ultimate limit for DOS is the 8.4 GiB barrier which corresponds to the maximum addressable size using the BIOS interrupt 0x13 functions.
Drive managers such as OnTrack or EZ-Drive work by installing a new boot block on the hard drive, and installing a new interrupt handler for 0x13 which translates between an optimal geometry (from a DOS perspective), supporting up to 8.4 GiB, and whatever geometry the underlying drive actually supports. In many cases they can eschew geometry considerations altogether by using LBA, logical block addressing: this views hard drives as linear collections of blocks, and addresses those blocks using a single index (dropping the cylinder/head/sector split). In other cases, the head index is split across the cylinder and sector index (or even the cylinder index only), so that 256 heads (as supported by the BIOS API) can be used in spite of IDE’s 16-head limit. Once a drive manager is installed, it is loaded at boot, installs its interrupt handler, and proceeds to boot the operating system on the drive.
Drive managers could do this safely by “hiding” from the operating system; see How did DOS know where to load itself in upper memory? for techniques to achieve this.