Back to home page

DOS ain't dead

Forum index page

Log in | Register

Back to index page
Thread view  Board view
Ninho(R)

E-mail

18.11.2009, 20:41
 

Phil Gardner's Wrapper.sys & MS-DOS7 bug (Miscellaneous)

Hi, Dinos! Anybody remembers Phil Gardner's excellent wrapper that enabled (quoting the DOC file)

... the loading of programs in
the CONFIG.SYS file as devices. The program may be a Terminate-and-
Stay Resident utility (TSR) or a program which simply executes but does
not stay resident.

(quoting ends.)

Excellent program (used to be try-before-buy shareware). Unfortunately it mostly stopped working ° starting with MS-DOS 7 (Win 9x). I remember studying the problem in the late 90s and came to the conclusion that MS DOS 7 introduced a bug whereby int 21 AH=31 (or int 27h which is the same code) when attempted during config.sys DEVICE installation trashes essential DOS memory because an uninitialised pointer (still = 0:0) is used erroneously.

I long thought I was the only one on earth to be aware of the bug (smile) - but of course others found and analysed it better than I ever did (yesterday while browing I found a Geoff Chappel page (spell?) about the bug in question and how he worked around it in his own programs).

Of course not having the wrapper.sys source makes the task very difficult of implementing a similar work around. This is the kind of things I might have attempted when younger... oh the joys of getting old.

Well, this makes me ask : does anyone have a version of wrapper.sys hacked around the MS-DOS 7+ bug ? Or have written an original new 'wrapper' with functionality equivalent to Phil's ? When I sought a few months ago I found Mr Gardner is now some kind of executive, or is he a president, at some Canadian software company, probably not interested in his old DOS shareware any more, in any case an email I sent to his company contact remained unanswered, either lost or trashed. :=(

Sorry for the rambling. Thought I'd ask the question here.


° Note : Only DOS programs that terminate and stay resident are affected by the M$ bug. Ordinary, transient DOS programs can still be launched by Wrapper.

---
Ninho

Rugxulo(R)

Homepage

Usono,
18.11.2009, 23:00

@ Ninho
 

Phil Gardner's Wrapper.sys & MS-DOS7 bug

> Hi, Dinos! Anybody remembers Phil Gardner's excellent wrapper that enabled
> (quoting the DOC file)
>
> ... the loading of programs in
> the CONFIG.SYS file as devices. The program may be a Terminate-and-
> Stay Resident utility (TSR) or a program which simply executes but does
> not stay resident.
>
> (quoting ends.)

Never heard of it. Dated 1992, for any "MS-DOS 3.1 or newer". So this was before INSTALL/INSTALLHIGH? (DOS 5+)

"WRAPPER.SYS v1.0 16-bit DOS TSR for MS-DOS 5/6 + Windows 9x/ME [17 KB, no nag shareware] loads almost ANY program/TSR as DEVICE(HIGH) from CONFIG.SYS.
Useful for saving low DOS RAM (upper memory manager required in CONFIG.SYS)."

> Well, this makes me ask : does anyone have a version of wrapper.sys hacked
> around the MS-DOS 7+ bug ? Or have written an original new 'wrapper' with
> functionality equivalent to Phil's ?

Sadly, no, and I'm not entirely sure I understand the usefulness (more conventional memory free??). I imagine others (ahem, Japheth) will know more.

Ninho(R)

E-mail

18.11.2009, 23:30
(edited by Ninho, 18.11.2009, 23:41)

@ Rugxulo
 

Phil Gardner's Wrapper.sys & MS-DOS7 bug

> Sadly, no, and I'm not entirely sure I understand the usefulness (more
> conventional memory free??).

It could be in some cases. More importantly, MSDOS loads and initialises all DEVICE(high) before processing any INSTALL(high) no matter how you try to arrange the CONFIG.SYS lines. This limitation, which did not exist in DRDOS IIRC, is what made wrapper.sys so useful in many instances. Not to mention more esoteric uses, like launching a command interpreter and/or a debugger in the midst of DOS device driver installation ! Don't know about you and where you have been, let it be said that being some old hacker who modified numerous programs [ including an old version of Microsoft "debug" ca 1985] to turn them into fake device drivers, and debugged a few DOS versions of IO.SYS/ MSDOS.SYS too, I did love wrapper.sys the very moment I got it on a 1200 bps modem.

---
Ninho

Khusraw(R)

E-mail

Bucharest, Romania,
19.11.2009, 07:18

@ Ninho
 

Phil Gardner's Wrapper.sys & MS-DOS7 bug

> Of course not having the wrapper.sys source makes the task very difficult
> of implementing a similar work around. This is the kind of things I might
> have attempted when younger... oh the joys of getting old.

Obtaining an intelligible and re-assemblable disassembly from a sys file is an easy task with the disassemblers available (try IDA Pro 4.9 Freeware, searching the net you can find freeware DOS based older versions too, which are more than enough for the task).

Ninho(R)

E-mail

19.11.2009, 11:32

@ Khusraw
 

Phil Gardner's Wrapper.sys & MS-DOS7 bug

> Obtaining an intelligible and re-assemblable disassembly from a sys file
> is an easy task with the disassemblers available (try
> IDA Pro 4.9
> Freeware, searching the net you can find freeware DOS based older
> versions too, which are more than enough for the task).

BTDT :=) An old IDA even possibly remaining somewhere on an dusty hard disk.
As I implied though, I'm passed the age of spending days (and nights) chasing the bits. Posted here in case somebody felt motivated - or was aware of new versions or what can I imagine... I don't do public usenet newsgroups anymore, maybe someone could follow up to the MSDOS groups there, maybe this has been discussed already (though Google found nothing for me), maybe Phil Gardner would notice and care even ?

Anyway... thought this can be a motivating project for someone still enthusiastic over DOS programming, such as may roam the forums here ;=)

---
Ninho

Khusraw(R)

E-mail

Bucharest, Romania,
19.11.2009, 12:54
(edited by Khusraw, 19.11.2009, 13:46)

@ Ninho
 

Phil Gardner's Wrapper.sys & MS-DOS7 bug

> Anyway... thought this can be a motivating project for someone still
> enthusiastic over DOS programming, such as may roam the forums here ;=)

For someone who has both interest in using with MS-DOS 7 such a wrapper and enough knowledge about the problem and its solution, patching the already existing wrapper.sys' code would be a relatively trivial task, not a question of nights and days.
Anyway, I don't see any link. Where is Geoff Chappel's page about the MS-DOS 7 bug and his working around?

Khusraw(R)

E-mail

Bucharest, Romania,
19.11.2009, 16:29
(edited by Khusraw, 19.11.2009, 17:19)

@ Ninho
 

Phil Gardner's Wrapper.sys & MS-DOS7 bug

I have found myself Geoff Chappell's page and I looked on wrapper.sys' code. 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).

Ninho(R)

E-mail

19.11.2009, 18:22

@ Khusraw
 

Phil Gardner's Wrapper.sys & MS-DOS7 bug

> 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

cm(R)

Homepage E-mail

Düsseldorf, Germany,
19.11.2009, 18:52

@ Ninho
 

Phil Gardner's Wrapper.sys & MS-DOS7 bug

> 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 ;=)

