🚀 go-pugleaf

Hi all,

Got a bit of a conceptual question here.  I have a piece of code that 
performs a recursive search of the users hard disk and generates a list of 
files.  Nothing new here.  My code is based around the FindFirstFile / 
FindNextFile API's.  From what I can see, there doesn't seem to be a way to 
specify a wildcard search mask i.e. *.exe so it seems necessary to check for 
.exe extension within the search, which I do like this:

    AnsiString sFile = (AnsiString)fdFindFileData.cFileName;
    if (ExtractFileExt(sFile).AnsiCompareIC(".exe")== 0)
       // add to my list

- using ExtractFileExt() to retrieve the file extension.  This seemed to 
work fine.  When I run it on my development machine, I get 2982 files 
returned.  However, if I fire up a command prompt and do dir *.exe /s I get 
3001 files returned, a difference of 19 files.  I dumped both lists to text 
files and compared them (which I had to do by hand because they weren't in 
the same order and I couldn't be bothered to write something to do it :-) ). 
In the dir *.exe dump, I have some file like this:

C:\WINDOWS\Installer\$PatchCache$\Managed\9040110900063D11C8EF10054038389C\11.0.5614\SCANOST.EXE_1033

when I examine the properties, they appear as executable files (although 
they appear to be back-ups and are not executable).  Based on this, I was 
wondering what the best option is to truly determine a executable?

My first thoughts are to just ignore them as they are not executable 
per-say, but i'm interested in how the dir commend determines there file 
type.  Simply looking for ".exe" in the file name would not work because it 
is possible to have a text document with the name "textfile.exe.txt".

Any thoughts or suggestions

Mike