Hi,

When will ue32ctmn.dll (explorer integration) be made compatible with Win XP x64?
I've seen that winrar does support this now, so I thought I'd ask here .

bye,
H

While you are waiting for that dll you could just do a basic integration with regedit. Really simple (took me 10min googling to figure out how to do it):

Create a "dummy.reg" file with this text: Then merge it into your registry by double clicking.

Is it possible to add something to the registry just like this guy describes it for the old WinRAR?

x64 WinRAR Shell Integration Registry Hack update

I'm amazed that 6 months later this still is an issue...

I've found a solution that doesn't require using the 32-bit Explorer shell.

Simply add the following into your Windows registry:

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\*\shell\UltraEdit_64-bit_Shell_Ext]
@="UltraEdit"

[HKEY_CLASSES_ROOT\*\shell\UltraEdit_64-bit_Shell_Ext\command]
@="\"c:\\Program Files (x86)\\IDM Computer Solutions\\UltraEdit-32\\uedit32.exe\" \"%1\""


Modify the path as appropriate to your installation. This should work on 32-bit & 64-bit Windows.

I am having similar trouble with the context menu, UE 17

After turning the option on and off a few times, I finally got it OK in Windows Explorer.

However, I mostly use XYplorer as my file manager, and in that environment, I do not get the Ultraedit context menu.

According to the XYplorer forums, its because UltraEdit only registers a 64 Shell.

See http://www.xyplorer.com/xyfc/viewtopic. ... 54&p=63094

I can see in my registry that other programs such as WinRar have registered a context menu for both 64 and 32 bits, so it looks like that needs to be done for Ultraedit. I managed to get the 32 bit version out of the install package, but can't get it to install..

Has anyone done this before?

SS

UltraEdit v17.10 registers the 32-bit shell extension DLL ue32ctmn.dll on a Windows XP SP3 x86 (32-bit) like posted in right click to "open in UltraEdit" with 2 differences:

Instead of HKEY_LOCAL_MACHINE now HKEY_CURRENT_USER is always used to make it possible to add/remove the shell extension registration from within UltraEdit at Advanced - Configuration - File Associations also by a user without administrator privileges.

And the default path to ue32ctmn.dll is now different.


I don't have any 64-bit computer, but from what I have read on other pages, copying following into an ASCII file, adapting the path to ue32ctmn.dll according to your installation, saving it as UE32ShellExt.reg and double clicking on this file to import it to your registry should be enough to register the 32-bit shell extension too.

HKEY_CURRENT_USER\Software\Classes\Wow6432Node\*\shellex\ContextMenuHandlers\UltraEdit]
@="{b5eedee0-c06e-11cf-8c56-444553540000}"

HKEY_CURRENT_USER\Software\Classes\Wow6432Node\CLSID\{b5eedee0-c06e-11cf-8c56-444553540000}]

HKEY_CURRENT_USER\Software\Classes\Wow6432Node\CLSID\{b5eedee0-c06e-11cf-8c56-444553540000}\InProcServer32]
@="C:\\Program Files (x86)\\IDM Computer Solutions\\UltraEdit\\ue32ctmn.dll"
"ThreadingModel"="Apartment"

But before you import this to your registry, please check with Regedit.exe if the key

HKEY_CURRENT_USER\Software\Classes\Wow6432Node\CLSID

really exists in your registry. I have taken this path from another forum page and I don't know if this is correct and can't verify it. And please verify also before import if the 64-bit shell extension of UltraEdit is not registered with exactly the same keys.

Good info, but still no success.

I looked at a 32 bit machine, and both the 32 & 64 bit dll's used the same CLSID {b5eedee0-c06e-11cf-8c56-444553540000}.

So I changed the 32 bit CLSID to {b5eedee0-c36e-11cf-8c56-444553540000}, which was unique and the 3 made it to distinguishable.

Using WinRar entries as a guide, I tried both setting entries for the CURRENT USER and for the MACHINE
Nothing helped. I did find that adding a new entry for UltraEdit32 was necessary because otherwise I lost the
context menu in Windows Explorer, but none of this got the context menu into Xyplorer.

Changing the class identification string was surely no good idea. The shell (Explorer) calls on loading of the shell extension the DllGetClassObject Entry Point of the extension. If the class identification is wrong, the shell extension is not loaded as I could verify on my WinXP x86.

Try registering the 32-bit version under Wow6432Node with correct CLSID string. Windows manages itself which shell extension is loaded for which application.

I looked again at winrar and dvdfab, two context menus on my computer that have both a 32 and 64 bit dll in the context menu registry entry [HKEY_LOCAL_MACHINE\SOFTWARE\Classes\*\shellex\ContextMenuHandlers]

They use different clsids for the 32 and 64 dlls, which seems to make sense since both dll's are in the system, and they are indeed different.