You'd either have to actually patch DOS (i.e. modify its code), or hook Int21 and take over anything DOS does when terminating a PSP TSR. Both requires knowledge about DOS's internal operation, although I'd prefer the second method because that depends less on DOS's code.

If you adapt either of these methods or the one presented by Geoff Chappel, please replace his version check by something dependable (such as exact kernel code pieces if you're going to patch code anyway). Other DOS versions report "true version" (Int21.3306) 7.00+ now too (because many programs depend on that to check for other things such as FAT32 support) but they probably don't support the TSR list pointer in the DOS data segment. The presented CRT's initialization code depends on this pointer (with a fixed offset) if the reported true version is 7.00 or higher.

---
l

Ninho(R)

E-mail

20.11.2009, 12:27

@ cm
 

Phil Gardner's Wrapper.sys & MS-DOS7 bug

> You'd either have to actually patch DOS (i.e. modify its code), or hook
> Int21 and take over anything DOS does when terminating a PSP TSR. Both
> requires knowledge about DOS's internal operation, although I'd prefer the
> second method because that depends less on DOS's code.
>
> If you adapt either of these methods or the one presented by Geoff
> Chappel, please replace his version check by something dependable (such as
> exact kernel code pieces if you're going to patch code anyway). Other DOS
> versions report "true version" (Int21.3306) 7.00+ now too (because many
> programs depend on that to check for other things such as FAT32 support)
> but they probably don't support the TSR list pointer in the DOS data
> segment. The presented CRT's initialization code depends on this pointer
> (with a fixed offset) if the reported true version is 7.00 or higher.

Good points, thanks. The version checking issue is real but IMO cosmetic. If I were to undertake something around that bug, I think I would not try to update Gardner's driver for obvious ethical and legal reasons. OTOH redoing a comparable program in the clean room is much work considering the lack of people's interest for DOS nowadays. Repairing DOS could be a better option and a reusable one. However distributing a patch for MS-DOS as such would present more legal (not ethical!) problems.

Anyhoo... I don't even know why I even go into these considerations. I would gladly use one if I had it, but there are close to 0% chances I'll ever let me involved in this programming. The choleric personality over there is right, I must be lazy.

Cheers

---
Ninho

Khusraw(R)

E-mail

Bucharest, Romania,
20.11.2009, 12:56

@ Ninho
 

Phil Gardner's Wrapper.sys & MS-DOS7 bug

> Repairing DOS could be a better option and a reusable one. However
> distributing a patch for MS-DOS as such would present more legal
> (not ethical!) problems.

A couple of years ago I red an interview with a former MS employee (I am sorry, I can't remember his name) who was involved with MS-DOS. He said we should never forget that MS is a business, and like in case of any other business what principally matters is the cost vs. profit ballance. So the source code looks awful and they left unfixed known bugs, because cleaning the source code and fixing those bugs would have meant more costs in comparison with the profits that would have been obtained. This is why MS doesn't publicly release the source code of MS-DOS, not because they have some precious secrets but because they would be strongly ashamed by the mess there.

> The choleric personality over there...

I am rather melancholic-choleric, not choleric type. Believe me, I know myself better.

Rugxulo(R)

Homepage

Usono,
22.11.2009, 01:08

@ Khusraw
 

Phil Gardner's Wrapper.sys & MS-DOS7 bug

> > Repairing DOS could be a better option and a reusable one. However
> > distributing a patch for MS-DOS as such would present more legal
> > (not ethical!) problems.
>
> A couple of years ago I red an interview with a former MS employee (I am
> sorry, I can't remember his name) who was involved with MS-DOS. He said we
> should never forget that MS is a business, and like in case of any other
> business what principally matters is the cost vs. profit ballance. So the
> source code looks awful and they left unfixed known bugs, because cleaning
> the source code and fixing those bugs would have meant more costs in
> comparison with the profits that would have been obtained. This is why MS
> doesn't publicly release the source code of MS-DOS, not because they have
> some precious secrets but because they would be strongly ashamed by the
> mess there.

Um, it's not like they are held in the greatest esteem anyways, so I doubt some old code would hurt them. They probably can't find it (old version control long hidden away, a la Novell DOS), don't fully own it, are too lazy/busy, rely on it for marginal sales (POS? developer network? third world? patents?) or just don't care.

I think the most generous things they've done are VC Express and XP Mode for Win7. That's probably more than anybody ever expected.

John Carmack gave away Doom and Quake engine sources (GPL'd) only when he no longer needed them and had a working replacement. Even then you still need data (original or make your own). Of course, the major benefit for that was having people port it to various other OSes and gfx subsystems. MS-DOS doesn't have anything to port, does it? Who knows, maybe they think "We can't compete with FreeDOS, it's too good." ;-)

rr(R)

Homepage E-mail

Berlin, Germany,
22.11.2009, 19:50

@ Khusraw
 

Phil Gardner's Wrapper.sys & MS-DOS7 bug

> > Repairing DOS could be a better option and a reusable one. However
> > distributing a patch for MS-DOS as such would present more legal
> > (not ethical!) problems.
>
> A couple of years ago I red an interview with a former MS employee (I am
> sorry, I can't remember his name) who was involved with MS-DOS.

Larry Osterman maybe?

Khusraw(R)

E-mail

Bucharest, Romania,
22.11.2009, 20:17

@ rr
 

Phil Gardner's Wrapper.sys & MS-DOS7 bug

> Larry Osterman maybe?

Unfortunately his name didn't say too much to me then, so I didn't retain it. In the meantime I have searched the web in order to find the interview or at least references to it, but so far I haven't got any success.:-(

Ninho(R)

E-mail

23.11.2009, 23:26

@ cm
 

Re MS-DOS7 bug, Patch done! available soon :=)

CM and All : Patch is done, I just want to do some more testing under different DOSes and make more checks before I release it for you to try. I have yet also to examine what happens if/when Windows 9x is eventually launched ;=)

Too tired to continue now, but within one/two days you'll get to see the simple and, I think elegant solution which is general (not a specific workaround for wrapper.sys), repairs the bug without touching the MS-DOS code itself.

It consists of a fake DOS device driver, that when installed takes 368 bytes, does NOT hook any interrupts or DOS function. All it has to do is sit there to offer space for the fake TSRinfo table during Sysinit.

> If you adapt either of these methods or the one presented by Geoff
> Chappel, please replace his version check by something dependable (such as
> exact kernel code pieces if you're going to patch code anyway). Other DOS
> versions report "true version" (Int21.3306) 7.00+ now too (because many
> programs depend on that to check for other things such as FAT32 support)
> but they probably don't support the TSR list pointer in the DOS data
> segment.

Now we'll need a 'true true version' function ! I don't think I like this kind of escalation. Can you name those offending non-Microsoft DOSes that report true ver = 7 or 8, and possibly suggest a /documented/ way to check for them ?

---
Ninho

cm(R)

Homepage E-mail

Düsseldorf, Germany,
24.11.2009, 15:03
(edited by cm, 24.11.2009, 15:26)

@ Ninho
 

Re MS-DOS7 bug, Patch done! available soon :=)

> It consists of a fake DOS device driver, that when installed takes 368
> bytes, does NOT hook any interrupts or DOS function. All it has to do is
> sit there to offer space for the fake TSRinfo table during Sysinit.

Okay, sounds like a working solution. How does your version check identify the offending MS-DOS versions? How do you remove the TSR after CONFIG.SYS?

> Now we'll need a 'true true version' function ! I don't think I like this
> kind of escalation.

Yes, we need other functions. Additionally we have to show people that they don't have to fake every "Get version" function that we're going to invent.

> Can you name those offending non-Microsoft DOSes that
> report true ver = 7 or 8, and possibly suggest a /documented/ way to check
> for them ?

PC-DOS, (E)DR-DOS, FreeDOS, PTS-DOS and ROM-DOS do that for sure. Note that I'd like to re-define the term "offender" here to blame the software that relies on version numbers for supported DOS features. This is a bad feature detection because it requires DOS to support exactly the same feature set as that version of MS-DOS did. In this case, the other DOS variants report a version of 7.10 to show that they support FAT32. No other DOS supports the TSRInfo pointer in the DOS data segment, but (because the version is 7.00+) Chappel expects that feature.

Microsoft already faked the first DOS version check call (Int21.30) with MS-DOS 5+ to counter external programs that relied on exact version checks instead of such checks which allow higher versions too. Both methods don't always behave well: what if MS-DOS 9.50 removed support for, say, UMBs?

Some DOS versions already have new version checks which allow distinction:

* DR-DOS: Int21.4452 (doesn't tell you whether it's DR-DOS or EDR-DOS though)
* PTS-DOS (at least 6.51): Int21.20 (but doesn't return version number)
* ZDOS: Int13.20.dl=80.bx=55AA (conflicts with media sense of some BIOSes but works around this, no version number?)
* ROM-DOS: Int21.30DB.si=B2D2.di=xx03 or the same function as Int21.DB03 (21.DB conflicts with Netware "Get number of local drives" but works around this)
* The FreeDOS Kernel: Int21.3000 (hope for the best) & Int21.33FF (only a string)

---
l

Ninho(R)

E-mail

24.11.2009, 18:10

@ cm
 

Re MS-DOS7 bug, Patch done! available soon :=)

>> It consists of a fake DOS device driver, that when installed takes 368
>> bytes, does NOT hook any interrupts or DOS function. All it has to do is
>> sit there to offer space for the fake TSRinfo table during Sysinit.

> Okay, sounds like a working solution.

Yay.

> How do you remove the TSR after CONFIG.SYS?

You don't! That's the beauty of the thing (simple=beautiful), it just works!
After MSDOS 7 is finished initialising DOS device drivers from Config.sys, it switches to using its own allocated block for mainaining the TSRInfo structure. The list is built properly including info for those TSRs which were loaded by Wrapper.sys (with my hack loaded of course).

And I have now checked not only DOS 7, Windows 98 can be loaded and work as designed on top of this tower ! Yeepee !

As for the memory eaten up by my solution, well it's only 368 bytes (and can be loaded in UMBs, if available, by DEVICEHIGH). Note it is only /once/ 368 bytes however many TSRs are subsequently loaded using Wrapper.sys or similar. The memory is not needed after driver init is finished - so it /could/ be unlinked from the device driver chain and made available for allocation to DOS programs, by manipulating the MCB chain. But it is so small a patch of memory lost in the middle of DOS drivers area that I don't think the "return on investment" of a specific unloader is worth it (when my little thing is released for "beta" testing, you are welcome to write one however ;)

> How does your version check identify
> the offending MS-DOS versions?

First, let it be remarked that since this program is only ever of use on Win-DOS 7 or 8, and advertised as such, a user /should not/ try to load it under an offending DOS !

However I'll do my best effort to identify genuine MS-DOS from Windows 9x/ME and I hope for you guys to check it works against those non MS DOSes which lie about their "true" ver including :

> PC-DOS, (E)DR-DOS, FreeDOS, PTS-DOS and ROM-DOS do that for sure.
...

> what if MS-DOS 9.50 removed support for, say, UMBs?

DOS ver 9 is the OS2 'compatibilty box' IIRC. It is not likely there will ever be an MS-DOS 9.50 (nor any MS-DOS ver over 8, for that matter)

Cheers

---
Ninho

cm(R)

Homepage E-mail

Düsseldorf, Germany,
24.11.2009, 23:11

@ Ninho
 

Re MS-DOS7 bug, Patch done! available soon :=)

> The list is built properly including info for those TSRs which
> were loaded by Wrapper.sys (with my hack loaded of course).

Neat!

> As for the memory eaten up by my solution, well it's only 368 bytes (and
> can be loaded in UMBs, if available, by DEVICEHIGH). Note it is only
> /once/ 368 bytes however many TSRs are subsequently loaded using
> Wrapper.sys or similar.

I understood that. But it still wastes memory.

> The memory is not needed after driver init is
> finished - so it /could/ be unlinked from the device driver chain and made
> available for allocation to DOS programs, by manipulating the MCB chain.
> But it is so small a patch of memory lost in the middle of DOS drivers
> area that I don't think the "return on investment" of a specific unloader
> is worth it

Why not manipulate MCBs during the installation and allocate the table in another memory block (at the top of low memory, or at the top of a UMB)? This is very simple for UMB installation because DOS doesn't seem to be allocating all UMBs right away. However, DOS likely allocates all low memory to your driver if it's loaded there, so you have to resize this MCB yourself.

Besides, a small environment sure fits in this space.

> (when my little thing is released for "beta" testing, you are
> welcome to write one however ;)

Write it yourself. The solution mentioned by you is simple, you just have to find your sub-MCB and then split or resize the system MCB that contains your driver. This could be integrated as executable into your program, so that the file would be a dual .COM/.SYS or .EXE/.SYS file.

> > How does your version check identify
> > the offending MS-DOS versions?
>
> First, let it be remarked that since this program is only ever of use on
> Win-DOS 7 or 8, and advertised as such, a user /should not/ try to load it
> under an offending DOS !

Because it might crash these perfectly fine DOS versions if it misdetects them as MS-DOS ;-)

