Anyone here remember the commands to make a "zip folder", not a "zip file"?

[ISAWHIM]

I vaguely remember that there was some specific method to get windows to create a "New zip folder", which was actually just a zip-file, but windows treated it as a normal folder you could navigate with windows-explorer.

If I am not mistaken, I think windows hid that feature, in favor of the setting for "Compress folder contents", which uses various compression techniques, not just "zip". (This was after windows obtained the rights to ZIP, and Pentium built special instructions to ZIP and UNZIP, within all the CPUs.)

I believe it involved the creation of a dummy-file, without a file-ext. Then there was some registry value that had to be set for that file, to tell windows to treat it as a "compressed folder" (a CommonDLG navigable zip-file).

If it wasn't a registry setting, it was some REG ID value, used some way, with the file, to change it's type. (Similar to how a SymLink or a ShortCut file is made.)

It is just one of those things I am having no luck getting google to give me an answer for.

The icon use to look like this...


You could select the desktop with the Second-Mouse and in the MENU for NEW, would be the option for "Zipped folder" (Originally) or "Compressed Folder" (After windows acquired ZIP). No relation to selecting a folder and selecting "Compress folder", which uses the "other" compression options that are NOT zip.

If you select a file and "Send to compressed (zipped) folder", it just makes a zip-file, not a zip-folder. (You can't navigate it with normal Common Dialogue controls, because it doesn't show as an actual "folder", like a shortcut or symlink does.)

I assume that is why Google is choking... It is returning Zip crap and "Folder compression", which is NOT what I am looking for.

This guy knows what I am talking about, but the solution provided just moves the new "Add to compressed (zipped) folder", which is a zip-file. (Horrible solution, pointing to what is already there, in another area, that ISN'T what was asked for. That's like asking for a new horse-buggy, and someone points you to a steam-engine.)
https://answers.microsoft.com/en-us/...4-c26299cd79c8

This is the one...


It produced this...

[ISAWHIM]

I realize that you don't get any fancy compression settings or (not sure if it could have a password)...

