🚀 go-pugleaf

Mike Collins wrote:

>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:

I use "*.exe" just fine.
What problem are you having with it?

This bit from one of my apps:

* do all files for this directory */
void AddNewFiles(const char*Directory,const char* ext)
{	HANDLE ff;
	WIN32_FIND_DATA fblk;
	char filename[MAXPATH];

	sprintf(filename,"%s*.%s",Directory,ext);
	ff=FindFirstFile(filename,&fblk);


>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".

The file type is the *last-dotted-item*
So your example is still type .txt, even with .exe embeded.
More relevant would be if you thought data.hexed was an exe.

I think if you used "*.exe" in your FFF, you would also be
presented with .EXE_1033, but your current code is more
stringent with it's AnsiCompareIC(".exe") rejecting it.