CG>
  > CG>     FYI there is no such attribute under Watcom 10.x C/C++.
  >
  > JdeBP> Yes, there is.  DosFindFirst is an operating system API, and the
  > JdeBP> parameters to it exist irrespective of C++ compiler (or even of
  > JdeBP> language).
  >
  > Looking at my "generic" help for the _dos_find commands, it has the
  > following attributes listed for the _dos_findfirst command:
  >
  > _A_NORMAL - normal file
  > _A_RDONLY - read only file
  > _A_HIDDEN - hidden file
  > _A_SYSTEM - system file
  > _A_VOLID  - volume ID
  > _A_SUBDIR - subdirectory
  > _A_ARCH   - archive flag
  >
  >     It also states this is for DOS, Windows, Win386, Win32, OS/2 1.x(all),
  > OS/2-32(DOS/PM).
  >
  >     So I believe our confusion lies in the fact that I was not looking at a
  > OS specific calls.  I was looking at the ones that work everywhere.. since
  > like my code being easy to port. :)
CG>

  It is uninformed, narrowminded, and foolish to think that the _dos_xxxx
  functions are "portable" or "generic".  As the name
suggests, they are
  *DOS* functions, and are provided with DOS C++ compilers as wrappers for
  the DOS API (which can only be accessed directly using assembly
  language).

  Functions of the same name are provided with OS/2 C++ compilers for
  downwards compatibility, nothing more.  They are by no means a
  "universal" API, particularly because the OS/2 library versions of many
  _dos_xxxx functions don't work quite as do the DOS library versions.
  The _dos_findfirst function is, ironically, a good case in point.  One
  cannot search a directory for files with a "volume" attribute on OS/2,
  so the _A_VOLID attribute is not "portable" or "generic".

  If you are using _dos_findfirst because you think that they are
  "portable" and "generic", then you have fallen into
the same trap of
  "DOS think" that many newbie programmers coming from DOS sadly do.  The
  reality is that there is _no_ generic or portable way of searching a
  directory.  The  functions from POSIX come close, but,
  ironically, their "least common denominator" design means that they
  don't do enough to be useful in most real world situations, and can
  result in long-winded and highly inefficient code.

  So instead of _gaining_ from stubbornly sticking to the old DOS wrapper
  functions, you are in fact _losing_ by doing so.  Compare the solution
  to the original poster's problem that you propose, of scanning all files
  one by one with _dos_find{first,next} and skipping all of those returned
  that do not have the "subdirectory" attribute, with the code that I
  posted, using DosFindFirst, the MUST_HAVE_DIRECTORY flag, and an 8Kb
  buffer.

  Since the claim to "portability" for the DOS wrapper functions that you
  suggest is completely spurious, there's no disadvantage to using the
  system API directly, and three distinct advantages.

  Firstly, calling DosFindFirst directly, rather than indirectly via
  _dos_findfirst, eliminates a useless extra layer of code, parameter
  massaging, and buffer copying.  Secondly, one can grab multiple (up to
  8Kb in the example) of directory entries in a single call, so reducing
  the number of system calls that the program makes (and on HPFS or a LAN
  this can make a measurable difference in speed).  And thirdly, using the
  MUST_HAVE_DIRECTORY flag allows the filesystem driver itself to skip all
  non-directory entries, which can take place on the fileserver rather
  than the client when a LAN is used, again resulting in a performance
  benefit (and also again reduces the overall number of system calls
  needed to scan an entire directory).

  > JdeBP <
___
 X MegaMail 2.10 #0:
--- Maximus/2 3.01