But, the whole reason for having it, was the following.
1: Because it worked like a normal folder, you could navigate it with normal DIR commands and "Common Dialogue Controls". Including all sub-dirs and see all files.
2: Windows did all the zipping and unzipping, and clean-up. (Really no actual clean-up, because unlike a normal zip, it used the internal CPU commands and just extracted the data "on the fly". It did not "unzip it into a temp-location", then use that location as the files virtual-location. Important because you could not use file2, called from file1, unless all files were extracted into the temp location. This way, you could, because they were virtually in the same location. The "folder".)
3: No need for any external dlls or dodgy shell-commands or complex APIs. You just navigated there, got the file or made one, and it was zipped or unzipped, instantly.
4: My game will have a LOT of text-based files, which ZIP LOVES to compress. It will also have a lot of images, which don't really gain from compression, but some may. I'd like to have the ability to just change locations, for those that do get compression. As opposed to having to decompress, copy into memory, use, then dispose of them, over and over again.
5: It was faster than winzip, 7zip, and most others, because it used native pentium/amd code and no fancy compression. (Wasn't the "best" compression, but it was adequate.)

[fafalone]

There's no distinction here. There's just zip files, which Windows treats as a folder via a shell extension.

You can create a new empty one, like the New->'Compressed (zipped) Folder' right click option in Explorer by creating a new file with the .zip extension and writing the following hex values as the first 22 bytes of the file:

50 4B 05 06 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

[ISAWHIM]

There's no distinction here. There's just zip files, which Windows treats as a folder via a shell extension.

You can create a new empty one, like the New->'Compressed (zipped) Folder' right click option in Explorer by creating a new file with the .zip extension and writing the following hex values as the first 22 bytes of the file:

50 4B 05 06 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

I saw a similar post, and I believe that is/was part of the equation...

The other part was, from reading about other "tricks", the addition of a CLSID value to the file-name. Similar to these "tricks", to make a folder or file look like another thing, by adding the CLSID value to the file-ext. Which also makes the program "launch" or "be processed" VIA special instructions. (In this case, it tells "windows" to treat the file without the file-ext as a "zip", but display and function as a "folder".)

http://letmeknowww.blogspot.com/2009...re-how-to.html
and this...
https://www.codeproject.com/Articles...lders-in-WinXP

What you posted, is quite possibly the the product of one created, originally, as this "shell" of an empty file. (Windows won't actually let you send "nothing" to an actual zip-file, it demands "something". While a "folder" didn't require anything.) Which is really annoying, because you can make a zip-file, with a file in it, then delete that file, leaving it blank. (But it is not truly blank, as it has that index info from the old file, until you add a new file for the new index.)

If I had to guess windows reasoning for removing it, I would say it was the following...
1: Security issue, due to people making self-extracting zips that look like folders, which were actually nested viruses.
2: Security related to "zip-bombs", which were scripted zips that expanded to unfathomable file-sizes, a billion times greater than the source file.
3: Confusion between "zip-files", "zip-folders" and "compressed folders" and "compressed (zipped) folders". But they stupidly re-used the same name for the "other type".
4: Something they couldn't figure-out, was giving them trouble, related to treating zip-folders as "virtual-folders". So they just stopped using it after Windows-98se/XP.
5: Legal reasons... (The "other white meat".)

But...

The CLSID still has to be there, and that function still has to exist, because it ONCE existed. (Otherwise there would be old files it couldn't open, from prior windows creations. From a time when many people were using that "new toy" for everything.)

I'm still googling. The CLSID thing helped narrow-down the garbage search results. Luckily, people with VB.NET 6 are not "zipping things", which would make this even harder to search for. That is what is killing half my search-results now, when looking for VB6 stuff. Luckily, not many people use VB.NET 6, or they aren't saying "6" when googling and typing crap up. But google still "knows" there is a VB .NET 6 (AKA: VB6 too), and feeds me those results, mixed with actual VB6 (classic) results. But google isn't smart enough to KNOW that "classic" = "Not .NET".

That's like trying to google for "World War I", just after "World War II", when World War I was just "World War", before that point.

[ISAWHIM]

I found the CLSID here...
https://www.oreilly.com/library/view...08767/apd.html

Compressed Folder {E88DCCE0-B7B3-11d1-A9F0-00AA0060FA31}

I can rename the folder to "TestFolder.{E88DCCE0-B7B3-11d1-A9F0-00AA0060FA31}", and that makes it "look" like the zip folder, and gives me an "access denied" if I try to actually use it. It also retains the CLSID visually, as the file-name. (Well, I have "show file extensions" set. But there was a method to do this, where it didn't show that. Same like how a shortcut doesn't show the "shortcut.lnk" extension, no matter what settings you select to show.)

I am getting closer!

UPDATED: Has something to do with "Shell Folder"... Not sure how to use VB6 to do that though. (Windows treats the "thing" as a virtual-folder, like "recycle-bin" which is just a series of zip/cab files and short-cuts and system-folders, etc.)

https://winaero.com/clsid-guid-shell-list-windows-10/

CompressedFolder shell:::{E88DCCE0-B7B3-11d1-A9F0-00AA0060FA31}

[ISAWHIM]

I am starting to wonder if they disabled the "processing" of the virtual-folders with CLSID {E88DCCE0-B7B3-11d1-A9F0-00AA0060FA31}...

For reasons, it still shows as a zip-folder and actually has a file-size of an empty zip. But, because it is not actually "being processed" as a virtual-folder, the CLSID remains visible and the function doesn't work anymore. (Thus, my odd access violation of permissions to the created folder/file.)

Or, that method just might not work for "that" type of virtual-folder, and I need to find that old code to set the "shell ext", using some specific shell:::Command process. (That sounds more familiar.)

Still poking around in the dark here. Hopefully something said here, will trigger someone's memory and they will just KNOW... "Oh yeah, isn't that BuddastBaby432343's post? From 1995! For VB4." :P

[fafalone]

You don't need to do anything besides create the empty zip file with the 22 bytes I mentioned. There's no trick to it whatsoever, it's just a shell extension that lets you view zip files.

All the CLSID stuff you're talking about is for registering the type and shell extension.

Also what are you talking about removed? I use them every day on Windows 10 and a quick check with google doesn't indicate it was removed from 11.

[Elroy]

There's no distinction here. There's just zip files, which Windows treats as a folder via a shell extension.

I thought you had to be a bit careful about the compression technology used in the ZIP file. I'm sure your 22 bytes does it, but I didn't think Windows understood all the options, and wouldn't treat them as folders if there was something Windows couldn't understand.

It'd be nice if we had an outline of the compression technologies that Windows did understand. Maybe Wqweto will weigh in, as he's done some very nice ZIP work in the past.

[fafalone]

I'd imagine there are some formats that it doesn't support, and there's the long standing issue with passwords, but the byte sequence I gave comes directly from a new one I created then opened in WinHex.

[ISAWHIM]

You don't need to do anything besides create the empty zip file with the 22 bytes I mentioned. There's no trick to it whatsoever, it's just a shell extension that lets you view zip files.

All the CLSID stuff you're talking about is for registering the type and shell extension.

Also what are you talking about removed? I use them every day on Windows 10 and a quick check with google doesn't indicate it was removed from 11.

You won't see it being removed, because they sneakily renamed it to the same thing. However, it is NOT making the same thing. People just think it moved, except those, like me, who know what it ACTUALLY was, and realized it's gone now. There are thousands of posts about it. They all gas-light every poster, telling them it's still there, and show how to make it "appear again", doing things like you are doing now. (The hard way of just recreating a standard empty "Zip file", than telling them to just call it a "zip folder", which it is not.)

If it says "something.zip", then it's not a "zip folder", that's a standard "zip file", which windows is calling a "folder", incorrectly. The "extension" is there and no CLSID is needed, except for windows to determine which program "gets the file" if you try to open it. It reads the EXT, finds the CLSID in the registry, then opens the associated program, if one exists. If the CLSID is IN the folder, windows does the reverse, in essence. It already KNOWS how to display the "thing" and how to access it. If it looks like a zip-file or a folder with a "Z" on it, then it's NOT a "compressed folder", it will look like that icon in the first picture.

The whole point of adding the CLSID to the file-name, also, is because these files don't have a visible "extension". Remove your .zip extension and the file is "unknown". (Windows may read the file-header and see it's a zip, but it may not.)

Here is what it looks like, exactly. (The CLSID trick set, but it's not "correct". I can't access the file. Notice it has no permissions or any other properties tabs besides "Previous version".)



Also the error, when I try to open it.



This will NOT work for an actual "file", just for the record. It has to be an actual folder.

This is why I think they got rid of it. (Well, half-way. Some parts of it still exist. Just not enough. Unless I am just doing it wrong. Which is highly possible and most-likely the real issue. I do remember it being a process like creating SymLinks and Shortcuts. There was some command or system API that had to be called, to create this correctly. Or a Shell-command.)

The CLSID tells windows how to process the "Virtual folder", which is what I am looking for. I'm not looking for something that I need to use special code to navigate, extract, and then use the contents within. It needs to be seamless, appearing as a folder, traversed like an actual folder and not require any code to "use" the things inside or to save things inside.

The other limitation was that you couldn't put another REAL "Compressed folder" into one that already exists. (Since, in reality, the folder is just a link to an actual zip-file, hidden under {in place of} the virtual-folder link.)

Every special folder-type has a hidden CLSID, as an extension. Windows just hides it from YOUR view, unless you use special code to reveal it, and often also to set it. These special "things" are not processed like normal files and folders, by windows.

[Dan_W]

I took the following from Ron de Bruin's VBA site:

Sub NewZip(ByVal FilePath As String)
    Open FilePath For Output As #1
    Print #1, Chr(80) & Chr(75) & Chr(5) & Chr(6) & String(18, 0)
    Close #1
End Sub

which you will note matches the 22 bytes in fafalone's reply above.

I'd like to have the ability to just change locations, for those that do get compression. As opposed to having to decompress, copy into memory, use, then dispose of them, over and over again.

As for your point about dealing with the contents of the ZIP without first having to unzip the entire contents of the folder to a temp location, etc., the Excel project I worked on might be useful? Excel has a bug which can sometimes cause "phantom rows", which results in workbook files sizes inexplicably larger than they should be (e.g. a simple 3x3 cell workbook can suddenly clock in at 5mb). As you probably know, Office files (xlsx/docx/etc) are actually ZIP files comprising XML files, and it transpires that these phantom rows are a result of excel filling one of these XML files with a huge amount of unnecessary XML code. The (arguably inelegant) solution we arrived at demonstrates a method of accessing an xml file, amending it, and adding it back into the ZIP file without having to first extract all the files and then rezip the files at the end of the process.

5: It was faster than winzip, 7zip, and most others, because it used native pentium/amd code and no fancy compression. (Wasn't the "best" compression, but it was adequate.)

I don't know how the method we used compares to Winzip, etc., but we did make a note in the thread of how long the code took to complete. Bear in mind, my computer is abnormally slow... and that this is in VBA.

[fafalone]

You won't see it being removed, because they sneakily renamed it to the same thing. However, it is NOT making the same thing. People just think it moved, except those, like me, who know what it ACTUALLY was, and realized it's gone now. There are thousands of posts about it. They all gas-light every poster, telling them it's still there, and show how to make it "appear again", doing things like you are doing now. (The hard way of just recreating a standard empty "Zip file", than telling them to just call it a "zip folder", which it is not.)

If it says "something.zip", then it's not a "zip folder", that's a standard "zip file", which windows is calling a "folder", incorrectly. The "extension" is there and no CLSID is needed, except for windows to determine which program "gets the file" if you try to open it. It reads the EXT, finds the CLSID in the registry, then opens the associated program, if one exists. If the CLSID is IN the folder, windows does the reverse, in essence. It already KNOWS how to display the "thing" and how to access it. If it looks like a zip-file or a folder with a "Z" on it, then it's NOT a "compressed folder", it will look like that icon in the first picture.

The whole point of adding the CLSID to the file-name, also, is because these files don't have a visible "extension". Remove your .zip extension and the file is "unknown". (Windows may read the file-header and see it's a zip, but it may not.)

Here is what it looks like, exactly. (The CLSID trick set, but it's not "correct". I can't access the file. Notice it has no permissions or any other properties tabs besides "Previous version".)



Also the error, when I try to open it.



This will NOT work for an actual "file", just for the record. It has to be an actual folder.

This is why I think they got rid of it. (Well, half-way. Some parts of it still exist. Just not enough. Unless I am just doing it wrong. Which is highly possible and most-likely the real issue. I do remember it being a process like creating SymLinks and Shortcuts. There was some command or system API that had to be called, to create this correctly. Or a Shell-command.)

The CLSID tells windows how to process the "Virtual folder", which is what I am looking for. I'm not looking for something that I need to use special code to navigate, extract, and then use the contents within. It needs to be seamless, appearing as a folder, traversed like an actual folder and not require any code to "use" the things inside or to save things inside.

The other limitation was that you couldn't put another REAL "Compressed folder" into one that already exists. (Since, in reality, the folder is just a link to an actual zip-file, hidden under {in place of} the virtual-folder link.)

Every special folder-type has a hidden CLSID, as an extension. Windows just hides it from YOUR view, unless you use special code to reveal it, and often also to set it. These special "things" are not processed like normal files and folders, by windows.

The only other thing you might be talking about is file system compression, but it doesn't show using that icon, and is very much a real folder, not a zip file or anything else-- it's when you select compress in the attributes.. should show the name in blue. But no special icon.

And where clsids are stored is complicated, it isn't always in the name.

It's possible you're remembering a 3rd party .zip shell extension, but there was never a different official one. The official one, for zip files, uses the exact icon in your post, unless you've reassigned .zip files to something else. Also it is seamless... Opens in Explorer, can browse subfolders, can read individual files... My ucShellBrowse control navigates them like any other folder too because it uses the same high level shell interfaces/apis as Explorer.

[OptionBase1]

I have access to a fairly vanilla Windows 2003 server. The right-click context menu in a Windows Explorer window has an entry under "New" called "Compressed (Zipped) Folder". Selecting that results in a new file being created with the icon you included in your first post, with the filename of "New Compressed (zipped) Folder.zip". It is, indeed, 22 bytes long. I didn't examine the file in a hex editor to see if they matched the above mentioned content, but I have no reason to suspect it is different.

If your memory is such that the filename had no extension, then I would posit that the option of "Hide extensions for known file types" must have been enabled on the computer you were using at that time.

Edit:

Or:
Under HKEY_CLASSES_ROOT\CompressedFolder
Create a new String Value called "NeverShowExt" with an empty value
Reboot

[Elroy]

So, the short of it is ... create one of these 22 byte "folders", and just put files into them with "Open ... For Output/Random/Binary" or "Name" or "FileCopy". Seems pretty straightforward.

[VanGoghGaming]

The compression ratio is very bad for those ZIP folders, even when they only hold text files. You would be better off using another compression method and extracting your files in memory when your application starts.

[ISAWHIM]

I have access to a fairly vanilla Windows 2003 server. The right-click context menu in a Windows Explorer window has an entry under "New" called "Compressed (Zipped) Folder". Selecting that results in a new file being created with the icon you included in your first post, with the filename of "New Compressed (zipped) Folder.zip". It is, indeed, 22 bytes long. I didn't examine the file in a hex editor to see if they matched the above mentioned content, but I have no reason to suspect it is different.

If your memory is such that the filename had no extension, then I would posit that the option of "Hide extensions for known file types" must have been enabled on the computer you were using at that time.

Edit:

Or:
Under HKEY_CLASSES_ROOT\CompressedFolder
Create a new String Value called "NeverShowExt" with an empty value
Reboot

This interests me... ("NeverShowExt") Wasn't aware that was even a thing. I wonder if they removed that from that specific CLSID, and that is why it shows that CLSID, when I try to use it. No other CLSID values do that to me. If I have to do that to a users system, to get it to work, then this is a lost cause. But, I can't even get it to function as an actual zip-file. It strips all the rights in the process. But, oddly, it allows me to delete it and rename it, without any permissions.

Can you see it as a "folder" in a common-dlg, in VB6? (Not "windows explorer")

I am thinking that "that file", is the one that needed the CLSID, somehow set to it. (The 22 byte-long empty file.) But, since it's a file, it can't hold that CLSID, which is reserved only for actual folders. I am wondering if this is a double-CLSID situation. One tells windows that it is a symbolic-link "as a folder", but "to a file". Then the second CLSID for the zip folder (since windows thinks it's a folder), changes how the file is accessed.

Like I said, it was a "trick". One of those things that apparently existed for only a brief moment in time.

The only reason I even remember it, was because I used it a LOT, once I found out how to do it. I am also about 95% sure I was using VB5 and about 5% sure I may have been using VB4. I am trying to help google get better results for that time-period. But the other side of this is the fact that I think I got this from a long-expired code-archive that hasn't been archived like the rest. I don't think I ever used anything zip-related, while programming in VB6. I was into graphics and text processing and web development, in that period. You know, "the bloat period".

I'm going to put this on the back-burner for now. I will go mad trying to chase the white rabbit.

Thank-you all who kept the flame going. The easy way is never actually easy.

[fafalone]

I've been doing heavy shell programming for 20 years. Everything you're describing is the CompressedFolder shell extension for handling zip files, from the icon to the behavior. There was never any 'trick' with this behavior and this icon involving putting the CLSID in the filename.

Whether you see them in common dialogs depends on the flags you select. And like I said... I have ucShellBrowse and ucShellTree, that enumerate and navigate paths...



It reports them as folders, with the SFGAO_FOLDER attribute. So they get browsed into as a folder (you can tell them apart to offer an option to manually treat them as a file by the presence of the SFGAO_STREAM attribute), then offer all the file enumeration and property system interfaces programs like Explorer and my ucShellBrowse use to show you a normal folder, just displaying inside a zip, with properties specific to zips. But they're otherwise normal folders. You can even drag/drop in and out of them (not just Explorer but common dialogs and ucShellBrowse). You're telling me this isn't what you're talking about? Notice how the icon on the right where it's displaying the zip is the exact one you're claiming is what you're talking about (but not this?).

And you know how those were all created?



The exact same menu entry you're trying to say is something else.

I'm 100% sure you're just misremembering some details like all this CLSID stuff; yes the shell extension has a CLSID associated with it, it's just not something you put in the file name, and there was never any zipped folder that wasn't actually a zip file.

[wqweto]

... and there was never any zipped folder that wasn't actually a zip file.

I had same conslusion here. Putting the zipfldr CLSID in the folder name does look like it's doing something but it fails any other interaction so my guess is this is a non-deliberate side-effect.

This CLSID is not meant to be put in folder names like Control Panel, Printers and the other "secret" CLSID which turn regular folders into special folders. This CLSID does not work the same although it changes the icon of the folder for some obscure (non-targeted) reason.

cheers,
</wqw>

[dilettante]

Files in CAB archive format are handled by File Explorer in a similar manner.

[ISAWHIM]

It's just not something you put in the file name, and there was never any zipped folder that wasn't actually a zip file.

Yes, I know you didn't just add it to the name. (I was just using that example to test if the CLSID was still functional) It was some API or shell-command, that told windows to treat that "actual zip file", as an "actual folder". But, not 100% as an actual folder. (It still processed it as a zip-file, internally. Because it was an actual zip file.) The difference being, ONLY that you, with a program, could see into it, as if it was an actual folder, and read and write files into and from it, without having to use any "zip" code.

It wasn't something that windows did natively. That listing (the one where it is in NEW, vs the one that is created when you use "Send To"), is the file that the "trick" was done to. (hack might be a better term, because it restored what windows originally had that file do)

Like I said, I am done with that, for now. :P

I did try the "Cab archive without an extension", which should ALSO have worked the same way, but windows won't even let me create cab-files anymore, as an archive, of a folder, through Shell commands in VB6. They seem to be blocking that too, or that old EXE is no longer functioning, for that purpose. No errors, it just dies if you try to do it, with or without a cab extension. (MAKECAB.EXE) doesn't seem to like me.