Hi, Eric reported a FindFirst/FindNext bug here in his message: "[Freedos-kernel] 2035 findfirst bug: attr a8 treated as 08 if local" (I included a part of it below in this message).
When I filed bug 1753 (NetWare VLM invalid opcode upon login, http://www.freedos.org/bugs/bugzilla/show_bug.cgi?id=1753 ), I added my suspicion that it might be invoked by a FindFirst/FindNext quirck. Since 1753 is in the 1.0-todo-list and Eric just mentioned a FindFirst/FindNext problem I thought to give it a shot. >From Eric I received following patches under the remark that it would not be a complete coverage of the FindFirst/FindNext issue he raised here but good enough for testing. Unfortunately it broke "mkdir" so this would need a bit more work than the 3 patch-lines I got from Eric. I can edit, compile and test but it all stops when I need to interprete Kernel-code and invent some modifications (I better not do that ;-) So is anybody out there with Kernel knowledge having some pointers for me (a diff ?) on this (clearing 1753 by brushing up FindFirst/Next) ? Thanks, Erwin [Eric's incomplete patch-proposal] dosfns.c DosFindNext: wrong --> if (dmp->dm_attr_fnd & (D_DEVICE | D_VOLID)) return DE_NFILES; correction --> if (dmp->dm_attr_find & (D_DEVICE)) return DE_NFILES; fatdir.c dos_findfirst: wrong --> if ((attr & (D_VOLID|D_DIR))==D_VOLID) i = 3; correction --> if ((attr & ~(D_RDONLY | D_ARCHIVE))==D_VOLID) i = 3; wrong --> if ((attr & (D_VOLID|D_DIR))==D_VOLID) correction --> if ((attr & ~(D_RDONLY | D_ARCHIVE))==D_VOLID) [From Eric Auer's initial message on FindFirst/Next to this list] > So I would like to report a kernel findfirst bug: > FreeDOS 2035 treats CX value 77a8 like CX value 0008, and returns only > the volume label, for a findfirst for "*.usr" on a local disk. On a > redir disk, no problems happen. Notice that the volume label does not > need to be *.usr to show up - it only has to exist - and that the game > does not need to be in the root directory to trigger this bug! > > For now, I can use a patch: "replace mov cx,dx by mov cl,0" - but > unless FreeDOS accidentally caused the load location & 00de (bits 0 > and 5 of CX are ignored in findfirst), the CONCLUSION for the kernel > should be: ONLY return only the volume label if cx & ffde equals 8. > Current situation seems to be "return only the volume label if cx & > 00de equals 8". ------------------------------------------------------- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 _______________________________________________ Freedos-kernel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/freedos-kernel
