In Windows XP, I have to wait for ZipMagic to finish unpacking a large zip, before I can further use Windows Explorer. Is ZipMagic or Windows Explorer not multi-threaded? I would rather Zipmagic unpack a compressed file in the background (500MB to 1GB files), while I continue to do other things.

ZIPmagic is even more than multi-threaded. In fact, all extraction happens inside externally launched processes, not even a separate thread - so it is virtually impossible for Explorer to block during the extraction.

Perhaps if your hard disk is slow or fragmented, this might explain if you experience speed problems during extraction. Try to pause the extraction, and then see if Explorer and other programs are responding normally.

It is not a matter of fragmentation, or slow system speed. I can continue to work with any other application, smoothly, except explorer, that remains locked up until the decompression completes. If you would like, I can give you a remote session via teamviewer, so you can work on resolving the issue. PM me, or email marcos at nerdondemand d0t com

Yes, with drag&drop, Explorer is simply designed to block until the data has arrived - making it quite an inefficient process.

You can try copy&paste, which works better in most instances.

Personally if I am extracting a large amount of data, I always use the right-click Extract menu (without even bothering to go inside the shell namespace extension), because as you saw, it is the fastest and most non-blocking approach of all.

I remember in Zipmagic98, all these things were possible!http://articles.chicagotribune.com/1997 ... ompression"While these .zip folders dramatically reduce the amount of disk space consumed by treated files, the special folders behave exactly like all other Windows 95 folders."

Zipmagic 98 was a file system driver for Windows 9X (MS-DOS based), which did not succeed in porting its implementation over to Windows XP (Windows NT based) or newer.

Because it was a file system driver, you could even browse inside archives from an MS-DOS command line window. Naturally, events like drag&drop and copy&paste would be non-blocking too, because as far as the entire operating system was concerned, you were navigating inside a real file system folder. This is how Zipmagic98 completely side-stepped the issue of blocking Windows File Explorer interfaces, but you can see that they did not survive the transition to the Windows NT world.

During ZIPmagic's own development (this current version, not the unrelated and now defunct Mijenix version), various approaches were tried, including copying "fake files" during drag&drop and copy&paste operations; to get around the blocking issue. A system monitor simply was on alert at all times to see where this "fake file" would appear, in order to be able to determine the target of the drag&drop or copy&paste operation. It would then directly, and in a non-blocking manner, extract the actual files to the desired destination. However this approach itself had its own array of problems.

Specifically, users were confused by this new file (typically a GUID), which would appear and disappear without explanation. The actual extraction going on in the background, they would not have a definite way of knowing when it would be finished (other than watching the Window), which contradicts standard Explorer behavior. And issues with tracking the GUID as well.

Assuming I grasp what you are saying, I have an example that may help with user confusion, waiting for the file to show up. For downloads, Firefox creates two files named file.part and file.ext, and once the download completes into file.part, it overwrites file.ext with file.part. You can also use the progress indicator you already have in the current Zipmagic.

ps. Yes, I'm aware MS made their OS less extensible to third party shell extensions