CB> That would be up to the user to use whatever is available.  When they
 CB> are setting their options etc. for compiling for their platform & OS,
 CB> they can chose to use the portable ones that I provide, or some
 CB> comparable functions if their OS provides it.  It's just that a lot of
 CB> OSs don't even provide comparable functions, so I felt I needed to give
 CB> them some.
Hmmm... snippets... dirport.[ch]... ;-)
DM>have to have a 'findclose' function to facilitate OS/2's thread-safe
DM>built-in-to-the-OS version... :-)
 CB> 
 CB> I'm not quite sure what you are meaning.  I don't have OS/2 installed
 CB> (it's sitting on the shelf, and probably always will since I don't
 CB> have any OS/2 apps or utilities and don't feel the urge to pay $$$
 CB> to get them....) and I've never programmed an OS that had threads built
 CB> in.
Basically, the structures that the OS has are "global" and "numerous".  That 
is ... you can have multiple searches going on simultaneously.  However, that 
means you have to tell the OS you're done so it can reuse the slot later.
 CB> Are you saying that OS/2 has findfirst/findnext, and it also has a
 CB> findclose function?  And that I need to provide a 'dummy' findclose
 CB> function to match?  Or does that function actually need to do something?
It's like fclose - you need to call it.  And I noticed Win32 has the same 
feature.  :-)
 CB> The opendir/readdir/closedir provided by the OS/2 compiler library
 CB> should already be thread safe.  And my findfirst/next don't store any
 CB> static data.  It's all stack or parameter pointers, so it shouldn't care
 CB> about threads.
Ah, but the underlying implementation (the OS) cares... ;-)
 CB> If you can explain it a bit better, I'm willing to see what I can do
 CB> before I post my next and hopefully final version of findfirst/findnext.
See dirport in snippets.  :-)
---
---------------