7zip dll

[MrBubbles]

So this question has been asked many, many, many times but I've never come across any kind of authoritative answer or well-accepted function that would allow me to extract a zip file or spanned 7zip archive using the DLL, get the progress status and show that in my own GUI.

I've seen that some posts talk about using a different dll, 7zip32.dll but since I'd be doing this in a corporate environment, I'd strongly prefer to use the actual 7z.dll that ships with 7zip.

Has anyone created a functioning wrapper function for the official 7z.dll that would allow me to extract a zip or spanned zip archive?

[wolf_II]

Have you considered the command line 7z.exe?

[MrBubbles]

Hi Wolf,
My current process is to use 7zG.exe and pass it the first of 5 10GB spanned archives to extract (which automagically extracts them all) via the RUNWAIT command.

I use 7zG.exe because I want the user to have a progress indicator for the extraction process as it takes a very long time to complete (almost 60GB uncompressed). This works fine except that I have to ship the 7zG.exe and 7z.dll with my app, which isn't a big deal. What bothers me more is that the progress bar is in a separate window from my app, specifically 7zG.exe window. Instead, I'd like to show the extraction progress in my app's window.

I'd be fine using 7z.exe CLI, but I haven't come across a good way to continually check for extraction progress via that interface either.

[wolf_II]

I understand. There does not seem to be a way to get progress data from the command line. Also you would have to trade 7z.exe for 7zG.exe which is not much of an advantage.
Short of you finding a library for 7zip, you could try to write your own AHK wrapper for the single 7z.dll function that you need. You may be able to find help for this small task?

If you start to write a wrapper for a single function call, you might get lucky ?!?

I would be interested in contributing but I am unable to do so, and having able helpers to clean up the mess I would inevitably create is probably not good for you.

I wish you the best of luck!!

[MrBubbles]

Yeah, I was surprised that no one has created a solid wrapper function for 7zip yet. I would but honestly my skillset with autohotkey and the windows api is not sufficient to do a very good job of it. The only thing I've thought of that might work is that since I know how large the uncompressed directory is supposed to be once extraction is complete, I could probably continually get the size of that directory and use that to deduce how far along a silent extraction process were and use that to update a progressbar. Just seems a really dumb way of doing it to me.

[wolf_II]

Another, possibly bad idea: (we are still brainstorming, right?)
You could try to catch the 7zG window with a hook and hide it. Then get the progress data from the progress bar and display it in your GUI?

[BoBo]

Let's assume that PhiLho's statement about 7z.dll in the following thread is correct ...
https://autohotkey.com/board/topic/1472 ... h-dllcall/

google: site:autohotkey.com+7z.dll

[MrBubbles]

Another, possibly bad idea: (we are still brainstorming, right?)
You could try to catch the 7zG window with a hook and hide it. Then get the progress data from the progress bar and display it in your GUI?

I tried that a while back. This has been an ongoing thing that I wanted to solve for a long time. If I am recalling correctly, when I tested that a couple of years ago, the issue I encountered was that I could not hide the 7zG.exe window fast enough to prevent a noticeable flicker.

[wolf_II]

Can you remember if you used a ShellHook or a SetTimer?

[kczx3]

Could you set the 7zG.exe window as a child of your AHK GUI window and position it inside?

[Masonjar13]

You can use StdOutStream to get the StdOut of any CL (command line) program. Any that I've tried work, anyway. Very important though to note that it is synchronous, meaning if you're pushing it to a GUI, your GUI (or any other part of the script) will become unresponsive any time it isn't spitting output. To get around this, I use a separate thread using AutoHotkey.dll (comes in AutoHotkey_H download). I made a class for handling threads if you'd like to use that. In combination, you can make some pretty great front-ends for CL software!

Edit: to use 7z.dll would mean that you'd have to manually accommodate for everything the executable does. I'm not sure if there's any documentation on it, but there are many DLL viewers you can use as a starting point (jNizM made one recently).

Edit2: a simpler route (if you want to go this way) would be to have one script launch the 7zC and pipe it out to a file: run,% comspec . " /c 7zCMD.exe >> filePath.txt. You may then read-in the file on another script. If you don't mind writing to disk, then this should work just fine.

[MrBubbles]

Can you remember if you used a ShellHook or a SetTimer?

I believe I was using SetTimer

[MrBubbles]

Could you set the 7zG.exe window as a child of your AHK GUI window and position it inside?

I have considered that, just figured there were probably more elegant ways of doing it.

[wolf_II]

SetTimer is prone to cause flicker. Try a ShellHook, that should be much faster, if it's unnoticeable you will have to test.

[MrBubbles]

You can use StdOutStream to get the StdOut of any CL (command line) program. Any that I've tried work, anyway. Very important though to note that it is synchronous, meaning if you're pushing it to a GUI, your GUI (or any other part of the script) will become unresponsive any time it isn't spitting output. To get around this, I use a separate thread using AutoHotkey.dll (comes in AutoHotkey_H download). I made a class for handling threads if you'd like to use that. In combination, you can make some pretty great front-ends for CL software!

Edit: to use 7z.dll would mean that you'd have to manually accommodate for everything the executable does. I'm not sure if there's any documentation on it, but there are many DLL viewers you can use as a starting point (jNizM made one recently).

Edit2: a simpler route (if you want to go this way) would be to have one script launch the 7zC and pipe it out to a file: run,% comspec . " /c 7zCMD.exe >> filePath.txt. You may then read-in the file on another script. If you don't mind writing to disk, then this should work just fine.

I'd tested something similar to StdOutStream a while back and ended up running into the app becoming unresponsive. Using a separate thread from AutHotkey.dll makes sense and I would love to get my hands on it. Unfortunately our corporate firewall blocks me from downloading it and even if I could get my hands on it, I'd bet money that our AV would block it. I've considered compiling it myself and then signing it with my corporate certificate which would make it trusted within the enterprise (that's what I currently do for exes built from AHK), but when I looked compiling the DLL myself, well let's just say I'm lucky to even be able to spell DLL.

I'm not vehemently opposed to writing to disk but I try to avoid it anytime I can. I'd probably hardcode the expected directory size and continue to interrogate the size of the target dir as files get extracted to it and run the progress bar off of that before I started piping the extraction progress out to a text file.

[MrBubbles]

SetTimer is prone to cause flicker. Try a ShellHook, that should be much faster, if it's unnoticeable you will have to test.

Cool, I'll give it a go.

[BoBo]

Unfortunately our corporate firewall blocks me from downloading it ...

As your IT allows building AHK executables it shouldn't be that tough to let'm download and approve the mentioned dll on your behalf, especially as this official request would cover your ass
JM2€C