DOS ain't dead

I'm making a patch for a certain bug in MS-DOS 7+ (Windows 9x/ME) available for tests/comments.

This new thread intended for questions/answers/comments/announces regarding the patch (unless the forum's Host objects)

New version 0.7(beta) uploaded!
Download from: HK31.SYS (beta 0.7) ,alternate : HK31.SYS (0.7 beta)
File details: hk31.sys, 703 bytes, MD5: 726AC3CB965872ECDF94212C19D1D265

changes from 0.6:
Version check enhanced, using int 2F/AX=4A33 (see Ralf's interrupt list; beware, Ralf's description not completely accurate). Hopefully this test positively identifies MS DOS 7 (also 8 ?) versus /any/ non-MS DOSes ! Please test & report

What is that thing ?

It implements a fix (or call it a work around) for a long standing bug in the DOS of Windows 9x/ME. Please refer to the earlier announcement in the Misc. section of this forum, which has detailed setting instructions :
new patch for MS-DOS 7 bug

Reminder : this is a free (but "copyrighted") public "beta". Although it is believed to be harmless and tested at home on different configurations of MSDOS 6/7/8, you should take the usual precautions before trying this software. Refer to these setting instructions.


Please! report test results and any problems or questions about this tool in this discussion thread.

---
Ninho

New version 0.8(beta) available :
HK31.SYS (beta 0.8)
Alternate : HK31.SYS (0.8 beta)

File details: hk31.sys, 733 bytes, MD5: 73362CE25F8FFE24D1773F24DD9B0F7E

Changes from 0.7:
Even better Version check, thanks CM ! Should outsmart those DOS clones which try to pass as MS-DOS 7.

This could be the last beta. I still need you to test run it on as many different DOS versions and configurations as possible. Come on guys, do test and report ASAP.

---
Ninho

New version 0.9(beta) available = release candidate :
HK31.SYS (0.9 beta)
Alternate link : HK31.SYS (0.9 beta)

File details: hk31.sys, 749 bytes, MD5: 9882BE54F2B2D97EE49B50B4F733C3CE

Changes from 0.8:
Upgraded check for genuine MS-DOS would fail in MS-DOS 8 (Windows ME). Fixed.

Please delete any older versions, download and test this release candidate as wildly as your fancy goes.
If no problem surfaces nor any sensible new feature suggestion is received this will be the last "beta" before 1.0 "stable" distribution.

Thx

--
Ninho

Download link doesn't work; file seems not to exist. Also, what exactly failed?

---
l

> Download link doesn't work; file seems not to exist.

It's working OK now; plus I have added the alternate download address.

> Also, what exactly failed?

The offset of the "DriveSpace patch" routine within the MS-DOS DATA Seg changed in MS-DOS 8 vs. MS-DOS 7.

---
Ninho

Hi, Guys ! Gals (any ?)...

This beta looks - to me - like it's working as designed

I've tested it under MS-DOS 3,5,6,7,8, and DR-DOS 7.01,
ROMDOS 7.10, PTDOS 32, FreeDOS 7.10, with expected behaviour, not
to forget LZDOS which is really MS-DOS 7.10 in disguise and happily
loads the patch ;=)

Next will come HACKWRAP.SYS 1.0 stable , with friendlier
messages and NO more nagging to "Press a key..."

However it's been a disappointment to receive such meager feedback from the forum regulars Maybe the majority doesn't care for "better software" any more or just can't be bothered to make a few simple tests when asked for help?

Thanks to CM who contributed useful ideas.

Come on, it is time still to help testing the last beta :
HK31.SYS beta 0.9
try as many odd DOSes and configurations as you can and see if it breaks in any.

Meanwhile holding the Release.

---
Ninho

> and NO more nagging to "Press a key..."
>
> However it's been a disappointment to receive such meager feedback from
> the forum regulars Maybe the majority doesn't care for "better
> software" any more or just can't be bothered to make a few simple tests
> when asked for help?

Maybe some other people are just as lazy as I am; therefore they can't be bothered to test a closed-source program with shareware-alike nagging for you. As long as you release programs in the forum only, you might at least remove the nagging: everyone here should know what he's doing if he uses some program exclusively announced here which is labelled as beta.

---
l

>> and NO more nagging to "Press a key..."

> As long as you release programs in the forum only, you might at least
> remove the nagging: everyone here should know what he's doing if he uses
> some program exclusively announced here which is labelled as beta.

Except it is *not* a nag (I used the term jokingly). It pauses to give the user a chance to actually *examine* the program's output. You should know of all people since you ran it - at least I suppose you ran it.

---
Ninho

> However it's been a disappointment to receive such meager feedback from
> the forum regulars Maybe the majority doesn't care for "better
> software" any more or just can't be bothered to make a few simple tests
> when asked for help?

It's simple: AFAIU your program is only useful in conjunction with wrapper.sys and MS-DOS 7. I neither own wrapper.sys nor intend to buy it, so I take no part in this and prefer to remain silent.

---
MS-DOS forever!

Hi Japheth

I didn't have you or anyone in particular in mind, but thanks for standing up.
First be it stated, I never requested or hoped everyone would interrupt their current activities on this test. Still :

>> ... it's been a disappointment to receive such meager feedback from

> It's simple: AFAIU your program is only useful in conjunction with
> wrapper.sys and MS-DOS 7.

A misconception. The program was deliberately conceived to work around the MS DOS bug and *not* depend on wrapper.sys, or any third party. I thought I made this point clear. You don't need to buy or even try wrapper.sys [albeit a free trial, as I said, and recommended] in order to do the simple checks I begged from the audience.

> I neither own wrapper.sys nor intend to buy it,
> so I take no part in this and prefer to remain silent.

Understandable, but it is just bringing water to my mill as we say in French.
This forum may not have been quite the friendly place for sharing DOS knowledge I had imagined. Never mind, you (I mean, you all, the lurkers) are still welcome to comment on the program and I'll release it soon to a more public channel. Not that I expect millions of users, considering how it's received here :=)

Thanks again for explaining your reasons

---
Ninho

> You should
> know of all people since you ran it - at least I suppose you ran it.

I ran it in a debugger on another DOS version, but I suppose that doesn't count. I still know what its output looks like, though. At least on my MS-DOS configuration, I can still read all output from CONFIG.SYS as soon as the shell's prompt is displayed. If that's not possible, load {shell} /C PAUSE or better yet a debugger using WRAPPER.SYS

---
l

> >> However it's been a disappointment to receive such meager feedback
> from
>
> > It's simple: AFAIU your program is only useful in conjunction with
> > wrapper.sys and MS-DOS 7.
>
> A misconception. The program was deliberately conceived to work around the
> MS DOS bug and *not* depend on wrapper.sys, or any third party. You don't
> need to buy or even try wrapper.sys in order to do the simple checks I
> begged (from the audience in general).
>
> > I neither own wrapper.sys nor intend to buy it,
> > so I take no part in this and prefer to remain silent.
>
> Understandable, but it is just bringing water to my mill as we say in
> French.

(bad joke)

"Get the mill key! (Hidden behind standard, shoot it once you get to the armory's hidden door, grind bones, get potion, open mithril door, get castle key)"

(been playing Hammer of Thyrion / Hexen2 demo lately, heh, fun but confusing)

> This forum may not have been quite the friendly place for sharing DOS
> knowledge I had imagined. Never mind, you (I mean, you all, the lurkers)
> are still welcome to comment on the program and I'll release it soon to a
> more public channel. Not that I expect millions of users, considering how
> it's received here :=)

There aren't that many users (apparently 72), most being inactive, and a few blabbermouths to make the forum seem ultra active. To be fair, we're just busy, lazy, or confused! The hack seemed fairly MS-DOS 7 specific, hence we blindly assumed you would test on that and be done with it.

However, if you want me to test to make sure the version check isn't broken, all I've really got is DR-DOS 7.03, MS-DOS 6.22, latest FreeDOS WIP, and an old MS-DOS 7 bootdisk (which I never use). I don't anticipate anything different from your results, though.

>>>> However it's been a disappointment to receive such meager feedback

Or I was feeling alone in this thread, or just being grumpy

> (been playing Hammer of Thyrion / Hexen2 demo lately, heh, fun but
> confusing)

I've heard playing computer games can lead to mental disorders indeed

