a fast function to scan byte

[TouEnMasm]

select any text, e.g. SMALL_RECT, and hit F1

No menu ,no link with " any text" can you be more clear ?

[TouEnMasm]

After a fierce battle to offer your masm basic the directory he want to be in,a open one asm (ouf!)
F1 on a selected text and I go on internet ,that's not what you say.
But perhaps i have skip another battle to put  your \xHelp\xHelp.ini in \Masm32\help

[TouEnMasm]

Later,tired by the path search and copy I found your  xhelp.exe.
Take the time to load all the files in memory (it's not half of a second) and accept only to search typedef structure one file by one file loaded in memory.
That's not I call a search in all the sdk.
I have enought lose time with this ,I reboot my system to avoid the things staying in memory.

[jj2007]

After a fierce battle to offer your masm basic the directory he want to be in

Later,tired by the path search and copy I found your  xhelp.exe.
Take the time to load all the files in memory (it's not half of a second) and accept only to search typedef structure one file by one file loaded in memory.
That's not I call a search in all the sdk.
I have enought lose time with this ,I reboot my system to avoid the things staying in memory.

Poor Yves :(

I thought the text on the MasmBasic download page, line 6, was clear enough:

To install the library, unzip the attached archive to the root of your Masm32 drive with the "use folder names" option.

> Take the time to load all the files in memory (it's not half of a second)
Yes, loading takes about ten seconds with a slow drive. But afterwards, it does search the 77MB of header files in a few milliseconds. Just try another search string to see.

> I reboot my system to avoid the things staying in memory
Pressing Alt F4 is usually sufficient. No need to reboot ;-)

[TouEnMasm]

It wasn't half a second,but ten only to load the files.
My IDE made a better choice.He have a list of all important things in the sdk.
He find the name of the file,load it.1/2 second is too much to do that.
Here is what i call a search in all the SDK (UNICODE but could be any other word)


Note:
I don't know know which compressor you use,but I haven't a "use a folder name option" in mine.I could just unzip the directory.
A good thing is to use RELATIVE PATH

[jj2007]

It wasn't half a second,but ten only to load the files.

Well, ten seconds, not minutes ;-)

My IDE made a better choice.He have a list of all important things in the sdk.
He find the name of the file,load it.1/2 second is too much to do that.
Here is what i call a search in all the SDK (UNICODE but could be any other word)

Note:
I don't know know which compressor you use,but I haven't a "use a folder name option" in mine.I could just unzip the directory.
A good thing is to use RELATIVE PATH

I use WinZip.

Your textfile looks ok. Here is my version, full source (sorry it took a bit longer, I had dinner in parallel ):
include \masm32\MasmBasic\MasmBasic.inc   ; download
  Init
  NanoTimer()
  Open "O", #1, "Unicode_for_Yves.txt"
  GetFiles ExpandEnv$("%ProgramFiles%\Microsoft SDKs\Windows\v7.0A\Include\*.h")
  push eax
  For_ ebx=0 To eax-1
   mov ecx, Files$(ebx)
   mov esi, Cat$(FileRead$(ecx))
   .if Instr_(esi, "UNICODE", 4)   ; full word, case-sensitive
      Print #1, CrLf$, ecx
      StringToArray esi, L$()
      push eax
      xor edi, edi
      .Repeat
         mov ecx, L$(edi)
         .if Instr_(ecx, "UNICODE", 4)
            Print #1, Str$("\n%i\t", edi), ecx   ; write the matches to file
         .endif
         inc edi
      .Until edi>=stack
   .endif
  Next
  Close
  pop ecx
  Inkey Str$("\n%i ms for ", NanoTimer(ms)), Str$("%i files processed. See them (y)?\n", ecx)
  .if eax=="y"
   Launch "Notepad.exe Unicode_for_Yves.txt"
  .endif
  Exit
end start

Output:
715 ms for 734 files processed. See them (y)?

[TouEnMasm]

Your prog show Nothing new on times,the only thing new is that there is need to reboot the computer to free the memory.Really new.
What i said in my initial post is that the use of sse can made win ten minutes in comparison with an application not using sse.
My ide made this without any code and take no more time,except for display the screen and the memory is freed.

[jj2007]

Your prog show Nothing new on times,the only thing new is that there is need to reboot the computer to free the memory.Really new.

There must be a serious problem with your Windows. My version of XP frees the memory when you press Alt F4 to close xHelp. By the way, how did you determine that xHelp stays in memory? According to Microsoft, ExitProcess frees all heap memory... besides, MasmBasic always frees all heap mem even before ExitProcess.

What i said in my initial post is that the use of sse can made win ten minutes in comparison with an application not using sse.

OMG! You mean it takes longer than ten minutes to process a few megabytes?

[TouEnMasm]

I see that memory is not freed because after exit a new launch of the prog don't reload the files and win times.Try it with the exe you have posted.

Just another word,it would be interesting to compare the time of heapalloc you use and globalalloc.

[jj2007]

Yes, that's correct, xHelp does not allow a second instance, i.e. a new launch just passes on the search string to instance #1 and then quits immediately. This is by design. But if you quit the first and only instance, all memory is freed.

Re Heap vs GlobalAlloc: In theory, they should yield the same results, in practice there are some oddities to observe. For small allocations as in this case, the official Microsoft line is to use HeapAlloc.

[qWord]

I see that memory is not freed because after exit a new launch of the prog don't reload the files and win times.Try it with the exe you have posted.

The reason is that windows buffers the file access - even if the process is closed, windows keep the files (or parts of them) in memory until they are reused or the memory is needed for other purpose.
If you do not want this mechanism, create the files with the flag FILE_FLAG_NO_BUFFERING.

File Caching

[KeepingRealBusy]

I see that memory is not freed because after exit a new launch of the prog don't reload the files and win times.Try it with the exe you have posted.

The reason is that windows buffers the file access - even if the process is closed, windows keep the files (or parts of them) in memory until they are reused or the memory is needed for other purpose.
If you do not want this mechanism, create the files with the flag FILE_FLAG_NO_BUFFERING.

File Caching

Caution,   FILE_FLAG_NO_BUFFERING has special conditions. The data must be read into a buffer you supply and it must start on a system page boundary. The file length to read must be a exact multiple of the disk sector size.

Dave.

[hutch--]

Arrrrgh !,

What wrong with using the API,


BOOL FlushFileBuffers(
    HANDLE hFile    // open handle to file whose buffers are to be flushed
   );

[jj2007]

Hutch,

FlushFileBuffers won't help a lot, because the sluggishness comes from other apps having to reload their files from disk, i.e.
- foreground app overuses file cache
- other file content in cache therefore gets thrown out
- foreground app exists
- other apps have to reload files into cache (and that is slow)

Why all that should be a problem for a mere 77MB (1.8% of 4GB RAM) remains a mystery but in any case flushing won't help - the cache manager will do that anyway.

Besides, afaik FlushFileBuffers clears write buffers only - and xHelp does not write anything other than a few bytes of settings.

[TouEnMasm]

Is there somewhere a piece of code using FILE_FLAG_NO_BUFFERING ?