Hi Christian, > the current DEVLOAD version contains a special check for EDR-DOS, to set > the DPB size to a 4 byte larger value if it's found. (It appends new DPBs > when loading block devices, and therefore needs to know the size of the > DPB.) ...
And there are difficulties knowing whether and which DR or EDR DOS you are in, indeed... Current suggestion is to just always reserve 4 bytes more than MS compatible FAT32 DPBs would need, because there seems to be a wish to make DR compatibility separate from the ability to detect the actual version ;-). > - To improve compatibility regarding the EDPB layout, the EDR-DOS EDPB > will be expanded to contain another additional 2 bytes. DEVLOAD won't work > with this EDR-DOS version. I rather had the impression that Udo was willing to make the MS / EDR FAT32 DPB size difference smaller than the current 4 bytes? :-). That way, adding 2 extra bytes after shaving off 2 others would still keep things working with the "general 4 byte safety margin". > - Other DOS versions might use larger EDPBs Somewhat unlikely, as MS compatible Ext DPBs for FAT32 contain all the fields that a DOS usually needs for FAT32 handling... And of course other DOSes might have more focus on MS compatibility, too. > To solve the problem, DEVLOAD could contain code to detect FAT32-capable > DOS versions that support Int21.7302 by checking this support... Current check is using int 21.3306 get true dos version and saying fat32 is supported if version is at least 7.01... For comparison, WHICHFAT checks for kernel fat32 support via int 21.7300.dl=0.cl=1 and checking if ax is still 7300 on return which means "no fat32". I think / hope this also works if the current drive is not FAT32 or not even FAT? The dl=0 means current drive. Using int 21.7302 can be problematic as it requires a buffer size as input and different DOS versions might need either bigger or exactly-right-sized buffers here... > SETVER-like programs. It could further detect the actual EDPB size using > the supported Int21.7302 then. (When using RBIL as reference, note that > the buffer description of Int21.7302 is wrong. The word at offset 0 is a > returned value only.) This would not require any EDR-DOS check... See above - some other DOS might have used RBIL as reference... > This solution would drop the partial support (only if VERSION= used as > explained above) for EDR-DOS 7.01.07 (and currently released 7.01.08 > WIPs), because this EDR-DOS version returns a smaller, modified EDPB on > Int21.7302. That sounds as if your solution would only work on some versions? > EDR-DOS 7.01.06 wouldn't be supported too, because it uses larger DPBs (2 > bytes larger than the DOS-C and MS-DOS EDPB) and actually supports FAT32 > but doesn't provide the Int21.73 functions at all. That does not really make things easier :-( > It however also doesn't return OEM value EEh on Int21.3000 What does it "normally" return as int 21.3306 version number? > DOS versions that don't provide Int21.7302 (usually aren't capable of > FAT32) but still use a larger DPB than MS-DOS aren't supported by current > DEVLOAD either unless they confirm to the DOS version values for > FAT32-capable MS-DOS versions (> 7.00). If this is the case, the proposed > DEVLOAD version would drop support for these DOS versions. Ahhhh version hell... > I discussed this with Eric and later with Udo. While Udo agreed to change > the EDPB layout of EDR-DOS to more closely match that one of DOS-C and > MS-DOS, and return the actual EDPB on Int21.7302 instead of a modified > one, Eric apparently doesn't want to use a SETVER-independant FAT32 > capability check (the problem affects other DOS versions with SETVER, too) > and an algorithm that safely detects larger EDPBs on FAT32-capable DOS > versions. What do you think of this? Should DEVLOAD work even if SETVER or > a similar program (CALLVER, GIVEVER, etc) is used? Should it allow DOS > versions with larger, further extended EDPBs? Note that if you have to do SETVER DEVLOAD SOMETHING in a way that lowers the "true DOS version" below FAT32-relevant 7.01 then your driver will probably not support FAT32 drives in the first place? Eric ------------------------------------------------------------------------------ Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensign option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects _______________________________________________ Freedos-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freedos-devel
