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 cm(R) Homepage E-mail, Düsseldorf, Germany, 10.12.2009, 15:56

> I don't intend any continued participation.


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

Online patching (by the device driver to load, or a special device driver for this purpose only such as HACKWRAP) is easier anyway, considering the kernel file compression of MS-DOS 8.

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

If that turns out to be necessary, hook Int21 or the Int2F redirector termination hook (the one that's called for TSR termination too) and reset the local TSR info structure when a process termination is attempted. Once MS-DOS's configuration part set its TSR info structure, resetting the local structure that we set up earlier won't cause problems either.

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

As you explained yourself, there's software that doesn't look for LFN functions if the true DOS version isn't at least 7.00. The same way, some software wants a true DOS version of at least 7.10.

> FAT32 is much older.

So which MS-DOS versions supported it earlier? I read about some "MS-DOS 6.23" version, but it apparently wasn't available for retail and I've never read someone actually stating they've seen it.

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

Yes. Consider that LFN functions even have an explicit installation check (21.71A0) which indicates whether LFNs are supported on a particular drive. There isn't such an explicit function for FAT32. Therefore it's not surprising that software checks the DOS version number for FAT32 support.

> I don't give a damn about the other DOSs.

Yes, I see. But where's the point in talking more about them then?

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

This way (i.e. completely hardcoded offsets) only MS-DOS is your perfectly fine DOS. An exact copy of MS-DOS is MS-DOS.

Interesting: Should your perfectly fine DOS (which is not MS-DOS itself) reproduce the faulty TSR info handling in Int21.31 ?

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

Okay, that can be seen as version check. I'd usually check for offset != -1 and segment != 0.

> but I also think it's as much
> defensiveness as can sensibly be implemented.

No. Int2F.1611, Int2F.4A33, and SDA "MagicPatch" pointer as all implemented in HACKWRAP.SYS (ask Ninho for the source or disassemble it if you're interested). The patch pointer points not exactly at the TSR info pointer, but near it. This is better than blindly assuming the TSR info pointer to be at some location in the DOS data segment (which might not extend that far in other DOS versions).



Complete thread:

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