Did exactly the same thing as far as I could see for UE, but didn't get the context menu into XYplorer. And it seemed that if I changed anything regarding the default 64 bit UE dll, then I would loose the context menu from Windows Explorer. Although turning the option off in UE, exiting the program, and then turning it back on seems to bring it back reliably.

UE seems unique in that it sets the context menu in the USER part of the registry in addition to the MACHINE side, have no idea why, but it is the only entry in the USER one, and there are 15 or more in the MACHINE side.

I think someone smarter than me will have to figure this out.

With UltraEdit v18.00 and later there should be no problem anymore on using the shell extension of UltraEdit on a computer running Windows x64 because both shell extensions are installed and registered now. Shell extension DLL ue64ctmn.dll is installed and registered for 64-bit Windows Explorer and other 64-bit applications, ue32ctmn.dll is installed and registered for 32-bit Windows Explorer and other 32-bit applications.

On a Windows x86 computer still only ue32ctmn.dll is installed and registered.

The registration of the shell extension DLL(s) can be changed at any time in UltraEdit at Advanced - Configuration - File Associations.

Hello,

With UltraEdit 18 it automatically integrates shell extension by adding registry key to "HKCU\SOFTWARE\Classes\*\shellex\ContextMenuHandlers\UltraEdit" upon first run of "UltraEdit" application.

Now what happens when you uninstall UltraEdit under System Account ( assume you are using SCCM in your enterprise ).
UltraEdit Shell Extension is LEFT in System for each User who had ever launched "UltraEdit". So that nice icon is left in system as Trash and when you click on it you receive error message that "uedit32.exe" file not found.

This is completely unacceptable and makes UltraEdit software non-compliant for Enterprise deployment.

First, your post reads like you want to tell your opinion IDM, but this is a user-to-user forum as stated at top of every forum page.

Second, before Windows Vista and Windows 7 with UAC the shell extension was always registered during installation as system key (except when a custom installation was executed with the option for Explorer integration unchecked). During uninstall the installer removed this registration of the shell extension too. As most users like the shell extension and Windows Vista and Windows 7 block by default any write access to HKLM, the shell extension is registered now by UltraEdit itself in HKCU. This gives any UltraEdit user at any time the possibility to register or unregister the shell extension by simply opening Advanced - Configuration - File Associations and checking or unchecking the option for Explorer integration.

In other words the shell integration option was changed from a system option to a user option. User options are never removed during an uninstall of an application. That is what Microsoft strongly recommends for all Windows applications as the user may reinstall same, a newer or an older version of the application again. Users usually don't like it in these scenarios that all their configurations are not existing anymore after temporary uninstall. Of course this behavior leads to the problem that when an application is really permanently uninstalled, the user has to manually remove all registry settings and files containing user customization and user configuration data for this application.

Third, I know that IDM has built-in in UltraEdit not public published options for system administrators to lock features. Perhaps there is an option which prevents UltraEdit users respectively UltraEdit running with standard user account privileges to register the shell extension for integration into Explorer. You have to contact IDM support by email and ask if such an option exists.

Mofi wrote: In other words the shell integration option was changed from a system option to a user option. User options are never removed during an uninstall of an application. That is what Microsoft strongly recommends for all Windows applications as the user may reinstall same, a newer or an older version of the application again. Users usually don't like it in these scenarios that all their configurations are not existing anymore after temporary uninstall. Of course this behavior leads to the problem that when an application is really permanently uninstalled, the user has to manually remove all registry settings and files containing user customization and user configuration data for this application.

I completely NOT agree.
Why could not they make shell extension properly then ? It must not left in system after uninstall, this is - Trash, that still shows on right-click menu after uninstall.

I can name several examples of popular software which has "user-type" shell extension, but after uninstall it doesn't show, even if registries are left in HKCU.
Check out: WinZip, Git 1.8 !!

User's shell extension there are made PROPERLY as COM DLL file and after uninstall no trash entries in right-click menu.

Sorry, but this excuse: "Of course this behavior leads to the problem that when an application is really permanently uninstalled, the user has to manually remove all registry settings and files containing user customization and user configuration data for this application."
- is a complete BS!

Well, I wrote my opinion, the opinion of an advanced UltraEdit user. I'm not an employee of IDM and so my opinion is not the one of IDM. Therefore discuss the behavior with IDM support by email.

It is of course possible to do the unregister of the shell extension DLL(s) with the uninstaller for the current user account. That would make the uninstall a little bit cleaner for computers with a single user account. For computers used by multiple users, there is most likely no chance that an uninstaller unregisters the shell extension for all user accounts.

The same problem exists with file extension assignment made by the user of UltraEdit with UltraEdit or even more worse with Windows Explorer. They are not restored / removed on uninstall. Restoring / removing the file extension assignments would have been possible in the past as the assignment were made in HKLM tree. Nowadays with making the assignments in HKCU to make it possible that every user even without administrator privileges can make the assignments wanted, it is not really possible anymore to restore/remove those file extension assignments during uninstall of UltraEdit.