How can I read a directory?
Raymond Li
Hello,
I am writing writing a program with Visual C++ 1.0. The program is going
to detect if any files exist in a specific directory. If files are found,
they are copied to somewhere in the Netware server and then the old one is
deleted.
The problem is that I do not know the filename in advance. Therefore, how
can I read the filenames ( with the file creation datetime as well ) of a
directory? Besides, I don't want any dialog box being pop up.
Preferably, I want to do this with Windows API ( 16-bit ). Does anyone has
any ideas? Thanks in advance.
Please drop a line to my mail box as well.
Raymond Li Cheuk Fai, supe...@planet.net.hk
Chris Marriott
In article <01bc8495$a634c140$ad1852ca@raymondl>, Raymond Li
<supe...@planet.net.hk> writes
> The problem is that I do not know the filename in advance. Therefore,
>how
>can I read the filenames ( with the file creation datetime as well ) of a
>directory?
Why do you assume that the fact that you're writing a Windows
application means that the standard C runtime library is mystereously
unavailable to you?
Chris
----------------------------------------------------------------
Chris Marriott, Microsoft Certified Solution Developer.
SkyMap Software, U.K. e-mail: ch...@skymap.com
Visit our web site at http://www.skymap.com
Lawrence Kirby
In article <ybJV6DAS...@chrism.demon.co.uk>
ch...@chrism.demon.co.uk "Chris Marriott" writes:
>In article <01bc8495$a634c140$ad1852ca@raymondl>, Raymond Li
><supe...@planet.net.hk> writes
>> The problem is that I do not know the filename in advance. Therefore,
>>how
>>can I read the filenames ( with the file creation datetime as well ) of a
>>directory?
>
>Why do you assume that the fact that you're writing a Windows
>application means that the standard C runtime library is mystereously
>unavailable to you?
The standard C library doesn't have any support for directories so it isn't
going to be much help here. The main problem with the original article is
that it is grossly over cross-posted.
--
-----------------------------------------
Lawrence Kirby | fr...@genesis.demon.co.uk
Wilts, England | 7073...@compuserve.com
-----------------------------------------
Chris Marriott
In article <867606...@genesis.demon.co.uk>, Lawrence Kirby
<fr...@genesis.demon.co.uk> writes
>The standard C library doesn't have any support for directories so it isn't
>going to be much help here. The main problem with the original article is
>that it is grossly over cross-posted.
You are of course quite right. What I meant to say is that you read the
directory in a 16-bit Windows application in exactly the same way you'd
do it for a DOS application, by using the appropriate C RTL functions.
Chris Marriott
fred@genesis.demon.co.uk (Lawrence Kirby)
>In article <01bc8495$a634c140$ad1852ca@raymondl>, Raymond Li
><supe...@planet.net.hk> writes
>> The problem is that I do not know the filename in advance. Therefore,
>>how
>>can I read the filenames ( with the file creation datetime as well ) of a
>>directory?
>
>Why do you assume that the fact that you're writing a Windows
>application means that the standard C runtime library is mystereously
>unavailable to you?
The standard C library doesn't have any support for directories so it isn't
going to be much help here. The main problem with the original article is
that it is grossly over cross-posted.
--
Chris Marriott
In article <01bc8495$a634c140$ad1852ca@raymondl>, Raymond Li
<supe...@planet.net.hk> writes
> The problem is that I do not know the filename in advance. Therefore,
>how
>can I read the filenames ( with the file creation datetime as well ) of a
>directory?
Why do you assume that the fact that you're writing a Windows
application means that the standard C runtime library is mystereously
unavailable to you?
Chris
Raymond Li
Hello,
I am writing writing a program with Visual C++ 1.0. The program is going
to detect if any files exist in a specific directory. If files are found,
they are copied to somewhere in the Netware server and then the old one is
deleted.
The problem is that I do not know the filename in advance. Therefore, how
can I read the filenames ( with the file creation datetime as well ) of a
Worf
Dear Raymond,
within any Win App you may use C-libraries from your compiler package.
You may find a function called _dos_findfirst() and _dos_findnext()
or similar.
These functions will do the job ...
cu,
Alex
--
// To reply remove the double dagger (#) from my email address
//
Lawrence Kirby
In article <5pbdvj$2...@airdmhor.gen.nz> gumboot@localhost "Simon Hosie" writes:
>Lawrence Kirby:
>> The standard C library doesn't have any support for directories so it isn't
>> going to be much help here.
>
> What do opendir() and readdir() not do? I mean, sure they're not actually
>ANSI,
Hence they aren't part of the standard C library, hence my comment that
the standard C library isn't going to be much help.
>but they're a whole lot more portable than _dos_findfirst() and
>_dos_findnext().
Perhaps, but questionable when considered against the general flavour
of newsgroup this is being cross-posed to. Either way my comment is correct.
gumboot@localhost (Simon Hosie)
Lawrence Kirby:
> The standard C library doesn't have any support for directories so it isn't
> going to be much help here.
What do opendir() and readdir() not do? I mean, sure they're not actually
ANSI, but they're a whole lot more portable than _dos_findfirst() and
_dos_findnext().
--
"gumboot\100airdmhor\056gen\056nz"
Cynthia Ledbetter
What is the best book to buy for advanced ASM?
Paul Mesken
>What is the best book to buy for advanced ASM?
Gee, what a MASSIVE cross post (you'd better posted this to c.l.a.x86
only).
"Advanced" ASM means optimization in respect to speed. Get the
Application Note about optimization from Intel's web site (it's free)
at: http://www.intel.com/design/litcentr/litweb/pntmii.htm (in the old
days (6 weeks ago or something) we would have said:AP 526).
Also Abrash's book "The Zen of Code Optimization" offers a nice taste
of code optimization (but now it's mostly obsolete since it goes to
Pentium only)
"I _know_ what partial register stalls are but I
want my compiler to know it as well!"
usu...@euronet.nl Paul Mesken aka Technocrate
Stephan Wilms
Cynthia Ledbetter wrote:
>
> What is the best book to buy for advanced ASM?
If I look at the massive and ugly crosspost, your question, and the
previous question that you replied to (did you notice that ?) I
fear that this thread will lead to *ANYTHING*.
Please have a look at the FAQ of comp.lang.asm.x86. If it's worth the
paper it's not written on, it will contain some book recommendations.
Stephan
(initiator of the campaign against grumpiness in c.l.c)
gumboot@localhost (Simon Hosie)
Lawrence Kirby:
> The standard C library doesn't have any support for directories so it isn't
> going to be much help here.
> What do opendir() and readdir() not do? I mean, sure they're not actually
> ANSI,
> Hence they aren't part of the standard C library, hence my comment that
Oh bugger off, how many modern commercial compilers don't supply POSIX
calls?
> Perhaps, but questionable when considered against the general flavour
> of newsgroup this is being cross-posed to. Either way my comment is correct.
Which? Comp.lang.c? You're not going to tell me that their "It's not
ANSI, it doesn't belong here" attitude won't even accept POSIX.
--
Name="gumboot", Site="airdmhor", Type="general", Country="New Zealand";
printf("%s@%s.%3.3s.%c%c", Name, Site, Type, Country[0], Country[4]);
Lawrence Kirby
In article <5pffpb$1...@airdmhor.gen.nz> gumboot@localhost "Simon Hosie" writes:
>Lawrence Kirby:
>> The standard C library doesn't have any support for directories so it isn't
>> going to be much help here.
>Simon Hosie:
>> What do opendir() and readdir() not do? I mean, sure they're not actually
>> ANSI,
>Lawrence Kirby:
>> Hence they aren't part of the standard C library, hence my comment that
>> the standard C library isn't going to be much help.
>
> Oh bugger off, how many modern commercial compilers don't supply POSIX
>calls?
What DOS, Win3.1 or Win95 compiler supports POSIX? POSIX tends to be
something that is associated with the platform rather than the specific
compiler (although of course a compiler could support it even when the
OS doesn't directly).
However what particular compilers support is irrelevant; even if every C
compiler supported POSIX it doesn't make POSIX functions part of the standard
C library. That is something very specific that is defined by an
international standard.
>> Perhaps, but questionable when considered against the general flavour
>> of newsgroup this is being cross-posed to. Either way my comment is correct.
>
> Which? Comp.lang.c? You're not going to tell me that their "It's not
>ANSI, it doesn't belong here" attitude won't even accept POSIX.
No, most of the newsgroups here are Microsoft related (noting win16 and
win95 parts which suggests this is not NT related).
You are correct however that POSIX is not an appropriate topic for
discussion in comp.lang.c, POSIX is an OS interface standard which is
heavily Unix centred. In the absense of a dedicated POSIX newsgroup probably
the best newsgroup to discuss POSIX is comp.unix.programmer (where POSIX
discussion is certainly on topic).
Cecil A. Galbraith
Raymond Li wrote:
>
> Hello,
> I am writing writing a program with Visual C++ 1.0. The program is going
> to detect if any files exist in a specific directory. If files are found,
> they are copied to somewhere in the Netware server and then the old one is
> deleted.
>
> The problem is that I do not know the filename in advance. Therefore, how
> can I read the filenames ( with the file creation datetime as well ) of a
> directory? Besides, I don't want any dialog box being pop up.
>
> Preferably, I want to do this with Windows API ( 16-bit ). Does anyone has
> any ideas? Thanks in advance.
>
> Please drop a line to my mail box as well.
>
> Raymond Li Cheuk Fai, supe...@planet.net.hk
Generally, you use the findfirst and findnext calls from the standard C
library. Use an asterisk for the file mask for searching and these two
calls will find everything in the directory.
Cecil
--
Cecil Galbraith
CustomSoft mail to cgal...@concentric.net
Free programmer's utilities and MFC tips at
http://www.concentric.net/~cgalbrai
scs@eskimo.com (Steve Summit)
[followups limited to just comp.lang.c, comp.os.ms-windows.programmer.misc,
and microsoft.public.vc.mfc]
In article <867943...@genesis.demon.co.uk>, fr...@genesis.demon.co.uk writes:
> In article <5pffpb$1...@airdmhor.gen.nz> gumboot@localhost
> "Simon Hosie" writes:
>> Lawrence Kirby:
>>> The standard C library doesn't have any support for directories so
>>> it isn't going to be much help here.
>> Simon Hosie:
>>> What do opendir() and readdir() not do? I mean, sure they're not
>>> actually ANSI,
>> Lawrence Kirby:
>>> Hence they aren't part of the standard C library, hence my comment that
>>> the standard C library isn't going to be much help.
>>
>> Oh bugger off, how many modern commercial compilers don't supply
>> POSIX calls?
>
> What DOS, Win3.1 or Win95 compiler supports POSIX?
Or, even simpler, what DOS and Windows compilers support opendir
and readdir? These calls are widely believed to be "Unix-only"
and to be unavailable under DOS and Windows. DOS and Windows
programmers usually use findfirst and findnext, and can regularly
be heard asking for Unix versions of those functions so that they
can port their DOS and Windows code to Unix.
MS-DOS (and, I presume, Windows) implementations of opendir and
readdir do exist (I've written a couple myself), but this fact
does not seem widely known, and I think I've only ever heard of
one compiler (details now forgotten) which supported them
out-of-the-box.
If I'm wrong, if opendir and readdir *are* now widely available
in the run-time libraries shipped with DOS and Windows C
compilers, I'd be glad to hear it, and to retract my pessimistic
assertions.
Steve Summit
s...@eskimo.com
Lawrence Kirby
In article <33BE1F...@concentric.net>
cgal...@concentric.net "Cecil A. Galbraith" writes:
...
>Generally, you use the findfirst and findnext calls from the standard C
>library. Use an asterisk for the file mask for searching and these two
>calls will find everything in the directory.
As previosuly noted in the thread there are no findfirst or findnext
functions in the standard C library, although your implementation might
provide them as extensions to the language.
Pete Becker
it seems to me they've been there for some time now. The header has an
initial copyright date of 1991, which suggests that they were added at
that time.
-- Pete
Chris Marriott
In article <5plha9$7pv$1...@eskinews.eskimo.com>, Steve Summit
<s...@eskimo.com> writes
>MS-DOS (and, I presume, Windows) implementations of opendir and
>readdir do exist (I've written a couple myself), but this fact
>does not seem widely known, and I think I've only ever heard of
>one compiler (details now forgotten) which supported them
>out-of-the-box.
>
>in the run-time libraries shipped with DOS and Windows C
>compilers, I'd be glad to hear it, and to retract my pessimistic
>assertions.
I believe that Borland support them, but Microsoft don't.
In the 32-bit Windows world, they aren't necessary, because the
operating system itself offers directory-handling functions, so there's
no need to use the C RTL at all for that purpose.
Lawrence Kirby
In article <fbUeqIAv...@chrism.demon.co.uk>
ch...@chrism.demon.co.uk "Chris Marriott" writes:
...
>>If I'm wrong, if opendir and readdir *are* now widely available
>>in the run-time libraries shipped with DOS and Windows C
>>compilers, I'd be glad to hear it, and to retract my pessimistic
>>assertions.
>
>I believe that Borland support them, but Microsoft don't.
>
>In the 32-bit Windows world, they aren't necessary, because the
>operating system itself offers directory-handling functions,
They are necessary if you want to write POSIX code, previous posters
suggested that providing a good vehicle for portability.
>so there's no need to use the C RTL at all for that purpose.
If software development is going to progress there is a string need to
standardise the basics. It is rather sad to see somebody simply disregard
what standards there are in favour of some unspecified propietary interface.
Anyway how do you typically call OS functions in a C implementation
other that through the C implementation's RTL?
Dan Pop
>If I'm wrong, if opendir and readdir *are* now widely available
>in the run-time libraries shipped with DOS and Windows C
>compilers, I'd be glad to hear it, and to retract my pessimistic
>assertions.
No such thing in MS VC++ 4.2, according to the on-line documentation.
Dan
--
Dan Pop
CERN, IT Division
Email: Dan...@cern.ch
Mail: CERN - PPE, Bat. 31 1-014, CH-1211 Geneve 23, Switzerland
Chris Marriott
In article <868218...@genesis.demon.co.uk>, Lawrence Kirby
<fr...@genesis.demon.co.uk> writes
>>In the 32-bit Windows world, they aren't necessary, because the
>>operating system itself offers directory-handling functions,
>
>They are necessary if you want to write POSIX code, previous posters
>suggested that providing a good vehicle for portability.
As has already been said, POSIX is a standard in the *Unix* world, not
the Windows world. NT doesn't descend from the same "architectural
family tree" as Unix - if it can be said to have "roots" at all, they
lie in VAX/VMS. I see no reason why NT *should* attempt to emulate Unix
- most Windows programmers don't come from a Unix background!
>
>>so there's no need to use the C RTL at all for that purpose.
>
>If software development is going to progress there is a string need to
>standardise the basics. It is rather sad to see somebody simply disregard
>what standards there are in favour of some unspecified propietary interface.
>
>Anyway how do you typically call OS functions in a C implementation
>other that through the C implementation's RTL?
In a Windows application, operating system APIs are called directly via
their "entry points" in the dynamic link libraries which comprise the
operating system. This is completely independent of the language used,
and has nothing whatsoever to do with the C RTL.
Lawrence Kirby
In article <SiFN0EAX...@chrism.demon.co.uk>
ch...@chrism.demon.co.uk "Chris Marriott" writes:
>In article <868218...@genesis.demon.co.uk>, Lawrence Kirby
><fr...@genesis.demon.co.uk> writes
>>>In the 32-bit Windows world, they aren't necessary, because the
>>>operating system itself offers directory-handling functions,
>>
>>They are necessary if you want to write POSIX code, previous posters
>>suggested that providing a good vehicle for portability.
>
>As has already been said, POSIX is a standard in the *Unix* world,
POSIX is an IEEE standard. It is certainly Unix based and all UNIX(tm)
system are required to be POSIX compliant. That doesn't mean that other
OSs can't be POSIX compliant too.
>not
>the Windows world. NT doesn't descend from the same "architectural
>family tree" as Unix - if it can be said to have "roots" at all, they
>lie in VAX/VMS. I see no reason why NT *should* attempt to emulate Unix
>- most Windows programmers don't come from a Unix background!
Microsoft appear to disagree with you. AFAIK they supply a POSIX environment
for NT.
>>>so there's no need to use the C RTL at all for that purpose.
>>
>>If software development is going to progress there is a string need to
>>standardise the basics. It is rather sad to see somebody simply disregard
>>what standards there are in favour of some unspecified propietary interface.
>>
>>Anyway how do you typically call OS functions in a C implementation
>>other that through the C implementation's RTL?
>
>In a Windows application, operating system APIs are called directly via
>their "entry points" in the dynamic link libraries which comprise the
>operating system. This is completely independent of the language used,
>and has nothing whatsoever to do with the C RTL.
That depends what type of Windows application you are talking about. Anyway
you appear to be saying that Windows is just one big C RTL.
Canada Bass
On 5 Jul 1997 13:13:45 GMT, s...@eskimo.com (Steve Summit) wrote:
>MS-DOS (and, I presume, Windows) implementations of opendir and
>readdir do exist (I've written a couple myself), but this fact
>does not seem widely known, and I think I've only ever heard of
>one compiler (details now forgotten) which supported them
>out-of-the-box.
>
>If I'm wrong, if opendir and readdir *are* now widely available
>in the run-time libraries shipped with DOS and Windows C
>compilers, I'd be glad to hear it, and to retract my pessimistic
>assertions.
>
> Steve Summit
> s...@eskimo.com
From the number of responses to this remark(mine too), I would say
that opendir() and readdir() are fairly wide used. In fact, I use
(call me cheap) DJGPP and have support for both... :)
Canada Bass
SonicD
On 5 Jul 1997 13:13:45 GMT, s...@eskimo.com (Steve Summit) wrote:
>[followups limited to just comp.lang.c, comp.os.ms-windows.programmer.misc,
>and microsoft.public.vc.mfc]
>
>In article <867943...@genesis.demon.co.uk>, fr...@genesis.demon.co.uk writes:
>> In article <5pffpb$1...@airdmhor.gen.nz> gumboot@localhost
>> "Simon Hosie" writes:
>>> Lawrence Kirby:
>>>> The standard C library doesn't have any support for directories so
>>>> it isn't going to be much help here.
>>> Simon Hosie:
>>>> What do opendir() and readdir() not do? I mean, sure they're not
>>>> actually ANSI,
>>> Lawrence Kirby:
>>>> Hence they aren't part of the standard C library, hence my comment that
>>>> the standard C library isn't going to be much help.
>>>
>>> Oh bugger off, how many modern commercial compilers don't supply
>>> POSIX calls?
>>
>> What DOS, Win3.1 or Win95 compiler supports POSIX?
>
>Or, even simpler, what DOS and Windows compilers support opendir
>and readdir? These calls are widely believed to be "Unix-only"
>and to be unavailable under DOS and Windows. DOS and Windows
>programmers usually use findfirst and findnext, and can regularly
>be heard asking for Unix versions of those functions so that they
>can port their DOS and Windows code to Unix.
>
>MS-DOS (and, I presume, Windows) implementations of opendir and
>readdir do exist (I've written a couple myself), but this fact
>does not seem widely known, and I think I've only ever heard of
>one compiler (details now forgotten) which supported them
>out-of-the-box.
>
>If I'm wrong, if opendir and readdir *are* now widely available
>in the run-time libraries shipped with DOS and Windows C
>compilers, I'd be glad to hear it, and to retract my pessimistic
>assertions.
>
> Steve Summit
> s...@eskimo.com
?
Bob Stout
On Tue, 8 Jul 1997, SonicD wrote:
> >MS-DOS (and, I presume, Windows) implementations of opendir and
> >readdir do exist (I've written a couple myself), but this fact
> >does not seem widely known, and I think I've only ever heard of
> >one compiler (details now forgotten) which supported them
> >out-of-the-box.
> >
> >If I'm wrong, if opendir and readdir *are* now widely available
> >in the run-time libraries shipped with DOS and Windows C
> >compilers, I'd be glad to hear it, and to retract my pessimistic
> >assertions.
Steve, it depends on how you define "widely available". SNIPPETS contains
an implementation of opendir(), closedir(), readdir(), seekdir(),
telldir(), and rewinddir(). These are not notably efficient, but they are
portable since each also uses SNIPPETS's DIRPORT.H which provides a common
syntax across all major compilers for DOS, Win32, and OS/2.
Hopefully, the compiler vendors will begin making these more generally
available in their standard libraries, which would obviate some of the
inefficiencies in the SNIPPETS implementation. As it stands, the only
thing the compiler vendors can be counted on doing is putting in some
half-assed version of dirent.h which winds up conflicting with any *real*
implementation.
-------------------------------------------------------------
MicroFirm: Down to the C in chips...
FidoNet 1:106/2000.6
Internet r...@snippets.org
Home of SNIPPETS - Current release:
ftp://snippets.org/pub/snippets/snip9707.zip & snip9707.tar.gz
http://www.snippets.org/
juge.com:/c/snip9707.lzh
PDN nodes (SNIP9707.RAR) and SimTel mirror sites
Chris Marriott
In article <868313...@genesis.demon.co.uk>, Lawrence Kirby
<fr...@genesis.demon.co.uk> writes
>Microsoft appear to disagree with you. AFAIK they supply a POSIX environment
>for NT.
You're right; there is a POSIX subsystem in NT. It exists for one
purpose and one purpose alone - to allow people such as the US
government who require POSIX-conformance in computer systems to buy NT
systems.
The POSIX subsystems on NT is an rigid and strict implementation of the
POSIX 1003.2 standard - ie it implements exactly and ONLY what that
standard dictates - no graphics, no networking, no just about anything!
The POSIX subsystem can be used to write Unix "cat" clones, but that's
about it. Nobody uses NT's POSIX subsystem - it's not really there to be
used.
>>>Anyway how do you typically call OS functions in a C implementation
>>>other that through the C implementation's RTL?
>>
>>In a Windows application, operating system APIs are called directly via
>>their "entry points" in the dynamic link libraries which comprise the
>>operating system. This is completely independent of the language used,
>>and has nothing whatsoever to do with the C RTL.
>
>That depends what type of Windows application you are talking about. Anyway
>you appear to be saying that Windows is just one big C RTL.
No, that's not what I'm saying at all. The Windows "import libraries"
which provide access to the functions exported by Windows have
absolutely nothing to do with the C runtime library, any more than, say,
the socket library on a Unix implementation is a part of the C runtime
library. In both cases they are a library which you link with a C
program, but they are NOT the C runtime library!
Simon Harris
> On 5 Jul 1997 13:13:45 GMT, s...@eskimo.com (Steve Summit) wrote:
> >Or, even simpler, what DOS and Windows compilers support opendir
> >and readdir? These calls are widely believed to be "Unix-only"
> >and to be unavailable under DOS and Windows. DOS and Windows
> >programmers usually use findfirst and findnext, and can regularly
> >be heard asking for Unix versions of those functions so that they
> >can port their DOS and Windows code to Unix.
> >
> >MS-DOS (and, I presume, Windows) implementations of opendir and
> >readdir do exist (I've written a couple myself), but this fact
> >does not seem widely known, and I think I've only ever heard of
> >one compiler (details now forgotten) which supported them
> >out-of-the-box.
> >
> >If I'm wrong, if opendir and readdir *are* now widely available
> >in the run-time libraries shipped with DOS and Windows C
> >compilers, I'd be glad to hear it, and to retract my pessimistic
> >assertions.
> >
> > Steve Summit
> > s...@eskimo.com
>
opendir() and readdir() were provided in Borland C V3.1 (I don't
know about earlier or later versions), and claim to work in both
DOS and Windows run-time environments.Could that be the compiler
you were thinking of?
Simon.
Steve Summit
[followups to comp.lang.c only]
A week or so ago, in article <fbUeqIAv...@chrism.demon.co.uk>,
Chris Marriott (ch...@chrism.demon.co.uk) wrote:
>In article <5plha9$7pv$1...@eskinews.eskimo.com>, Steve Summit
><s...@eskimo.com> writes
>> MS-DOS (and, I presume, Windows) implementations of opendir and
>> readdir do exist... but... I think I've only ever heard of
>> one compiler which supported them out-of-the-box.
>
> I believe that Borland support them, but Microsoft don't.
That's the impression I'm getting. (Good for Borland!)
> In the 32-bit Windows world, they aren't necessary, because the
> operating system itself offers directory-handling functions,
> so there's no need to use the C RTL at all for that purpose.
Unless you care about portability to systems other than
32-bit Windows.
In the C programming world, opendir and readdir are de facto
standards for reading directories in a system-independent way,
just as fopen and getc et al. are de jure standards for reading
files in a system-independent way.
Whenever I have to port a directory-reading, opendir-using
program to a system without opendir/readdir, I don't modify
the program to make it use the new system's official directory-
handling functions. Instead, I write myself a new version of
opendir/readdir (based of course on the new system's official
directory-handling functions). Not only does this make porting
the one program easier (no cumbersome #ifdef's), but the new
opendir/readdir implementation will of course also make porting
all other opendir-using programs easier.
Steve Summit
s...@eskimo.com