64-bit shell extensions - why did they have to change them

[glugglug]

In 64-bit windows, the shell extensions added by most 32-bit apps don't work.

I miss the stuff on my right click menu for WinRAR, 7-zip, and UltraEdit.
Why the heck did Microsoft decide to change the way these are set up in the registry?

 

[Budman]

Why dont you wait till they actualy release it?

they might put it back once it's done.

 

[Nothinman]

Why the heck did Microsoft decide to change the way these are set up in the registry?

I doubt they did, if they did anything it was to allow for 64-bit and 32-bit programs to be installed side-by-side. Chances are your extensions are 32-bit dlls and there's no way for a 64-bit process (in this case explorer) to load 32-bit dlls.

 

[glugglug]

Originally posted by: Nothinman

Why the heck did Microsoft decide to change the way these are set up in the registry?

I doubt they did, if they did anything it was to allow for 64-bit and 32-bit programs to be installed side-by-side. Chances are your extensions are 32-bit dlls and there's no way for a 64-bit process (in this case explorer) to load 32-bit dlls.

Don't the shell extensions all spawn processes? So even if it is a DLL it would be by spawning by a RUNDLL32 process?

I checked and the command prompt here shell extension just spawns the command cmd.exe /k "cd %L" (The %L is the path to the selected folder).
I'm fairly certain the WinRAR and 7-zip shell extensions all launch the winrar or 7zip executables with predefined sets of parameters. The menus for 7zip, WinRAR, and UltraEdit are through ContextMenuHandlers (it has a GUID for a COM object) - why can't it just load the object out of process with COM+?

 

[Nothinman]

Don't the shell extensions all spawn processes?

No, if they did they would make explorer even slower.

I checked and the command prompt here shell extension just spawns the command cmd.exe /k "cd %L" (The %L is the path to the selected folder).

You're missing the point, to enable the menu to show up most extensions are dlls themselves regardless of what they do. The above one is probably an exception because it's just a registry entry with a command in it.

The menus for 7zip, WinRAR, and UltraEdit are through ContextMenuHandlers (it has a GUID for a COM object) - why can't it just load the object out of process with COM+?

I have no idea how each of those integrate with explorer or how COM+ works locally, chances are there are some vague problems with 32-bit -> 64-bit interaction that havn't been resolved yet.

 

[VirtualLarry]

I hate how Explorer.exe shell extensions are run in the same process, if one crashes, the whole shebang goes down with it. It would be much better, security-wise, for them to run as their own seperate process, and be remoted via COM+ as an out-of-process thing. Additionally, it would seem to me, offhand, that something like that would also offer much easier compatibility between 32-bit and 64-bit stuff, all you would need is the proper remoting stub functions and marshalling stuff. I'm no COM guru though.