mars_nwe/mars-nwe
1
0
Fork 0
Code Issues Pull Requests Actions Projects Releases 2 Wiki Activity

docs: clarify legacy NCP audit compatibility scope

Browse Source
This commit is contained in:
Mario Fetka
2026-06-01 20:00:36 +00:00
parent 8ccc4cbea2
commit dcfe19b799
3 changed files with 24 additions and 21 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
AI.md
View File

@@ -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

24
TODO.md
View File

@@ -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

15
src/nwconn.c
View File

@@ -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 */