File Formats
Director movie, cast, and projector file formats - .dir, .dxr, .dcr, .cst, .cxt, .cct - and what is inside them.
Format family
Director content ships in three parallel families: movies, casts, and packaged runtimes. Each family has an editable form, a protected form, and a compressed (Shockwave) form.
| Extension | Family | Form | Scripts inside |
|---|---|---|---|
.dir | Movie | Editable source | Source + compiled bytecode |
.dxr | Movie | Protected | Bytecode only (source stripped) |
.dcr | Movie | Shockwave compressed | Bytecode only, assets compressed |
.cst | Cast | Editable external cast | Source + bytecode |
.cxt | Cast | Protected external cast | Bytecode only |
.cct | Cast | Shockwave compressed cast | Bytecode only, compressed |
.exe | Projector | Player + embedded movie(s) | Depends on embedded movie form |
.w32 / .a5r etc. | Xtra-related / legacy | Various | - |
.x32 | Xtra (Windows) | Native plugin DLL | Native code |
.x16 | Xtra (16-bit Windows) | Legacy native plugin | Native code |
Container structure (RIFX)
Director files are RIFF-style containers with a big-endian variant signature RIFX (or little-endian XFIR on Windows-authored files). Inside, four-character-code chunks describe the movie:
| Chunk | Contents |
|---|---|
imap | Initial map: points at the current mmap. |
mmap | Memory map: table of every chunk, its offset and size. |
KEY* | Key table: associates child chunks (media data) with owner cast members. |
CAS* | Cast member ID table for a cast library. |
CASt | One cast member's metadata (type, name, registration, flags). |
VWSC | Score data: frames, channels, sprite spans. |
VWLB | Frame labels (markers). |
VWFI | File info. |
Lscr | Compiled Lingo script (bytecode) for one script. |
Lnam | Lingo name table (handler and symbol names) for a script context. |
Lctx / LctX | Script context: maps scripts to the name table. |
BITD | Bitmap pixel data (optionally RLE-compressed). |
CLUT | Color lookup table (palette). |
STXT | Styled text data. |
XMED | Extended media (Director 7+ text members, other media). |
snd | Sound data. |
THUM | Thumbnail. |
Fver, Fcdr, ABMP | Shockwave (afterburner) versioning and compressed chunk map. |
Shockwave files (.dcr, .cct) are "afterburned": the chunk map is replaced by a compressed ABMP table and most chunk payloads are zlib-compressed. Community tooling reconstructs a normal RIFX view from that.
Community projects that parse these structures include ScummVM's Director engine, the dirplayer runtime, Shockky, ProjectorRays, and the various "offset registry" writeups from the Director preservation scene. When in doubt, cross-check a parser against more than one of these; several chunk fields changed meaning across Director versions.
Lingo bytecode
Protected and Shockwave files carry compiled Lingo only. Key facts for tooling authors:
- Each
Lscrchunk is one script: a header, handler table, literal table, and bytecode stream per handler. - Handler and variable names live separately in the
Lnamchunk; bytecode refers to names by index. This is why decompilers can recover readable handler names even from protected files. - Opcodes are one byte, with one-, two-, or four-byte operand forms for larger arguments (the same width-promotion idea appears inside the native descriptor executor documented in Native Lingo internals).
- The stack machine matches Lingo semantics directly: push literal, push symbol, call handler by name index, get/set property via descriptor, chunk operations, and so on.
- Decompilation to readable Lingo is well understood; multiple community decompilers produce faithful source for D4 through MX 2004 era files.
Projectors
A projector is the player runtime with one or more movies appended. Windows-era projectors consist of:
- a small launcher executable,
- the runtime DLLs (
Dirapi.dll,Iml32.dll,Proj.dll, plus Xtras in anXtrasfolder, or all of these embedded for single-file projectors), - the movie data appended or external.
Projector behavior flags (fullscreen, resizable stage, center stage, title bar) are stored as resource strings inside Proj.dll and parsed at startup. The recovered flag list and their bit values are documented in Native stage and presentation.
Casts: internal vs external
A movie always has at least one internal cast. External casts (.cst/.cxt/.cct) can be linked at authoring time or loaded at runtime, and are the standard mechanism for:
- sharing UI assets between movies (Habbo used dozens of
.cctfiles), - streaming updates without re-shipping the movie,
- splitting large media from logic.
At runtime a cast library is addressed as castLib n or castLib "name", and members as member "name" of castLib "ui". Member lookup rules are covered in Cast members.
Practical identification
First 4 bytes:
52 49 46 58 "RIFX" big-endian Director file (Mac-authored)
58 46 49 52 "XFIR" little-endian Director file (Windows-authored)
Next 4 bytes (codec):
"MV93" / "39VM" movie (.dir/.dxr)
"MC95" / "59CM" cast (.cst/.cxt)
"FGDM" / "MDGF" afterburned movie (.dcr)
"FGDC" / "CDGF" afterburned cast (.cct)If a file claims to be .cct but starts with XFIR+MC95, it is really an uncompressed protected cast that was merely renamed; parsers should trust signatures, not extensions.