>> This forum may not have been quite the friendly place for sharing DOS
>> knowledge I had imagined. Never mind, you (I mean, you all, the lurkers)
>> are still welcome to comment on the program and I'll release it soon to a
>> more public channel. Not that I expect millions ...

> There aren't that many users (apparently 72), most being inactive, and a
> few blabbermouths to make the forum seem ultra active. To be fair,
> we're just busy, lazy, or confused! The hack seemed fairly MS-DOS 7
> specific, hence we blindly assumed you would test on that and be done with
> it.

This is probably all I would have done, until CM started me on the urgency of proper testing for all DOS look-alike, past present and forecoming.

> However, if you want me to test to make sure the version check isn't
> broken, all I've really got is DR-DOS 7.03, MS-DOS 6.22, latest FreeDOS
> WIP, and an old MS-DOS 7 bootdisk (which I never use). I don't anticipate
> anything different from your results, though.

Neither do I. More testing never hurts anyway, there is a tendency for bugs to reveal themselves just after the final packaging.

Cheers...

---
Ninho

> >>>> However it's been a disappointment to receive such meager feedback
>
> Or I was feeling alone in this thread, or just being grumpy

It's very noble to patch bugs that are never fixed, but it's a lonely job!

> > (been playing Hammer of Thyrion / Hexen2 demo lately, heh, fun but
> > confusing)
>
> I've heard playing computer games can lead to mental disorders indeed

http://www.engadget.com/2007/03/12/duke-nukem-like-video-game-to-help-measure-depression/

> > The hack seemed fairly MS-DOS 7 specific, hence we blindly
> > assumed you would test on that and be done with it.
>
> This is probably all I would have done, until CM started me on the urgency
> of proper testing for all DOS look-alike, past present and forecoming.
>
> > However, if you want me to test to make sure the version check isn't
> > broken, all I've really got is DR-DOS 7.03, MS-DOS 6.22, latest FreeDOS
> > WIP, and an old MS-DOS 7 bootdisk (which I never use). I don't
> anticipate
> > anything different from your results, though.
>
> Neither do I. More testing never hurts anyway, there is a tendency for
> bugs to reveal themselves just after the final packaging.

"*non* installed" on everything except the MS-DOS 7 (pre-OSR2??) bootdisk. And even there I didn't test wrapper (should I? with what??).

Ninho -

> However it's been a disappointment to receive such meager feedback from
> the forum regulars Maybe the majority doesn't care for "better
> software" any more or just can't be bothered to make a few simple tests
> when asked for help?

Hey. Thanks for your work. Anything to patch bugs in the "original" O/S is worthwhile i think!

Two questions:

1) Later tonite, i can test IBM PC-DOS 7.1 (the 2003 update with FAT32 support) and IBM PC-DOS 2000 (actually, just the 7.0 from 1998 with Y2K fixes -- no FAT32 support). This might be useful, as IBM PC-DOS must be *very* close to M$ MS-DOS, having diverged, IIRC, at 6.0. Still, they must share much of the same coding -- i can't imagine that IBM would do a total re-write.

2) Other than WRAPPER.SYS, what is the patch useful for? Or maybe i should ask, other than WRAPPER, what does the "bug" mess up?

- Doug

Nice to meet you, Doug

> Two questions:
And very good ones at that

> 1) Later tonite, i can test IBM PC-DOS 7.1 (the 2003 update with FAT32
> support)

please do ! I suspect HK31 won't install

and IBM PC-DOS 2000 (actually, just the 7.0 from 1998 with Y2K
> fixes -- no FAT32 support).

actually I tested on that one. Won't install the hack.

This might be useful, as IBM PC-DOS must be
> *very* close to M$ MS-DOS, having diverged, IIRC, at 6.0. Still, they
> must share much of the same coding -- i can't imagine that IBM would do a
> total re-write.

Of course their source is derived from Microsoft's and partly kept in sync. However quickly peeking at the DOS DATA segment while I was trying to run my hack showed significant differences in the layout. Is PC-DOS 7 supposed to be able to run Windows 9x anyway ? I have not researched whether it maintains a table of loaded TSRs nor whether the MS bug is present. You might be able to help in this respect.

> 2) Other than WRAPPER.SYS, what is the patch useful for? Or maybe i
> should ask, other than WRAPPER, what does the "bug" mess up?

