[Freedos-kernel] Int21.7304.sf03 should actually copy/move FATs
Hi, the kernel is supposed to support all Int21.7304 (Set DPB/BPB fields for formatting) subfunctions but doesn't provide subfunction 03h completely. The current code simply gets (and sets as requested) the flags from the BPB, but doesn't move the FAT accordingly. MS-DOS apparently contains code to do so. This isn't documented in RBIL, but can be tested by setting the active FAT (of a FAT32 drive) to a single one, then resetting the flags to include all FATs later. The second call overwrites the previously inactive FAT(s) with a copy of the active one. (Depending on the size of the file system, this results in a short delay. If this isn't the case, files/directories can be created (changing FAT entries) while only the active FAT is used and dosfsck can be used to insure both FATs have the same content later when the flags were reset.) Regards, Christian -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Int21.7304.sf03 should actually copy/move FATs
2009/8/6 Christian Masloch c...@bttr-software.de: the kernel is supposed to support all Int21.7304 (Set DPB/BPB fields for formatting) subfunctions but doesn't provide subfunction 03h completely. The current code simply gets (and sets as requested) the flags from the BPB, but doesn't move the FAT accordingly. MS-DOS apparently contains code to do so. This isn't documented in RBIL, but can be tested by setting the active FAT (of a FAT32 drive) to a single one, then resetting the flags to include all FATs later. The second call overwrites the previously inactive FAT(s) with a copy of the active one. (Depending on the size of the file system, this results in a short delay. If this isn't the case, files/directories can be created (changing FAT entries) while only the active FAT is used and dosfsck can be used to insure both FATs have the same content later when the flags were reset.) About a month ago I looked at the int21/ah=73 functions and there are a lot of corrections to make, mostly because RBIL is very brief in this area. I found this documentation which says more or less what you tell us too: http://www.thehackademy.net/madchat/vxdevl/vxmags/moonbug05/FAT32_32.HTM The links don't work without manually correcting URLs (case sensitivity!) but this looks like MSDN-style Microsoft documentation. Bart -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
Re: [Freedos-kernel] Int21.7304.sf03 should actually copy/move FATs
Bart Oldeman wrote: 2009/8/6 Christian Masloch c...@bttr-software.de: the kernel is supposed to support all Int21.7304 (Set DPB/BPB fields for formatting) subfunctions but doesn't provide subfunction 03h completely. The current code simply gets (and sets as requested) the flags from the BPB, but doesn't move the FAT accordingly. MS-DOS apparently contains code to do so. This isn't documented in RBIL, but can be tested by setting the active FAT (of a FAT32 drive) to a single one, then resetting the flags to include all FATs later. The second call overwrites the previously inactive FAT(s) with a copy of the active one. (Depending on the size of the file system, this results in a short delay. If this isn't the case, files/directories can be created (changing FAT entries) while only the active FAT is used and dosfsck can be used to insure both FATs have the same content later when the flags were reset.) About a month ago I looked at the int21/ah=73 functions and there are a lot of corrections to make, mostly because RBIL is very brief in this area. I found this documentation which says more or less what you tell us too: http://www.thehackademy.net/madchat/vxdevl/vxmags/moonbug05/FAT32_32.HTM Yeah, the RBIL was mainly used as guide for development of FAT32 support, but MSDN was checked too, though RBIL was more complete on this topic at that time, dunno about MSDN's completeness at present time. We really need more complete docs on FAT32 to support it smoothly. Various bits of the info are spread over the internet here and there. Recovering the truth from these bits are very painful process. Victor Vlasenko -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Freedos-kernel mailing list Freedos-kernel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-kernel
