Hi, have some answers :-). Maybe you can push them
into alt.os.free-dos somehow, in a spam-safe way...

> Google Groups is a nice web<>USENET interface. Have a look at
> http://groups.google.com/group/alt.os.free-dos
> Look for "Kernel Bug" (the first message right now) and
> "FreeDOS Install Language" (third one).

Let me see.... Somebody writes that the 1.0 CD switches to
the wrong language and produces many messages after selecting
"boot from CD drive". He wonders whether this is a bug in
the distro or in his hardware / his copy of the CD or in how
he is using the CD. I think we would need more details to find
out about that. At least some of those messages for example.

In the other mail, Jason Burgon writes that the 1.0 kernel
(2036 stable, that is) function 29h, parse filename into FCB,
returns AL=0, drive is valid, for ALL drives, while it should
return AL=FF for drives which only are in the allowed range
(up to LASTDRIV) but which do not actually exist. For example
it should return FF for "R:" if there is no R: even if the
LASTDRIV value would allow one.

For example EDIT uses "setdisk, then getdisk" to see if
a drive exists. Then it uses int 21.440e and 4409 to check
for fake B: drives and network/ramdisk. For comparison,
FORMAT uses int 21.4409 first, then uses int 21.60 (truename)
with an input string like "R:\" (note the backslash).

The relevant FreeDOS kernel function for int 21.29 is
FcbParseFname which is called with &AL, DS:SI and ES:DI
as input, and the output is returned in SI. It is indeed
lacking code to check for drive validity beyond the
check for lastdrive.

For comparison, COUNT truename(const char FAR * src,
char * dest, COUNT mode) uses get_cds(drivenumber) to
determine if a drive is valid. The check result depends
on some flags in the CDS and on whether there is a DPB
for the drive in question in that case. The CDS is the
table of current directories per drive and includes some
flags, IFS record, and other mixed fields and pointers.

The DPB are, by the way, set during FsConfig and in
update_dcb. I think the latter is when you load drivers.
The DPBp pointer / array holds the drive parameters which
are mostly from the boot sectors. media_check updates it,
using bpb_to_dpb (int 21.53) and rqblockio(C_BLDBPB, dpbp).
This finally calls execrh which jumps to the block device
driver for the drive in question (probably throws an error
for nonexisting drives, too).

Anyway. FcbParseFname should do something with get_cds and
check if the returned pointer is NULL, as done in truename.
That would fix the int 21.29 problem :-). Forwarding to the
kernel list for further discussion.


Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
Freedos-user mailing list

Reply via email to