Are there any API functions to open directory, get file number and all filenames? And other functions to work with directories?
Posted on 2004-05-20 07:18:18 by Vaxon
FindFirstFile(), FindNextFile(), FindClose()
Posted on 2004-05-20 07:46:39 by Scali
The folder apis are a pain in the butt to use. When using the FindFirst/NextFile apis Windows will return the . and .. folders as well, so don't be suprised if you see those. If you are doing a folder recursive search, you definatly do not want to process those two folders.

The directory APIs are here
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/base/directory_management_functions.asp
Posted on 2004-05-20 18:56:01 by Mecurius
This is from my files library, it will allow you to pass the files recursively to a callback one at a time. You have only to pass a root folder and return TRUE to continue the enumeration. It is based on Ketil's TreeViewDir.

/*

RecurseFolder:
This is a callback function that will list all files in a folder
Parameters:
lpPth = Pointer to a fully qualified path
pCallback = Pointer to a call back function
fRecurse = Set to TRUE to recurse the directory
The function will send the filenames to the callback one at a time
Format for callback:
RecurserFolderProc:
pFileName = A pointer to the filename being enumerated
dwAttributes = File attributes
The callback returns false to stop the enumeration
Returns the count of enumerated files
*/

.data
rfpszBuffer db MAX_PATH DUP (?)
rfpwfd WIN32_FIND_DATA <?>
rfpszSearchString db MAX_PATH DUP (?)
rfpfEndProc dd 1
rfpnFileEnum dd 0
rfpBkSColon db "\*",0

.code

RecurseFolder FRAME lpPth,pCallback,fRecurse

mov D[rfpfEndProc],1
mov D[rfpnFileEnum],0
invoke xRecurseFolder,[lpPth],[pCallback],[fRecurse]

mov eax,[rfpnFileEnum]
RET
ENDF

xRecurseFolder FRAME lpPth,pCallback,fRecurse
LOCAL hwfd :D

cmp D[rfpfEndProc],0
je >>E2
invoke lstrcpyA,addr rfpszBuffer,[lpPth]
invoke lstrcatA,addr rfpszBuffer,offset rfpBkSColon
invoke FindFirstFileA,addr rfpszBuffer,addr rfpwfd
cmp eax,INVALID_HANDLE_VALUE
je >>E2
;Save returned handle
mov [hwfd],eax
N1:
;Check if found is a dir
mov eax,[rfpwfd.dwFileAttributes]
test eax,FILE_ATTRIBUTE_DIRECTORY
jz >>C1
cmp D[fRecurse],FALSE
je >>C2
;Do not include '.' and '..'
mov eax,[rfpwfd.cFileName]
and eax,0FFFFFFh
cmp eax,2E2Eh
je >>C2
and eax,0FFFFh
cmp eax,2Eh
je >>C2
invoke lstrlenA,addr rfpszBuffer
mov edx,eax
push edx
dec edx
cmp B[rfpszBuffer+edx],"\"
jne >
inc edx
:
mov eax,OFFSET rfpszBuffer
add eax,edx
invoke lstrcpyA,eax,addr rfpwfd.cFileName

inc D[rfpnFileEnum]
push [rfpwfd.dwFileAttributes]
push OFFSET rfpszBuffer
call [pCallback]
mov [rfpfEndProc],eax
or eax,eax
jz >
invoke xRecurseFolder,addr rfpszBuffer,[pCallback],[fRecurse]
:
pop edx
mov B[rfpszBuffer+edx],0
cmp D[rfpfEndProc],0
je >>E1
jmp >C2
C1:
invoke lstrcpyA,OFFSET rfpszSearchString,OFFSET rfpszBuffer
invoke lstrlenA,OFFSET rfpszSearchString
add eax,OFFSET rfpszSearchString
dec eax
invoke lstrcpyA,eax,addr rfpwfd.cFileName
invoke GetFileAttributesA,ADDR rfpszSearchString

inc D[rfpnFileEnum]
push eax
push ADDR rfpszSearchString
call [pCallback]
mov [rfpfEndProc],eax
or eax,eax
jz >E1
:
C2:
invoke FindNextFileA,[hwfd],addr rfpwfd
or eax,eax
jne <<N1
E1:
invoke FindClose,[hwfd]

E2:

ret

ENDF
Posted on 2004-05-20 19:37:55 by donkey

Windows will return the . and .. folders as well, so don't be suprised if you see those.

Don't all (related) OS'es? DOS certainly did, and I think linux does too.
Posted on 2004-05-20 19:53:04 by f0dder
The . and .. were introduced with DOS 2.0 and were part of the rip-off of part of the Unix file system by Microsoft in order to allow better handling of heirachical directory structures. My recursion routine handles them and also allows "." folder names, which f0dder kindly pointed out to me were possible (I didn't know before he mentioned it)
Posted on 2004-05-20 21:14:02 by donkey
And don't forget the super secret ... directory which bestows upon its user absolute wealth and power.
Posted on 2004-05-20 21:31:29 by iblis

And don't forget the super secret ... directory which bestows upon its user absolute wealth and power.


:grin: That would be the $HOME directory which I geuss MS did steal after all though they seem to have renamed it.
Posted on 2004-05-20 21:33:22 by donkey
MS-DOS actually ripped off CP/M, I think.
And I'm not sure if CP/M ripped off *nix, or the other way around.
Posted on 2004-05-21 03:32:44 by Scali
thanks a lot :)
Posted on 2004-05-21 06:07:50 by Vaxon
In Windows 9X, ... refers to the directory two levels up, .... refers to the one three levels up and so on. I bet there weren't many of you who knew about that.
Posted on 2004-05-21 06:08:49 by Sephiroth3
MS-DOS actually ripped off CP/M, I think.
And I'm not sure if CP/M ripped off *nix, or the other way around.


