XYplorer Beta Club

admin wrote:The main problem with (free, but also paid) 3rd party stuff is simply this: It usually has bugs, bugs that I have no chance to fix. And it has limitations, limitations that I have no chance to get rid off. This will sooner or later drive me into depression.

...while MS / Windows routines generally always work without any problems

By the way: if it's open source you could
but I'd understand if you wouldn't want to

admin wrote:The main problem with (free, but also paid) 3rd party stuff is simply this: It usually has bugs, bugs that I have no chance to fix. And it has limitations, limitations that I have no chance to get rid off.

Author 7-zip always produces the program without errors. The separation on alpha and beta and release really matches the names.
Restrictions. I do not know the limitations.
If you mean special requests, like my desire, for example I would like to have the md5-information about files inside archive, then there are two solutions. Or it will make the author of 7zip, as this makes you when we ask you to make it, or you're using the dll and do it yourself.

I'm going to pull a, hopefully small, worm out of the can.

The popularity of the Zip format has out-grown its extension - it's now used in many places with many extensions (docx, vsix, sublime-package, epub, jar, apk, ...).

My long-term vision has XY gaining a custom Archive Previewer (again similar to Fonts, etcs) and a new Archive category in Previewed Formats to control the extensions it should handle. Then this list could also be used to determine when the "Extract" and "Drop into" menu items are available.

However, that's complicated and understandably takes time. But....


Why not introduce that last part now as an INI-tweak "ArchiveCustomExtensions" or if you want to plan ahead for that long-term vision "ArchivePreviewCustomExtensions"?

Then those of us dealing with many zip files of different names can start building new habits around using XY for all our archiving needs.

Nice idea but it will not work. The zipfolder technology stubbornly insists in a ZIP extension.

admin wrote:Nice idea but it will not work. The zipfolder technology stubbornly insists in a ZIP extension.

What stupidity of Microsoft!

Seems official information about abusing zipfldr.dll is rather sparse.
Are you positive it relies on the extension and not something special about how the type is defined in the registry?


I'm willing to tinker to attempt to get it working but no sense trying if it will always come back to the file's extension.

No, I did not deep-research it. But when I rename a zip to another extension ZipFolders tech fails with an "automation error".

admin wrote:No, I did not deep-research it. But when I rename a zip to another extension ZipFolders tech fails with an "automation error".

I hate to ask you to look into this more but....

First decide if you want the change to apply for the current user (HKEY_CURRENT_USER) or all users of the machine (HKEY_LOCAL_MACHINE), as this determines where the change needs to occur. Then browse down into the 'Software\Classes' key of the corresponding hive. Create a new key under 'Classes' named '.zippit' and assign its '(Default)' key a value of 'CompressedFolder'.

Then take a zip file and change its extension to zippit. Now Windows Explorer seems to treat it exactly the same as a regular zip file as it allows exploring the contents and extracting.

Am I wrong in viewing this as proof that ZipFolders can handle zip files of other extensions?

Unfortunately, at this point XY's zip SCs still fail on the zippit, but I don't know if I really should have expected any differently.

EDIT: Clarified where the key needs to go, since you really shouldn't be editing HKCR.

Wouldn't XY lose its portability by doing so?

Marco wrote:Wouldn't XY lose its portability by doing so?

No... this isn't about XY making these changes. It's about XY supporting the case of the user making these changes.

EDIT: To provide some clarity...

Don's testing shows that ZipFolders only supports zip files with the zip extension.
I'm trying to uncover where that limitation is actually introduced, as the above registry change demonstrates that WE seems to be using it on files without the zip extension just fine.

If it turns out that ZipFolders only supports file types that identify as "CompressedFolder" in the registry then XY will not be able to magically handle non-zip zips in the way I previously requested. But it should hopefully then be possible for XY to handle them if the user configures them correctly in their registry.

(And really at that point the argument could be made that since XY already performs some registry writing for Shell Integration, why couldn't it do this writing as well if the user demands it? However, I'm not going to be making that argument.)

So at this point the question has become how does WE get ZipFolders to seemingly support non-zip extensions, and can the same be done in XY?

TheQwerty wrote:

admin wrote:No, I did not deep-research it. But when I rename a zip to another extension ZipFolders tech fails with an "automation error".

I hate to ask you to look into this more but....

If under HKEY_CLASSES_ROOT you create a new key '.zippit' and assign its '(Default)' key a value of 'CompressedFolder'. Reg Import:

Code: Select all

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\.zippit]
@="CompressedFolder"

Then take a zip file and change its extension to zippit. Now Windows Explorer seems to treat it exactly the same as a regular zip file as it allows exploring the contents and extracting.

Am I wrong in viewing this as proof that ZipFolders can handle zip files of other extensions?

Unfortunately, at this point XY's zip SCs still fail on the zippit, but I don't know if I really should have expected any differently.

Wow, that sounds promising! I have no time for testing now, but I'll simply give you a tweak to add custom extensions for zip support.

admin wrote:Wow, that sounds promising! I have no time for testing now, but I'll simply give you a tweak to add custom extensions for zip support.

The SCs appear to work, but do either of those tweaks also affect the zip context menu?

Now I just have to see if I can pinpoint it down further so you don't have to destroy the original behavior for a type by redefining it as 'CompressedFolder'.

It should work everywehere, not just SCs.

admin wrote:It should work everywehere, not just SCs.

The Zip submenu is still mostly disabled for me after adding an extension to both tweaks.


Seems you can narrow it down to just giving the desired formats (the key corresponding to the '(Default') value of the '.ext') the same 'CLSID' as 'CompressedFolder', but I'm not sure what the consequences of doing so might be, or if there is still a better way.

This should at least allow the files to continue to be identifying by their proper types.
Maybe I'll experiment some more tomorrow.


EDIT: It also doesn't make complete sense since I have '.zip' pointing to 'WinRAR.zip' and it doesn't have the 'CLSID' so I'm not sure why it continues to work unless ZipFldr falls back to the extension.

Confirmed, my work was not complete yet. Next version should be better.

@TheQwerty:
I am trying to understand how this is supposed work.
Following your directions XY's zipview works fine if i rename my .zip to .7z or .tar or any other extension that i modified in the registry and enabled latest XY's tweaks.
But it doesn't work with real .7z file or other files that were made using say 7-zip software.
So this hack only works if i rename my zips to something else and not with archive created by other softs? or am i missing something?
Edit:
Forgot to mention that if i use zipview on .7z files created by 7-zip software i get "archive is empty".