How do I disable the build-in "zip folder" support ?

[R.Wieser]

Hello all,

Today I decided that the build-in zip folders where more often creating a
(seach slow-down when searching for files) problem than I cared for, an
wanted to disable them.

Easy enough, yes ? Just, on a commandline, execute "regsvr32 /u
zipfldr.dll", reboot afterwards and you're done, right ?

Ehhh... Nope.

Just double-clicking the file causes the zipfolder support to come back in
its
full glory (recreating several registry keys), and opens the zipfolder as if
nothing happened.

So, I also removed the HKCR\CLSID\{E88DCCE0-B7B3-11d1-A9F0-00AA0060FA31}
"compressedFolder", "HKCR\.zip" and "HKCR\CompresedFolder" keys.

Although that causes the zipfolders icon to disappear a simple double-click
again brings everything back. Well fiddlesticks!.

Than I tried to see what would happen if I just renamed the "zipfldr.dll"
file. Well, the OS considers it a "very important system file" and just
recreates it. Foiled again. :-\


-- Question --

Without trashing my XPsp3 (read: using a reversable method) how do I get the
zipfolder support to stay away (disabled) ?

Bonus question : what is causing the zipfolder support to get re-installed
when I double-click a zip file ? Mind you, the ".zip" registry key has been
removed at that point.

In regard to the above I've been searching thru the registry for the
"zipfldr.dll" name, but have not found anything that I could recognise as
being "it".

Regards,
Rudy Wieser

[Apd]

"R.Wieser" wrote:
> Without trashing my XPsp3 (read: using a reversable method) how do I
> get the zipfolder support to stay away (disabled) ?

Have a look at the REGINST resource in zipfldr.dll. It's all plain-
text setup information. Perhaps there's a clue there regarding the reg
keys.

[R.Wieser]

Apd,

> Have a look at the REGINST resource in zipfldr.dll. It's all plain-text
> setup information. Perhaps there's a clue there regarding the reg keys.

I did not even think of that, and its certainly worth checking. Thanks.

@others :
Nonwithstanding the above, don't hesitate to post if you have more, specific
info. :-)

Regards,
Rudy Wieser

[JJ]

Type these from the Command Prompt. No need to restart anything.

assoc .zip=nothing
reg delete hkcr\systemfileassociations\.zip\clsid /f

[R.Wieser]

JJ,

> Type these from the Command Prompt. No need to restart anything.
>
> assoc .zip=nothing
> reg delete hkcr\systemfileassociations\.zip\clsid /f

Alas.

I already tried to delete those as part of a "big cleanup" (10 total, 5
CLSIDs among them - some found thanks to Apd's suggestion) after
unregistering, but a simple double-click on a zip file /still/ regenerates
everything.

I can't find any reference to "zipfldr.dll" in the registry that would cause
it to be called when I double-click the zip file or open it thru the context
menu.

IOW, I /think/ it has something to do with some add-on for the context menu.
I can't find anything in that regard though.

Regards,
Rudy Wieser

[Mayayana]

"R.Wieser" <add...@not.available> wrote

| Today I decided that the build-in zip folders where more often creating a
| (seach slow-down when searching for files) problem than I cared for, an
| wanted to disable them.
|

Why do you need to remove it? I set FilZip as default for
ZIP files. I haven't used Windows search for decades. I
haven't seen a ZIP as a folder for many years. One of the
reasons I stopped using Windows seach was because it couldn't
see the filename list inside CAB files.

[R.Wieser]

Mayayana,

> Why do you need to remove it? I set FilZip as default for
> ZIP files.

Who said I did ? I said I wanted to *disable* zipfldr.dll's handling of
.ZIP files. Thats the baseline.

After that I /could/ connect the .ZIP extension it to some other program.
Or maybe not, who knows.

> haven't seen a ZIP as a folder for many years. One of the
> reasons I stopped using Windows seach was because it couldn't
> see the filename list inside CAB files.

One of the reasons I currently do not like "Windows search" is because it
dives into *FILES* without any setting to change that.

Funny though : it has no problem with ignoring the whole \Windows folder,
again with no way to change it. :-|


And by the way, I just found a way to keep zipfldr.dll's grubby fingers off
of .ZIP files : By associating that extension to some other program. Using
a dummy, non-existing filename doesn't work.

Also, thanks for mentioning those .CAB files. I just checked, and "windows
search" does look inside those too. Something else I've got to disable. :-)

Regards,
Rudy Wieser

[Paul]

On 2/19/2022 3:34 PM, R.Wieser wrote:

> I can't find any reference to "zipfldr.dll" in the registry that would cause
> it to be called when I double-click the zip file or open it thru the context
> menu.

One thing you could try (which stops WinXP Search from searching inside ZIP
files), is something like this.

regsvr32 /u zipfldr.dll
regsvr32 /u cabview.dll

That can help speed up un-indexed searches.

But Windows will also re-register those, and I don't know
what the trigger condition is. It's not necessarily just one
reboot that does it.

Paul

[Shadow]

On Sat, 19 Feb 2022 18:52:30 -0500, Paul <nos...@needed.invalid>
wrote:

//
Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{E88DCCE0-B7B3-11d1-A9F0-00AA0060FA31}\ShellFolder]
"Attributes"=dword:00000000
"UseDropHandler"=""
//