Besides breaking WRAPPER, it broke Geoff Chappell's original CRTDRVR library,for one. Other than those two, I'm not aware of other, commercially or otherwise available, applications that need the patch. The patch is *potentially* needed for any WRAPPER-like driver that is unaware of the "bug".
For instance I hacked MS DEBUG way back (DOS 3.21 times) to be able to launch it as a driver. With my hack, I can now launch TSRs from the modified Debug without crashing the system

Granted, this patch is basically a specialty thing, the main purpose of which will be to use Wrapper in MS-DOS 7.

---
Ninho

> It's very noble to patch bugs that are never fixed, but it's a lonely
> job!

Sure, but sharing the results makes it feel less lonely. I've made too many solitary patches in the past years many of which are nowadays useless.


>>> However, if you want me to test to make sure the version check isn't
>>> broken, all I've really got is DR-DOS 7.03, MS-DOS 6.22, latest FreeDOS
>>> WIP, and an old MS-DOS 7 bootdisk (which I never use).

>> Neither do I. More testing never hurts anyway, there is a tendency for
>> bugs to reveal themselves just after the final packaging.

> "*non* installed" on everything except the MS-DOS 7 (pre-OSR2??) bootdisk.

Just as expected Thx!

> And even there I didn't test wrapper (should I? with what??).

No obligation. But if you wish to try Wrapper, by itself or (under MSDOS 7) with HK31, you would typically want to test it with mouse or keyboard drivers (of the com/exe variety, not DOS device drivers). In fact it could be especially interesting for /you/ to see if Wrapper.sys works on the FreeDOS - considering FreeDOS did not even exist when wrapper was last updated (or did it ? I haven't checked the historic records)

---
Ninho

> This is probably all I would have done, until CM started me on the urgency
> of proper testing for all DOS look-alike, past present and forecoming.

You don't have to test for all DOS versions (especially not the forecoming ones), you just should test for the DOS version that you want.

---
l

> Of course their source is derived from Microsoft's and partly kept in
> sync. However quickly peeking at the DOS DATA segment while I was trying
> to run my hack showed significant differences in the layout. Is PC-DOS 7
> supposed to be able to run Windows 9x anyway ? I have not researched
> whether it maintains a table of loaded TSRs nor whether the MS bug is
> present. You might be able to help in this respect.

PC-DOS doesn't support Windows 4.x (or Windows doesn't support PC-DOS?). AFAIK even the PC-DOS 6 distribution was different from MS-DOS, so maybe they didn't sync version 7 either.

> For instance I hacked MS DEBUG way back (DOS 3.21 times) to be able to
> launch it as a driver.

Is that, like, a necessity for DOS programmers? I did that (independantly!) a year after learning to program. I thought no one else would ever have such a great idea. Silly me!

---
l

Is PC-DOS 7
>> supposed to be able to run Windows 9x anyway ?

> PC-DOS doesn't support Windows 4.x (or Windows doesn't support PC-DOS?).
> AFAIK even the PC-DOS 6 distribution was different from MS-DOS, so maybe
> they didn't sync version 7 either.

You're corroborating my findings, both experimental and wikipedian. PC-DOS shouldn't need the hack.

>> For instance I hacked MS DEBUG way back (DOS 3.21 times) to be able to
>> launch it as a driver.

> Is that, like, a necessity for DOS programmers? I did that
> (independantly!) a year after learning to program. I thought no one else
> would ever have such a great idea. Silly me!

Yes I suppose it was kind of a necessary passing rite for likely minded people. I then found it a necessity to hack the DOS from beneath itself, which was facilitated once I noticed that my industrial AT look alike (one of the rare clones made with IBM's *approval* in the mid 80's) featured a mini debugger built in to the BIOS (instead of the useless "ROM Basic" or press a key to reboot...) that for instance allowed to interrupt the system any time without paying respect to the so-called "IN-DOS" flag.

But that was soon not enough to satisfy my debugging appetites, especially when I started building a 80286-protected mode monitor. My next hack was a NMI switch, efficient although a primitive design, made out of a trombone-shaped desktop clip inserted into the rear of an available ISA slot - of course my machines ran top-less ;=) Real men don't need no damping resistors nor debouncing circuits (don't do that with nowadays' motherboards!)

