Chain Loading¶

A running executable hands primary control to a separately loadable successor stage through a platform-defined loading interface.

Version: v1 · 2026-10-03 · History
Domain-specific #: 13053
Domain group: Applied Sciences & Engineering
Origin domain: Computer Science & Software Engineering
Subdomains: Program Execution, Boot Loading → Computer Science & Software Engineering
Aliases: Chainloading

Core Idea¶

Chain loading is a staged program handoff: a currently controlling executable selects and prepares a separately loadable successor, then gives that successor primary execution through the host system's loading and control-transfer interface. In a boot sequence, GNU GRUB can load another boot loader and jump to it rather than loading an operating system directly. In HP BASIC for OpenVMS, CHAIN transfers from a running program to another executable image. Those are unlike environments, but both have a predecessor that deliberately yields execution to a successor stage rather than merely calling one of its own returning routines.^[1]^[2]

The defining relation is successor-stage control, not physical overwriting of every byte of the predecessor. What stays in memory, what state crosses the boundary, and whether a later return is possible are properties of the implementation. GNU GRUB explicitly allows return from a chain-loaded loader on some platforms such as EFI; HP BASIC's CHAIN does not return to the old program after the new image finishes. Treating either behavior as universal would exclude a documented case of the same staged handoff.^[3]^[2]

Structural Signature¶

Sig role-phrases: present controlling executable — separately loadable successor — selection and loading interface — control transfer — platform-defined handoff state — possible further chain stage.

Present controlling executable. The first stage is already running and determines the next stage. GRUB chooses a boot loader; an HP BASIC program names the next executable. If a machine simply loads its first program without a predecessor selecting a successor, this role is absent.^[1]^[2]
Separately loadable successor. The target is a distinct boot loader or executable image able to run as a stage, not merely another function in the same program. The successor need not be new to physical memory in every related transfer mechanism: IBM's XCTL, for example, loads its target module only if no usable copy is present.^[1]^[2]^[4]
Selection and loading interface. The predecessor names or identifies the target and relies on firmware, a loader, or a language runtime to prepare its execution. This interface is not interchangeable across settings; a boot protocol is not a BASIC executable-file specification.^[1]^[2]
Control transfer. The successor becomes the primary executing stage. In GRUB's documented boot case, the operation jumps to another boot loader. In HP BASIC it begins the new executable. This differs from a routine call whose normal purpose is to return a result to the still-controlling predecessor.^[1]^[2]
Platform-defined handoff state. The host determines what context, parameters, open resources, and memory remain usable. The defining requirement is an intelligible handoff contract, not one universal common-data area. HP BASIC closes open files and releases storage in its CHAIN implementation; POSIX exec, a related image-replacement operation, retains selected process attributes and file descriptors instead.^[2]^[5]
Possible further chain stage. A successor can in turn select another successor, making the pattern repeatable. A single completed handoff still instantiates the method; neither original vendor example requires a third stage to establish its identity.^[1]^[2]

What It Is Not¶

It is not a claim that a whole old program is always overwritten. GRUB's manual says it loads another boot loader and transfers control; it does not establish that all GRUB storage is overwritten, and its documented EFI return path makes such a blanket picture particularly misleading. IBM's related XCTL may find the target module already in storage and removes an issuer module only when its use count reaches zero.^[1]^[3]^[4]

It is not method chaining, where consecutive method calls use successive return values inside an expression. Nor is it any ordinary subroutine call, any overlay that swaps code while the same program retains control, or direct initial loading with no predecessor-selected successor. POSIX exec illustrates a related process-image replacement, but the POSIX specification does not call every exec use “chain loading”; similarity of mechanism is not an automatic synonym decision.^[5]

Scope of Application¶

In boot management, a boot manager can delegate to another boot loader under the boot platform's protocol. GRUB documents chain-loading for systems it does not load directly, with a jump through real mode or firmware. The successor boot loader then owns the immediate boot path. On some EFI platforms it can later return to GRUB, so “handoff” does not always mean irreversible disappearance of the first loader.^[1]^[3]

In program segmentation, an HP BASIC for OpenVMS program can issue CHAIN to start a different executable image. That runtime flushes buffered output, closes files, and releases storage before execution of the new image. This case illustrates a nonreturning handoff, not a portable rule for all chain-loading environments.^[2]

Related control-transfer facilities help set the boundary. IBM z/OS XCTL passes control to a target load module without returning to its issuer; the target may already be loaded, and parameters can be passed by registers or a parameter list. POSIX exec replaces a process image while retaining process identity and certain descriptors. Both resemble portions of the pattern, but their standards and manuals use their own names and their retention rules differ. They are comparison cases, not evidence that all program transfers are called chain loading.^[4]^[6]^[5]