Fixed searching inside zip files for me.
[]'s
--
Don't be evil - Google 2004
We have a new policy - Google 2012
Google Fuchsia - 2021

[R.Wieser]

Paul,

> One thing you could try (which stops WinXP Search from searching inside
> ZIP
> files), is something like this.
>
> regsvr32 /u zipfldr.dll

It does*. Thats not the problem (anymore). The thing is that dll
re-registers itself when I double-click or contect-menu -> open a .ZIP file.

* strangely all registry values are removed, but the key structure remains.

> regsvr32 /u cabview.dll

I did not think of that one, and only yesterday verified that "Windows
search" does indeed look inside them too (I regard .CAB files as being
installation, not working files).

> That can help speed up un-indexed searches.

Yup, thats what I'm using.

> But Windows will also re-register those, and I don't know
> what the trigger condition is.

I know /when/ it happens, but not what does it. Though late yesterday did
find that giving the HKCR\.ZIP registry entry an actual target program stops
that re-installing (a dummy name like "foobar" didn't).

> It's not necessarily just one reboot that does it.

It doesn't seem to be. I've rebooted after each un-install a number of
times, as suggested from stuff I found on the 'web.

Regards,
Rudy Wieser

[R.Wieser]

Shadow,

> [snip registry editing of a drop-handler]

>
> Fixed searching inside zip files for me.

I have absolutily no idea how a *drop* handler has anything to do with it,
but I'm going to try it. It would be by far be the easiest (reversible)
solution. Thanks.

Regards,
Rudy Wieser

[Shadow]

On Sun, 20 Feb 2022 09:03:39 +0100, "R.Wieser" <add...@not.available>
wrote:

It fixes .cab files too. I have a large collection of XP hacks
I've picked up over the years, all tested.
That one was from 2009, and it's still working.
Note I turned off indexing too. Not sure if it's the same reg
hack. I rarely keep notes.
YW

PS I use 7-Zip and associate it with all archives, minus ISO.
Tools --> Options --> System --> Associate 7-Zip with.

[Shadow]

On Sun, 20 Feb 2022 07:22:45 -0300, Shadow <S...@dow.br> wrote:

>On Sun, 20 Feb 2022 09:03:39 +0100, "R.Wieser" <add...@not.available>
>wrote:
>
>>Shadow,
>>
>>> [snip registry editing of a drop-handler]
>>>
>>> Fixed searching inside zip files for me.
>>
>>I have absolutily no idea how a *drop* handler has anything to do with it,
>>but I'm going to try it. It would be by far be the easiest (reversible)
>>solution. Thanks.
>>
>
> It fixes .cab files too.

Ooops. I lied.

Cab files:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{0CD7A5C0-9F37-11CE-AE65-08002B2E1262}\ShellFolder]
"Attributes"=dword:00000000

LOL. Too many hacks.

[R.Wieser]

Shadow,

> It fixes .cab files too.

I got the feeling that the same approach would work there too, so I tracked
down its shellfolder, did the same, and got the same "no searching in"
result.

> I have a large collection of XP hacks I've picked up over the
> years, all tested.

I've saved quite a few "for future consideration" (like the zipfldr.dll
un-installing one), but applied only a few of them. Strangely enough I did
not find your shellfolder attributes fix anywhere. I did find an attempt to
outright delete the zipfldr.dll file though - which doesn't work as its a
protected system file.

By the way: I found a list with descriptions of most bits in that
shellfolder attribute value. Looking at them I'm a bit surprised that just
zero-ing them all out still allows me to drag-and-drop files outof and into
ZIP and CAB files. Not that I'm complaining, mind you. :-)

> PS I use 7-Zip and associate it with all archives,

I also have 7-Zip installed, but I've only got it associated with its own
".7z" file extension. All others I open thru the context menu.

Ofcourse, I consider compressed data files as either "source" or "backup" -
not something I regulary work with/in.

Thanks again.

Regards,
Rudy Wieser

P.s.
I saw your other "Ooops" post too. I won't hold it against you. :-p

[Sjouke Burry]