---
Ninho

Ninho -

Ok. Tried HK31.SYS 0.9 under IBM PC-DOS 7.1 -- as you suspected, it did not load.

Also tried WRAPPER.SYS with a mouse driver -- loaded ok, worked ok in a program i tried, but i didn't do extensive work with it, as i had to boot the OS off diskette (not my normal configuration).

So i guess that PC-DOS 7.x does not have the "bug". Curious, being so close to MS-DOS....

- Doug

P.S. Interestingly, it seems that WRAPPER cannot be used to load a driver if the system needs the LASTDRIVE command to be used. In my system, i have three logical hard drives (C: D: E:), a CD drive (F:), and a DVD drive (G:). When i tried loading a CD/DVD redirector (MSCDEX or SHSUCDX) with WRAPPER, each complained that there were not enough drive letters available. They loaded fine using an INSTALL command and a LASTDRIVE=G: line... but not with WRAPPER, even with a LASTDRIVE=G: line. By doing a step-by-step boot, at least in PC 7.1, LASTDRIVE is executed after all the DEVICE commands and before the INSTALL commands, so WRAPPER must load whatever driver using the default LASTDRIVE setting.

> Ok. Tried HK31.SYS 0.9 under IBM PC-DOS 7.1 -- as you suspected, it did
> not load.
>
> So i guess that PC-DOS 7.x does not have the "bug". Curious, being so
> close to MS-DOS....

It's not that curious, AFAICT, since MS and IBM both worked together originally with PC-/MS-DOS and later OS/2 (where both parties had full sources to Win 3.0 and MS-DOS 5), but nothing after the "divorce" (circa 1991). This is why OS/2 can run Win16 and DOS binaries but not Win32. Also why early WinNT (3.1?) supported HPFS with even Win2k ("NT 5") the last to support some OS/2 1.x 16-bit apps. And probably one of the main reasons OS/2 will never be open sourced (MS code, patents, lack of hardware driver support, still sold, etc).

So no, I wouldn't imagine anybody could easily run Win9x on top of other DOSes although MS did admit that there was no technical reason it couldn't be done (pure marketing strategy only). DR-DOS guys never did release their "working" keyboard hack to let Win9x run on theirs. (Of course, why anybody would actually want to run it atop other DOSes is fairly obscure, but hey, why not? No worse than running Win31 inside DOSBox!)

> P.S. Interestingly, it seems that WRAPPER cannot be used to load a driver
> if the system needs the LASTDRIVE command to be used.

Hmmm... in general, for real /block devices/ I don't think there is a problem. UIAM, the LASTDRIVE command is processed by MS-DOS to build the System File Tables /before/ processing installable device drivers. Note: MS/PC-DOS make several passes of the Config.sys (3 in total, I think), you should not believe they haven't "seen" the lastdrive=... line before they present it to you!

But the CD (and DVD) drivers are special devices which don't fit well in the old DOS driver model, being treated as network drives, hence each of these devices need both a /character/ mode driver specific to the device model and the MSCDEX or compatible redirector. The latter, not the CD/DVD driver proper, is what creates/rearranges/messes with SFTs & drive letters as needed to provide the illusion of a block mode device.

> In my system, i
> have three logical hard drives (C: D: E:), a CD drive (F:), and a DVD
> drive (G:). When i tried loading a CD/DVD redirector (MSCDEX or SHSUCDX)
> with WRAPPER, each complained that there were not enough drive letters
> available. They loaded fine using an INSTALL command and a LASTDRIVE=G:
> line... but not with WRAPPER, even with a LASTDRIVE=G: line. By doing a
> step-by-step boot, at least in PC 7.1, LASTDRIVE is executed after all the
> DEVICE commands and before the INSTALL commands, so WRAPPER must load
> whatever driver using the default LASTDRIVE setting.

Interesting indeed. Does it work with LASTDRIVE=Z ?

A question of mere academic interest anyway, I can't see whatsoever could be gained by loading the MSCDEX with WRAPPER.

--
Ninho

