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:14

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

Sorry, I was wrong. I thought it was older, looked in my MS-DOS 5 Programmer's Reference, which I am amazed is still in my office bookshelves, saw something about FAT32 or 32-bit FAT entries, felt confirmed, and thought nothing more of it. Be damned if I can find it there today!

I ought anyway to take my own advice and look only in the code.

> There isn't such an explicit function for FAT32. Therefore it's not
> surprising that software checks the DOS version number for FAT32
> support.

Maybe, but then I'd have to wonder what support is it that they're checking for and why are they doing it. Are you sure there's no explicit function for FAT32? What about the various subfunctions of int 21h function 73h or of int 21h function 440Dh with 48h in CL?

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

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

Because you'd have it that it's wrong (or at best incomplete) not to check for other DOSs. And I'm just saying: do it if you want, but it's not my responsibility and I'll object if you say it ought to be.

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

It's not as if this pointer is just some internal variable that the DOS kernel happens to use on its own and I've picked it out by its hard-coded offset. No, this pointer is one of the very many DOS kernel variables that have to be in the right place for one or another program of Microsoft's that Microsoft has let depend on hard-coded offsets in the DOS kernel.

As I see it, supporting this is a fact of life for any manufacturer of a different DOS. At least since DOS 3.2 or something like that, it just has not been sensible to hope that any so-called compatible DOS is "perfectly fine" if it implements just the well-defined interfaces, even if it also covers all the undocumented interfaces. There are data dependencies, too. They are part of the interface - an ugly part but one that the maker of every alternative DOS has to support if they want to be compatible with such DOS programs as Windows.

If someone makes a different DOS and calls it version 7.00, then they have the entire burden of supporting the data dependencies that are exposed by MS-DOS 7.0 and its relationship with network redirectors and especially with Windows. One of those dependencies is the pointer at offset 1328h.

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

No, but any DOS that calls itself version 7.00 will need to have offset 1328h in its data segment pointing to TSR information in the expected format, assuming that this DOS supports its users trying to run Windows 95.

If a different DOS doesn't get this right, why should DOS programmers have to account for it in their code?

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

It's not a version check and I don't offer it as one. If it works as one, then fine but incidental.

> I'd usually check for offset != -1 and segment != 0.

You can make up whatever test you want, I suppose, but how would you support your usual test's relevance for this particular pointer?

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

But none of these would be defensiveness for the workaround. To my mind, they count as more-or-less specific support for one or another DOS that's incomplete. It may be that commercial imperatives - not that I can imagine them applying nowadays to any DOS programmers - may favour writing special code for a different DOS. That's a question of the DOS programmer's commercial good sense or maybe just of his tastes or prejudices, but not one of whether his coding is sufficiently defensive. He has no technological or legal obligation to give any DOS but MS-DOS the slightest consideration.

 

Complete thread:

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