DM> CB> wildcarding yourself, and so on.)   So that's what my routines do.  
t
DM> CB> provides a portable DOS like wildcard findfirst / findnext to every 
S
DM> CB> that might need to port some DOS code.  I remember a 'long' time ago,
DM>And I hope that your routines will merely call the OS when the OS provides
DM>ff/fn routines... which would necessarily mean that when you're finished, 
yo
That would be up to the user to use whatever is available.  When they
are setting their options etc. for compiling for their platform & OS,
they can chose to use the portable ones that I provide, or some
comparable functions if their OS provides it.  It's just that a lot of
OSs don't even provide comparable functions, so I felt I needed to give
them some.
DM>have to have a 'findclose' function to facilitate OS/2's thread-safe
DM>built-in-to-the-OS version... :-)

I'm not quite sure what you are meaning.  I don't have OS/2 installed
(it's sitting on the shelf, and probably always will since I don't
have any OS/2 apps or utilities and don't feel the urge to pay $$$
to get them....) and I've never programmed an OS that had threads built
in.
Are you saying that OS/2 has findfirst/findnext, and it also has a
findclose function?  And that I need to provide a 'dummy' findclose
function to match?  Or does that function actually need to do something?
The opendir/readdir/closedir provided by the OS/2 compiler library
should already be thread safe.  And my findfirst/next don't store any
static data.  It's all stack or parameter pointers, so it shouldn't care
about threads.
I'm not quite sure what you mean, and what changes I need to make.  (And
frankly, D-Flat itself is only a single thread anyway.)
If you can explain it a bit better, I'm willing to see what I can do
before I post my next and hopefully final version of findfirst/findnext.
--- QScan/PCB v1.19b / 01-0162
---------------