GW>>> [...] there are no major extensions to the MS/PCDOS interface 
 GW>>> since DOS 3.3, [...]
 JDBP>> I'd say that the new file open API introduced in DOS 4.0 is
 JDBP>> "major".  The ability to create a file *and* specify a sharing
 JDBP>> mode in one atomic operation is very useful for LANs.
 JDBP>>
 JDBP>> The only problem is that most DOS C libraries' implementations of
 JDBP>> fopen() have never been updated to use this new function, and
 JDBP>> still use a CREAT/OPEN pair, complete with race conditions. (The C
 JDBP>> library that I wrote used the DOS 4.0 API, of course.)
 GW> According to Ralf Brown's interrupt list there are problems with that
 GW> API on LANS using the INT 2F redirector. Maybe that's why the
 GW> compiler library writers avoid it, as well as the backwards
 GW> compatibility.
I doubt it.  The "action taken" status returned in CX has no counterpart in 
the DOS 3.3 API in the first place, so the fact that it isn't returned 
properly by the INT 2Fh redirector isn't a consideration if one is simply 
looking to replace a pair of calls to INT 21h/3Dh and INT 21h/3Ch.  One 
certainly wouldn't need to query that value if one were implementing fopen(). 
 I speak as one who *has* implemented fopen() over the top of this exact 
ll.
I'd say that the *real* reason that the compiler libraries still use the two 
DOS 3.3 calls, complete with race condition, rather than the single atomic 
DOS 4.x call, is that by the time one could safely say that the DOS 4.0 API 
had become the lowest common denominator, compiler library development 
manpower was no longer being expended on DOS at all.
 ¯ JdeBP ®
--- FleetStreet 1.19 NR
---------------