Hi, 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.) Now, that's a fine thing, to support other DOS versions and all, but it has some flaws:
- The EDR-DOS check requires that the first version of (D)CONFIG.SYS VERSION=x.y,z.w is set to a value of 6.00, and that the second version is larger than 7.00. (The default values of 6.00 and 7.01 confirm to this.) - 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. - Other DOS versions might use larger EDPBs (even larger than 67 bytes), too. To solve the problem, DEVLOAD could contain code to detect FAT32-capable DOS versions that support Int21.7302 by checking this support, instead of relying on DOS version numbers that can be modified by VERSION= or 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. I could write this code as a proposal. 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. 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. It however also doesn't return OEM value EEh on Int21.3000 so it currently isn't supported either. 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. 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? * After all, the loaded device driver might want a specific DOS version. So you'd better expect people to use SETVER on DEVLOAD. Regards, Christian ------------------------------------------------------------------------------ _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
