Xref: utzoo comp.sys.ibm.pc:30509 comp.misc:6394
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!bionet!agate!shelby!helens!relgyro!mike
From: mike@relgyro.stanford.edu (Mike Macgirvin)
Newsgroups: comp.sys.ibm.pc,comp.misc
Subject: Re: DOS directory access
Keywords: function dos c directory
Message-ID: <238@helens.Stanford.EDU>
Date: 23 Jun 89 18:44:35 GMT
References: <33856@tention.uucp>
Sender: news@helens.STANFORD.EDU
Reply-To: mike@relgyro.STANFORD.EDU (Mike Macgirvin)
Distribution: usa
Organization: Stanford Relativity Gyro Experiment (GP-B)
Lines: 44

In article <33856@tention.uucp> pay@tention.uucp (David Gibbs) writes:
>I am about to write a program that needs to find all files and directories
>on a list of drives.  I have reviewed the DOS function calls and found
>"findfirst" and "findnext" will do what I need.  I believe that the OS
>(PCDOS or MS-DOS) already reads a full directory at a time into some
>memory structure under some "reserved" function call.  This seems logical
>since an operator doing a "dir" command will see drive access the first
>time, but a second "dir" does not access the drive.  It would greatly
>speed up my program if I could access the directory information that
>DOS contains, instead of finding each directory entry; one by one.
>I do not want to read the FAT, since I might wish to port this program
>to unix later.
>Does anybody out there know where DOS stores the directory and what
>the structure definition for that memory space is OR is there a function
>call that does this and which one is it and how do I use it?

	Let me get this straight:
  You don't want to access the FAT because of porting issues, but reading
an internal DOS table is OK? How do you port THAT? 
  Oh well, yes DOS actually does store directory info. You can poke through
your system memory and find it. It is stored, I believe, by COMMAND.COM.
Internal commands, such as DIR and CD, can use it, because they know the
address. This is highly dependant on the DOS version, and the location is
almost guaranteed to change with versions of COMMAND.COM. There are no
DOCUMENTED system calls that will touch this, and the UNDOCUMENTED calls
aren't documented because they almost invariably change or go away. As
I recall, the structure of this memory was exactly as it is on the disk.
  To speed up your program, I recommend allocating space for the entire
directory, gobbling it up with one read(), and then you have duplicated
what DOS does. Your program can then scan through this memory as it wishes.
If you are careful about not depending on the internal structure of this
memory, i.e. if all you are after is filenames, you could use the same 
technique under unix.


+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+            These views are my own, and may not be correct.                +
+  Mike Macgirvin                                                           +
+  - Systems Administrator  Stanford Relativity Gyroscope Experiment        +
+  - Internet:              mike@relgyro.stanford.edu (36.64.0.50)          +
+  - Bitnet:                mike%relgyro.stanford.edu@stanford              +
+  - Uucp:                  uunet!relgyro.stanford.edu!mike                 +
+  "There must be some kind of way out of here." - Dylan (w/help from Jimi) +
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++