After I downloaded .NET Framework 2.0 SP1 today, I double-clicked the .exe file (which is SFX CAB file) to run it, but instead of running it, Opus shows the Open With... dialog. If I right-click the file and select Open (which is the default command), the file runs normally.
I tested some SFX CAB files and found out that this happens with some newly downloaded SFX CAB files not the old ones.
PS: I don't have any custom commands for the double-click event of .exe files.
Weird. Double-clicking them in Explorer works okay I presume?
If you make a toolbar button which runs FileType EDIT and click it while one of the files is selected, do you get the usual Application/.exe filetype or something else? What about with the files which do work normally?
I can't reproduce the problem on Vista but I assume you were using XP (or Win2k or Win2k3) since the installer itself says it isn't intended to be run on Vista.
OK, the problem has nothing to do with file I mentioned above, it's related to the name of the file saved on disk. I saved the above mentioned file as .NET Framework 2.0 SP1.exe
If you rename any exe to start with a . (dot), you'll be able to reproduce the behaviour I refered to. This happens with .exe files and maybe with others
Actually, this is a bug in opus due to error in the logic used to extract file extensions which makes it consider all chars after the first . in exe files to be the ext, which in turn has no file association.
this is for the authors if they need more tech details:
After I started a quick debug session, I found out that opus uses the same routine at VA 006CA290 to pass a file ext. string and other times to pass the file part string (returned by the exported function FindFilePartW in dopuslib.dll), but at the instruction at VA 006CA2C6 it compares the start of the string arg passed with the . (dot) char, if it's so, it'll bypass passing the string to the exported function FindFileExtensionW in dopuslib.dll and consider the string to be an ext., but this leads to the bug I mentioned when a file part is passed and starts with the . char which makes opus bypass the FindFileExtensionW function and consider the file part as extension.
My suggestion is to remove the instruction at VA 006CA2C6 and whether the string passed starts with . or not pass it to the FindFileExtensionW function.
It's possible that the code to 9.1 was locked down for a long time before the release but it's also possible they simply don't know about the bug because nobody reported it to them.