DOS ain't dead

>> - Case DOS 8 ...
>> DOSCode = FFFFh. Seems to be hardwired, HiMem is built-into IO.SYS
>> and DOS is always loaded in the HMA (DOS=LOW has no effect).

> I'd still rather use the other method here. If it works just as well,
> handling MS-DOS 8 separately only adds unnecessary code.

Read again, Mister. The DOS7 method won't work in DOS 8, and vice versa. DOS8 CS=FFFF is hardcoded, it's how they built it. MS-DOS 8 is intended as a launcher for Windows ME, not as a compatible all purpose DOS.

> Also, the
> XMM might find the HMA to be unavailable somehow and the kernel would then
> probably revert to another location.

No, no, no! It's hard coded my friend. The necessary mechanics to load DOS elsewhere have been removed (which also makes DOS8 marginally faster than its predecessor). Do like me, just look at the code (if like me you don't own ME, you can make a DOS 8 diskette from Win XP, or download one from many sites. Just remove the junk and study the code!)

>(Might be due to unknown A20 switch
> method, or only 1 MiB of physical memory.

DOS couldn't load. In the better case they'll output a cryptic message (you must reinstall Windows ME ???), or, as we know Microsoft, might simply crash. I don't know which, care to check ? Use an emulator and somehow break the HMA...

Not that you could find a PC using a totally exotic A20 control method these days.
And ME wasn't supposed to run on a 386. I believe it's "Pentium or better" (Win 95 : 386+, 98: 486DX IIRW).


>> Amusingly Microsoft seems to ignore this fact and includes a copy of
>> HIMEM.SYS on their boot disquettes, which is just wasting space (unless
>> you want to give HIMEM extra parameters, you may delete it).

> Don't they load the internal driver unconditionally (before processing
> CONFIG.SYS), thus rendering the executable completely useless?

My bet is they load the standalone HIMEM, or another XMS driver, as specified in Config.sys. The reason there IS a himem.sys must be precisely to allow specifying special parameters. In the majority of cases nowadays, the built-in HIMEM with default params and A20 method autodetection should work.

Not that I am a regular user of Win-ME (who is ? )


>> - Case DOS 7.x : peek into DOSData, there is

> Where? Or rather: How do you find that table? If I'd want to find it now,
> I'd look at the interrupt vector for one of the unaltered interrupts in my
> debugger. Your way might be able to find the table even with all these
> interrupts hooked.

Yes of course it is and is the reason I choose this way. The interrupt table is the worst possible option, unless you're prepared for hardcore virus-like following and possibly even tracing of the interrupt chains !

>> I think I will provide the source code per request rather than make it
>> downloadable anonymously.

> I'll just state it flat out: I do not agree with this; I don't see a
> reason to exclude the source generally but to make it available per
> request nonetheless. (Of course this still is better than not providing
> source at all, therefore I thank you. I just don't see why not to provide
> it directly.)

I like to get an idea of who requests the code, how many samples, their expectations, and possibly get some feedback. Do you think an informal email request is too much to ask of them ? If it were, rather cast margaritas ante porcos.

It's not like I'm concealing trade secrets, on the contrary, I am set up to explain clearly the hows and whys, namely in answers to this forum, in a manner which I think for most people makes more sense than an assembly listing.

I don't expect more than a handful persons to be really interested in the ASM code (you being an exception!); I'll change my mind in case I'm overwhelmed by a flow of requests

--
Ninho

---
Ninho

Hi, Geoff!

> You perhaps do not have to go as far as finding which segment DOS itself
> uses for addressing its code. Since you have no interest in the address of
> the TEST instruction, you just have to find it with sufficient assurance
> that you have the right one.

Yes I know but I /can/ find that segment easily enough and use it to do checks and locate the exact bounds of the actual code, per MCB and HmaContrlBlock. I prefer exact science, where available, to guesswork and black magic

---
Ninho

> I incline to think that if you go with your method, you may as well leave
> it to the user's responsibility to repeat the loading of your driver as
> the last DEVICE entry. It is just a workaround, after all. If the user is
> unhappy, let him rewrite WRAPPER.SYS.

Couldn't agree more. After all, a user savvy enough to play with WRAPPER.SYS must be capable of RTFMing.

>> Magic_test: TEST Win386flags, MS_mask OR Ninho_bit
>> JNZ skip_unwanted ; jmp if any mask bit(s) is (are) set