> However I'll do my best effort to identify genuine MS-DOS from Windows
> 9x/ME and I hope for you guys to check it works against those non MS DOSes

I'll certainly try it.

> > what if MS-DOS 9.50 removed support for, say, UMBs?
>
> DOS ver 9 is the OS2 'compatibilty box' IIRC.

Nope, that's "DOS versions" 10 and 20.

> It is not likely there will
> ever be an MS-DOS 9.50 (nor any MS-DOS ver over 8, for that matter)

Indeed. But the MS people probably didn't know that back when they released MS-DOS 5.

---
l

Ninho(R)

E-mail

25.11.2009, 00:36

@ cm
 

Re MS-DOS7 bug, Patch done! available soon :=)

>> As for the memory eaten up by my solution, well it's only 368 bytes (and
>> can be loaded in UMBs, if available, by DEVICEHIGH).

> I understood that. But it still wastes memory.

It does. Minimally.

>> The memory is not needed after driver init is
>> finished - so it /could/ be unlinked from the device driver chain and made
> > available for allocation to DOS programs, by manipulating the MCB chain.

> Why not manipulate MCBs during the installation and allocate the table in
> another memory block (at the top of low memory, or at the top of a UMB)?

There are various complications with your suggestion. Messing with mem allocation is always a pain especially while the system is not set up yet (BTDT). Also we can't count on having UMBs or a memory manager available at the point we are called, so we have to envision putting the small block in conventional memory. But the highest possible location would be just under the Sysinit code and structures, typically around the 500 kilobytes mark, leading to stupidly fragmented conventional mem afterwards. It would subsequently be necessary to have a second program for repairing the memory allocation afterwards (assuming the fragmentation does not cause command.com to choke, as happens too easily).

