# Native 68K makePAD ABI repair — development candidate

Target: Mac OS 8.1, native 68K. Runtime retest pending. This is not in public macMAKE v0.1.0.

- macMAKE development revision: `9cf1380695cc061f87c75cf2c03a07dcf5dae214`
- makePAD source revision: `c03f39ae7a805a838419b65db1d9de4641818733`
- Provider: GNU GCC 12.2.0 and Binutils 2.46.1, m68k-unknown-elf; no Retro68.
- Artifact: `makePAD-v0.1-macos8.1-68k-abi-repair.bin`
- Size: 18,560 bytes
- SHA-256: `57c2444dec22d87380e9780f010aa5388b4bb1f72f9631d4cc44ac428264db5d`

The preceding candidate failed document opening and window movement in the owner's test. Investigation found that macMAKE consumed unspecified padding instead of the Toolbox Boolean result, did not preserve GCC D2 across Toolbox calls, did not return the File Manager's EOF value, and registered C callbacks without a Pascal ABI bridge. Those defects are corrected in the development runtime. Screen bounds now use the desktop port rather than pixels-per-inch values. makePAD restores the drawing port after closing custom dialogs.

All six C89 sources compiled and linked. CODE 0/CODE 1, resources, APPL/MPAD metadata, and MacBinary packaging passed structural inspection. Eighteen tests execute actual assembled M68000 runtime instructions with simulated OS traps, and 194 macMAKE CLI unit tests pass. The former bridge fails the new execution check.

These host tests do not establish guest runtime behavior. Window movement, close box, File > Open, saving/reopening, Finder opening, and menu operation await owner verification. Authorized local headers were used for compilation; no SDK material or private application source is included here.

## Owner runtime result and Finder metadata follow-up

The owner confirms launch, closing, File-menu operation, Apple logo rendering, and text opening through File > Open on Mac OS 8.1 68K. Direct Finder document opening still fails. This supersedes the pending retest status above for the ABI-repair artifact.

The next candidate corrects SIZE isHighLevelEventAware (0x0080) and Finder hasBundle (0x2000). Its CODE 0 and CODE 1 are byte-identical to the owner-tested artifact. macMAKE development commit 0441901 derives hasBundle from creator-matching BNDL resources; makePAD 422bc10 explicitly enables high-level events through the supported memory configuration. All 195 CLI unit tests pass; the actual resource fork and MacBinary metadata were decoded and checked.

New candidate: `makePAD-v0.1-macos8.1-68k-finder-events.bin`, 18,560 bytes, SHA-256 `7fd3a8981d4fb9e4a20a769a0468feb1e79d62b4723469573df3c89675c9e08c`. Direct Finder document opening awaits owner retest. This remains unreleased development work.

## Finder follow-up retest and compiler correction

The owner reports the metadata-only candidate still cannot open a document directly. It extracts as makePAD.bin.1 because the embedded name incorrectly included .bin and the extractor added a collision suffix.

Disassembly proved that GCC -mshort truncated SDK four-character constants: the Apple-event class became 0x7674 instead of 0x61657674, with similar damage to event IDs and descriptor types. macMAKE development c55760a now lowers those tokens to explicit 32-bit constants after preprocessing, covering SDK headers as well as application source. The rebuilt object contains the expected full values. The embedded filename is now makePAD.

Replacement: `makePAD-v0.1-macos8.1-68k-fourcc-fix.bin`, 18,560 bytes, SHA-256 `b77387dafb3269dac2c6365622ca74517bd96f0291e5c52dd216a8611321ec18`. All 196 CLI tests and 18 CPU ABI execution checks pass; guest direct-open behavior is pending. This correction belongs to the unreleased native 68K development path.

## Mac OS 8.1 SIZE event-mask correction

The owner confirms direct document opening still fails on Mac OS 8.1. The earlier notes incorrectly identified 0x0080 as high-level-event-aware. The SDK Processes.r definition places isHighLevelEventAware at 0x0040; 0x0080 is 32-bit compatibility. The native makePAD target now requests 0x00c0, and the actual packaged resource was decoded to verify it. This corrects the earlier flag descriptions without rewriting the historical results.

Candidate `makePAD-v0.1-macos8.1-68k-hle-mask.bin`, 18,560 bytes, SHA-256 `097d8e54a505f4dd0d5a1969af2ae8a490b124986b0907bae84875dfd58842a6`. Application code is unchanged from the four-character-code candidate. Guest retest is pending. The resource inspector also gains an explicit event-awareness field to make this distinction visible.
