Subj : sexyz: ZMODEM ESC8 (Escape8thBit) is advertised but implemented in nei
To   : GitLab note in main/sbbs
From : Rob Swindell
Date : Sun Aug 30 2026 17:46:34

https://gitlab.synchro.net/main/sbbs/-/issues/1229#note_10246

**One of the two reasons for closing this has since expired.** Recording it here for whoever revisits the decision; not reopening, because the defect itself — advertising a mode we implement in neither direction — is fixed and stays fixed.

This was closed on two grounds: sexyz could not decode ESC8, **and** there was nothing definite to implement, since the specification never states how a high-bit byte is escaped and the only two implementations in existence encoded it incompatibly.

The second ground no longer holds. **zmtx/zmrx 2.05, released 2026-08-30, adopted Forsberg's encoding rather than its own.** Commit `399e3b6`, "Implement normative Omen ESC8 and RLE", carries a comment naming "DSZ.EXE's ZMODEM-90 seven-bit encoder", and emits `SO` (`0x0E`) followed by the byte with bit 7 cleared — with special cases for `SO` itself, `0x80` and `0x7f` — alongside ordinary ZDLE escaping of control characters. That is exactly the encoding recovered here by known-plaintext capture from the 1997 DSZ binary.

Verified interoperating in both directions on a 16 KiB file:

| Pair | Result |
|---|---|
| `zmtx` 2.05 → `DSZ rz -E` | identical |
| `DSZ sz` → `zmrx -b` | identical |

So ESC8 now has a **de facto normative encoding with two implementations agreeing on it**, where a week ago it had two encodings and no agreement. If sexyz ever wants the mode, the target is unambiguous — which it was not when this issue was closed.

## What implementing it would take

- A decode path in the receive escape handling: `SO` prefix meaning "the following byte, with bit 7 restored", coexisting with the existing ZDLE handling. Its absence is what produced the `Illegal sequence: ZDLE 229` failures described above.
- The matching encode side in the transmit class table, so a peer's request can be honoured rather than ignored.
- Re-advertising `ZF0_ESC8` in `zmodem_send_zrinit()`, which `cf91dbd29c` (judges-20-spas, 2026-08-30) removed, and restoring the `Escape8thBit` key or an equivalent.

## Why this is still not a reason to do it

Nothing has changed about the demand side. ESC8 exists for links that cannot pass 8-bit data, and no such link has been reported against sexyz. The mode had no working peer at all for 21 years, and now has exactly one plus a 1997 DOS binary. `ESCCTL` remains the interoperable answer for control-character-hostile links and is fully supported in both directions.

The removal was right when it was made and remains right today. This note exists so that a future reader weighing "should we implement ESC8" does not re-derive an obstacle that has since been cleared, and does not conclude from the discussion above that there is nothing definite to implement.

Measurements and the full history are in `docs/zmodem_comparison.md` §7.2 and §7.4, re-measured against 2.05.

— *Authored by Claude (Claude Code), on behalf of @rswindell*
--- SBBSecho 3.37-Linux
 * Origin: Vertrauen - [vert/cvs/bbs].synchro.net (1:103/705)

.