Frankly my method looks more attractive, is "fire and forget", and if the "wasted" bytes are a problem (which they aren't) it can be repaired later.


> This is very simple for UMB installation because DOS doesn't seem to be
> allocating all UMBs right away. However, DOS likely allocates all low
> memory to your driver if it's loaded there, so you have to resize this MCB
> yourself.

It's more complicated, regular MCB-based memory management functions are not the way a driver's initialisation routine reserves memory. In fact MCBs do not exist officially during this phase, although there is one embryonic MCB underneath the suface. DOS memory allocation functions (48/49/A) aren't supposed to be available and even though they in fact are unoficially present, they will not do what you'd expect. A program such as wrapper.sys has to establish a temporary chain of (fake) MCBs, among other things, in order to satisfy executable programs it is EXEC'ing. Regular driver initialisation does not even want to hear about MCBs.


>> (when my little thing is released for "beta" testing, you are
>> welcome to write one however ;)

> Write it yourself. The solution mentioned by you is simple, you just have to ...

Better left as an exercise to the reader :=)

> Besides, a small environment sure fits in this space.

Sure but, you know, a typical DOS system has lots more space lost than this.

---
Ninho

Khusraw(R)

E-mail

Bucharest, Romania,
19.11.2009, 19:16

@ Ninho
 

Phil Gardner's Wrapper.sys & MS-DOS7 bug

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

It would have spared me a few good minutes of searching if you would have provided the link...

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

The disassembled 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.(...)

You are undoubtedly right. I just wanted to give you a "starting point", a "basement" for you to build over. If the problem would have really hurt you, even losing "nights and days" at the age you pretend to have, would have meant nothing. But you know very well that even patching DOS in this regard wouldn't be a question of "nights and days" as long as you have the needed kowledge.

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

If your intention was just to launch some kind of challenge, as it seems now to me, I am not the "guy" to have interest for such things (because I have no need to assert myself - not even just for myself, I feel too old for this). I thought your interest for the problem was real and you are just too lazy to resolve the things for yourself.

Ninho(R)

E-mail

19.11.2009, 23:48

@ Khusraw
 

Phil Gardner's Wrapper.sys & MS-DOS7 bug

> It would have spared me a few good minutes of searching if you would have
> provided the link...

Sure. I did not have the link when originally posting, and anyway, the Chappel text is only loosely relevant to the question which is, remember, does someone have a revised 'wrapper.sys' some other tsr wrapper working in DOS 7/8. Nor did I ask you personally to lose those precious minutes of your time, you chose to search because, presumably, you felt interested. Anyway I have apologised for not giving a URL, do you want more ?

snipping some

>> Anyhoo... if you are the kind of guy who likes challenges, please go

> If your intention was just to launch some kind of challenge, as it seems
> now to me, I am not the "guy" to have interest for such things (because I

You're not the guy. Fine. And no I'm not making a challenge.

> have no need to assert myself - not even just for myself, I feel too old
> for this). I thought your interest for the problem was real and you are
> just too lazy to resolve the things for yourself.

So we are too old both of us. And yes I am too lazy to try and resolve the thing considering the expected benefit. Otherwise I would not have posted. Doing it right would mean patching DOS which is by no means trivial, considering the structures and interfaces involved are undocumentend (even in Ralf Brown's list which unfortunately is not updated for a long time). Maybe they are described in Chappell's book, which I don't possess.

Thank you for your insights ! ( Regarding acid remarks, I make no notice of such in general).

---
Ninho

Khusraw(R)

E-mail

Bucharest, Romania,
20.11.2009, 08:29
(edited by Khusraw, 20.11.2009, 10:06)

@ Ninho
 

Phil Gardner's Wrapper.sys & MS-DOS7 bug

> Sure. I did not have the link when originally posting, and anyway, the
> Chappel text is only loosely relevant to the question which is, remember,
> does someone have a revised 'wrapper.sys' some other tsr wrapper working
> in DOS 7/8.

Considering that it seems no one has a revised 'wrapper.sys', and except my tentative to help you, you didn't find here too many positive reactions, the only solution for you would have been to patch the existing 'wrapper.sys'. Again, it seems that you have no disponibility for this, which is not a problem for me anyway. So for now you have no choice but to don't "wrap" TSRs when using MS-DOS 7.

> Nor did I ask you personally to lose those precious minutes of
> your time, you chose to search because, presumably, you felt interested.
> Anyway I have apologised for not giving a URL, do you want more ?

Usually it is considered "de bon ton" for the people to provide the link when refering to it in their posts. Even if you don't think so, please understand that my request was not an idiosyncrasy.

> So we are too old both of us. And yes I am too lazy to try and resolve the
> thing considering the expected benefit. Otherwise I would not have posted.
> Doing it right would mean patching DOS which is by no means trivial,
> considering the structures and interfaces involved are undocumentend (even
> in Ralf Brown's list which unfortunately is not updated for a long time).
> Maybe they are described in Chappell's book, which I don't possess.

I am not too old generally, I am just too old to be interested in challenges. And I never said that patching DOS is trivial, I just said that the task is easy for someone who has the needed knowledge, as any other task. Do people who have enough knowledge about MS-DOS 7 internals still exist? Yes, they still exist. So address them! This is what I wanted to tell, but now I have to be more explicit in order for you to finally understand.

> Thank you for your insights ! ( Regarding acid remarks, I make no notice
> of such in general).

You are welcome! (What acid remarks?).

Ninho(R)

E-mail

20.11.2009, 09:59

@ Khusraw
 

Phil Gardner's Wrapper.sys & MS-DOS7 bug

> I am not too old generally, I am just too old to be interested in
> challenges. And I never said that patching DOS is trivial, I just said
> that the task is easy for someone who has the needed knowledge, as
> any other task. Do people who have enough knowledge about MS-DOS 7
> internals still exist? Yes, they still exist. So address them! This
> is what I wanted to tell, but now I have to be more explicit in order for
> you to finally understand.

I already understood perfectly your impolite assumptions and insinuations, and don't feel like addressing them would be any use in this forum. Your fail to realise I didn't ask for your or any one's condescending advice. Believe it or not, I pretty have the skills required to do it, should I need to undertake the task. Just like you, it's not because I (think I) /can/ do it that I /will/. Why you feeled challenged or summonned in person I don't understand (and I don't care).

> You are welcome!

But apparently not so.

> (What acid remarks?).

Now please stop playing this game. You should have stopped answering this thread earlier, short of having anything substantial to add; this
is what I wanted to tell, but now I have to be more explicit in order for
you to finally understand.:=)

---
Ninho

Khusraw(R)

E-mail

Bucharest, Romania,
20.11.2009, 10:43

@ Ninho
 

Phil Gardner's Wrapper.sys & MS-DOS7 bug

> Now please stop playing this game. You should have stopped answering this
> thread earlier, short of having anything substantial to add; this
> is what I wanted to tell, but now I have to be more explicit in order for
> you to finally understand.:=)


