Re: [Freedos-devel] DEVLOAD handling of EDR-DOS EDPBs

[Christian M. <cm...@bt...>]

>> - 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