Author Topic: Progressbar starts too late  (Read 10713 times)

clamicun

  • Member
  • ***
  • Posts: 347
Re: Progressbar starts too late
« Reply #30 on: December 16, 2014, 04:58:28 AM »
JJ,
! is  dangerous or not...
There are folders on my computer, which start with .!!

So I wrote it like this:
 .if byte ptr wfd.cFileName != '.'  || byte ptr wfd.cFileName+1 == 21h || byte ptr wfd.cFileName+1  > 2Eh

In case that next week there are folders like .x   or.y

I still don' understand why your prog comes to the same result without.  It has to do with MasmBasic.inc - hasn't it?

jj2007

  • Member
  • *****
  • Posts: 9687
  • Assembler is fun ;-)
    • MasmBasic
SmallBasic finds different files
« Reply #31 on: December 28, 2014, 05:34:34 AM »
I got curious and installed Microsoft SmallBasic on my Win7-64 machine.

The good news: It runs just fine. The rest is mixed. The syntax is awful, but maybe I just must get used to it. Help is practically unavailable.

Then I stumbled over some awkward behaviour:
Code: [Select]
dir = "C:\Windows\System32\"
getFiles = File.GetFiles(dir)
ct=0
TextWindow.WriteLine("start")
For i = 1 To Array.GetItemCount(getFiles)
  getFile = getFiles[i]
  If 1=1 Then '(Text.EndsWith(getFile,".dll")) Then
    ct=ct+1
    File.AppendContents("TestSB.txt", getFile)
    TextWindow.WriteLine(getFile)
  EndIf
EndFor
TextWindow.WriteLine(ct+" files found")
TextWindow.Pause()

Very simple, it writes 2750 file paths to TestSB.txt
Problem is, the following yields a somewhat different set of files:

include \masm32\MasmBasic\MasmBasic.inc      ; download
  SetGlobals ct, fileMB$="TestMB.txt"
  Init
  GfNoRecurse=1            ; SmallBasic doesn't search in subfolders
  Open "O", #1, fileMB$
  GetFiles C:\Windows\System32\*
  For_ ecx=0 To eax-1
      mov esi, Files$(ecx)
      lea eax, [esi+Len(esi)-4]
      .if 1 ;Cvl(eax)==Mirror$(".dll")
            inc ct
            PrintLine #1, esi
      .endif
  Next
  Close
  Print Str$("%i files found", ct)      ; finds 2225 files
  Exit
end start


90% of the files coincide, but MB finds clearly less files than the SmallBasic GetFiles, and different ones. For example, SB finds an Acer.scr that MB doesn't find.
FreeCommander and the DOS prompt go with MB, while Explorer goes with SB. It is as if SB and Explorer used something different from FindFirstFile, with different results.

One more example: SmallBasic GetFiles doesn't find
C:\Windows\System32\12520437.cpx
C:\Windows\System32\12520850.cpx

MasmBasic GetFiles and the cmd prompt finds them.

EDIT: Gotcha! It's the SysWOW64 thing. Apparently FindFirstFile gets SysWOW64 when you ask for System32 on a 64-bit system. Strange though that SmallBasic gets two different results - it's a 32-bit app, too. Maybe there is some hidden Microsoft only flag that you can pass to FFF ::)
« Last Edit: December 28, 2014, 08:26:10 AM by jj2007 »

hutch--

  • Administrator
  • Member
  • ******
  • Posts: 6660
  • Mnemonic Driven API Grinder
    • The MASM32 SDK
Re: Progressbar starts too late
« Reply #32 on: December 28, 2014, 10:05:04 AM »
 :biggrin:

I just had a quick play with small basic and its awful but funny enough it popped a 2.5k exe that only depends on a runtime DLL.
hutch at movsd dot com
http://www.masm32.com    :biggrin:  :skrewy:

jj2007

  • Member
  • *****
  • Posts: 9687
  • Assembler is fun ;-)
    • MasmBasic
Re: Progressbar starts too late
« Reply #33 on: December 28, 2014, 10:34:00 AM »
:biggrin:

I just had a quick play with small basic and its awful but funny enough it popped a 2.5k exe that only depends on a runtime DLL.

... which has 250k and in turn depends on mscoree.dll. I feel a bit ashamed for MasmBasic's 20k overhead, but compared to that it's still tiny. However, SmallBasic's runtime is really not too big compared to many other bloated stuff. Rumours say a hello world in QT needs 10MB.

I made some tests with string manipulation, it's a factor 5-7 slower than my favourite dialect :bgrin:

Apparently, Microsoft touts this as a free tool to make kids acquainted with object orientation à la VB. I hate it, but it has many fans, and for a reason.

Just for fun, attached a proggie that saves the names of both the redirected 32-bit DLLs and the native 64-bit DLLs to file. Source:

include \masm32\MasmBasic\MasmBasic.inc      ; download
  Init
  Dll "Kernel32"
  Declare void Wow64DisableWow64FsRedirection, 1
  Declare void Wow64RevertWow64FsRedirection, 1
  GetFiles C:\Windows\System32\*.dll
  Print Str$("%i 32-bit DLLs found\n", eax)      ; 2806
  Store "Sys32_redirected.txt", Files$()
  push 0                  ; create a DWORD zero on the stack
  Wow64DisableWow64FsRedirection(esp)
  GetFiles C:\Windows\System32\*.dll
  pop eax
  Wow64RevertWow64FsRedirection(eax)
  Store "Sys32_native64.txt", Files$()
  Inkey Str$("%i 64-bit DLLs found", Files$(?))      ; 3195
  Exit
end start