From dcfe19b799ba8114effd11aab50725921c387564 Mon Sep 17 00:00:00 2001 From: Mario Fetka Date: Mon, 1 Jun 2026 20:00:36 +0000 Subject: [PATCH] docs: clarify legacy NCP audit compatibility scope --- AI.md | 6 +++--- TODO.md | 24 +++++++++++++----------- src/nwconn.c | 15 ++++++++------- 3 files changed, 24 insertions(+), 21 deletions(-) diff --git a/AI.md b/AI.md index 618c3f5..23e54e5 100644 --- a/AI.md +++ b/AI.md @@ -29,11 +29,11 @@ use, the current project status that the user pasted into the chat. ## Current protocol audit scope -- The current endpoint documentation/audit pass is scoped to NetWare 3.x-compatible NCPs. Do not add NetWare 5.x / MOAB-only endpoints or TODOs unless the user explicitly asks for later-version coverage. +- The current endpoint documentation/audit pass is scoped to compatibility NCPs through NetWare 3.x, including NetWare 1.x/2.x legacy calls where they are documented. Do not add NetWare 4.x/5.x/OES/MOAB-only endpoints or TODOs unless the user explicitly asks for later-version coverage. - When a `0x2222` group is forwarded out of `nwconn.c`, document both layers: `nwconn.c` should explain the group handoff/header, and the destination file (for example `nwbind.c`) should document concrete subfunction request/reply layouts. -- For documentation-only endpoint patches, do not change parser offsets, byte order, reply layout, or completion behavior. Always compare the code parser/reply layout against the NetWare 3.x SDK/WebSDK/PDF request format. If the code differs from the SDK layout, document the concrete difference inline and mirror it in `TODO.md` for later testing. If it matches, say so in the patch summary so the audit trail is clear. +- For documentation-only endpoint patches, do not change parser offsets, byte order, reply layout, or completion behavior. Always compare the code parser/reply layout against the applicable NetWare 1.x/2.x/3.x SDK/WebSDK/PDF request format. If the code differs from the SDK layout, document the concrete difference inline and mirror it in `TODO.md` for later testing. If it matches, say so in the patch summary so the audit trail is clear. - Keep `TODO.md` endpoint audit notes grouped by logical endpoint family instead of as one long flat list. -- The rejected `0152-docs-note-message-control-subfunction.patch` must not be applied: it documented `0x2222/21/0x0c Connection Message Control`, which is outside the NetWare 3.x MARS-NWE target scope. +- The rejected `0152-docs-note-message-control-subfunction.patch` must not be applied: it documented `0x2222/21/0x0c Connection Message Control`, which is outside the NetWare 1.x/2.x/3.x MARS-NWE target scope. ## mars-nwe coding style rules diff --git a/TODO.md b/TODO.md index ceef931..dd7cfd0 100644 --- a/TODO.md +++ b/TODO.md @@ -90,13 +90,14 @@ Follow-up: paths intentionally forward bindery/global-server work to `nwbind`. -### NCP endpoint layout audit (NetWare 3.x compatibility) +### NCP endpoint layout audit (NetWare 1.x/2.x/3.x compatibility) Current status: -- The NCP endpoint audit is scoped to NetWare 3.x-compatible calls unless the - user explicitly asks for later NetWare/OES additions. Do not add NetWare 5.x - / MOAB-only endpoints to the implementation TODO list. +- The NCP endpoint audit is scoped to compatibility calls through NetWare 3.x, + including NetWare 1.x/2.x legacy calls where documented, unless the user + explicitly asks for later NetWare/OES additions. Do not add NetWare 4.x/5.x + / OES / MOAB-only endpoints to the implementation TODO list. - Keep SDK request/reply details close to the corresponding endpoint in the source file that handles the call. If `nwconn.c` forwards a group to `nwbind.c`, document the handoff in `nwconn.c` and the concrete subfunctions @@ -163,8 +164,9 @@ Current status: - `NCP 0x12 Get Volume Info with Number`, `NCP 0x13 Get Station Number`, `NCP 0x14 Get File Server Date And Time`, and the `NCP 0x15` message group handoff have inline SDK request/reply layout documentation. -- The forwarded NetWare 3.x `NCP 0x15` message subfunctions in `src/nwbind.c` - have inline SDK request/reply layout documentation for broadcast send/get, +- The forwarded NetWare 1.x/2.x/3.x-compatible `NCP 0x15` message + subfunctions in `src/nwbind.c` have inline SDK request/reply layout + documentation for broadcast send/get, enable/disable, and console broadcast calls. - `NCP 0x13 Get Station Number` is documented by the SDK as a three-byte StationNumber reply; MARS-NWE currently returns only the low one-byte @@ -187,16 +189,16 @@ Current status: - `NCP 0x2222/22` is handled in `src/nwconn.c`, not forwarded to `nwbind.c`. - The group header is documented inline as `SubFuncStrucLen` (Hi-Lo), `SubFunctionCode`, and subfunction payload. -- The first NetWare 2.x/3.x directory services subfunctions now have inline SDK - request/reply layout documentation: `22/00` Set Directory Handle, `22/01` - Get Directory Path, `22/02` Scan Directory Information, `22/03` Get - Effective Directory Rights, `22/04` Modify Maximum Rights Mask, `22/05` Get +- The first NetWare 1.x/2.x/3.x-compatible directory services + subfunctions now have inline SDK request/reply layout documentation: + `22/00` Set Directory Handle, `22/01` Get Directory Path, + `22/02` Scan Directory Information, `22/03` Get Effective Directory Rights, `22/04` Modify Maximum Rights Mask, `22/05` Get Volume Number, and `22/06` Get Volume Name. - The old SDK PDF table for `22/00` repeats `TargetDirectoryHandle` for the second payload byte, but the remarks describe a source handle; MARS-NWE parses the byte as `SourceDirectoryHandle`. This is documented inline but not changed. -- No NetWare 3.x SDK/PDF entries were found for direct `22/07`, `22/08`, or +- No NetWare 1.x/2.x/3.x SDK/PDF entries were found for direct `22/07`, `22/08`, or `22/09` during this audit. The next documented direct directory calls continue at `22/0a`. - `22/0a` Create Directory, `22/0b` Delete Directory, `22/0d` Add Trustee to diff --git a/src/nwconn.c b/src/nwconn.c index 3e254cd..6a993dd 100644 --- a/src/nwconn.c +++ b/src/nwconn.c @@ -2855,8 +2855,8 @@ static int handle_ncp_serv(void) * and 0xff lock error, while newer 0x6a also documents * 0x7f ERR_LOCK_WAITING. * - * The newer 0x6a call replaces the old 0x04 call for NetWare 3.x - * and later. MARS-NWE currently handles both calls in one branch + * The newer 0x6a call replaces the old 0x04 call for later + * clients. MARS-NWE currently handles both calls in one branch * and reads the timeout with GET_BE16(). That matches the 0x6a * Hi-Lo SDK layout; the old 0x04 SDK page documents Lo-Hi. This * comment records the wire-layout difference only; the parser is @@ -3236,7 +3236,8 @@ static int handle_ncp_serv(void) /* * NCP 0x2222/21 is the Message NCP function group. The SDK routes * individual message calls through a nested SubFunctionCode, for - * example the NetWare 3.x broadcast send/get and enable/disable calls. + * example the classic NetWare 1.x/2.x/3.x-compatible + * broadcast send/get and enable/disable calls. * * SDK group request header: * @@ -3264,7 +3265,7 @@ static int handle_ncp_serv(void) * requestdata[2] SubFunctionCode * requestdata[3..] subfunction-specific payload * - * The first NetWare 2.x/3.x-compatible directory calls are + * The first NetWare 1.x/2.x/3.x-compatible directory calls are * documented by the SDK as: * * 22/00 Set Directory Handle @@ -3275,7 +3276,7 @@ static int handle_ncp_serv(void) * 22/05 Get Volume Number * 22/06 Get Volume Name * - * No NetWare 3.x SDK/PDF entries were found for direct 22/07, + * No NetWare 1.x/2.x/3.x SDK/PDF entries were found for direct 22/07, * 22/08, or 22/09 in this group during this audit. The next * documented direct directory calls continue at 22/0a. * @@ -3586,7 +3587,7 @@ static int handle_ncp_serv(void) * SDK reply: completion code only. * * Parser comparison: current INPUT layout matches the - * documented NetWare 3.x request layout. + * documented NetWare 1.x/2.x/3.x request layout. */ struct INPUT { uint8 header[7]; /* Requestheader */ @@ -3640,7 +3641,7 @@ static int handle_ncp_serv(void) * SDK reply: completion code only. * * Parser comparison: current INPUT layout matches the - * documented NetWare 3.x request layout. + * documented NetWare 1.x/2.x/3.x request layout. */ struct INPUT { uint8 header[7]; /* Requestheader */