> > P.S. Interestingly, it seems that WRAPPER cannot be used to load a
> driver
> > if the system needs the LASTDRIVE command to be used.
>
> Hmmm... in general, for real /block devices/ I don't think there is a
> problem. UIAM, the LASTDRIVE command is processed by MS-DOS to build the
> System File Tables /before/ processing installable device drivers. Note:
> MS/PC-DOS make several passes of the Config.sys (3 in total, I think), you
> should not believe they haven't "seen" the lastdrive=... line before they
> present it to you!

DEVICE= lines are processed in the last or second-to-last pass; the FILES= and LASTDRIVE= lines have been recorded then. However, LASTDRIVE= doesn't affect System File Tables (SFTs). As their name implies SFTs are allocated for opened files, therefore the FILES= line is responsible for the (total) number of (regular) SFTs in the system. LASTDRIVE= instead sets the number of Current Directory Structure (CDS) entries. The CDS therefore is an array of LASTDRIVE entries. A DOS drive letter (or the DOS drive number) is an index into the CDS array. All drives such as "local" (FAT) drives, SUBST links, JOINed "local" drives and "network redirector" drives require CDS entries.

The recorded LASTDRIVE= value seems to be used only between processing DEVICE= and INSTALL= lines (i.e. after drivers are loaded). Before that, DOS probably creates a CDS just large enough to hold entries for all "local" drives installed yet. Previously I thought DOS would create a CDS with 32 entries (the maximum) initially and would cut that down later; however it could've assumed all drives to be "local" during DEVICE= processing. So the actual behaviour is better than I thought, because SHSUCDX already aborts before installing its drives.

> But the CD (and DVD) drivers are special devices which don't fit well in
> the old DOS driver model, being treated as network drives, hence each of
> these devices need both a /character/ mode driver specific to the device
> model and the MSCDEX or compatible redirector.

No they don't. The requirement of character devices is imposed by MSCDEX's design. Redirected drives don't need DOS devices.

> The latter, not the CD/DVD
> driver proper, is what creates/rearranges/messes with SFTs & drive
> letters as needed to provide the illusion of a block mode device.

There's no such illusion. The drive appears to the user the same, but below the DOS API (Int21) "network" and "local" drives are handled completely differently. They both use SFTs and CDS entries but the content of a "network" and "local" SFT/CDS is mostly different. (It might be worth to note that the different content of the "network" structures is defined by the redirector and completely ignored by DOS.)

> A question of mere academic interest anyway, I can't see whatsoever could
> be gained by loading the MSCDEX with WRAPPER.