> At any time that your bit is set, you make DOS take the jump, and at any
> time your bit is clear, you leave DOS to decide whether to take the jump.
>
> Since you're going to make DOS take the jump, why not just change the
> jump? The bit is redundant. At any time that you would set your bit, just
> change the JNZ to a JMP SHORT, and at any time that you would clear your
> bit, just change the JMP SHORT back to a JNZ.

> Leave the TEST alone. Change the 0x75 to 0xEB.

Yeah, there's more than one way to skin this cat. I still see advantages to having a separate switching bit in the DOS data segment : undoing the fix is then as simple as switching this bit off, no need to replay the code chasing game. Also, I certainly wouldn't /modify system files/ on anonymous clients' disks, but you and me and all the members here, could easily patch the one bit of code in /our/ copies of IO.SYS, once and for all, and then the FIXWRAP becomes as simple as flipping one data bit without all the heuristic work nor magics, black or otherwise. Oh well...

>> and black magic

> I think you'll end up with quite a lot of the latter. What the "exact
> science" points to, over and over, is that the DOS code segment is not
> meant to be found - well, not by anyone but DOS itself.
>
> Besides, what good is it to you to know what segment DOS uses for
> accessing its code? It's just an addressing base. It doesn't tell you
> where the DOS code starts, let alone where it ends. You're going to be
> involved in some heuristics, come what may.

It's not not exact science perhaps, but not too far. I combine the exact CS value that DOS uses (from the yet unmodified SHARE hooks) with the offset of Int27_entry (found at DOSDATA:F8E), and I bet you the "magic test" is fourteen bytes ahead of that! However I do not have to rely on the distance being 14 bytes - in practice though the code from the MTI to int27entry was unchanged in all samples I have examined, from Windows 95 Gold to Windows ME.
(Apart from the magic byte itself being 01 in 95A and 03 later).


>> DOS CS is kept near the start of IO.SYS data area @ 0070:0003.
> It holds the DOS data segment, as far as I ever knew. It was always a
> handy thing to know when debugging.

Yeah sorry. I already noted in another message, it was just brain fart

---
Ninho

> Since you're going to make DOS take the jump, why not just change the
> jump? The bit is redundant.

The more I think of it the more I'm happy with the dual bit option. They play a different role than each other and work together nicely.

The MAGIC_Bit which we patch inside of the DOS kernel signals that the bug fix has been applied; Ninho's flag bit in DOS Data is what is used to SWITCH the fix on and off as instructed per DEVICE=HACKWRAP.SYS directives.

Now examine all the combinations of MAGIC and SWITCH and what they signify to us when we are launching "DEVICE=HACKWRAP ON ".

CASE 00: MAGIC_Bit and Ninho_SWITCH BOTH zero : the DOS is still unpatched (buggy!), this must be the first instance of HACKWRAP, so patch-in the fix and switch Fixwrap on (Set bits to 11)

CASE 10: MAGIC is ON but SWITCHed OFF : the bug fix was applied, but the command bit os off. Maybe there has been a succession of HACKWRAP=ON/OFF invoocations, to be expected if e.g. you have a complex CONFIG.SYS with [MENU] and INCLDE=... directives.

This case may also happen on the first invocation of FIXWRAP, if the IO.SYS file had the MAGIC permanently patched in.

Action : switch Fixwrap ON again. (->11)

CASE 11: Both bits ON : Fixwrap already active, leave as is =11). Warn, no error.

CASE 01: DOS unpatched yet but Ninho's SWITCH bit was ON : is an ERROR. Other software has "owned" Ninho's bit, YELL! and quit. Better not declare war on an unidentified enemy.


I think things are turning out quite nicely. We'll be taking off ASAP....

---
Ninho

> > Installing SHARE.EXE is legitimate under MS-DOS 7.00 and might work with
> a
> > specially written FAT32 SHARE.EXE under MS-DOS 7.10+.
>
> FIXWRAP is executed as a DEVICE= driver installation. The user may well
> INSTALL=SHARE.EXE if s/he likes, we couldn't care less !!!
>
> So evident, we must have been blind.

I don't like this. Say, a user loads FIXWRAP using DEVLOAD. This is of course not what users should do but they are able to. It's just no general solution to find the code segment, even restricting the OS to MS 7+.

I'd suggest you use the far jump at 0:C0 instead (the CP/M "CALL 5" compatibility entry). This either points directly to the DOS code segment or to one of the stubs in the DOS data segment. You can identify the stub and if it's one, you have to retrieve the address that it jumps to in its last instruction; this address points to the DOS code segment. To ensure that this will actually retrieve correct pointers, check that at 0:C0 there is indeed a far jump. You could probably decide where to search for the patch location using the CALL 5 handler instead of the Int27 handler as well.

