Back to home page

DOS ain't dead

Forum index page

Log in | Register

Back to the forum
Board view  Mix view

Phil Gardner's Wrapper.sys & MS-DOS7 bug (Miscellaneous)

posted by Ninho(R) E-mail, 12.12.2009, 01:04

> Ask away, but you'll most likely just confirm that I ought to leave this
> stuff alone. I doubt that in the last decade I have given DOS a passing
> thought more than twice.

I hadn't touched programming stuff for over 10 years too, I came here asking if there was a known, premade fix for the Wrapper problem (the DOS bug, rather)... and being challenged ended-up doing the fix myself. It's addictive, be you warned ;-)

> Everything I ever knew was flagged long ago as
> something I don't need to remember any more - and there has been a lot to
> take its place in my deteriorating memory.

But what little remains is still a good lot it seems !

> I only visited because I wondered why my handful of archived DOS pages
> were getting unusual attention. The last DOS matter I ever looked at was
> precisely this problem for int 21h function 31h during device driver
> loading.

Before stepping through your precious replies and comments, let me first tell that I've *dropped* the previous approach (the thing I called HACKWRAP which we've been discussing in this thread) in favor of a new one, wrequires no memory reservation at all and even less interrupt hooking. It is so neat it renders the questions and incertitudes evoked here, obsolete.

To avoid confusion I'll call the new design FIXWRAP, - really need to find a better name! - and I've started a new thread where I'll explain the concept in detail later. If it works - and no doubt it works, the programming itself requires time and a minutia of details of course, but the principle is astonishingly simple... a little hint lower on,

That said

>> For one, hooking DOS interrupts is almost unthinkable, because we're
>> attempting to mess with, precisely, the DOS kernel's monitoring of
>> interrupt hooks !

> The intention wouldn't be to stop DOS from monitoring the hooking of
> interrupts. Neither would you be lying to DOS about what's hooked. So, I
> doubt there'd be any trouble.

Maybe. I'm sure there is no trouble whatsoever for ints are hooked by TSRs loaded from a Wrapper driver. But it's not what annoyed me, it was the potential problems if I made HACKWRAP itself hook an interrupt of interest to DOS. It would be difficult to unhook the interrupt cleanly later, once it's been inited and is no more under monitoring by DOS. OTOH if the hooks were to be kept forever, and regrettably the memory too, in addition Windows "enhanced" mode would possibly consider it a "bad" TSR reducing system "performance" in proportion. :-(

> Whether it's worth your trouble is another question. (...)

I'll snip some more of the quoting in the interest brevity

>> first, as noted, the place(s) to patch change between IO.SYS builds,
>> and they can't even be found straight from the int 21 dispatch table,
>> since they are buried inside of subroutines.

> Yes, there seems to be no reliable means of locating the routine and the
> place from which it's called. I'm sure if there were, I'd have favoured
> diverting the call to my own code that would first test the pointer.

Ha! I had similar thoughts too when I started pondering alternatives, and indeed not until after seeing the untidiness of the HACKWRAP-type of solutions, I decided to peek closely at the kernel code. And, behold, what I found, there is no need for patching out DOS code in the traditional, messy, way. The problem is completely, and safely, solved by flipping ONE bit of DOS code in conjunction with ONE unused bit of flags in the DOS data area.

When you realise that, the prospect of dynamically finding the interesting instruction in memory suddenly ceases to stop you; and indeed as it happens it doesn't even require a load of "artificial intelligence" to locate it. :-P

> there's no doubt here that the problem is only that the
> routine for post-processing resident termination doesn't test the pointer.

Indeed ! But by hacking only one TEST instruction we will skip the problem subroutine when and only when it is undesirable. TEST can work magics !

>> But I won't touch WRAPPER.SYS, at least for public consumption - doesn't
>> belong to me! -

> I was thinking you may have found source code - and permission to edit it
> - or even that you can rewrite it. The ideal plainly would be that an
> updated WRAPPER.SYS accommodates the DOS bug.

I got no reply to an email I tentatively sent to Phillip Gardner, sometime before I started this here. I'll assume it was never received...

> It sounds like you have several people here who could easily enough write
> a new WRAPPER.SYS.

Sure. Even I, old dummy as I am, could attempt it, I wouldn't say exactly "easily". The perspective of spending weeks redoing existing work is not exactly exaltating - but it's just me, and maybe the age shows. I prefer the fun of creating a little thing, but a new one (economy of means). It's conceivable others will have a different take. In any case, I honestly think the newer fix I've devised for DOS makes the question of rewriting a WRAPPER moot.


Again I'm snipping across your insightful technical replies, comments and hints - be assured I appreciated and saved them all.


> I was just thinking of what you might do well to look at, for things to go
> wrong. I was suspicious of the DRVRPTR array at the end, as if maybe this
> grows with reuse. It doesn't however.

Indeed it doesn't grow. But as explained, I won't need to fake undocumented structures any more, what a relief!


Didn't I forget something ? Oh, yes : merci! Hope to see you again...



Complete thread:

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