Number and type of arguments required for call to C library

[GoneFishing]

...
Wow. I've done it a wide berth around powershell in the past. Was that an error?
...

Hi Gunther,
I don't think so . It's a matter of personal preferences, your free time and professional interests.

@Dave
FIRST SUCCESS HERE ! 
On my P3 with 128MB RAM I must give zipfldr some time to finish its work :

invoke Sleep,10000
_exit::

Only 10 seconds and posted above asm source was zipped 
"Sleep" is not the best solution though
I'll think about thread / file lock monitoring ...

[dedndave]

nice job   :t

PowerShell is very cool
however, the user may not have it installed

[GoneFishing]

nice job   :t

PowerShell is very cool
however, the user may not have it installed

Powershell is included in Windowws 7 and can be downloaded for Windows XP  from here
For detailed instructions read this

Remarks:
Powershell requires appropriate .NET Framework pack   

[dedndave]

yah - i have it installed and .NET 1.0, 1.1, 2.0, 3.0, 3.5 i think
i can't install 4.0+ because it is incompatible with XP Media Center Edition   :(

later today, i may do some more COM reading

[jj2007]

Folks,

I am watching with fascination and some envy your efforts to tame the COM beast :t

In the meantime, I've given up and went, as far as un-zipping is concerned, for a third party library provided by the fabulous Jørgen Ibsen - one or two k extra, fast and comfortable ;-)

Here is a demo from \Masm32\MasmBasic\MbGuide.rtf, using UnzipInit, UnzipFile() and UnzipExit:

include \masm32\MasmBasic\MasmBasic.inc  ; version 28 May 2014 required
  Init
  UnzipInit "test.zip"      ; expects a filename, returns a comment (if present); edx has #records
  .if Sign?
      Print eax      ; print an error message
  .else
      push eax      ; UnzipInit returns a comment or an empty string
      For_ ecx=0 To edx-1      ; #files returned in edx
            mov esi, Files$(ecx)
            PrintLine Str$(GfSize(ecx)), Tb$, GfDate$(ecx), Spc2$, GfTime$(ecx), Tb$, esi
            .if Instr_(esi, ".asm", 1)      ; assembler source, plain text?
                  PrintLine "##First 60 chars: [", Left$(UnzipFile(ecx), 60), "]"
            .endif
      Next
      pop eax
      Print "Zipfile comment: [", eax, "]"
      UnzipExit
  .endif
  Exit
end start
Rem
- decompresses files in zip archive to a buffer returned by UnzipFile(ecx)
- you may save the file as FileWrite Cat$("\SomeFolder\"+Files$(ecx)), UnzipFile(ecx)

Sample output:
20222   19.04.2011  14:33:14    Irvine32Mb.lib
9451    02.12.2011  15:26:26    IrvineMacsMb.asm
##First 60 chars: [.NOLIST
COMMENT ! ** for use with MB - nothing adapted here]
3318    10.12.2012  09:40:28    IrvineMasm32.asc
16274   02.12.2011  15:18:26    IrvineSmallWinMb.inc

When your COM version is ready, we can start the timings thread in the Laboratory.

[dedndave]

we're close, Jochen
i may work on it, if i have some time later today
but Vertograd may get one going, first - lol

[peter_asm]

afaik WaitForSingleObject can take a process handle, too.

Could enumerate threads with Thread32First/Thread32Next then call WaitForMultipleObjects()

Or enumerate all threads before calling CopyHere() and then after, using WaitForSingleObject() on new handle.

I find it strange there isn't some way to wait on thread termination through COM API..

[dedndave]

i am sure COM provides a way - we just don't know what it is yet - lol

have been reading a bit
they have something called "thread apartments"
not sure that applies here, but it looks about right (haven't finished reading that part)

if you want to see some COM code, i suspect you could disassemble Explorer and some of the DLL's to see how it's done

[GoneFishing]

...

[jj2007]

The Windows , ohh,  it's huge  , it's like the ocean . The ocean never meets fast brooks  ;)

Indeed. I have timed the unzipping of the 1.7->17MB database in my spreadsheet viewer, and it's around 340 ms on my trusty old Celeron. I doubt that Explorer can compete

[dedndave]

i unzipped a fairly large archive the other day
333 Mb zipped, 640 Mb unzipped
took forever - lol
well - i have to wonder if the algorithm used for zipping wasn't kind of old

[GoneFishing]

i was thinking how to wait on thread termination and ExecNotificationQueryAsync might work, see vbscript for basic example
...
implementing this solution as C++ would mean inheriting from IWbemObjectSink and I've no idea how that would be done using assembly so it's probably more pain than it's worth.
...

Thanks peter_asm,
your suggestion to use WMI  IWbemServices interface method ExecNotificationQueryAsync seems to be the reasonable way to monitor threads .
I've found COM API for WMI reference and C++ Example: Receiving Event Notifications Through WMI
That's all I need for now
So ... my path lies to WMI   
As soon as I restore my development machine I'll dive into WMI coding in MASM 

P.S.: WaitForSingleObject / WaitForMultipleObjects require thread(s) handle(s) in parameters . Enumerating threads with Thread32First/Thread32Next  functions we get only thread IDs . However we can count the total number of threads with their help. I've already have this code written but can not re-assemble it because it wants modified kernel32.lib which I've lost with my HD .   

[adeyblue]

well - i have to wonder if the algorithm used for zipping wasn't kind of old

The older versions of zipfldr have various 'Dynazip' strings in them, so it looks like they licensed their code rather than writing it from scratch. That product had been alive since 1996-ish so yeah, I'd guess explorer's zip algorithm is older than it is!

As soon as I restore my development machine I'll dive into WMI coding in MASM 

I don't envy that :) I think it's painful and long enough in C++, it must be like War & Peace in assembly.

I tried two other notification methods of various complexity. You can register for Shell change notifications on the zip file with SHChangeNotifyRegister, downside is it requires creating a window and a message loop.

There's also the WinEvent hooks and their window creation/deletion callback. Set one for the current process, determine when the compressing dialog has been created, then wait the reciprocal delete where you signal that it's finished and exit the app. Downside is it requires Microsoft not to change the window properties of the compressing dialog

[GoneFishing]

...

[peter_asm]

adeyblue, just added function to monitor thread termination using Thread32First/WaitForMultipleObjects but it's just a hack to show how it might work. Would cause problems where process threads > MAXIMUM_WAIT_OBJECTS (64) or lots of other thread activity going on..unreliable.

Also looked inside zipfldr.dll to see how it works there but still unsure.
Seems to be based on window notifications posted to explorer.