You got pissed off for nothing. I didn't insult you, I just detected irony in your first reply, when my intention was just to help you, and I answered accordingly. It would have been better if you would have ignored my answer in case you considered it stupid/outside your problem, but you didn't, so you had to suffer the consequences: "culpam poena premit comes".
And I have no idea about your skills, not even about who you are (I can't see any name in your "User info" box), for me you are just "Ninho" (I think you intended the Spanish "Niño", not the Portuguese "Ninho").;-)

EOD

Ninho(R)

E-mail

20.11.2009, 12:00

@ Khusraw
 

Phil Gardner's Wrapper.sys & MS-DOS7 bug

> You got pissed off for nothing.

Exactly my thoughts about you !!!

> I didn't insult you, I just detected irony
> in your first reply, when my intention was just to help you, and I answered
> accordingly.

Ah, OK. There was not a trace of intended irony however, I assure you. Your irony detector misfired :=(

> It would have been better if you would have ignored my answer

In retrospect it would. But you seemed to be interested enough to go fetch that excellent old programme, look for an unidentified web page (do you own the book "undocumented DOS" by Chappell, by the way?), fire your IDA... so I could infer you might be willing to do more work (not for /me/ God forbid! but for your own pleasure). I too misdetected.

> And I have no idea about your skills, not even about who you are (I can't
> see any name in your "User info" box), for me you are just "Ninho" (I
> think you intended the Spanish "Niño", not the Portuguese "Ninho").;-)

What's in a name ? In fact I do mean the Portuguese ninho, é uma velha historia. You misdetected (again :)

> EOD

Good day, Khusraw!

---
Ninho

Ninho(R)

E-mail

25.11.2009, 22:01
(edited by Ninho, 26.11.2009, 17:49)

@ Ninho
 

*beta* Patch available !

For your testing pleasure the int 21/31 hack for MS-DOS 7 (Windows 95/98) has just been made available for download:
download HK31.SYS v 0.7 (beta)

Update : for a fresh link to the newest version, please refer to the new discussion thread, in the Misc. section :
beta Patch discussion thread.


Important notes : this is a public "beta". Although it is believed to be harmless and tested at home on different configurations of MSDOS 6 and MSDOS 7, you should take the usual precautions before tesing this software. Preferably run it on non mission-critical systems, or some kind of virtual machine. Backup your files as necessary. Generally, if you don't feel at ease with running unknown software, don't do it.

For those who can't wait, express usage notes. I'll upload a "manual" later.

- download HK31.SYS from above URL, optionally check MD5, virus-check etc.
- put the file somewhere on your DOS disk, say C:\TEST\HK31.SYS

- Your CONFIG.SYS should be edited include a line similar to :

DEVICE=C:\TEST\HK31.SYS
... or use DEVICEHIGH= in conjunction with a suitable memory manager.

When that line is executed, the driver will load and pause itself to allow you to read screen output conveniently (there is a reason it is called a beta!). Press the ANY key after studying its output in order to continue booting DOS.

- IF running MS-DOS versions prior to Windows 95, OR non-Microsoft DOS, it should refuse to install itself and tell you so. No harm done but those systems do not require the hack.

- IF running MS-DOS 7 from Win 95 to Win 98 SE, it will install itself to memory. Also under MS-DOS 8 from a Win ME boot disquette (not tested by me)

Your system should continue to boot normally to DOS and eventually to Windows.

- Now get Philip Gardner's WRAPPER.SYS (Shareware, free to try, see its license. I have no connection to the Author) if you haven't already.

http://ftp.sunet.se/pub/simtelnet/msdos/bootutil/wrap10.zip

Assuming you put wrapper.sys to C:\TEST along with HK31.SYS, you might
add a line such as the ff. to your CONFIG.SYS :

DEVICE=\TEST\WRAPPER.SYS path-to\TSR.EXE
... or DEVICEHIGH, if applicable.

where TSR.EXE is any DOS TSR which you would otherwise load from the command line, or AUTOEXEC.BAT, or INSTALL(high)= line from CONFIG.SYS (try keyboard or mouse driver for instance)

But NOTE the HK31.SYS MUST load BEFORE any WRAPPER.SYS instance (that loads TSRs). This is the whole point about this fix.

Warning again : IF you OMITTED HK31.SYS on a MS-DOS version which is affected by the bug, the loading of any TSR by Wrapper.sys WILL (on MSDOS 7/8) result in memory corruption and system instability or crash.

Please report test results and any problems or questions about this tool.

Especially I wish to know if under those non-MS DOSes which misreport themselves as MS-DOS 7, HK31 refuses to load (as it should)

---
Ninho

cm(R)

Homepage E-mail

Düsseldorf, Germany,
25.11.2009, 22:17

@ Ninho
 

*beta* Patch available !

Could you release the source as well?

---
l

Ninho(R)

E-mail

26.11.2009, 00:02

@ cm
 

*beta* Patch available !

> Could you release the source as well?

I don't want to release the source while I'm solliciting public comment, because I wish to control any modifications. When it's deemed stable, I may release the source per request - before that however it needs to be made pretty and translated (as it stands, it's in a mix of languages).

---
Ninho

cm(R)

Homepage E-mail

Düsseldorf, Germany,
26.11.2009, 15:04

@ Ninho
 

*beta* Patch available !

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

---
l

Ninho(R)

E-mail

26.11.2009, 17:33
(edited by Ninho, 27.11.2009, 11:42)

@ cm
 

*beta* Patch available !

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

It's been available since yesterday. New version 0.7 uploaded now.

Please confirm if any trouble with the download, the host might be having problems. It seems OK from my tests (across the Atlantic!)

[Update] The server there might be flaky of late, I've added another, more robust dwnld location - first download link in the new thread :

HK31.SYS *beta* announce & discussion thread

---
Ninho

rr(R)

Homepage E-mail

Berlin, Germany,
09.12.2009, 22:50

@ Ninho
 

Phil Gardner's Wrapper.sys & MS-DOS7 bug

Today I received this message from Geoff Chappell:
Your site directs me to this Contact page if I'm to comment on your members' comments about me. Please register me if you have to, but I don't intend any continued participation. Perhaps it would be better if you would just relay the following to the topic given in the Subject.

==== begin ====

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

A workaround is surely better, and the only one available is to provide the least necessary memory in advance of int 21h function 31h so that the kernel can do what its coding error makes it need to do. What the kernel records in this memory will not matter. The persistent record will be made, as it ought, when WRAPPER.SYS returns. If you could edit WRAPPER.SYS, you could indeed just duplicate what I've done for my CRTDRVR.LIB.

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.

> 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? FAT32 is much older. 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.

> No other DOS supports the TSRInfo pointer in the DOS
> data segment, but (because the version is 7.00+)
> Chappel expects that feature.

And why not? I don't give a damn about the other DOSs. 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.

By the way, my code actually has version >= 7.00 only as a necessary condition. 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, but I also think it's as much defensiveness as can sensibly be implemented.

==== end ====

Thank you.

Ninho(R)

E-mail

10.12.2009, 13:11
(edited by Ninho, 10.12.2009, 16:42)

@ rr
 

Phil Gardner's Wrapper.sys & MS-DOS7 bug

RR wrote :
> Today I received this message from Geoff Chappell:
>> Your site directs me to this Contact page if I'm to comment on your
>> members' comments about me.

Not that I wrote any comments about Geoff Chappell yet. Let me tell I'm flattered by Mr Chappell's interest in my little hack, and grateful for his comments.