CP/M does not have heirarchical directory structures and certainly does not have ". and ..". MSDOS 1.0 was based on QDOS (Quick and Dirty Operating system) not CP/M though QDOS was loosely based on CP/M as it was originally intended to be replaced by it. Beginning with PCDOS (or MSDOS) 2.0 Microsoft broke from the QDOS model in an attempt not to live up to it's royalty agreement with SCP (the makers of QDOS). DOS 2.0 was a complete rewrite and got rid of the CP/M like crap and replaced it with Unix like commands
Posted on 2004-05-21 10:03:47 by donkey
If QDOS is based on CP/M, and MS-DOS is based on QDOS, then MS-DOS is based on CP/M.
I am not sure about the royalty thing with QDOS either. I thought they bought all rights to QDOS (http://inventors.about.com/library/weekly/aa033099.htm).
Wikipedia actually claims that QDOS was a "16-bit clone" of CP/M (http://en.wikipedia.org/wiki/QDOS).
So I wonder how 'loosely' it was based on CP/M.

I am not too sure about MS-DOS 2.0 differencing that much from MS-DOS 1.0 though.
I would guess that would break compatibility in a nasty way.
Posted on 2004-05-21 10:29:30 by Scali
Wel, anyone old enough to remember the change from 1.0 to 2.0 also remembers the wholesale scrapping of most of their disks. DOS 1.0 was broken with DOS 2.0, the last time that happened. The license agreement is a matter of public record and MS was sued for violating the terms of the agreement and lost. They had agreed to allow SCP to distribute MSDOS royalty free in perpetuity with all available upgrades, they had argued that MSDOS 2.0 was completely new and unrelated to MSDOS 1.0 and therefore not covered by the license agreement they signed, the judge sided with SCP and MS was forced to buy the complete rights to QDOS in order to stop SCP from distributing free of charge. The original QDOS was developped because DR was not ready with CP/M and it was an interrim patch, it can hardly be said to be a CP/M clone when CP/M did not even exist when it was written, it was loosely based on the proposed design of CP/M. Yes, I have used CP/M and QDOS and though they are obviously based on the same root concepts, they are different beasts.
Posted on 2004-05-21 10:54:48 by donkey
Ah, so eventually MS did get the exclusive rights.
I've never used CP/M, so I have no idea what it looks like. I don't think I want to know either.

And I didn't use PCs in the early days. I used real computers. My first PC had MS-DOS 3.21 on it.

PS: your ignore is not working
Posted on 2004-05-21 11:03:38 by Scali
PS: your ignore is not working


Turned it off, it was childish.
Posted on 2004-05-21 11:12:39 by donkey
Just something along the lines, in the good old dos days I used to install on every computer I used/maintained a folder named (ALT-255) where I kept personal stuff, and some goodies (like games). Windows never seemed to be able to open those and refused to display its contents. Wonder if that has changed... Nowadays, I just dump my stuff inside any System folder and can be sure people won't find it :tongue:

And yes, Ignore would be better if you couldn't see the ignored member at all. I mean who wants to see The click here is just so damn hard to resist :)
Posted on 2004-05-21 11:48:54 by JimmyClif
Originally posted by donkey
The original QDOS was developped because DR was not ready with CP/M and it was an interrim patch, it can hardly be said to be a CP/M clone when CP/M did not even exist when it was written, it was loosely based on the proposed design of CP/M. Yes, I have used CP/M and QDOS and though they are obviously based on the same root concepts, they are different beasts.


Technically, CP/M-86 was not around yet. But CP/M-80, of course, had been around for a couple of years at that point. DOS 1.0 was a repackaged QDOS, which of course, was based on the CP/M user interface (this was back in the days before doing stuff like that got you sued). But the underlying structure of the two OSes was completely different. They shared a common user interface and the APIs were *very* similar, but that was about it.

Little known fact: CP/M was based on Intel's ISIS OS for their 8080/8085 development systems and anyone who has ever used DEC's RT-11 OS will also recognize an uncanny resemblance. Gary Kildall (founder of DR and author of CP/M) did contract work for Intel just prior to developing CP/M (he wrote their PL/M compiler, IIRC). I don't know of any OSes on which RT-11 was based, that's getting back a little before my time.

Cheers,
Randy Hyde
Posted on 2004-05-21 14:49:39 by rhyde
As I recall, there were some features in DOS that came from supporting CP/M. For example the "call 0" way to exit do DOS, and some obsolete "int 21" calls. It's all in Ralph Brown's interrupt list. :)
Posted on 2004-05-21 15:54:41 by QvasiModo
Well, the first 30 or so INT 21h functions mirror the BDOS calls for CP/M-80.

INT 21h, AH=9 is BDOS func. 9, complete with '$' to terminate the displayed string.

The PSP is similar to CP/M "page 0", with command tail at offset 80h.

So, yes, the QDOS/MS-DOS interface was originally copied from CP/M. Tim Paterson, who created QDOS, made no secret of this.

Incidentally, a company called Cromemco made a CP/M-80 clone called CDOS. A major difference was the use of Z80 instructions. Cromemco made hardware, and they never built an 8080 board. They created CDOS to support their Z80 board.

There were quite a number of minicomputer systems that had similar looking file structures (flat directory with two part file names and separate volume name). Some of the microcomputers OS's happily made their systems look like this.

Eventually, the spread in C language usage brought along its Unix culture, resulting in desire for and acceptance of hierarchial directory structures.
Posted on 2004-05-21 18:42:34 by tenkey