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 00:17:58

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

**Correction and new evidence: Forsberg's commercial DSZ *does* implement ESC8.** My earlier note left this open, and a comment above it inferred too much from the product manuals. Those manuals name no protocol constant at all — `ESCCTL`, `ZDLE`, `ZRINIT` and `ZSINIT` all appear zero times in DSZ.DOC, GSZ.DOC and the ZCOMM docs — so their silence about ESC8 meant nothing. Settled instead by running the binary.

**Method.** DSZ.EXE 1997-05-25 (the last release; note the version names are dates, so `dszx0597` = May 1997 is newer than `0607` = June 1995) under DOSBox 0.74, its COM1 bridged to TCP with `serial1=nullmodem`, talking to a Linux-side relay that pipes into a local ZMODEM program and captures both directions. DSZ needs the `d` command or it exits silently, since DOSBox never asserts carrier. **DSZ.EXE, not DSZ.COM** — the 7-bit options are EXE-only.

**As a receiver, `-E` sets the ESC8 bit.** Captured ZRINIT `ZF0`:

| DSZ command | ZF0 | flags |
|---|---|---|
| `rz` | 0x2F | CANFDX CANOVIO CANBRK CANRLE CANFC32 |
| `rz -E` | **0xAF** | the same **+ ESC8** |
| `rz -P` | 0x2F | (Pack-7 negotiated some other way) |
| `rz -e` | 0x6F | the same **+ ESCCTL** |

So ESC8 is exactly what its name says, and `-E` — DSZ.DOC's "7 bit mode … RLE compression and 8th bit quoting" — is what turns it on.

**As a sender, DSZ honours a request, and the result is not decodable by the only other implementation.** Sending a 4096-byte random file:

| Peer | Result | Wire | Bytes with bit 7 set |
|---|---|--:|--:|
| `zmrx -o` (no ESC8) | **byte-identical** | 4,376 | 2,088 (47.7 %) |
| sexyz `rz` (no ESC8) | **byte-identical** | 4,374 | — |
| **`zmrx -o -b`** (ESC8 requested) | **fails** — `zmrx: can't establish contact with sender` | 296 | 9 of 267 after ESC8 engages (3.4 %), all one repeated 3-byte sequence |

DSZ clearly acts on the request — high-bit bytes essentially vanish from the stream — but it also **switches to an undocumented frame type**. Scanning every `ZPAD ZDLE <type>` in the two captures:

- without ESC8: `'B'` (ZHEX) and `'C'` (ZBIN32) — standard
- with ESC8: `'B'` once, then **`0x31` (`'1'`) four times**

`'1'` is not one of the eight frame types defined in any published `zmodem.h` (`ZBIN 'A'`, `ZHEX 'B'`, `ZBIN32 'C'`, `ZBINR32 'D'` and the `ZVBIN` lowercase variants) — checked in every free release from 1987 to 2003. It is a ZMODEM-90 extension Forsberg never published.

**What this means for this issue.** There are exactly two ESC8 implementations in existence — Forsberg's commercial DSZ/GSZ line, and zmtx/zmrx 2.04 (2026-08-25) — and **they do not interoperate**. That is the expected outcome when a flag is negotiated but its encoding was never specified: ZMODEM.DOC names ESC8 once in passing and never says how a high-bit byte is escaped, so each implementer invented something, and Forsberg's involves a frame type outside the documented set.

This makes **option 2 the clear choice**. "Implement ESC8" is not a well-defined task: it would mean picking one of two mutually incompatible private encodings, one of which needs an undocumented frame type. Advertising `ZF0_ESC8` commits us to whichever encoding the peer happens to use, and we cannot satisfy both. Dropping the advertisement from `zmodem_send_zrinit()` and retiring the `Escape8thBit` key removes a config option whose only reachable effect is to break transfers — while costing nothing, since the mode has never worked with any peer.

Worth noting separately: **without ESC8, DSZ interoperates with sexyz perfectly** — a 4096-byte binary transferred byte-identically in the direction tested, with a 1997 DOS binary at one end. The base protocol is fine; only this option is broken.

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

.