DOS ain't dead

> I have found myself
> Geoff
> Chappell's page

Yes, sorry for omitting the link but you proved it was easy to find given the description.

> and I looked on wrapper.sys' code.

As in, unassembled using IDA or the like ? You're quick. Or have you found the original source ? I don't suppose it was made public...

> You have just to
> implement the changes just before load and execute program is called (see
> the code above the source of the jump to the int 21h which is immedialtely
> after sys' header).

Who, me ? I swore to myself I won't reload the old DOS tools and re-learn them. Too much other interesting stuff in life. Ans seeing as you have started looking at the thing, you're finished before I've reloaded a good disassembler, let alone studying the code.

Further I believe it takes a little more thinking than just copying Geoff Chappels code into Phil Gardner's, there are strategic decisions to be made. We probably don't want to allow the infernal couple (int 21/4B & int 21/31) record the interruptions our TSR hooked, rather ISTM we should somehow patch 21/31 so it does not attempt to do said recording (instead DOS will record the changes when wrapper.sys itself gives back control). IOW it could pay to patch DOS itself rather than try to adapt wrapper.sys. Just rambling ;=)

Anyhoo... if you are the kind of guy who likes challenges, please go for it your own way. There is more than one to skin a cat, so I'm told

---
Ninho

Well. Then let us know when it's ready.

---
l

> Ask away, but you'll most likely just confirm that I ought to leave this
> stuff alone. I doubt that in the last decade I have given DOS a passing
> thought more than twice.

I hadn't touched programming stuff for over 10 years too, I came here asking if there was a known, premade fix for the Wrapper problem (the DOS bug, rather)... and being challenged ended-up doing the fix myself. It's addictive, be you warned

> Everything I ever knew was flagged long ago as
> something I don't need to remember any more - and there has been a lot to
> take its place in my deteriorating memory.

But what little remains is still a good lot it seems !

> I only visited because I wondered why my handful of archived DOS pages
> were getting unusual attention. The last DOS matter I ever looked at was
> precisely this problem for int 21h function 31h during device driver
> loading.

Before stepping through your precious replies and comments, let me first tell that I've *dropped* the previous approach (the thing I called HACKWRAP which we've been discussing in this thread) in favor of a new one, wrequires no memory reservation at all and even less interrupt hooking. It is so neat it renders the questions and incertitudes evoked here, obsolete.

To avoid confusion I'll call the new design FIXWRAP, - really need to find a better name! - and I've started a new thread where I'll explain the concept in detail later. If it works - and no doubt it works, the programming itself requires time and a minutia of details of course, but the principle is astonishingly simple... a little hint lower on,

That said

>> For one, hooking DOS interrupts is almost unthinkable, because we're
>> attempting to mess with, precisely, the DOS kernel's monitoring of
>> interrupt hooks !

> The intention wouldn't be to stop DOS from monitoring the hooking of
> interrupts. Neither would you be lying to DOS about what's hooked. So, I
> doubt there'd be any trouble.

Maybe. I'm sure there is no trouble whatsoever for ints are hooked by TSRs loaded from a Wrapper driver. But it's not what annoyed me, it was the potential problems if I made HACKWRAP itself hook an interrupt of interest to DOS. It would be difficult to unhook the interrupt cleanly later, once it's been inited and is no more under monitoring by DOS. OTOH if the hooks were to be kept forever, and regrettably the memory too, in addition Windows "enhanced" mode would possibly consider it a "bad" TSR reducing system "performance" in proportion.

> Whether it's worth your trouble is another question. (...)

I'll snip some more of the quoting in the interest brevity

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

> Yes, there seems to be no reliable means of locating the routine and the
> place from which it's called. I'm sure if there were, I'd have favoured
> diverting the call to my own code that would first test the pointer.

Ha! I had similar thoughts too when I started pondering alternatives, and indeed not until after seeing the untidiness of the HACKWRAP-type of solutions, I decided to peek closely at the kernel code. And, behold, what I found, there is no need for patching out DOS code in the traditional, messy, way. The problem is completely, and safely, solved by flipping ONE bit of DOS code in conjunction with ONE unused bit of flags in the DOS data area.

When you realise that, the prospect of dynamically finding the interesting instruction in memory suddenly ceases to stop you; and indeed as it happens it doesn't even require a load of "artificial intelligence" to locate it.


