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 geoffchappell, 15.12.2009, 16:55

> 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!
Not easily, no. If you have to stay in memory, you may as well just "fix" DOS by providing temporary memory for TSR information. We're talking of not even half a KB of memory that is wasted - and if you do want to free it, then at least you can, whenever you want.

Your way would require possibly more than half a KB for code that stays active while watching for this or that condition. I don't know that this is a gain.

I incline to think that if you go with your method, you may as well leave it to the user's responsibility to repeat the loading of your driver as the last DEVICE entry. It is just a workaround, after all. If the user is unhappy, let him rewrite WRAPPER.SYS.

> Magic_test: TEST Win386flags, MS_mask OR Ninho_bit
> JNZ skip_unwanted ; jmp if any mask bit(s) is (are) set
At any time that your bit is set, you make DOS take the jump, and at any time your bit is clear, you leave DOS to decide whether to take the jump.

Since you're going to make DOS take the jump, why not just change the jump? The bit is redundant. At any time that you would set your bit, just change the JNZ to a JMP SHORT, and at any time that you would clear your bit, just change the JMP SHORT back to a JNZ.

> In your proposition, i.e. without Ninho_bit, how exactly do you propose
> to change the TEST and JNZ ?
Leave the TEST alone. Change the 0x75 to 0xEB.

> Yes I know but I /can/ find that segment easily enough and use it to
> do checks and locate the exact bounds of the actual code, per MCB and
> HmaContrlBlock. I prefer exact science, where available, to guesswork
> and black magic
I think you'll end up with quite a lot of the latter. What the "exact science" points to, over and over, is that the DOS code segment is not meant to be found - well, not by anyone but DOS itself.

Besides, what good is it to you to know what segment DOS uses for accessing its code? It's just an addressing base. It doesn't tell you where the DOS code starts, let alone where it ends. You're going to be involved in some heuristics, come what may.

> DOS CS is kept near the start of IO.SYS data area @ 0070:0003.
It holds the DOS data segment, as far as I ever knew. It was always a handy thing to know when debugging.

Post reply
 

Complete thread:

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