Back to home page

DOS ain't dead

Forum index page

Log in | Register

Search:  
Back to the forum
Board view  Mix view

new HACKWRAP fix for MS-DOS7+, aka smashing the bug (Miscellaneous)

posted by Ninho E-mail, 14.12.2009, 11:49
(edited by Ninho on 14.12.2009, 12:11)

>> - I pick an unused bit in the SAME byte for a new flag which HACKWRAP, or
>> dare I say FIXDOS ;=) will set during of Config.sys.

> There's a luxury that comes with knowing that there will be no more DOS
> versions from Microsoft. It would not have occurred to me to define a new
> bit: I'm still thinking as I was back in 1996!

Indeed it is a relief to know MS will never stamp on my bit.
On the flip side, in your case, you have the luxury of regaining control automatically once an embedded TSR have been terminated by DOS.
Fixwrap by being standalone cannot be called back in that manner, at least there is no easy solution for it to be.

>> An other instance of HACKWRAP, or a companion program will later unset
>> the flag, restoring the usual DOS working (an oxymoron?)

> To me, this is fundamentally unsound. What if your other instance doesn't
> load? You disturb the system without ensuring that you will un-disturb it.
Agreed just in principle. I could reply that won't happen if users RTFM :=)

Also it won't be a problem if they stay in DOS, only if they eventually launch Windows and only if they carelessly launched more TSRs without UNfixwrapping. Let'm RTFM !

I haven't given much thought yet to how far I want to make the "companion program" comprehensive versus simple (it would not be a separate binary, rather a combined .exe or .com type driver/executable). I'm finishing the first FIXWRAP first, so we have something to play with.

But yes, again, ideally we should ensure the "fix" is rendered inactive as soon as Sysinit finishes loading the config.sys drivers.
If I can devise a /simple/ scheme whereby the first FIXWRAP device stayed in memory to be callback'ed after all drivers have been initialised, I will consider employing that to avoid the users pain. You may have ideas!

While considering any method I will have to balance it with the ease and comfort that having none of FIXWRAP stay in memory provides !

Also I have to put some limits to the amount of self-inflinged work, perfection, alas! is not a thing of this world...

>> So, what FIXDOS/HACKWRAP does is we'll FLIP one bit in that instruction,
>> in memory, that will change it to TESTing for both OUR new bit and THEIRS
>> and the following JNZ will take the proper action in all cases, skipping
>> over the bookkeeping whenever it is unwanted !

> So, you will find the TEST instruction and patch it to recognise your new
> bit, and then also set your new bit before WRAPPER.SYS and clear it after.
> Why define a new bit to set and clear? Since you still must patch the TEST
> instruction, why not just patch the JNZ that follows it (and patch it back
> later)?
Mainly because I don't want to take the risk of breaking MS's case logic, nor even want or need to /know/ what the precise purpose is of those MS's bits.

Symbolically this is the patched test :

Magic_test: TEST Win386flags, MS_mask OR Ninho_bit
JNZ skip_unwanted ; jmp if any mask bit(s) is (are) set


In your proposition, i.e. without Ninho_bit, how exactly do you propose to change the TEST and JNZ ?
MS_mask is = 03 ( 01 in Win95 original "gold" say you, I haven't checked. A priori, the difference could be either an added feature of service packs, or a silent bug correction.)

---
Ninho

Post reply
 

Complete thread:

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