>> - 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".
No, you misunderstood that. He's going to expand the current EDR-DOS EDPB (call it the [FAT32] DDSC, that's the DR-DOS term "Drive Descriptor") by another 2 bytes, it will be 6 bytes larger than the known EDPB then. >> - 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. Interestingly, Udo wants to use 4 of the mentioned 6 bytes to improve layout compatibility with MS-DOS, but older version (6.x and 7.00 without FAT32). We had an exhausting discussion about that, but he has a point there. (To understand this, examine how the 16-bit and 32-bit "number of free clusters" fields of the DPB and EDPB overlap.) >> 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. This method is not very safe, because Udo apparently didn't think 21.7300 or 21.7301 are required to support FAT32. The purpose of most or all of these flags isn't known so we can only guess about it (or disassemble MS-DOS and completely rebuilt the code, which is no option). I think, since it's all unknown and doesn't seem related to the 'mandatory' drive locking for LFNs, that these flags are only there for usage by Windows 4.x anyway. This is of course just an educated guess, not a fact. We didn't talk about this call yet (because I didn't know you used it), but I'm independently of the same opinion as Udo and will probably not implement 21.7300 and .7301, too. Your "is still 7300h" check could probably still work, since I'd rather return error 0001h if the subfunction isn't supported. Do you check the Carry Flag properly, too? > Using int 21.7302 can be problematic as it requires a buffer size > as input and different DOS versions might need either bigger That's exactly the trouble we have with EDR-DOS. Fortunately, your program can check for an error code of 0018h with Carry Flag set. This error code, "Bad request structure", (which was a "critical error" for Int24 returned by devices only previously) is used by MS-DOS 7.10+ if the buffer size specified in cx is too small. You could even set the buffer size to zero and set the drive value to something invalid (to avoid accessing some random drive if you don't have to), then determine whether the function returned with either ax=0018h, CF set or ax=000Fh, CF set (invalid drive error code). > or > exactly-right-sized buffers here... This is a good reason to try the call only with a very large buffer (like about 512 byte). Exactly-right-sized buffers could be used to preserve compatibility with programs that expect the same EDPB as returned by MS-DOS (and therefore provide a buffer not large enough for the larger custom DPB), but there's no reason a capable DOS version should deny succeeding the function with a buffer which is too large. >> 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... I hope there ain't any of these. Udo admits he previously used and believed the list too much, resulting in some previous incompatibilities of EDR-DOS because RBIL in some places wasn't specific enough or plainly wrong. RBIL is a fine piece of documentation but you have to question all of its content, too. Fortunately I didn't hear of any DOS kernel development lately which could have believed RBIL too strictly, since you know to avoid this now too. >> 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? Yes. This solution would drop the partial support for EDR-DOS 7.01.07 and currently released 7.01.08 WIPs. >> 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? I don't know. Probably still 6.00, or 7.01 too. As mentioned (or didn't I?) EDR-DOS 7.01.06 isn't supported by current DEVLOAD versions either, and I don't see any reason to include special work-arounds into DEVLOAD just to support each old EDR-DOS version. >> 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... This is the reason I avoid using reported-reported or reported-true MS-DOS versions to identify features whenever possible. Quoting your current FAT32 version check of DEVLOAD, which I would replace as discussed above: > Current check is using int 21.3306 get true dos version and saying > fat32 is supported if version is at least 7.01... > 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? Might be that the device happens to be a block device and your DOS version happens to be an actually FAT32-capable one and that your DOS version also happens to want correctly sized EDPBs even for non-FAT32 drives. After all, yes, that's a large "might be". But the reason not to depend on SETVER or true SETVER versions especially in DEVLOAD's code is still valid. Regards, Christian ------------------------------------------------------------------------------ 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