>> Please register me if you have to, but I don't
>> intend any continued participation.

Geoff's choice not to participate here is fully understood and respectable. It is slightly unfortunate, for I would've had a couple technical question to ask of him otherwise. Will you Robert, please relay the content of this reply, asking him if he would mind me emailing (and if agreed, provide an appropriate email address of his)?

Geoff Chappell wrote :

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

Sure, patching the IO.SYS files - the many variants - is out of the question.

The problem has a few interesting aspects. For one, hooking DOS interrupts is almost unthinkable, because we're attempting to mess with, precisely, the DOS kernel's monitoring of interrupt hooks !

Patching DOS in-memory presents a few challenges, too : 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. While feasible this sounds more like 'viral' than sound programming techniques...

However, I may have come by a different approach to modifying DOS, than patching-in the suggested "defence" instructions. The beauty of that newborne being that it won't add one byte to internal DOS code! No need to find a suitable place for the d$mned patch! More on that will be written in the other (HACKWRAP) thread.


> A workaround is surely better, and the only one available is to provide
> the least necessary memory in advance of int 21h function 31h so that the
> kernel can do what its coding error makes it need to do. What the kernel
> records in this memory will not matter. The persistent record will be
> made, as it ought, when WRAPPER.SYS returns. If you could edit
> WRAPPER.SYS, you could indeed just duplicate what I've done for my
> CRTDRVR.LIB.

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


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