What about loading device drivers from the CD? This would be especially useful for a boot CD. Of course most device drivers can now be loaded either by DEVLOAD or by updating them to load as executable too, but these related to low memory management can't without dropping DOS's UMA/HMA initialization. (Linking UMBs to DOS's chain (DOS=UMB) yourself isn't difficult, but relocating the DOS code segment to the HMA (DOS=HIGH) requires knowledge of DOS's exact behaviour and code, which probably changed with every version.)

---
l

>>> P.S. Interestingly, it seems that WRAPPER cannot be used to load a driver
>>> if the system needs the LASTDRIVE command to be used.

>> Hmmm... in general, for real /block devices/ I don't think there is a
>> problem. UIAM, the LASTDRIVE command is processed by MS-DOS to build the
>> System File Tables

> DEVICE= lines are processed in the last or second-to-last pass; the FILES=
> and LASTDRIVE= lines have been recorded then. However, LASTDRIVE= doesn't
> affect System File Tables (SFTs). As their name implies SFTs are allocated
> for opened files, therefore the FILES= line is responsible for the (total)
> number of (regular) SFTs in the system. LASTDRIVE= instead sets the number
> of Current Directory Structure (CDS) entries. The CDS therefore is an array
> of LASTDRIVE entries.

Right CM, I stand corrected. I really meant CDS entries, not SFTs :(
As we (should) know, and you correctly recall :

> A DOS drive letter (or the DOS drive number) is an
> index into the CDS array. All drives such as "local" (FAT) drives, SUBST
> links, JOINed "local" drives and "network redirector" drives require CDS
> entries.

Now I'll also trust you about the ff. observations

> The recorded LASTDRIVE= value seems to be used only between processing
> DEVICE= and INSTALL= lines (i.e. after drivers are loaded). Before that,
> DOS probably creates a CDS just large enough to hold entries for all
> "local" drives installed yet. Previously I thought DOS would create a CDS
> with 32 entries (the maximum) initially and would cut that down later;
> however it could've assumed all drives to be "local" during DEVICE=
> processing. So the actual behaviour is better than I thought, because
> SHSUCDX already aborts before installing its drives.

As far as that

>> But the CD (and DVD) drivers are special devices which don't fit well in
>> the old DOS driver model, being treated as network drives, hence each of
>> these devices need both a /character/ mode driver specific to the device
>> model and the MSCDEX or compatible redirector.

> No they don't. The requirement of character devices is imposed by MSCDEX's
> design.

Rather, by the fact that using a classical DOS block device driver requires rather rigid structures, including a DPB which in turn assumes the existence of a FAT, all of which can't be applied to CD volumes.

> Redirected drives don't need DOS devices.

I didn't say they did!

>> The latter, not the CD/DVD
>> driver proper, is what creates/rearranges/messes with SFTs & drive
>> letters as needed to provide the illusion of a block mode device.

> There's no such illusion. The drive appears to the user the same, but
> below the DOS API (Int21) "network" and "local" drives are handled
> completely differently. They both use SFTs and CDS entries but the content
> of a "network" and "local" SFT/CDS is mostly different. ...

So, the MS network redirector dressing of network drives, or CD-ROMS etc, as if they were local FAT units, is the <<illusion>>.

>> A question of mere academic interest anyway, I can't see whatsoever could
>> be gained by loading the MSCDEX with WRAPPER.

> What about loading device drivers from the CD? This would be especially
> useful for a boot CD.

Yes, good point. Unfortunately then, it seems it won't work.

> Of course most device drivers can now be loaded
> either by DEVLOAD or by updating them to load as executable too

But probably not the CD-ROM drivers :( Have you ever heard of one that could be devloaded ? A possibly interesting research subject.

> but these
> related to low memory management can't without dropping DOS's UMA/HMA
> initialization. (Linking UMBs to DOS's chain (DOS=UMB) yourself isn't
> difficult, but relocating the DOS code segment to the HMA (DOS=HIGH)
> requires knowledge of DOS's exact behaviour and code, which probably
> changed with every version.)

Internal MS-DOS UMA and HMA management did not change from DOS 5 until DOS 8 AFAIK.

---
Ninho

> Rather, by the fact that using a classical DOS block device driver
> requires rather rigid structures, including a DPB which in turn assumes
> the existence of a FAT, all of which can't be applied to CD volumes.

Exactly.

> > Redirected drives don't need DOS devices.
>
> I didn't say they did!

> >> But the CD (and DVD) drivers are special devices which don't fit well
> >> in the old DOS driver model, being treated as network drives, hence
> >> each of these devices need both a /character/ mode driver specific to
> >> the device model and the MSCDEX or compatible redirector.

Sorry. It sounded that way too me.

> So, the MS network redirector dressing of network drives, or CD-ROMS etc,
> as if they were local FAT units, is the illusion.

You forget that at this level (Int21 and up) there's no knowledge about the concept of block devices anymore. You're right now, stating that the native and the redirected drives look the same there. Previously you said "the illusion of a block mode device". This however doesn't make much sense to a user who doesn't know what a block device is.

> > Of course most device drivers can now be loaded
> > either by DEVLOAD or by updating them to load as executable too
>
> But probably not the CD-ROM drivers :( Have you ever heard of one that
> could be devloaded ? A possibly interesting research subject.

I didn't have any issues loading a CD-ROM device driver with DEVLOAD, then MSCDEX or SHSUCDX. It wouldn't make sense to have issues there. In DOS terms the CD-ROM device drivers are very simple: a proper name, allow IOCTL Read/Write and that's it.

> Internal MS-DOS UMA and HMA management did not change from DOS 5 until DOS
> 8 AFAIK.

Seems to be true for the UMA management (as mentioned), but the HMA management requires you to know where and how DOS fixes up entry points as well as the size of the DOS code segment, or even more. At least the code segment's size changed between most or all of the versions from MS-DOS 5.

---
l

> I'm making a patch for a certain bug in MS-DOS 7+ (Windows 9x/ME) available

Please no replies below, creating new thread instead !

Thanks for the great feedback, at last ;=)

---
Ninho