Clarity¶

The word loading invites three conflations. First, loading a successor is not necessarily overwriting the entire predecessor; loader and runtime rules decide storage disposition. Second, yielding primary execution is not necessarily barring every later return; GRUB's platform note says return can occur. Third, passing context is not synonymous with a fixed shared-memory block; an interface may pass arguments, registers, environmental state, or nothing application-specific, and may close some resources while retaining others.^[3]^[2]^[6]^[5]

For a proposed case, ask which executable is currently in control, which distinct image is selected, how it is prepared, where execution goes, and which source actually specifies the state-and-return contract. Answering those questions separates the abstraction from a colloquial description such as “one program starts another.”^[1]^[2]

Manages Complexity¶

A boot path or segmented application may contain many images, firmware calls, addresses, and runtime rules. The chain-loading lens compresses them into a small stage graph: predecessor, successor, transfer interface, and state contract. This helps locate a failure at the correct boundary. A successor never started suggests selection/loading failure; a started successor with missing expected context suggests a handoff-contract mismatch; a mistaken expectation of return suggests a control-flow mismatch.^[1]^[2]^[3]

That compression must not erase implementation differences. Treating all stages as if they share one memory layout would misrepresent HP BASIC's release of storage, IBM's conditional module deletion, and POSIX's retained descriptors. The graph is a reasoning aid; the actual resource rules come from the specific loader or runtime.^[2]^[4]^[5]

Abstract Reasoning¶

The first inference is a membership test. If a running stage selects a distinct executable and yields primary execution under a defined loading interface, the case has the chain-loading structure. If the target is merely a returning routine and the old program remains the normal controller, it does not. A boot manager's handoff to another boot loader passes the test; invoking a helper to compute a filename does not.^[1]

The second inference is a contract test. After identifying the successor, do not infer which resources survive from the abstract name. Inspect the platform rule before assuming persistence or return. GRUB permits return on some EFI paths; HP BASIC's CHAIN closes files and does not return; IBM XCTL can retain an already resident target and deletes the issuer only conditionally. Thus a program dependent on retained files, parameters, or resumption must be assessed against the particular mechanism, not against a universal “replacement” slogan.^[3]^[2]^[4]

Knowledge Transfer¶

Within computing, the same role map is useful for bootloader delegation and language-runtime program chaining: a stage selects another stage, an interface prepares it, and the successor takes over execution. The role map transfers; the bytes, addresses, preserved resources, and return rules do not. This makes an analogy between two settings precise without claiming that their executable formats or operating-system contracts are interchangeable.^[1]^[2]

One might recognize a broader “successor assumes control” skeleton in organizational or workflow handoffs, but those are analogies, not literal chain loading. The live prime Authority Handoff requires a persistent authority-bearing role, briefing, acknowledgment, and broadcast to dependents; neither GRUB nor HP BASIC necessarily has those roles. A portable generalization, if later evidenced, is a future-prime question rather than a parent asserted by word resemblance.

Examples¶

Bootloader-to-bootloader transfer. GNU GRUB documents chain-loading another boot loader for an operating system it does not load directly. GRUB loads the other loader and jumps to it through the relevant real-mode or firmware pathway; on some EFI systems that loader can later return to GRUB.^[1]^[3] Mapped back: present controlling executable = GRUB; separately loadable successor = the other boot loader; selection and loading interface = GRUB's chain-loader operation and platform boot protocol; control transfer = jump to the other loader; platform-defined handoff state = whatever the particular boot protocol carries, not a universal common area; possible further chain stage = that loader may continue toward an operating-system stage, but a third transfer is not required.

Program-to-program transfer. An HP BASIC for OpenVMS program's CHAIN statement names another executable image. The runtime flushes output, closes open files, releases storage, and starts the new program; ordinary control does not return to the original when the successor finishes.^[2] Mapped back: present controlling executable = the current BASIC program; separately loadable successor = the named executable image; selection and loading interface = the CHAIN statement and runtime's executable lookup; control transfer = execution of the new image rather than a returning BASIC subroutine; platform-defined handoff state = the documented resource release and whatever the runtime contract otherwise permits, not a presumed common block; possible further chain stage = the new program could make another such handoff, although this example is complete with one.

Structural Tensions¶

