Re: New Kernel Bug (a small one)

Hi Bart,

> well this turned out to be really a bug in NDN and not the kernel.
> 
> NDN does:
> 
> INT21 (0) at 456b:0207: AX=4409, BX=0043, CX=004c, DX=6143, DS=297f, ES=3771
> check if block device remote
> 
> Here it has 0x43 in BL which corresponds, following RBIL, to drive
> 0x40+0x43=0x83. 0x83 gives you that weird looking drive letter.
> 
> So the FreeDOS kernel says that the drive is out of range and NDN
> investigates this as a critical error. The same happens with MSDOS 7.1
> (aka Win98 DOS) and DRDOS 7.03 btw. I'm not sure about other DOSes.
> 
> Now we can easily work around this:
> 
> --- ke2027rc/kernel/ioctl.c Mon Oct 21 22:40:18 2002
> +++ ke2027/kernel/ioctl.c Mon Oct 28 22:05:20 2002
> @@ -199,7 +199,8 @@
>  /* JPP - changed to use default drive if drive=0 */
>  /* JT Fixed it */
> 
> -      CharReqHdr.r_unit = (r->BL == 0 ? default_drive : r->BL - 1);
> +      CharReqHdr.r_unit = ((r->BL & 0x1f) == 0 ? default_drive :
> +                           (r->BL & 0x1f) - 1);
> 
>        dpbp = get_dpb(CharReqHdr.r_unit);
> 
> But I'm not sure if this is a good idea ... We want MSDOS
> compatibility, not broken DOS utility compatibility.

That is not the case: NDN 2.02 Real Mode does not have this error
in MS-DOS. (I just tested it again in a Win98 dos box, just to make sure)
In fact I have been using it in many machines for some time and with many
flavors od DOS. I usualy install this version in clients machines because 
it is smaller and being RM it is less prone to problems.

The sad thing is that there isn't any newer Real Mode version. 

Are you sure that you got this behaviour with MS-DOS 7.1? 
Please tell me how you tested it?

> In the changelog at http://www.necromancer.newmail.ru/ I read for the 2.03
> prerelease:

Only version I found there of 2.03 is dpmi16. Do you have a 2.03 RM? 
I would like very much to get it.

> - Critical Error on drive ? bug fixed (at least in my machine)
> Indeed they had this bug in NDN. Any opinions?

I agree that it the bug is in the application, it is not for the
kernel to solve it, _but_ there are some cases that are marginal:
If I understood correctly the fix you sent, you are proposing
to ignore the unused bits in that call to Int21. It looks to me
that this can be considered an unharmfull extention to DOS,
but I don't have enough knowledge to say if it is 100% harmless.
If this is so, and everybody that has the knowledge say it is ok,
then I believe it can be ok.

There is another possibility: maybe this wrong value in BL comes from
another call to the kernel that gave a bad answer, do you believe in this?
Unfortunatly Necromancer has been hard to find lately.

The other side of the coin: NDN is the only really good (and free) navigator
for FreeDOS.

Alain