Some tuning tools like XP-Antispy are able to disable the functionality of compressed folders, however it didn’t work for me on Vista the last time I tried.
After a while of research I found the solution how to edit the registry, so that double-clicking associated files will truly be opened with the external application:

Deleting the following two registry keys and restarting Windows will disable compressed folders (or “Komprimierte Ordner” as they are called in the German Windows):

HKEY_CLASSES_ROOT\CLSID\{E88DCCE0-B7B3-11d1-A9F0-00AA0060FA31}

HKEY_CLASSES_ROOT\CLSID\{0CD7A5C0-9F37-11CE-AE65-08002B2E1262}

I found the solution here, where you will find .reg files for automated removal (and adding the keys back to the registry).

After you reboot, compressed folders should be turned off.

Update 04/14/2010:
As pointed out by Mark, the above instructions don’t fully work in Windows 7 due to some permission restrictions. Here are the additional steps you need to do in Windows 7 (credit goes to James):

• Right-click “Permissions” on the two keys mentioned above when browsing the registry editor
• Click “Advanced”, tab “Ownership” and select your username (which needs to be an administrator)
• Check “Replace owner on subcontainers and objects” and click “OK”
• Back in the permissions, select your username (or “Add…” it if it’s missing) and grant “Full Control”

Now you can delete the key(s) after you have performed those steps (for each key).

Update 05/20/2010:
One user reported his screen went black (on his laptop) after applying the .reg files (under Vista). I don’t know whether there’s a direct connection or whether it was just coincidence, but he let me know that after a (manual) reboot, everything was fine again – including compressed folders being disabled.

In my opinion, it took me too long to find the solution online, that’s why I am posting this blog entry (apart from self-interest as a reminder ).

So, after you have possibly created and edited the customized keyboard setup to your needs – drumroll – while in the Edit-Dialog of your keyboard setup (Tools -> Preferences -> Advanced -> Shortcuts -> select your “Keyboard setup” and click Edit) you need to click on the Default button in order to (as I called it) “enable” the keyboard setup.
That’s all there is to it – simple if you know it, but a bitch if you don’t and try all sort of tricks .

Btw, for those of you who’re interested: The only change I made in the keyboard setting (and that really matters to me) is that I like Ctrl+D to perform “Paste + go” as it used to do in older Opera versions. For me it was one of the most useful shortcuts ever and in my opinion was way more efficient than the “new” default setting (after Opera adapted Ctrl+D to be “Bookmark directly”, that I never use anyway, from Firefox).

My first try via tweaking the registry (adding an entry in the HKEY_CLASSES_ROOT as you would normally do for an extension) was without success. Also other tweak programs, which are capable of setting file associations, fail to do this for files which do not have an extension.
When looking for a solution on the web, I came across this blog entry of Elijah Grey, who wrote a batch file with which you’ll be able to associate all files without file extension to any program. He uses the command line tools ftype and more importantly assoc. Even though this solution is neat, it didn’t quite satisfy my needs – because I might want to associate different filenames (without extensions) to different programs.
Looking at the help of assoc, the command line tool just handles extensions (as parameters), e.g. “.txt” or just “.” for files without extension. But it is not able to use the parameter as desired fixed filename (without extension). As you can see from my comment to the blog entry, Elijah stated that it is not possible to associate certains file names to a program under Windows.

This means, at least for the time being I will not be able to restrict file associations of files without file extension to just certain filenames.

However, when you think about this issue, you will face the following questions:

• where do the files come from / where are or were they created?
• which program should they be associated?

The answer to the first question is, of course, for the most part such files will have something to do with Unix – and furthermore therefore most likely not have Windows line breaks. That means (starting to find the answer to the second question), if you intended the special files to be associated with notepad, the standard Windows editor, it would not be neatly formatted in the first place.
But on the other hand, if you wanted those files to be associated with your favorite editor (UltraEdit, SciTe, EmEditor, Notepad++, Programmer’s Notepad, … just to name a few), with which you wouldn’t have line break issues, actually all of those editors have the option to be integrated in the right-click context menu (of any file explorer). That means, to edit those files instead of double-clicking you would have to go through one right-click and then one left-click.

