Back to home page

DOS ain't dead

Forum index page

Log in | Register

Search:  
Back to the forum
Board view  Mix view

the algorithm, sketched for review. Nitpicks ? (Miscellaneous)

posted by Ninho E-mail, 16.12.2009, 19:51
(edited by Ninho on 17.12.2009, 16:43)

After the great collective brain storming, here's for review a rough sketch of the algorithm I settled for finding the Magic Test Instruction & installing the fix. I think it's not far from the ideal, viz produces the correct result using the least amount of effort.

Pre-assertions :
- the code is running as part of the driver's initialisation routine.
- Win95/DOS 7 (any version). The DOS8 case is merged somewhere along the path below, and is only simpler because so much is hardcoded.

Finding and fixing the Magic Test Instruction, step by step; being programmers, our first step has to be step zero, right ? ;-)

-0. Check SHARE not installed (should not really be needed since SHARE.EXE can't be installed before driver initialisations, but this step is to please CM and guard against his hypothetical mad hacker trying to DEVLOAD FIXWRAP after loading a version of SHARE.EXE) :
Use Int 2F/1000. -> AX=0 or 1, OK for us to continue; else bail out.

-1. Get CS:IP of int 27 in DOS Kernel :
CS from IOSYS share hooks (DATA:0092),
IP from MSDOS Data:0F90

IF this routine entry is NOT in the HMA, GOTO step 3 below.

-2. Else MS-DOS is "high" using the HMA, ergo XMS must be present :
-2a. check int 2F/4300 -> AL=80h. Else (incoherent! output dbg msg and bail out)
-2b. int 2F/43.10 -> get the far entry point to XMM functions,
-2c. Call with AH=5, the LOCAL Open HMA function. -> AX=0001 OK (else incoherence, dbg msg, undo work, bail out)

-3. Locate the Magic Test instruction :
We start by checking for the MTI straight at (int27_entry - 0Eh).

This is justified by my tests always finding the same layout of the code around this point in samples of MS-DOS 7.0, 7.1 (also 8). PLEASE everybody who can have a look, can we assert the MTI is always exactly fourteen bytes ahead of the int 27 entry in MSDOS code in all your versions, including national variations of Win 9x/ME ?

Of course we needn't rely on the offset of MTI with respect to Int27 being fixed. If the MTI was not found in its expected location, we may start searching for it (in the vicinity only??? Warn, for debugging purposes. TBD)

If NO magic instruction was found, error! mesg, undo work, bail out...


-4. TEST and SET Ninho's bit in the MTI. This establishes the fix proper (and could be applied permanently to the IO.SYS file, if desired). If the bit was set already, put a message (notice, rather than an error).

IFF we had opened the HMA in step 2c, now close it (locally!) using
XMS function 6.

-5. Finally, switch the fix ON, i.e. prevent DOS 21/31 from checking the TSRs, by setting Ninho's bit in DOSDATA offset F5B. Yell : Cocorico !!!!
(If the bit was found to be SET already, user may be loading FIXWRAP multiple times. No harm done, Warn only)

The rest is routine work : clean up, fill in exit values to caller, RETf to DOS Sysinit.

_______________________________________________________________________


Compared to the sweat of installation, the later undoing of the fix will be trivial and does not need much more than, switch Ninho's bit off at DATA:F5B :-)



[Dec 17 : Typo corrected, thanks CM]

---
Ninho

Post reply
 

Complete thread:

Back to the forum
Board view  Mix view
22049 Postings in 2034 Threads, 396 registered users, 286 users online (1 registered, 285 guests)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum