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, 10.12.2009, 13:11
(edited by Ninho on 10.12.2009, 16:42)

RR wrote :
> Today I received this message from Geoff Chappell:
>> Your site directs me to this Contact page if I'm to comment on your
>> members' comments about me.

Not that I wrote any comments about Geoff Chappell yet. Let me tell I'm flattered by Mr Chappell's interest in my little hack, and grateful for his comments.

>> Please register me if you have to, but I don't
>> intend any continued participation.

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. Will you Robert, please relay the content of this reply, asking him if he would mind me emailing (and if agreed, provide an appropriate email address of his)?

Geoff Chappell wrote :

>> IOW it could pay to patch DOS itself rather than try to
>> adapt wrapper.sys.

> In an ideal world, yes, the DOS kernel's routine for acting after int 21h
> function 31h would have a few extra instructions to check that it actually
> does have memory for TSR information. If you could patch in the defence
> that's missing, then you might try it - but who's going to have your
> patched DOS kernel?

Sure, patching the IO.SYS files - the many variants - is out of the question.

The problem has a few interesting aspects. For one, hooking DOS interrupts is almost unthinkable, because we're attempting to mess with, precisely, the DOS kernel's monitoring of interrupt hooks !

Patching DOS in-memory presents a few challenges, too : 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. While feasible this sounds more like 'viral' than sound programming techniques...

However, I may have come by a different approach to modifying DOS, than patching-in the suggested "defence" instructions. The beauty of that newborne being that it won't add one byte to internal DOS code! No need to find a suitable place for the d$mned patch! More on that will be written in the other (HACKWRAP) thread.

> A workaround is surely better, and the only one available is to provide
> the least necessary memory in advance of int 21h function 31h so that the
> kernel can do what its coding error makes it need to do. What the kernel
> records in this memory will not matter. The persistent record will be
> made, as it ought, when WRAPPER.SYS returns. If you could edit
> WRAPPER.SYS, you could indeed just duplicate what I've done for my

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

> Otherwise, you can provide the memory in a separate device driver, as I
> see has been attempted. There is the problem of discarding the memory when
> done, but also of re-initialising it if you want the one instance to
> support multiple WRAPPER.SYS loadings of programs that terminate with int
> 21h function 31h.

Now, this is what I have to question. 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. [addition:] I'm aware of potential problems if more than 20 TSRs will have been submitted by this method. I also agree the internal pointer @DOS:1328 should probably be zeroed before Sysinit passes the relay to the DOS kernel after all drivers are initialised. The latter is not done in the present prototype [/addition.]

Admittedly my tests have been limited [I was too much absorbed in devising a scheme for separating True MS-DOS from the ivy of Clones]. Admittedly (bis) while I have succumbed to the temptation of unassembling and browsing the MS-DOS kernel code, 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).

That it seems to work flawlessly thus was even a surprise to me first; 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.

BICBW. Members, if you have to bet, put your money on Geoff, he's the expert!

.... (some snipping done)

> And why not? I don't give a damn about the other DOSs. Moreover, if they
> want to declare themselves as DOS 7 or higher, then it's their
> responsibility to get the emulation right. That's the game they play. If I
> have to code specially for them, then they are not perfectly fine DOSs.

> By the way, my code actually has version >= 7.00 only as a necessary
> condition. It also has that the dword at offset 1328h must be 0. That's
> natural defensiveness, of course, since there's a bug to work around in
> the true DOS only if that pointer is 0, but I also think it's as much
> defensiveness as can sensibly be implemented.

I have to say that the situations are slightly different. Your library was intended for programmers, who (should) know what they do and can test for the DOS versions in their main programs anyway; 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.




Complete thread:

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