The way via the context-menu obviously takes more time (and time adds up ) and is still no solution to the original problem. But it seems, for the moment we will just have the option of the context-menu or (using assoc or Elijah’s script) to associate all files without file extension with a program. Meaning, no two different programs for two differently named files – but let’s be honest, most of the files without extensions (see above for the examples) are simple text files anyway

The boot process would then be like this:

• load OpenSolaris GRUB from third primary
1. boot OpenSolaris from third primary
2. load Microsoft bootloader from first primary
3. load Microsoft bootloader from second primary
1. boot Windows 7 from C: (as first primary)
2. boot Windows XP from E: (as second primary)
4. boot Ubuntu (several entries for different kernels) from logical

It turned out that when installing Windows 7 over XP, it kept the second primary partition as booting partition and installed its bootloader there. Choosing load Microsoft bootloader from second primary in GRUB got me to the MS bootloader screen, where I was able to choose which Windows I would like to boot into. However, if I went for load Microsoft bootloader from first primary, I was getting this error message:
BOOTMGR is missing
Press Ctrl+Alt+Del to restart
or in German:
BOOTMGR fehlt
Neustart mit Strg+Alt+Entf

It means that there was no MS bootloader (of any sort) located on the first primary partition (obviously because Win7 kept the second primary as boot partition).
I was able to fix this by booting via the second primary partition into Windows 7 and running “bcdboot.exe C:\Windows C:” on the command line with elevated rights. This command would create the file C:\bootmgr as well as the directory C:\Boot (which contains the BCD registry file along with language files).
After that I was perfectly able to choose the entry from GRUB which would load the MS bootloader from the first primary partition.
(As a note: if you found this blog entry without having the same setup and a working Windows 7 or Vista installation, you can achieve the same effect via the Installation-DVDs. Maybe not via bcdboot but bootrec)

The second effect I encountered was, when I was trying to edit the text of the MS bootloader on the second partition (change “Earlier Windows version” into “Windows XP”), which is done via bcdedit.exe, all I found was this error message:
The boot configuration data store could not be opened.
The system cannot find the file specified.
in German:
Der Speicher für die Startkonfigurationsdaten konnte nicht geöffnet werden.
Das System kann die angegebene Datei nicht finden.
The reason for this is, bcdedit looks for its registry file (\Boot\BCD) only on the active partition. (You can check this on this Microsoft site)
Note: BE CAREFUL about the program with which you make a partition active! You can safely do this for example via GRUB or Gparted. I strongly discourage from using diskmgmt.msc (under Windows): it removed Ubuntu’s swap and root partition from the partition table and I had no choice but to reinstall Ubuntu (this might be a bug in the Win 7 RC, but I think it’s rather a bug in the disk management console itself).

So, after some fuss about changing the active partitions back and forth while setting messages for the (different) MS boot loader(s), I renamed (just in case) the folder \Boot and file bootmgr on the second(!) primary partition, leaving just NTLDR on it.
Because Windows XP was booting just fine, I am assuming, that an MS bootsector first looks for bootmgr and if it doesn’t find one, it looks for ntldr. (The reason why I believe this is, if I renamed the file ntldr as well, I got the above message about BOOTMGR missing).

The current setup now looks like this (after making the third primary, OpenSolaris, partition active again):

• load OpenSolaris GRUB from thirrd primary
1. boot OpenSolaris from third primary
2. load Microsoft bootloader from first primary, which boots via bootmgr (into Win7)
3. load Microsoft bootloader from second primary, which boots via ntldr (into WinXP)
4. boot Ubuntu (several entries for different kernels) from logical