I use 7zip as well as peazip, the last one for more exotic
formats.
link: > https://peazip.github.io/index.html

System; Celeron 2.6 Ghz, XP PRO .

[JJ]

You only need to apply those two registry changes. Keep other ZIPFLDR.DLL
registration intact. Otherwise, if Windows can not find the ZIPFLDR.DLL
registration, it'll try to re-register it - which will revert the above two
registry changes.

[R.Wieser]

JJ,

> You only need to apply those two registry changes. Keep other
> ZIPFLDR.DLL registration intact.

After the uninstall of zipfldr.dll all I was left with where registry keys
without any data in them. IOW, I only cleaned up empty key trees.

> if Windows can not find the ZIPFLDR.DLL registration, it'll try
> to re-register it

As it turns out the trigger seems to be the absense of a
HKCR\.ZIP\shell\open\command executable.

Shadow provided me with another solution though : keeping the zipfolder
itself, but thru disabeling a number of flags its not part of the filesystem
itself.

Though one small problem that I now have is that 7Zip is gone from the
file/folders rightclick menu ... (might reinstall 7Zip to se if it fixes
anything).

Regards,
Rudy Wieser

[R.Wieser]

Shadow,

> PS I use 7-Zip and associate it with all archives, minus ISO.
> Tools --> Options --> System --> Associate 7-Zip with.

I Yesterday I noticed that my file/folder contextmenu was somehow different,
and today I realized what it was : 7Zip is gone from it, and I'm /sure/ you
did that. :-)

All jokes aside, is that something you perhaps recognise and know how to fix
? Other than reinstalling 7Zip I mean.

Regards,
Rudy Wieser

[Shadow]

On Wed, 23 Feb 2022 19:08:49 +0100, "R.Wieser" <add...@not.available>
wrote:

My 7-Zip isn't installed, I use the portable version. Just
open the 7-Zip manager and follow the instructions above. You can
choose only 7-Zip, but I use it for RAR, ZIP, TAR, GZ and a few
others.
All the reg entries will be made for you.

I also like some explorer context items.

Tools --> Options --> 7-Zip -->
Check Integrate 7-Zip to shell context menu + cascaded context
menu.

The two most useful IMHO are "Test Archive" (to test if
something I downloaded is OK) and "Add to Archive" ( to select a
number of files, then make an archive of them). Don't think you'll
need any of the other items.
HTH

[R.Wieser]

Shadow,

> I also like some explorer context items.
>
> Tools --> Options --> 7-Zip -->
> Check Integrate 7-Zip to shell context menu + cascaded
> context menu.

You hit the nail on the head. When I checked it was un-tagged, and
tagging-and-applying the change brought the 7-Zip context menu items right
back. Thanks.

In retrospect I remember having seenthat 7-Zip configuration recently, but
do not remember having changed anything. Must have done it anyway. :-|

> The two most useful IMHO are "Test Archive" (to test if
> something I downloaded is OK) and "Add to Archive" ( to select
> a number of files, then make an archive of them). Don't think
> you'll need any of the other items.

Hmmmm... What about including an option to, you know, actually /extract/
something from an archive file ? :-p

Most what I use 7-Zip for is to peek into-and-extract (selected, single)
files from a random archive, as well its ability to do the same with
self-extractors (executables). Nowerdays I seldom put stuff into archive
files. Just too much disk space available.

Regards,
Rudy Wieser

[Shadow]

On Thu, 24 Feb 2022 09:10:02 +0100, "R.Wieser" <add...@not.available>
wrote:

>Shadow,
>
>> I also like some explorer context items.
>>
>> Tools --> Options --> 7-Zip -->
>> Check Integrate 7-Zip to shell context menu + cascaded
>> context menu.
>
>You hit the nail on the head. When I checked it was un-tagged, and
>tagging-and-applying the change brought the 7-Zip context menu items right
>back. Thanks.
>
>In retrospect I remember having seenthat 7-Zip configuration recently, but
>do not remember having changed anything. Must have done it anyway. :-|
>
>> The two most useful IMHO are "Test Archive" (to test if
>> something I downloaded is OK) and "Add to Archive" ( to select
>> a number of files, then make an archive of them). Don't think
>> you'll need any of the other items.
>
>Hmmmm... What about including an option to, you know, actually /extract/
>something from an archive file ? :-p

I just double-click on the archive for that and choose a
destination.

>
>Most what I use 7-Zip for is to peek into-and-extract (selected, single)
>files from a random archive, as well its ability to do the same with
>self-extractors (executables). Nowerdays I seldom put stuff into archive
>files. Just too much disk space available.

Add "open archive" to the context menu.
[]'s
>
>Regards,
>Rudy Wieser