Stage independence versus state continuity. Giving a distinct successor primary control lets a boot loader delegate an otherwise unsupported OS path and lets an application segment its program, but the successor cannot assume arbitrary access to the predecessor's live resources. Preserving more context can ease continuation, while coupling the stages to a more demanding interface; releasing context simplifies the boundary but requires the new stage to reconstruct what it needs. HP BASIC's file closure and POSIX exec's descriptor retention show why neither side can be inferred from the name alone.^[1]^[2]^[5] Diagnostic: Which state must the successor receive, and does the actual platform contract preserve it?

One-way yield versus resumable control. A nonreturning transfer, as documented for HP BASIC CHAIN, removes any requirement for the old program to resume, but cannot serve a workflow that expects it to continue afterward. A platform that permits return, as GRUB can on EFI, supports that possibility but requires the earlier stage to remain able to handle resumed control. These are implementation alternatives, not competing definitions of the abstraction.^[2]^[3] Diagnostic: Is return possible here, and if so which stage and resources are available when it happens?

Structural–Framed Character¶

Chain loading sits toward the structural end within a strongly computing-framed spectrum: its predecessor–successor–interface relation travels between boot management and program segmentation, while executable loading and actual transfer of machine control remain constitutive. Its five character criteria are separable. Evaluative weight: “chain loading” describes a mechanism, not inherent goodness; correctness depends on the chosen target and handoff contract. Human-practice dependence: engineers configure or write the stages, but the operational relation is machine-executable rather than constituted by human agreement. Institutional origin: specific commands and runtimes are vendor-defined, yet the common stage relation is not one institution's policy. Vocabulary travel: GRUB explicitly uses “chain-loading” and HP BASIC uses CHAIN; IBM XCTL and POSIX exec have related mechanics without proving universal name travel. Import versus recognition: the shared skeleton is recognized by comparing original vendor descriptions, not by forcing one platform's memory or return rules onto another.^[1]^[2]^[4]^[5]

Its character: a reusable, structurally legible domain-specific computing method, not a prime. Its apparent breadth is constrained by executable images, loading interfaces, and system-defined control/state semantics; recognizing a broad handoff resemblance outside computing does not make the named method substrate-independent.

Structural Core vs. Domain Accent¶

The core is the relation in which a controlling executable selects a separately loadable successor, invokes a loading interface, and yields primary execution under a specified state contract. The domain-bound mechanism is executable image or boot-stage preparation followed by machine control transfer. GRUB, EFI, HP BASIC, file closure, real mode, and particular module loaders are accents: they determine a case's precise behavior but are not individually required for every case.^[1]^[3]^[2]

Remove the hardware, executable, and runtime frame and “one stage hands off to another” becomes much broader than chain loading. That portable skeleton is an explicit future-prime question, not a currently justified typed parent. The named entry therefore does not clear the prime bar. Its proposed DAG status is unparented pending review; no edge is manufactured to Sequencing, Cascade, Bootstrapping, or Authority Handoff merely to make the graph connected.

No strict typed parent is currently proposed. Bootstrapping can describe how an initial system gains the means to operate, and Sequencing or Cascade can describe ordered stages, but chain loading does not necessarily depend on any one of their full live signatures. It is also not a subtype of Authority Handoff's human/institutional role protocol. These are comparison points, not recorded DAG edges.

GRUB's bootloader delegation does not imply that every boot process chain-loads. A runtime can transfer from one program to another without necessarily using a boot manager. The relevant relation here is between executable stages, not a claim that all staged operations are the same abstraction.^[1]^[2]

Neighborhood in Abstraction Space¶

Chain Loading sits in a sparse region of the domain-specific corpus (68^th percentile for distinctiveness): few abstractions share its structure, so a faithful description tends to retrieve it precisely.

Family — Program Execution & Runtime Concepts (27 abstractions)

Nearest neighbors

Computed from structural-signature embeddings · 2026-10-08

Not to Be Confused With¶

Method chaining: adjacent method calls in an expression, where a returned object becomes the next receiver; no successor executable assumes primary program control.
A returning subroutine: the caller ordinarily remains the controlling stage and resumes after the callee; chain loading hands primary execution to the successor.^[2]
An overlay: replacing a region of code while the same controlling program continues is not, by that fact alone, a successor-executable handoff.
POSIX exec: a related process-image replacement with specified retained process properties; calling every exec instance “chain loading” exceeds what the POSIX standard names.^[5]
IBM XCTL: a related nonreturning module-control transfer, not proof that all targets overwrite the predecessor or that IBM uses the same label.^[4]
A universal common-data area or irreversible handoff: neither is constitutive; resource and return behavior differ between HP BASIC and GRUB.^[2]^[3]