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 geoffchappell(R), 11.12.2009, 17:12

> Geoff's choice not to participate here is fully understood and
> respectable. It is slightly unfortunate, for I would've had a
> couple technical question to ask of him otherwise.

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. 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.

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.

> 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.

Whether it's worth your trouble is another question. You'd be able to supply memory for fake TSR information in advance of the named program's execution, and undo the hack when the named program terminates. It's tidy that the hack is active only for the least time, but you may have to leave those hooks in place forever (if the named program hooks your same interrupts).

> 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. Workarounds should deal as closely as possible with what I think to be the problem, and there's no doubt here that the problem is only that the routine for post-processing resident termination doesn't test the pointer.

> 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.

It sounds like you have several people here who could easily enough write a new WRAPPER.SYS. Really, it's just a matter of writing glue to translate from device driver initialisation to running the program that's named on the device driver command line, and then of a few fiddles before and after you actually do run the program. You have to build a memory arena so that your int 21h function 4B00h will see a block of free memory in which to load the named program. You have to fake an FCB-SFT (before DOS 7) and fake TSR information (in DOS 7 and higher). I'd preserve the DTA too, though I can't say that SYSINIT actually depends on it to be preserved across a device driver load.

> In my tests (and as far as I know, other members'), multiple TSRs have
> been launched in this way without ill effect in DOS before or even
> after launching Win9x.

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. The minimal allowance of 1 in CRTDRVR.ASM looks like it will be good for you, too.

> I did not look deep inside the all important Windows side of the
> question (my copy of the Win95 DDK being buried God knows where)

When you find it, you may save time from knowing that IOS.VXD is the one that cares about this data. On the other hand, that doesn't really matter. When SYSINIT is ready to start loading TSRs, it will point DOS:1328h to its own TSR information and ignore yours, which therefore will never be seen by IOS.

In IOS, the offset 1328h is hard-coded.

To SYSINIT, the offset 1328h is found by its being at offset 20h from the address that the DOS kernel's initialisation routine returns in bx.

> my current theory is that the compare&record work done by int 21/31
> is useless but also harmless (provided the hack is in place), the
> useful recording of TSR resources is that done each time WRAPPER.SYS
> returns from its initialisation.

At this stage, yes. The TSR executes within the driver. Everything it does should look to have been done by the driver and should be recorded as driver usage for IOS to retrieve through the documented int 2Fh function. That it's also recorded as TSR usage won't matter.

> while my hack will potentially end up being stored on end users' disks
> and I feel I have to do my best to prevent any damage in case they
> attempt to launch it under any DOS or DOS alike versions.

Each to his own, I think. If you would feel responsible for problems if your code got used on another DOS, then support it. I would never criticise anyone for supporting another DOS, just for insisting that anyone must.

 

Complete thread:

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