Analysis model: gpt-5.5 xhigh

The Third Courier Text Loader by $print - Source-Limited Technical Dissection

The Third Courier Text Loader is a 15 October 1989 MS-DOS cracktro / text loader by $print. Demozoo preserves metadata, two public screenshots, and a Defacto2 download reference. The Defacto2 file and download routes return a Cloudflare challenge from this environment, so no executable bytes are available for this pass.

Release year: 1989.

This is therefore a source-limited article. The public stills expose a compact two-screen text presentation and repeated key prompts, but the real loader and handoff code cannot be verified.

Sources

Demozoo production page: https://demozoo.org/productions/362701/
Demozoo group page for $print: https://demozoo.org/groups/112416/
Defacto2 file reference listed by Demozoo: https://defacto2.net/f/b430232
Defacto2 download reference listed by Demozoo: https://defacto2.net/d/b430232

Visual References

Time	Image	Notes
first public still		Plain text release/info page dated 10/15/89, with a short game description, support notes, install warning, and bottom key prompt.
second public still		Text title page with a centered framed game box, visible group/title text, greetings block, and bottom load/key prompt.

Generated source-boundary map:

The Third Courier Text Loader source-boundary map

Evidence Boundary

Available evidence:

Demozoo title, group, date, platform, and production-type metadata;
two public Demozoo stills;
Defacto2 identifier b430232;
visible release/info screen;
visible title/load prompt screen;
HTTP evidence that both the Defacto2 file page and download route are blocked by a Cloudflare challenge in this environment.

Missing evidence:

archive filename and hash;
executable format and size;
whether the pages are produced by direct text memory writes, BIOS calls, DOS/ANSI output, or bitmap copy;
exact key-wait implementation;
transition order and timing between the two screens;
game payload filename;
installer or machine-ID check implementation;
any verified machine-code inner loop.

The public stills prove the presentation states, not the implementation.

Public Screen Sequence

The first frame is a left-aligned release/info page. It includes:

a release/date line;
a short description of the game;
a short support list for input and display options;
an install warning for the user's machine ID;
a bottom "Press any key to continue." prompt.

The second frame is a title/load page. It contains:

a small centered framed box naming the game, publisher, and display support;
a group / release text block to the right of the box;
a greetings block in the lower half;
a bottom "To Load Third Courier .Press any key to continue." prompt.

The likely user-visible flow is:

screen 1:
    show release notes
    wait for key

screen 2:
    show title/load prompt
    wait for key

after screen 2:
    unknown loader, exit, or game handoff path

That flow is inferred from the prompts and carousel order. It is not recovered control flow.

640x400 Text-Screen Model

Both stills are 640x400 pixels. The visible glyphs are consistent with an 80-column by 25-row screen displayed with 8x16 cells:

80 columns * 8 pixels  = 640 pixels
25 rows    * 16 pixels = 400 pixels

The text is monochrome white on black, with no visible colour attributes. The second frame's box drawing and prompt alignment are cell-like, and the first frame's wrapped paragraphs land on normal character columns.

That makes an 80x25 text-page model likely, but it does not prove the backend. The executable is required to distinguish:

direct B800h / B000h character-attribute writes;
BIOS cursor/string output;
DOS console output;
ANSI stream output;
a pre-rendered graphics bitmap that mimics text.

Plausible Screen Writer

A direct text-memory writer would be:

clear 80x25 page
for each line:
    choose row and column
    write character/attribute words
wait for key

The framed title box on the second screen could be produced by a small box helper:

draw horizontal top border
draw vertical side borders
draw horizontal bottom border
write centered box strings

The release-info page could be a simple array of static strings:

for each text_record in release_page:
    set cursor to text_record.row, text_record.col
    write text_record.string

These are implementation classes only. No loop has been recovered.

Install / Machine-ID Note

The first screen's install warning is technically useful. It suggests that the loader expected the user to run the game's installer or configuration program before starting the game. That could matter to the eventual handoff path:

show text loader
wait for key
start game or return to instructions

But the public still does not prove whether the loader checks any installed state itself. The warning could be only a static note.

Key Gate

Both screens show a key prompt. Plausible implementation choices include:

INT 16h AH=00h       BIOS blocking key read
INT 16h AH=01h loop  BIOS poll then consume
INT 21h AH=08h       DOS console key read

The article cannot choose among them. It can only state that key prompts are visible on both screens.

What Cannot Be Claimed

The blocked binary prevents claims about:

COM versus MZ format;
video-mode setup;
text memory segment;
BIOS versus DOS versus direct memory output;
ANSI.SYS dependency;
exact string table storage;
key-wait loop instructions;
whether the two pages are in one executable or loaded from sidecar data;
payload filename;
installer/machine-ID logic;
child process handoff;
interrupt or resident-hook behaviour.

Conservative Runtime Model

The maximum responsible runtime model is:

start
  show release/info text page
  wait or transition
  show title/load text page
  wait for key
  unknown load / exit / handoff path

The only visible inner-loop class is generic text-page emission:

for each prepared text line or cell run:
    write it to the visible page

That is not disassembly. It is the minimum model that matches the public screens.

Summary

The public evidence for The Third Courier Text Loader establishes a 15 October 1989 MS-DOS $print text loader with two 640x400 text-like screens: a release/info page and a title/load prompt page. The Defacto2 executable route is blocked, so exact screen writer, key loop, installer handling, and game handoff remain unknown. A later pass with the b430232 executable should replace this source-limited model with hashes, file layout, text backend, string storage, and verified transition / payload code.