On , Darin McBride (1:250/102@fidonet) wrote: 
 > How is opendir/closedir implemented in the RTL of OS's which have the 
 > findfirst family?  Usually by using the findfirst family.  So you're 
 > going to majorly impact these platforms which probably have highly(!) 
 > optimized findnext routines by not using them.
Darin (& Carey)...
 
  I've been following this with some interest (obviously) and other than 
scavenging Carey's code, I only have a couple of observations...
  First of all, I agree with Carey that DIRPORT.H as it exists in SNIPPETS is 
really confusing - that's why I wrote the DIRPORT.HOW file (I even refer to 
it sometimes!) It's an unfortunate side effect of portability, and 
portability is the only reason for something like DIRPORT to exist in the 
first place.
  Secondly, you're quite right - doing Posix-compliant directory functions in 
a PC OS is a pain - see POSIXDIR.C in SNIPPETS. It's also highly inefficient 
since the OS simply doesn't work that way! Again, the only reason I wrote 
POSIXDIR.C (and the obligatory DIRENT.C) iis for portability.
  Carey's approaching this from the other side, though. As I see it, what 
he's doing is writing a set of PC OS look-alike functions to port PC code to 
*nix. This is just as useful and justfiable as when I wrote POSIXDIR.C to 
port *nix code to PC's.
  What's missing in the exchange so far is where DIRPORT fits into all this. 
The answer, quite simply, is that it doesn't - not directly anyway. DIRPORT 
exists to port code between similar PC OS's - quite a different task than 
porting between incompatible OS's. POSIXDIR actually uses DIRPORT in order to 
allow porting *nix code to various PC OS's.
  OTOH, Carey's implementation of PC-like directory processing on *nix might 
still benefit from a touch of DIRPORT. How so? Simple... If the purpose of 
his find first/next functions is to emulate PC's on a Posix system, then he's 
still faced with the same issue I face when coming from the other side, 
namely various PC compilers and OS's use different syntax. Once he's done, 
will his functions accept Microsoft's or Borland's syntax? It appears he's 
already addressed the multiple PC OS issues, but again it's unclear how his 
package can work as a portability tool if he doesnt' define a common syntax. 
That is specifically what DIRPORT was designed to do, inelegant though it may 
be.
  Of course, I think Carey is already on record as saying that portability, 
per se, is not his goal in this, so my point (if any!) may be moot. 
--- QM v1.00
---------------