---
l

> > Look for SHARE.EXE hooks; they're listed in the Int21.52 (DOS data)
> > description.
>
> That listing always puzzled me. I don't believe anyone ever had any
> evidence of any Microsoft code accessing the SHARE hooks relative to the
> address returned by int 21h function 52h. As you noted, SHARE uses
> hard-coded offsets for these pointers (005Ch or 0090h). It's one of those
> programs that know the layout of DOS data depends on the indicator at
> offset 04h.

The Int21.52 description apparently has all the structures from the DOS data segment that didn't fit better at other locations. There are other structures there which aren't closely related to the main SYSVARS.

> I'm pretty sure it doesn't and never has. Once the code's at its final
> position, the segment only has to persist in far pointers that connect
> data to code. For instance, if DOS actually has ended up in the HMA, then
> there's a pointer so that int 21h can get from the stub in low memory to
> the code in high memory, but that pointer otherwise won't be meaningful.
> Of course, in the "otherwise" case, you can find the code segment by other
> ways.

You're correct; in case the code isn't moved to the HMA the interrupt vectors just point into DOS directly.

---
l

> If you really wanted to, you could reliably find the code segment
> experimentally. DOS calls various interrupts, most notably int 2Fh,
> directly from its code wherever its code may be. So, hook int 2Fh and call
> a DOS function that you know will call a particular case of int 2Fh. When
> your hook sees this case, it can look up the return address and save it
> for you. When the DOS function returns, you can unhook. The first one that
> comes to mind is that int 21h function 0Dh always finishes by calling int
> 2Fh function 1120h - but there's surely a better one than that.

Nice and easily applied trick, thank you very much! Didn't you tell you had forgotten you DOS basics

However the principle of least work (or simple=pretty) makes me stick to my current method (pick the DOS CS from the pristine share hooks). Of course I'll switch to using your method IFF someone find a convincing case where mine is in fault - when looking for the kernel CS during drivers init phase, be it clearly stated. I agree your method is the better one to use in the general case.

---
Ninho

>> [...] this step is to please CM [...]
>> Use Int 2F/1000. -> AX=0 or 1, OK for us to continue; else bail out.

> A. The Int2F installation check doesn't return ax, it only returns al.

My bad. Be sure I check every detail when actually coding, the above sketch is just that... a rough sketch done to give you all something to chew (or bite) at

> B. If it returns al = 01h then something strange is going on as well.
> Better to abort.

Disagree. 01 signifies DOS cannot accept SHARE installation at this moment. In no way does it prevent us from setting up FIXWRAP. To us 01 just means SHARE is not installed. Nor do I expect it to ever be installed, again, we're a driver initialising itself. Share is a regular program. At the very soonest your mad tester would load share using WRAPPER (not sure it will work, just hypothesing), and as you know that must come after FIXWRAP !

> C. Int2F.1000 is not reliable. If you really want to please me you
> have to use a reliable installation check.

Postponed.

>> CS from IOSYS share hooks (0070:0092),
> You mean from DATA:0092.

Of course. Good catch, I've edited the posted sketch.

>> IF this routine entry is NOT in the HMA, GOTO step 3 below.

> Make sure to add the offset*16 and segment for this check. An overflow
> (CY) means it's in the HMA.

This is exactly how it is coded, Christian

>As you probably know MS-DOS 7 doesn't use
> segment FFFFh to address it's DOS code segment in the HMA. (FF39h here.)

The exact CS it uses was fetched and found in step 1.

>> -4. TEST and SET Ninho's bit in the MTI. This establishes the fix proper
>> (and could be applied permanently to the IO.SYS file, if desired). If the
> > bit was set already, put a message (notice, rather than an error).

> This notice might annoy those who patched their kernel file. Might just
> leave it out, or at least display it on the same line as the program name.

How's that annoying exactly ? Are you annoyed at every line of scrolling boot-up time messages?
Assuming they are not hidden behind the Windows logo screen, that is.
What's annoying in my book is if a program doesn't give a clue of what it's doing and what maybe going wrong.

Besides, the /sketch/ is that of the test version which we will have to try and make misbehave in all possible manners, so better it details what it's thinking it's doing. The final will have less messages, and may sport a /Quiet switch even.

Thanks for the nits...

---
Ninho