Progressbar starts too late

[Tedd]

"The issue is that you only have one thread.Run the search in a separate thread and then the window can continue to be updated."

Could you or someone be a bit more explicit - I do not have the slightest idea how to start a new thread.

CreateThread will start a new thread; you provide the offset of your search function for lpStartAddress, and lpParameter allows you to pass in a single parameter (a value, or a pointer to something useful.)
This thread will then run in parallel with your main window thread.
So then you can update a progress value from the new thread, and have the window update to reflect that value. But try to keep shared variables to a minimum to avoid weird synchronisation bugs.

[jj2007]

What is the difference between WIN32_FIND_DATA  and WIN32_FIND_DATAW ?

No big difference. I used the Unicode version because ANSI FindFirstFile works with the wide version but not the other way round.

Good and bad news:
- Absolutely no difference for C:\Windows, 20,000 folders
- Your version chokes for my complete C: drive. The culprit is here:

00401313               ³.  3C 40                   ³cmp al, 40
00401315               ³. 74 F7                   ³je short 0040130E
00401317               ³.  AA                      ³stosb

That is at the beginning of Clean_Dir_Array.

For the comparison of the textfiles, I used this snippet: It loads both files into an array, strips the \* from your version, sorts both arrays alphabetically and then checks if the strings are identical. They are.

include \masm32\MasmBasic\MasmBasic.inc
  SetGlobals ctc, ctj
  Init
  SetGlobals
  Recall "Folders_Clam.txt", cl$()
  push eax
  xor ecx, ecx
  .Repeat
      mov esi, cl$(ecx)
      Let cl$(ecx)=Left$(esi, Len(esi)-2)
      inc ecx
  .Until ecx>=stack
  pop eax
  QSort cl$()
  mov ctc, eax
  Recall "Folders_JJ_Callback.txt", jj$()
  QSort jj$()
  mov ctj, eax
  xor ecx, ecx
  .Repeat
      .if !Instr_(cl$(ecx), jj$(ecx))
            deb 1, "Gotcha", ecx, $cl$(ecx), $jj$(ecx)      ; no Gotcha seen for C:\Windows!
      .endif
      inc ecx
  .Until ecx>=ctc
  deb 4, "Counts", ctc, ctj
  Exit
end start

P.S.: For a better comparison e.g. with fc (=file compare), use e.g.
  mov ctj, eax
  Store "Folders_C.txt", cl$()   ; write the sorted and stripped strings to disk
  Store "Folders_J.txt", jj$()   ; write the sorted strings to disk
  xor ecx, ecx

[clamicun]

JJ,
this was a stupid mistake in Clean_Dir_Array, which I corrected.
Your "Compare File Routine" is very helpful.
Thank you for everything. I learned a lot.

A last question.

.if byte ptr FileName != '.'  || byte ptr FileName+1 == '!'   ;works on a folder  .!!OIM

Why doesn't this have the same effect?

.if byte ptr wfd.cFileName != '.'  || byte ptr wfd.cFileName+1 != '  '   ;shows the old MS-DOS '.' and '..'  folders

Am I illogic?

Now I go back and try to organize the progressbar.

[jj2007]

Thank you for everything. I learned a lot.

My pleasure :icon14:

.if byte ptr FileName != '.'  || byte ptr FileName+1 == '!'   ;works on a folder  .!!OIM

Not quite sure what you are looking at, but dot folders are 2E00h (=current folder aka ".") and 2E2E00h (=parent folder aka "..") - all others are named folders or files. So you might want to check for the position of the nullbyte, e.g. via word ptr []==2E00h

[dedndave]

be aware that a valid file or folder name may have a '.' as the second char
so - that test is only good if the first char is also '.'   

[jj2007]

be aware that a valid file or folder name may have a '.' as the second char
so - that test is only good if the first char is also '.'   

dot folders are 2E00h (=current folder aka ".") and 2E2E00h (=parent folder aka "..") - all others are named folders or files. So you might want to check for the position of the nullbyte, e.g. via word ptr []==2E00h

From the top secret MasmBasic source:

                        lea edx, [ebx.WIN32_FIND_DATA.cFileName]
                        mov eax, [edx]            ; might be ., .. or .aname
                        .if al=="."
                                    shr eax, 8                              ; aname or nullbyte?
                                    .if !al
                                          xor eax, eax
                                    .elseif al=="."
                                          shr eax, 8
                                          .if !al
                                                xor eax, eax
                                          .endif
                                    .endif
                        .endif
                        .if eax ;)

[nidud]

deleted

[TWell]

Thank's nidud.
Same as C lingo

Code Select Expand

int main(int argc, char **argv)
{
char name[] = "..";
if ((short)'.' != *(short*)&name[0])
if ((short)'.' != *(short*)&name[1])
return 1;
return 0;
}

[jj2007]

   but not this "x." --> "x"

What exactly do you mean? Chr$(34) is illegal?

Otherwise, your code looks shorter than mine, I might steal it ;-)

[nidud]

deleted

[clamicun]

What I meant was this...

I want to catch all filenames which start with '.'
and have in byte ptr+1 whatever except for the second  '.'

There are lots on my machine:  .!,  ._,  .NET,  .d, .r  and more.

That's why I asked if

byte ptr != '.' || byte ptr+1 == '!'     

is the same as

byte ptr != '.' || byte ptr+1 != '  '       ;it is not obviously

What is right to catch all filename which are like '.something ?  ! _ r N d .....

[adeyblue]

What exactly do you mean? Chr$(34) is illegal?

I think the OS strips trailing dot's on creation so you wont find a file named "?."

They technically can be created, but you have to use NtCreateFile directly to do it. Of course since practically nothing uses that function directly you can't do anything with the file, because as you said, CreateFile and friends will get rid of the trailing dot.

[dedndave]

chr$(34) should be illegal   
it's often used to delimit filenames that contain spaces

anyways....
the folders "." and ".." will only show up once, unless you change the current folder
maybe that will simplify your code

[dedndave]

this program doesn't do exactly what you want, but the code may be of interest

http://masm32.com/board/index.php?topic=3468.msg36521#msg36521

[jj2007]

That's why I asked if

byte ptr != '.' || byte ptr+1 == '!'     

is the same as

byte ptr != '.' || byte ptr+1 != '  '       ;it is not obviously

You should look at your code through the eyes of OllyDbg.
' ' is not a nullbyte, it's a space - could be a valid filename
'!' is a dangerous char because it's a MASM special character meant to handle e.g. certain situations with brackets. Depending on how macros are constructed/expanded, you may need up to FOUR exclamation marks until MASM grants you one valid one. Workaround: Chr$(31) or 1Fh.

@nidud+adeyblue: thanks for the excursion into trailing dots ;-)