[C#] How would I recreate how Windows Explorer opens zip files as folders?

I have the method for decompression, I know XP uses the DLL zipfldr.dll.

I just have absolutely no idea how I would go about integrating it and actually making it work the way I want.

If someone could just give me an exmaple for point in the right direction it would be very helpful.

Just use System.IO.Compression or something like that...

Quote:

---

Originally Posted by xSilv3rbullet

Just use System.IO.Compression or something like that...

---

I'm not unzipping something, I'm recreating how Windows can directly open a zip file and view it as a folder. =/

Read the file headers from the zip : http://en.wikipedia.org/wiki/ZIP_(file_format)

I don't care about the zip part.

Can I say that any clearer?

I want to know how Windows Explorer can open the zip, call the bullshit DLL and then act like it's a normal folder instead of an actual zip file. AlphaZIP does the same thing except with zips, rars, 7zips, and a few other things; but it's not open source.

http://bytes.com/topic/net/answers/8...-zipfldr-dll-c

If this your problem ?

I'm not trying to unzip anything and it's not a problem. I'm trying to find out how to do something.

Quote:

---

Originally Posted by inumedia

I'm not trying to unzip anything and it's not a problem. I'm trying to find out how to do something.

---

Oh i see, you're trying to convert zipped files to folders right ?

Quote:

---

Originally Posted by FrostElite

Oh i see, you're trying to convert zipped files to folders right ?

---

In a sense, yes. But I don't think you're looking at it properly. Windows Explorer can "view" the contents of a zip folder without extracting it, and it even has the extension of the zip in the URL. That's what I want to recreate.

PaulBub is somewhat right. You'd need to obtain the file names from a .zip file by using BinaryReader or something similar. Then, list them the same way you'd list files. If someone executes an action such as opening a file inside a zip archive, you'd have to unzip it in the background to a temporary directory somewhere on the user's computer and show the user that temporary file and then monitor changes.

Quote:

---

Originally Posted by Nuklear

PaulBub is somewhat right. You'd need to obtain the file names from a .zip file by using BinaryReader or something similar. Then, list them the same way you'd list files. If someone executes an action such as opening a file inside a zip archive, you'd have to unzip it in the background to a temporary directory somewhere on the user's computer and show the user that temporary file and then monitor changes.

---

Okay you've got the right idea but to be honest it doesn't tell me a lot. Maybe I should be a little clearer. I plan on recreating a WZ Data File explorer so you can just click the WZ and open it in Windows Explorer.

I do understand that for a .zip file I'd have to use a binaryreader and then go through and list the files, but that's the problem. I don't know how'd I list the files, how to make the DLL, or really where to start. D=


Edit:
I do believe this article talks a little bit about it, but to be honest it's so vague it's too hard for me to understand.

http://msdn.microsoft.com/library/cc....85).aspx#file

Here's what I would do. Make a console program that runs in the background. Now, associate all .wz files with the console program in Windows Explorer. This will cause your console program to execute when the user double-click on any .wz file.

If I recall correctly, the file name of the file will be passed to the console program as a parameter. Now, you have two options here:

1. Extract all files to a temporary directory.
2. Grab all filenames from the WZ file and create token files in a temporary directory.

For method #1, actually extract the file in the background and then display the contents to the user.

For method #2, just retrieve file names from the WZ archive using BinaryReader and then create blank files with the same name. Now, the problem is, you'd have to suffix all file names with some unique file extension because Windows Explorer will assume these files are already extracted. Simply associate the file extension with your console program and have it extract the files and execute it when the user commits an action.

After doing one of the methods above, you can simply use the following method:

Code:

---

System.Diagnostics.Process.Open("C:/Path/To/Temp/Dir");

---

The problem with method #1 is that for large files, it might take a while before displaying the file in Windows Explorer on slower computers.

The problem with method #2 is that when the user attempts to copy and paste, they'd be copying a blank file. Also, unless you pad the token files to represent the file size as the original file, all files will appear in Windows Explorer to have 0 bytes.


I suggest going with method #1, and I'm sure there might be a better way out there. It's been a while since I've programmed desktop applications.

Quote:

---

Originally Posted by Nuklear

Here's what I would do. Make a console program that runs in the background. Now, associate all .wz files with the console program in Windows Explorer. This will cause your console program to execute when the user double-click on any .wz file.

If I recall correctly, the file name of the file will be passed to the console program as a parameter. Now, you have two options here:

1. Extract all files to a temporary directory.
2. Grab all filenames from the WZ file and create token files in a temporary directory.

For method #1, actually extract the file in the background and then display the contents to the user.

For method #2, just retrieve file names from the WZ archive using BinaryReader and then create blank files with the same name. Now, the problem is, you'd have to suffix all file names with some unique file extension because Windows Explorer will assume these files are already extracted. Simply associate the file extension with your console program and have it extract the files and execute it when the user commits an action.

After doing one of the methods above, you can simply use the following method:

Code:

---

System.Diagnostics.Process.Open("C:/Path/To/Temp/Dir");

---

The problem with method #1 is that for large files, it might take a while before displaying the file in Windows Explorer on slower computers.

The problem with method #2 is that when the user attempts to copy and paste, they'd be copying a blank file. Also, unless you pad the token files to represent the file size as the original file, all files will appear in Windows Explorer to have 0 bytes.


I suggest going with method #1, and I'm sure there might be a better way out there. It's been a while since I've programmed desktop applications.

---

You suggest going with #1 but I have every intention of going with #2, simply because it's exactly what I'm looking for. But at the same time I'm sure Windows Explorer will go straight to that location instead of showing that it's inside the WZ file.

I'm pretty sure Windows Explorer would possibly un-zip the files to a temporary location - just like WinRAR would.

Anyway, i'm not really sure about being able to replicate how Windows Explorer opens .zip files - but you can probably make a Win32 API call to get Explorer to open it as it usually would, but i'm not sure if you could physically embed that within say a Form without first un-zipping to a temporary location.

Hope that sorta made sense :S

Thats what you got shell objects for.

the win 7 zip handling is done via that:
{E88DCCE0-B7B3-11d1-A9F0-00AA0060FA31}
InProcServer32 - %SystemRoot%\system32\zipfldr.dll
ShellFolder\Attributes - 0x20 00 01 a0
---
SFGAO_CANDELETE 20 00 00 00 Object can be deleted
SFGAO_LINK 00 00 01 00 Object is shortcut (arrow)
SFGAO_FOLDER 00 00 00 20 Object is a folder
SFGAO_HASSUBFOLDER 00 00 00 80 Object contain folder (expandable in explorer/plus sign)
http://www.virtualplastic.net/html/u...tml#attributes

These registry entrys hook the dll up with windows explorer, everything else is done inside the dll. How to write shell applications - refer to MSDN or some random websites or export the zip dll's interface with some debugging tools.