Now, this is what I have to question. In my tests (and as far as I know, other members'), multiple TSRs have been launched in this way without ill effect in DOS before or even after launching Win9x. [addition:] I'm aware of potential problems if more than 20 TSRs will have been submitted by this method. I also agree the internal pointer @DOS:1328 should probably be zeroed before Sysinit passes the relay to the DOS kernel after all drivers are initialised. The latter is not done in the present prototype [/addition.]

Admittedly my tests have been limited [I was too much absorbed in devising a scheme for separating True MS-DOS from the ivy of Clones]. Admittedly (bis) while I have succumbed to the temptation of unassembling and browsing the MS-DOS kernel code, I did not look deep inside the all important Windows side of the question (my copy of the Win95 DDK being buried God knows where).

That it seems to work flawlessly thus was even a surprise to me first; my current theory is that the compare&record work done by int 21/31 is useless but also harmless (provided the hack is in place), the useful recording of TSR resources is that done each time WRAPPER.SYS returns from its initialisation.

BICBW. Members, if you have to bet, put your money on Geoff, he's the expert!

>>
.... (some snipping done)

> And why not? I don't give a damn about the other DOSs. 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.

> By the way, my code actually has version >= 7.00 only as a necessary
> condition. 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, but I also think it's as much
> defensiveness as can sensibly be implemented.

I have to say that the situations are slightly different. Your library was intended for programmers, who (should) know what they do and can test for the DOS versions in their main programs anyway; while my hack will potentially end up being stored on end users' disks and I feel I have to do my best to prevent any damage in case they attempt to launch it under any DOS or DOS alike versions.

Regards,

---
Ninho

geoffchappell(R)

11.12.2009, 17:12

@ Ninho
 

Phil Gardner's Wrapper.sys & MS-DOS7 bug

> Geoff's choice not to participate here is fully understood and
> respectable. It is slightly unfortunate, for I would've had a
> couple technical question to ask of him otherwise.

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

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.

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

Whether it's worth your trouble is another question. You'd be able to supply memory for fake TSR information in advance of the named program's execution, and undo the hack when the named program terminates. It's tidy that the hack is active only for the least time, but you may have to leave those hooks in place forever (if the named program hooks your same interrupts).

> 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. Workarounds should deal as closely as possible with what I think to be the problem, and there's no doubt here that the problem is only that the routine for post-processing resident termination doesn't test the pointer.

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

It sounds like you have several people here who could easily enough write a new WRAPPER.SYS. Really, it's just a matter of writing glue to translate from device driver initialisation to running the program that's named on the device driver command line, and then of a few fiddles before and after you actually do run the program. You have to build a memory arena so that your int 21h function 4B00h will see a block of free memory in which to load the named program. You have to fake an FCB-SFT (before DOS 7) and fake TSR information (in DOS 7 and higher). I'd preserve the DTA too, though I can't say that SYSINIT actually depends on it to be preserved across a device driver load.

> In my tests (and as far as I know, other members'), multiple TSRs have
> been launched in this way without ill effect in DOS before or even
> after launching Win9x.

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. The minimal allowance of 1 in CRTDRVR.ASM looks like it will be good for you, too.

> I did not look deep inside the all important Windows side of the
> question (my copy of the Win95 DDK being buried God knows where)

When you find it, you may save time from knowing that IOS.VXD is the one that cares about this data. On the other hand, that doesn't really matter. When SYSINIT is ready to start loading TSRs, it will point DOS:1328h to its own TSR information and ignore yours, which therefore will never be seen by IOS.

In IOS, the offset 1328h is hard-coded.

To SYSINIT, the offset 1328h is found by its being at offset 20h from the address that the DOS kernel's initialisation routine returns in bx.

> my current theory is that the compare&record work done by int 21/31
> is useless but also harmless (provided the hack is in place), the
> useful recording of TSR resources is that done each time WRAPPER.SYS
> returns from its initialisation.

At this stage, yes. The TSR executes within the driver. Everything it does should look to have been done by the driver and should be recorded as driver usage for IOS to retrieve through the documented int 2Fh function. That it's also recorded as TSR usage won't matter.

> while my hack will potentially end up being stored on end users' disks
> and I feel I have to do my best to prevent any damage in case they
> attempt to launch it under any DOS or DOS alike versions.

Each to his own, I think. If you would feel responsible for problems if your code got used on another DOS, then support it. I would never criticise anyone for supporting another DOS, just for insisting that anyone must.

Ninho(R)

E-mail

12.12.2009, 01:04

@ geoffchappell
 

Phil Gardner's Wrapper.sys & MS-DOS7 bug

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


> 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

geoffchappell(R)

12.12.2009, 10:57

@ Ninho
 

Phil Gardner's Wrapper.sys & MS-DOS7 bug

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

It's not unused though, is it? As noted on my page for the CRTDRVR update, the comparison with the snapshot from before the program runs is made "whenever a program terminates via int 21h function 31h and Windows Enhanced Mode is not running".

So, yes, there's a bit test that stops the int 21h function 31h code from calling the buggy routine that assumes a non-NULL pointer at offset 1328h. In DOS 7.0, the test is of 01h at offset 0F5Bh, but this is the DOS kernel's record of whether Windows Enhanced Mode is running.

If this is the test you mean, then I have to ask if you really want to tell DOS that Windows Enhanced Mode is running when it actually isn't. I wouldn't be surprised to find that no harm can come from it, especially if you can clear the bit afterwards. The points on which DOS varies its behaviour for Windows are few and perhaps will not conflict with anything your loaded program wants to do. I, however, am not so adventurous that I'd want to try.

But perhaps you do not mean to "fix" int 21h function 31h by setting this bit and risking other consequences. Perhaps you mean just to use the TEST as a sequence to search for so that you can stop the call to the defective routine. That would not present any troubles, again provided you re-enable the call before there can be any supported loading of TSRs.

By the way, the test has the same offset in DOS 7.10 but it tests 03h, i.e., two bits. I have no idea about DOS 8.0. It seems I never prepared a listing. I also don't recall any dependency by Windows on this offset: it looks like it's genuinely an internal variable.

Ninho(R)

E-mail

12.12.2009, 11:50
(edited by Ninho, 12.12.2009, 16:10)

@ geoffchappell
 

Phil Gardner's Wrapper.sys & MS-DOS7 bug

>> 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.
>
> It's not unused though, is it?

Not that bit! I take possession of a previously unused bit in the same byte. MS uses bits 0,1,2 only. I deign to leave bit 3 in their realm, and I annex bits 4-7 of which bit 4 shall be used in the present hack.

Let's now if you please all use the new thread for the new FIXWRAP.
I'll explain everything there (though I'm sure you now guess the main lines).
Link to the new technical sub-thread : http://www.bttr-software.de/forum/forum_entry.php?id=7351


> By the way, the test has the same offset in DOS 7.10 but it tests 03h,
> i.e., two bits. I have no idea about DOS 8.0. It seems I never prepared a
> listing. I also don't recall any dependency by Windows on this offset: it
> looks like it's genuinely an internal variable.

In ME also the instruction tests for 03h. But I don't care, I only need to add the test of MY bit (bit 4 it shall be), so I change that instruction to TEST against 13h (or 11h in original Win 95). As I said the installation of the hack will just have to flip the repective bit in the TEST instruction. It could also be made permanently to my/your/their of the IO.SYS file, BTW, without damage but without real advantage since the fix will have to be loaded anyway.

Ah, I am aware of more details than you may think. I have an idea what bit 1 is used for, at least partially - in conjunction with the following byte, they're used during Windows start, the infamous secret handshake that occurrs between Win.COM and Kernel386 IIRC from my old attempts at launching Windows, i.e. the VMM.VXD, without the help of Win.com). We do not care in the least as far as the present project is concerned...

Nuff said - I'll update the other thread only, but I must beg your patience.


Regards...
--
Ninho

Message edited, the earlier version was confused.

cm(R)

Homepage E-mail

Düsseldorf, Germany,
10.12.2009, 15:56

@ rr
 

Phil Gardner's Wrapper.sys & MS-DOS7 bug

> I don't intend any continued participation.

So.

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

---
l

Rugxulo(R)

Homepage

Usono,
11.12.2009, 07:14

@ cm
 

Phil Gardner's Wrapper.sys & MS-DOS7 bug

> > I don't intend any continued participation.
>
> So.

Usually that means "I am too busy to participate fully in every forum out there, esp. since I already attend quite a few". In this case, I think he also means "I'm no longer actively interested in DOS".

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

MS-DOS is by far the most popular DOS. And their version 7 was inside Win95, when LFNs (in VFAT) were first introduced. DR-DOS always tried to one-up them with version numbering (purely for marketing reasons). Of course, MS also most likely used "XBox360" to counter the PS3 (since XBox 2 < PS3 ??).

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

Eh? No, AFAIK, MS-DOS 7.10 means Win95 OSR2 or Win98 or Win98SE, as nothing earlier supported FAT32. (Even DR-DOS only had an unofficial TSR, which I blindly guess was pulled when they discovered MS had patents on it, ugh.)

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. Maybe ROM-DOS does the same, I dunno. My copy of DR-DOS 7.03 is definitely not LFN aware (except in very few places, e.g. COMMAND.COM), e.g. DR's CHKDSK aborts if any LFNs are found. Of course, DR-DOS reports "IBM DOS 6" to the standard version checks, for compatibility, so you have to go out of your way to test for DR-DOS specifically (int 21h, 4452h "DR").

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

Obviously you can use LFNs in any FAT, e.g. FAT12, FAT16, FAT32. Typically Linux calls "msdos" the 8.3 file system and "vfat" the LFN-aware one.

> > I don't give a damn about the other DOSs.
>
> Yes, I see. But where's the point in talking more about them then?

I'm pretty sure this guy is only interested in modern Windows these days. Also, MS-DOS pretty much clobbered the DOS market. Hence, I blindly guess he's never even tried DR-DOS (and probably doesn't know how good / compatible it is) or others.

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

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. There are many many patches and rewrites for MS-DOS and Windows to get them to work correctly. (Sadly MS is not too interested in fixing old OSes.) E.g., see my codepage detection patch.

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.

cm(R)

Homepage E-mail

Düsseldorf, Germany,
11.12.2009, 16:02

@ Rugxulo
 

Phil Gardner's Wrapper.sys & MS-DOS7 bug

> 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

Rugxulo(R)

Homepage

Usono,
11.12.2009, 19:42

@ cm
 

Phil Gardner's Wrapper.sys & MS-DOS7 bug

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

DRFAT32, but I've never used it.

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

Original (Jan. 1999) COMMAND.COM from 7.03 does indeed support it.

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

More importantly, if you actually want someone to test or use your app, you don't have to say, "Buy such and such", just point them to the download!

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

It's FreeDOS, mostly because it's good and truly free. I just also include misc. extra stuff that might be useful for other DOSes (since I use or have used others too).

geoffchappell(R)

12.12.2009, 11:08

@ Rugxulo
 

Phil Gardner's Wrapper.sys & MS-DOS7 bug

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

Arjay(R)

12.12.2009, 11:34

@ geoffchappell
 

Phil Gardner's Wrapper.sys & MS-DOS7 bug

> > I'm pretty sure this guy is only interested in modern Windows these
> days.
I think this is bit unfair, I mean why shouldn't Geoff only care about what is on the whole the "current" area. He is after-all only one person and there is a limit to what we can all do. Indeed I have only recently got into Freedos myself as I wanted to make use of it for projects however I'm here as I'm keen to also feed back into FreeDOS/other projects. I'm learning a lot from these forums about FreeDOS/other things simply because I was so out of touch with what has happened (as I had moved onto many other things), now it's in my interest hence I'm dusting off stuff. That's just me but I can fully understand why Geoff needs to limit the areas that he is working with.

> 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.
Thanks Geoff, being aware of your work at a high level I hadn't even realized you were still being as kind as to go that far back. It is appreciated.

> > Hence, I blindly guess he's never even tried DR-DOS (and probably
> doesn't know how good / compatible it is) or others.
Likewise I'm in full support of Geoff here - I have never cared much for DR-DOS in days of old. That said I did see it and use it under Netware.

> 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.
Fair enough. Still really good to see you on here Geoff. Thanks for coming.

Rugxulo(R)

Homepage

Usono,
12.12.2009, 12:03

@ Arjay
 

Phil Gardner's Wrapper.sys & MS-DOS7 bug

> > > I'm pretty sure this guy is only interested in modern Windows these
> > days.
> I think this is bit unfair, I mean why shouldn't Geoff only care about
> what is on the whole the "current" area. He is after-all only one person
> and there is a limit to what we can all do. Indeed I have only recently
> got into Freedos myself as I wanted to make use of it for projects however
> I'm here as I'm keen to also feed back into FreeDOS/other projects. I'm
> learning a lot from these forums about FreeDOS/other things simply because
> I was so out of touch with what has happened (as I had moved onto many
> other things), now it's in my interest hence I'm dusting off stuff.
> That's just me but I can fully understand why Geoff needs to limit the
> areas that he is working with.

I just meant that obviously DOS isn't as popular as it once was, and obviously this guy has a heavy interest in Windows. I'm not blaming him, but yeah, I do still like and use DOS, so obviously I'm biased. :-D

> > 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.
> Thanks Geoff, being aware of your work at a high level I hadn't even
> realized you were still being as kind as to go that far back. It is
> appreciated.

I use Windows all the time, but it is definitely a bit weird in some areas.

> > > Hence, I blindly guess he's never even tried DR-DOS (and probably
> > doesn't know how good / compatible it is) or others.
> Likewise I'm in full support of Geoff here - I have never cared much for
> DR-DOS in days of old. That said I did see it and use it under Netware.
>
> > 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.
> Fair enough. Still really good to see you on here Geoff. Thanks for
> coming.

In all fairness, I completely understand that DR-DOS isn't nearly as popular. However, it's very good, it does plenty of goodies (more than MS, even), and it's very compatible. It's basically the successor to CP/M-86. Owned by Digital Research, Novell, Caldera, Lineo, DeviceLogics, DR-DOS Inc. But it's dead now, I guess, last updated in early 1999 (7.03). While you can ignore it with impunity, it's indeed a valid choice (well, it was ... lack of LBA or FAT32 really hurts, 64 MB limit for each task, can't even see all FAT16 partitions easily, etc.).

It's kinda weird with Windows: you could either say "hey, let's make it run on all DOSes" (wouldn't that be more income?) or "meh, we don't have time, don't care". They chose the latter path, so that kinda drowned out DR-DOS. But the DR guys never updated it much either, so part of the blame goes to them. Thankfully we have FreeDOS, else we'd really be suffering!!

Arjay(R)

12.12.2009, 12:25

@ Rugxulo
 

Phil Gardner's Wrapper.sys & MS-DOS7 bug

> I just meant that obviously DOS isn't as popular as it once was, and
> obviously this guy has a heavy interest in Windows.
It's ok I kind of realized that and hope you realize that I wasn't having a direct go either at you either.

> I'm not blaming him, but yeah, I do still like and use DOS,
> so obviously I'm biased. :-D
No need to apologise. I'm traditionally a shell junkie also. But came back to DOS myself as I wanted some easy direct hardware access to assist someone with something for which they had extremely limited funds hence FreeDOS etc.
Now I'm back with DOS.... I'm thinking to stay around for a little while.

> I use Windows all the time, but it is definitely a bit weird in some
> areas.
heh, DOS/Linux aren't? :)

> In all fairness, I completely understand that DR-DOS isn't nearly as
> popular. However, it's very good,
Indeed that is often the case. Likewise with all the 4DOS, Norton Commander fan-boys that were around... ok still around. Great tools but not for many of us we actively avoided them. Indeed I went out of my way to learn techniques that meant I could deal with systems without any 3rd party stuff.

> It's basically the successor to CP/M-86.
Which in turn was based on Unix and in many ways we've come back round full circle ;) Yeah I'm very familiar with the history of DOS etc.

Anyway don't want to just chat here. Best to keep this on topic and all I can see is I'm reading this thread but probably won't comment further on it.

> Thankfully we have FreeDOS, else we'd really be suffering!!
Amen.

geoffchappell(R)

14.12.2009, 08:28

@ Arjay
 

Phil Gardner's Wrapper.sys & MS-DOS7 bug

> Thanks Geoff, being aware of your work at a high level I hadn't even
> realized you were still being as kind as to go that far back. It is
> appreciated.

It's not kindness, more like a pathological need for completeness.

That said, I am getting much better at drawing a line, e.g., by keeping my alternative documentation effort to functions that begin no earlier than Windows XP. I find myself writing "outside the scope of this note" ever more often, and am surprised to find that I am ever less troubled.

> Fair enough. Still really good to see you on here Geoff. Thanks for
> coming.

Thanks to you and others for their many kind words, but I can't be here for long - not unless I have to give up my Windows research and I then think to make a living from DOS. Somehow, I don't see the latter happening.

geoffchappell(R)

11.12.2009, 17:14

@ cm
 

Phil Gardner's Wrapper.sys & MS-DOS7 bug

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

cm(R)

Homepage E-mail

Düsseldorf, Germany,
11.12.2009, 18:21

@ geoffchappell
 

Phil Gardner's Wrapper.sys & MS-DOS7 bug

> 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

geoffchappell(R)

12.12.2009, 10:56

@ cm
 

Phil Gardner's Wrapper.sys & MS-DOS7 bug

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

Why would it care about the DOS version for this? To make a DOS drive from the block device's units it needs to make a DPB, yes, but the kernel has a function for this. There's a FAT32 version as int 21h function 7304h subfunction 01h, but in fact, good old int 21h function 53h does the trick as long as you pass 4558h in CX and 4152h in DX. Why can't DEVLOAD try these and just be happy with what it gets if they succeed, whatever the DOS version?

Well, of course, those interfaces are for MS-DOS, but surely FreeDOS has them work the same way. Have I just misunderstood what you mean? There'd be nothing I could do about it 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.

If by explicit you want it in letters ten feet high "test for whether DOS has FAT32 support", then no, but that was never very much Microsoft's way in the days of DOS or VxDs. If you want to test that support exists, you try to use the desired support in a way that won't change anything important, but whose success you can assess. That's as explicit as things mostly ever got. There was never a lot of hand-holding.

cm(R)

Homepage E-mail

Düsseldorf, Germany,
12.12.2009, 11:48

@ geoffchappell
 

Phil Gardner's Wrapper.sys & MS-DOS7 bug

> Why would it care about the DOS version for this? To make a DOS drive from
> the block device's units it needs to make a DPB, yes, but the kernel has a
> function for this.

No, the kernel function only fills the DPB with data. For this, the DPB must be allocated. DEVLOAD needs to know the DPB's size to allocate it. (Sorry, me stating it needs to "create" DPBs was too vague.)

> If by explicit you want it in letters ten feet high "test for whether DOS
> has FAT32 support", then no, but that was never very much Microsoft's way
> in the days of DOS or VxDs.

My previous example Int21.71A0 is called "LFN Get volume information" and one of the returned flags is "Supports DOS long filename functions". I'd count that as explicit, though you're right: many other interfaces don't have explicit checks.

> If you want to test that support exists, you
> try to use the desired support in a way that won't change anything
> important, but whose success you can assess.

Exactly. Unfortunately not all programmers had this good idea, especially regarding checks for DOS FAT32 and LFN support.

---
l

geoffchappell(R)

14.12.2009, 08:29

@ cm
 

Phil Gardner's Wrapper.sys & MS-DOS7 bug

> No, the kernel function only fills the DPB with data. For this, the DPB
> must be allocated. DEVLOAD needs to know the DPB's size to allocate it.
> (Sorry, me stating it needs to "create" DPBs was too vague.)

Can't it just start with the larger amount while trying the new function and reduce if it has to fall back to the old function?

> My previous example Int21.71A0 is called "LFN Get volume information"
> and one of the returned flags is "Supports DOS long filename functions".
> I'd count that as explicit, though you're right: many other interfaces
> don't have explicit checks.

Sure, that one is very explicit - as explicit as it's exceptional. Someone with control of the DOS interface may just have been feeling kind that day or been asked for it by the "right" people.

Back to index page
Thread view  Board view
15108 Postings in 1358 Threads, 246 registered users, 15 users online (0 registered, 15 guests)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum