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, 11.12.2009, 18:21

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

Might be something about 32-bit drives or such, which before FAT32 meant the feature of 32-bit sector addressing (i.e. > 65536 sectors). This was introduced by a special MS-DOS 3.31 first and later by MS-DOS 4.

MS-DOS up to 6 (i.e. all stand-alone versions) never supported LFNs, other VFAT stuff (new time stamps), FAT32 or LBA (disks > 8 GiB).

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

Disk checking and such, but recently also FreeDOS's famous new DEVLOAD (which needs to know whether to create FAT32 EDPBs or the normal MS-DOS 4+ DPBs to load block device drivers) as well as the open-source USBDRIVE (similar reason; installs from command line instead CONFIG.SYS).

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

The IOCtl functions might not be supported by third-party block devices (such as USBDRIVE) and I don't know about an obvious function there anyway. (Seeing that the block device might be dettached from DOS, this won't be a particular reliable check anyway.)

Int21.7302/.7304/.7305 is what I recommend to check for, but all of these aren't exactly named "FAT32 check" and thus might not be obvious at first. They certainly aren't explicit.

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

Fine.

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

It seems that the only program depending on this is IOS. Or generalized: Windows 4.

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

Note that Windows 3 and Windows 4 are treated entirely different by DOS developers. Technically, the interface provided for Windows 4 by MS-DOS 7+ actually seems to have been expanded to cover much more than the Windows 3 interface did. (Windows 4.90 ("Millenium Edition") might even require some more only provided by MS-DOS 8.)

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

Just as a side note, the redirector interface didn't seem to change between MS-DOS 6 and 7/8. Which is bad, because thus it was never updated to support long file names.

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

As stated, developers tend to treat MS-DOS's Windows 4 integration differently. No other DOS supported running Windows 4 yet. (Although some vendor of DR-DOS once stated they had a TSR for that. They never released that TSR though.)

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

It's not of relevance to any particular pointer but to real-mode pointers. Pointing somewhere with a segment of zero doesn't make sense for DOS data, pointing at the last byte of a segment doesn't work for most code or data.

---
l

 

Complete thread:

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