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 01:54:09

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

**Resolved by option 2 — removed.** Rob's call: given two incompatible encodings, neither specified, and 21 years without the feature working, sexyz should not be asking for it.

What changed:

- `Escape8thBit` is gone from `sexyz.ini` and from `sexyz.c`.
- `zmodem_send_zrinit()` no longer sets `ZF0_ESC8` under any condition, so the mode can no longer be requested at all.
- Both remaining mentions of the flag say why it is inert. A peer's ESC8 request is still recorded from its ZRINIT for the log and still ignored, which is what lrzsz does with the same request.
- Removed from `docs/sexyz.txt`, the wiki page, and noted in the release notes.

Verified with `Escape8thBit=true` still present in `sexyz.ini`, so the key is provably inert rather than merely undocumented:

- sexyz's ZRINIT now reads **ZF0=0x23**, ESC8 clear.
- **`zmtx` 2.04 → sexyz now transfers byte-identically.** That is the pair that previously aborted 766,470 bytes into a 4 MiB file, because zmtx honoured the request and sexyz could not decode the result.
- Error-recovery gates at a 3e-6 bit-error rate are unchanged: 3 of 3 receiving, 3 of 3 sending.

The send-side half is unchanged and worth stating plainly: if a peer requests ESC8 *from us*, sexyz still sends unescaped, because there is no encoding to honour it with. `zmrx -b` tolerates that; a stricter receiver might not. lrzsz behaves identically, and this is now the documented, deliberate position rather than an accident.

Not fixed here, and not ours: `zmtx` 2.04's ESCCTL sender still omits carriage return, so it cannot send to any ESCCTL receiver other than its own `zmrx`. That is recorded in `docs/zmodem_comparison.md` §7.2 for the zmtx/zmrx maintainer.

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

.