> there's no doubt here that the problem is only that the
> routine for post-processing resident termination doesn't test the pointer.

Indeed ! But by hacking only one TEST instruction we will skip the problem subroutine when and only when it is undesirable. TEST can work magics !

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

> I was thinking you may have found source code - and permission to edit it
> - or even that you can rewrite it. The ideal plainly would be that an
> updated WRAPPER.SYS accommodates the DOS bug.

I got no reply to an email I tentatively sent to Phillip Gardner, sometime before I started this here. I'll assume it was never received...


> It sounds like you have several people here who could easily enough write
> a new WRAPPER.SYS.

Sure. Even I, old dummy as I am, could attempt it, I wouldn't say exactly "easily". The perspective of spending weeks redoing existing work is not exactly exaltating - but it's just me, and maybe the age shows. I prefer the fun of creating a little thing, but a new one (economy of means). It's conceivable others will have a different take. In any case, I honestly think the newer fix I've devised for DOS makes the question of rewriting a WRAPPER moot.

....

Again I'm snipping across your insightful technical replies, comments and hints - be assured I appreciated and saved them all.

....

>
> I was just thinking of what you might do well to look at, for things to go
> wrong. I was suspicious of the DRVRPTR array at the end, as if maybe this
> grows with reuse. It doesn't however.

Indeed it doesn't grow. But as explained, I won't need to fake undocumented structures any more, what a relief!

...

Didn't I forget something ? Oh, yes : merci! Hope to see you again...

---
Ninho

> In this case, I think he
> also means "I'm no longer actively interested in DOS".

This is what I meant.

> Eh? No, AFAIK, MS-DOS 7.10 means Win95 OSR2 or Win98 or Win98SE, as
> nothing earlier supported FAT32.

Exactly.

> (Even DR-DOS only had an unofficial TSR,
> which I blindly guess was pulled when they discovered MS had patents on
> it, ugh.)

Are you talking about the TSR supposedly (i.e. we never got it) able to run Windows 4.x, or about DRFAT32 ?

> FreeDOS, as you probably know, by default uses 6.22 as the FAT16 kernel
> versions and 7.00 (or 7.10, I forget) for FAT32-enabled versions.

It is 7.10, as 7.00 won't make sense.

> Maybe
> ROM-DOS does the same, I dunno.

Pretty sure they have their own build numbers (currently 4.x.something? there are some neat calls to get version strings and numerical values), the "6.22" or "7.10" labels are just extending the version fakery to the user.

> My copy of DR-DOS 7.03 is definitely not
> LFN aware (except in very few places, e.g. COMMAND.COM),

Probably the later COMMAND.COM beta versions, I don't think the original 7.03 COMMAND.COM supported LFNs.

> > 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.
>
> Obviously you can use LFNs in any FAT, e.g. FAT12, FAT16, FAT32.

Obviously, yes. Did my answer seem ambiguous?

> I'm pretty sure this guy is only interested in modern Windows these days.

I'm pretty sure that's right but he probably still reads our answers, so you might as well address him directly.

> They all have bugs, and if you run into one, you either ignore it, abandon
> the project (no!), or work around it. Even the hallowed "original" MS-DOS
> has quite a few annoying quirks and bugs.

Understatement. However, with MS-DOS it's the application programmers who have to work around DOS's bugs. This is the definitive advantage of open source: the first (app) programmer who had to work around the bug can integrate it into the main program, or at least report the bug.

> I've actually been (local only) updating my mini distro's disk #3, and a
> good deal of stuff on there is (funnily enough) for compatibility or bug
> fixes with other DOS-ish OSes.

Isn't it a FreeDOS distro? Or is it supposed to allow exchanging the kernel?

---
l

> I'm pretty sure this guy is only interested in modern Windows these days.

Modern Windows, yes, for the last decade. Whenever a write-up of a Windows shell function goes as far as doing a bug history, I still cover all the 32-bit Windows versions that run on DOS, but that's it for my involvement even with the old Windows, let alone with DOS.

> Hence, I blindly guess he's never even tried DR-DOS (and probably doesn't
> know how good / compatible it is) or others.

Never tried, never knew, and never saw that supporting it should be a DOS programmer's general responsibility no matter how good it might be. And I kept to the latter view even while helping Caldera's anti-trust suit.

> 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