Hi, at the risk of talking too much about EDR DOS... > 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. ... > 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.)
As far as I remember, MS uses a 16 bit "low half" field followed by a 16 bit "high half" field, which can be seen together as one 32 bit field which is truncated after the low half for FAT16... So I still do not understand why Udo used a 16 bit FAT16 field followed by a 32 bit FAT32 field duplicating the data here. Even if he tries to put DIFFERENT values into both copies, it would only help quite specific FAT16 apps to "understand a bit more about that FAT32 drive letter" in specific cases, but would it really be worth introducing extra incompatibilities with EDPB? Adding extra fields AFTER a MS compatible EDPB would have less impact on compatibility imho... >>> To solve the problem, DEVLOAD could contain code to detect FAT32-capable >>> DOS versions that support Int21.7302 by checking this support... > This method is not very safe, because Udo apparently didn't think > 21.7300 or 21.7301 are required to support FAT32... Similar for FreeDOS, but the different return values still show whether you have a FreeDOS with FAT32 which just has no or no full support for 21.7300 or rather a FAT16-only FreeDOS which returns AX etc unchanged for all 21.73xx calls. > 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? Interestingly, MS DOS does NOT use carry in cases where it does return AX unchanged when you call a not supported function... >> 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). Phew this starts sounding as esotheric as the attempts of the current DEVLOAD to detect DR DOS in the first place... There should be some easier way to detect FAT32 and/or DR DOS... >> or exactly-right-sized buffers here... > > This is a good reason to try the call only with a very large buffer I meant some DOSes might do unexpected things if the buffer is not exactly as big as their implementation of 21.7302 wants. > but there's no reason a capable DOS version should deny > succeeding the function with a buffer which is too large. Nobody said DOS implementations had to be logical ;-) > 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 wrong Got some examples? >>> 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. If it only supports future versions, it would not be very useful. Then it would be easier to wait until EDR DOS uses MS EDPB :-). > I don't see any reason to include special work-arounds into DEVLOAD > just to support each old EDR-DOS version. Yet it would be good to support several EDR FAT32 kernels with some sort of a generic solution, even if it wastes a bit of RAM. >> 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... I still do not see why you would SETVER the "true" version to a pre-FAT32 version exactly at the moment when you load a FAT32 disk driver... Because only when you DEVLOAD a FAT32 disk driver the whole EDPB size question becomes relevant at all? Although I am not sure here, FAT16 disk drivers might be affected, too? >> 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. Too complicated, but if somebody on the list still understands what we are talking about, maybe he could make some suggestions... :-) 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