The primary targets were Windows XP (SP3) and Ubuntu (9.04) for coding purposes, secondly Windows 7 RC for testing purposes and OpenSolaris for experience.
I did a lot of installing and reinstalling this past week, until I finally managed to get all four systems working and accessible.

The original partitioning plan was to have two primary partitions and a few logical partitions (inside an extended partition, of course), so there will be room for more systems. After installing Windows XP to the second (primary) partition and Windows 7 in the first, I found out, that the OpenSolaris installer did not create a logical partition (as expected) in the extended partition, but deleted the extended and created a solaris partition (with new size) instead. But because I wanted OpenSolaris to be in a logical partition, I used GParted to created the extended partition again and prepared a dedicated (logical) partition for OpenSolaris. Unfortunately OpenSolaris doesn’t see behind the walls of the extended partition, so – again with GParted – I shrunk the extended and created a third primary partition for OpenSolaris. This time the installer used the partition correctly – nevertheless it contains bugs, and that’s why the installation failed on first try. But with the help of this awesome guide I managed to also take this hurdle. Finally, after installing Ubuntu, I decided I would want to use OpenSolaris’ grub rather than Ubuntu’s (I can’t quite recall whether it was just a visual reason or whether there was more…).

Furthermore I had to face other issues: Windows XP installed itself on drive E:, because it recognized the first primary partition as C: and the card reader as D: (even though E: is the second primary partition), I still haven’t figured out why. Also, after installing Windows 7 and OpenSolaris, I couldn’t boot XP anymore (copying NTLDR and stuff didn’t help). And last but not least, for (still) unknown reason, Windows 7 wouldn’t start bcdedit anymore (yes, even though I started it from a commando prompt with elevated rights).

In order to get Windows XP booting again, I had no choice but to reinstall it (fixmbr from the installation disk wouldn’t work). So I also had to reinstall Windows 7, because from the RC disk I couldn’t start bcdedit, either. This time, however, the Windows 7 installer did not recognize Windows XP as a previously installed version – nevertheless I was able to add Windows XP to the MS bootloader.
OpenSolaris and Ubuntu were still were they belonged, but I had to get them booting again. Trying to restore OpenSolaris’ GRUB (and load it into the MBR) failed with read/write errors, as also shown in this thread. I tried it many times, never successfully though. I thought, the heck with it, I’ll use Ubuntu’s GRUB. Well, I wasn’t able to restore that one, either: stage1 couldn’t be read correctly. According to this wiki entry, with an inode size other than 128, GRUB isn’t able to read from the filesystem. I thought the situation is rather kinda stupid, that the Ubuntu installer creates a partition with an inode size that GRUB won’t be able to read? So I decided to try with OpenSolaris’ GRUB again.

I could boot into OpenSolaris, but just using the LiveCD and entering GRUB commands manually (rootnoverify (hd0,2), chainloader +1) – because at the moment, Windows 7′s bootloader was booting at system start. Since trying to restore OpenSolars’ GRUB back to the MBR (see this) still failed, I was again looking for solutions online. I stumbled across this page (currently only accessible via Google cache), which sounded really easy: just activate the OpenSolaris partition again. Could it really be that simple? It was. After making the partition active, GRUB fired up at system start, and I could boot into all four systems. For Ubuntu I had to adjust the menu.lst settings though: Jaunty uses uuid rather than root by default, but somehow OpenSolaris’ GRUB can’t yet deal with this.

Status quo: At system start I will see the OpenSolaris GRUB with Windows 7, Windows XP, OpenSolaris and Ubuntu as boot options. Windows 7 gets me to the Microsoft bootloader (where I again can choose between 7 and XP, which I added via bcdedit in the beginning). Otherwise I can boot the three remaining systems directly.

Finally, I got the system I wanted: Four operating systems, bootable without inconvenience

[UPDATE 07/07/09:] In order to fix problems with the Windows boot loader, I was using the description at this page.
But using the “manpages” via bcdedit.exe /? also helped. [/UPDATE]