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 rr(R) Homepage E-mail, Berlin, Germany, 09.12.2009, 22:50

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. Please register me if you have to, but I don't intend any continued participation. Perhaps it would be better if you would just relay the following to the topic given in the Subject.

==== begin ====

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

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

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.

> In this case, the other DOS variants report a version
> of 7.10 to show that they support FAT32.

Why on earth would they do that? FAT32 is much older. I can imagine that some of them do it to show that they support long file names. They'll have surely preferred to indicate it by supporting the int 21h function 71h variants, but no doubt run into software that doesn't look for those variants unless the version number is at least 7.00.

> No other DOS supports the TSRInfo pointer in the DOS
> data segment, but (because the version is 7.00+)
> Chappel expects that feature.

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.

==== end ====

Thank you.

 

Complete thread:

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