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. Eric ------------------------------------------------------------------------- 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 http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
