> Hi, at the risk of talking too much about EDR DOS... Are you afraid of different DOS versions? ;-)
>> 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... Apparently I didn't express it enough, sorry. The new DDSC now uses the word dpbFreeClusterCount (that's what I call it), which is the same as the low word of the dword edpbFreeClusterCount as you mentioned. The high word however isn't used by EDR-DOS (probably set to zero), and the remaining EDPB fields are at the addresses you would expect them for MS-DOS and DOS-C. After the last EDPB field, the DDSC adds the FAT32 version number (one word) and the new field which holds the real number of free clusters for FAT32 (one dword). [The order might be exchanged.] This way, the overall EDPB layout is implemented but dpbFreeClusterCount can still hold a compatibility word value for FAT32-unaware programs even if the drive is FAT32. The drawback is that FAT32-aware programs might read a wrong value (the FAT16 compatibility value) from edpbFreeClusterCount if they get to the DDSC by internal data walking. Udo said he will probably re-write EDR-DOS's 21.7302 handler so that it will return an adjusted EDPB (edpbFreeClusterCount overwritten with the new DDSC field's value, structure shortened to the size of an EDPB) if the buffer size is large enough for that one but not large enough for the true DDSC. >> 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... > > [...] > > 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... > > [...] > >> 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? Yes. The error return register situation, especially for FAT32 functions (21.73) and LFN functions (21.71). Originally, DOS versions which didn't know function numbers that large would default to the MS-DOS 1.x invalid function error code. This means, unaware DOS versions leave CF unchanged (!) and set al=00h (!, only ah unchanged). Aware DOS versions (take MS-DOS 7.10 for FAT32 or MS-DOS 7 with running Windows 4.x for LFN) would provide some of the subfunctions, and invalid subfunctions would return the appropriate MS-DOS 2.x error code. This means, calling f.e. 21.7142 on LFN-capable MS-DOS or Windows versions will result in CF set (!) and ax=0001h (!). If new DOS versions provide some but not all 21.71 or 21.73 subfunctions they might return either the MS-DOS 2.x error code for invalid ones or else the MS-DOS 1.x one, for compatibility reasons. If the DOS supports FAT32 and most Int21.73 functions, it might return the 2.x error code for 21.7300 and .7301. If the DOS doesn't support LFNs (natively) but does support some Int21.71 functions (such as .7142) it might return the DOS 1.x error code for invalid subfunctions as to show unaware programs that there ain't any LFN functions. RBIL doesn't really document this behaviour (that of MS-DOS 6.x and 7.00/7.10) correctly and recommends different (more or less working) methods to detect whether LFNs or FAT32 are supported. Except from checking whether the required 21.71 functions are available, LFN software should also call the LFN volume info call and check whether the LFN flag bit of that particular drive is set, and whether the maximal filename and path length are correct (that is, larger than 12 and 128). Another famous misunderstanding is the 21.5800 memory allocation strategy of "low memory only". It isn't. If the UMB link is enabled (21.5803.bx=1), it turns into "low then upper memory" which can be verified by using the "last fit" or "best fit" strategy. If the UMB link is disabled, I think all strategies are changed to "low memory only" (I have to verify that later). How self-owning PSPs are terminated is only mentioned in a short notice of the Int21.4C description, and RBIL fails to mention that the self-owning PSP termination is handled exactly like a TSR termination. If this was decribed better, DOS-C might have been correct here a long time before someone tried a program abort utility on FreeDOS. The mistake in the buffer description of Int21.7302 might lead developers to think that DOS doesn't return the number of bytes actually required for the EDPB as you mentioned. Another problem arised when I wanted to use Int21.4B01 in a small program. I tried to use the description in RBIL but it lacks the necessary information that the parent's code either has to patch the child's saved Int22 value, or has to patch it's own code at the address the Int21 call returned to because terminating the child will again return to this address. (I first wrote this second solution but the first one is better.) >>> 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. I don't think that someone would do this. The function seems to work very straightforward in MS-DOS and so are the results you can obtain by calling it with different (too large, too small) buffer sizes. >> 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 ;-) Yes, especially since they don't want to be logical in many places if they want to be compatible. >>>> 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 :-). You would probably wait forever ;-) No, I don't think dropping support for two EDR-DOS versions is a large drawback. EDR-DOS 7.01.05 and older versions (no FAT32 support) should still work as they did before. > 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? I guess they are, see below. >> 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... :-) I hope that at least some people still do ;-) 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 Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
