BB>    I may be completely misreading what you want, Carey, but I am fairly 
sur
BB>that stat() (and sys/stat.h) are common to DOS and the real operating 
system
It is common to DOS and most compilers, since it was a Unix system
function and nearly every compiler since has followed the Unix tradition
even while supplying ANSI/ISO/POSIX support.
However, like with many things about the classic Unix library, there are
differences between implementations.  It may be in what the stat()
function actually returns (for example, many Unix flags have no meaning
in DOS, and some DOS flags doesn't exist in the traditional Unix flags),
or in the names the flags are called (like DJGPP does with some of
them.)
I think POSIX has standardized it, to a point, but many compilers,
especially older ones on other systems, don't have posix stuff.  And I
don't think POSIX even did the directory flag, because there's a file in
the snippets to add that 'semi-standard' flag to the list.
So you can't make it totally portable.  The best you can do is provide
some generic routines and let the user modify it as needed.
BB>The st_mode flag has an S_IFDIR component that can be tested to 
istinguish
BB>between a directory and a regular file.
I am doing that.  (When I originally posted that request, about how to
identify a directory, I had totally forgotten about stat().  I had been
trying to think of a pure ANSI way, or just within the posix opendir
etc. routines.  That's what I get for writing the message late at
night.)  (, of course, what I was really hoping for was that
somebody had already written some portable clones for findfirst /
findnext and would save me the trouble...)
The original purpose of my wanting to be able to identify whether a
filename was a directory or not, was so I could have some portable
findfirst/findnext functions, which don't exist outside of DOS OS's
(such as Unix, Amiga, OS9, Linux, etc.)
Many DOS programs, including the D-Flat CUA interface I'm working on,
make heavy use of it to hunt for files, deal with wildcards, and so on.
D-Flat uses it for the entire file selection process.  The user can
enter a wildcard spec of files to chose from (say *.h), and the file
selection window has to adapt, and if the user does a different
directory or drive, it has to adapt.  It makes heavy use of ff/fn.
Other systems don't always have comparable routines to do that.
On those systems, all they have is probably something akin to the POSIX
opendir/readdir, and using those to try and search for a filename like
DOS does automatically with findfirst/findnext isn't trivial.  (Well, it
isn't _extremely_ hard, but you have to do all the work of going through
file by file, examing each one for the type you want, deal with all the
wildcarding yourself, and so on.)   So that's what my routines do.  It
provides a portable DOS like wildcard findfirst / findnext to every OS
that might need to port some DOS code.  I remember a 'long' time ago,
somebody was trying to port csplit to another OS and was having problems
because they didn't have anything similar to findfirst/findnext on that
OS or in the compiler library.  Now they, and anybody else who might
need it, has some.  And it's enough like how DOS itself does it that the
code they are porting should be able to work with no to few changes to
that area, unlike if they were using their own routines.
The code I posted _is_ rough.  I readily admit that.  But I wanted to
post it while it was still fairly 'generic' and before I modified it a
bit more to suit my purpose, and in case anybody was interested.  I've
already cleaned up several areas, but I don't really see any point in
reposting it since not many people would be interested.
--- QScan/PCB v1.19b / 01-0162
---------------