Part 1 decoded the geometry stream. Part 2 traced the boundary between curves, faces, topology, and the original CADKEY runtime. This is the last entry in the series: the point where the research stops being only a parser and becomes something another person can run.
The deliverable is not a screenshot, a one-off export, or a Wine desktop someone has to operate by hand. It is a reproducible command-line pipeline for turning a CADKEY Gen 2 .prt file into a standard .dxf file.
The shipped path
The production path is deliberately boring:
input.prt
→ isolated Wine prefix
→ patched CADKEY 98 runtime
→ private Xvfb display
→ CADKEY native DXF exporter
→ output.dxf
→ structural validationThere is no VNC requirement. No mouse coordinate recording. No operator clicking through File → Export. The wrapper starts a private virtual display, launches CADKEY with the PRT path as an argument, waits for the host to finish loading its CDE modules, invokes the native DXF command, fills the save dialog through Win32 controls, validates the output, and shuts the process down.
The native exporter remains important. The research established that DXF.CDE is not a standalone library that accepts raw PRT bytes. It expects CADKEY’s loaded database and runtime function tables. The shipped wrapper therefore uses the original application as a controlled conversion engine while keeping the human out of the loop.
Two scripts, two responsibilities
The repository separates setup from execution.
Setup
setup.py accepts a locally obtained CADKEY runtime and:
- verifies known artifact hashes;
- copies the required executable, DLL, CDE, and graphics files into an isolated runtime directory;
- applies the existing runtime patch without modifying the source installation;
- compiles the small 32-bit Win32 export helper;
- writes a runtime manifest containing copied-file hashes and patch locations.
The proprietary CADKEY files stay outside the repository. The private GitHub project contains source code, documentation, and the patch procedure—not the vendor runtime, sample parts, credentials, or a patched binary.
Run
run.py accepts an input PRT, an output DXF, a runtime directory, and a Wine prefix:
python3 run.py \
/path/to/input.prt \
/path/to/output.dxf \
--runtime-dir /path/to/headless-runtime \
--wineprefix /path/to/wineprefixThe wrapper reports the output size, entity count, and discovered DXF entity types. It fails rather than silently claiming success when CADKEY does not appear, the export dialog cannot be controlled, or the resulting file is not structurally valid DXF.
The Win32 boundary mattered
The first automation attempts used VNC and simulated keyboard input. They were useful for proving that CADKEY could open the files, but they were fragile. Focus handling, modal registration dialogs, DPI, and the absence of a normal window manager made screen-level automation unreliable.
The stable solution was one level below the screen:
find CADKEY top-level window
→ SendMessage(WM_COMMAND, 0xD403)
→ find native Save dialog
→ find its Edit filename control
→ WM_SETTEXT
→ submit IDOK0xD403 is the shipped CADKEY command identifier for DXF export. The helper does not depend on coordinates or the visible arrangement of the desktop. That distinction is what makes the conversion usable in a batch process.
Real files, real output
The pipeline was exercised against actual CADKEY samples rather than a synthetic rectangle.
Input Output size DXF entities
───────────────────── ──────────────── ─────────────
toyclip.prt 429,427 bytes 2,187
4pinplug.prt 43,182 bytes 454The resulting files contain the same kinds of output observed through manual CADKEY exports: analytic arcs and circles, lines, polylines, blocks, inserts, layers, text, and—where the source requires them—3D faces. The exporter is transforming the loaded CADKEY database; it is not copying PRT records into an ASCII wrapper.
The native export also remains a measurement instrument. In toyclip.prt, sixteen unresolved TYPE15 records correspond in count to sixteen DXF 3DFACE entities. That is a strong candidate mapping, but the project keeps the claim provisional until all sixteen faces are matched vertex by vertex. Shipping does not turn an interesting correlation into a false certainty.
What the service delivers
For an archive conversion, the useful deliverable is more than a directory full of files:
converted DXF files
conversion manifest
per-file success/failure status
entity and byte-size summary
warnings for approximations or unsupported contentThe output can be inspected in FreeCAD, AutoCAD, or another modern tool without preserving a CADKEY workstation. The conversion report gives an engineer a place to start when a part needs review instead of pretending every legacy feature survived perfectly.
That is the difference between a demo and a recovery service.
What is not promised
The pipeline does not claim that every CADKEY feature becomes a perfect modern solid. The current native path is strongest when the goal is DXF recovery. Complex solid semantics, associative construction history, unresolved surface ownership, and some native curve families still require inspection.
The service boundary is therefore explicit:
- DXF is the deliverable format;
- the native CADKEY exporter is the exactness reference;
- raw PRT files are preserved;
- conversion warnings are retained;
- unsupported or approximated geometry is reported;
- visual output is a sanity check, not proof of byte-level meaning.
The research is finished enough to ship
The Gen 2 format is no longer an opaque file extension. The investigation established a working geometry parser, decoded shared headers and entity families, recovered COEDGE vertices, separated CADKEY database records from embedded ACIS topology, restored the original display path, and used CADKEY’s own DXF exporter as an executable oracle.
The final result is intentionally less ambitious than rebuilding CADKEY. It is more useful:
old PRT archive
→ repeatable command
→ inspectable DXF archiveThe private implementation is available at longjoel/prt-to-dxf on GitHub. The public research record remains available in Part 1, Part 2, Part 4: The Presentation Boundary, and the maintained format specification.
If a company has a drawer full of CADKEY files and no dependable way to open them, that is now a conversion problem—not a reason to lose the geometry.