I recently switched from 32bit Vista to the 64bit version (change from 32 to 64bit may be irrelevant), and since then DOpus hasn't properly replaced explorer. Choosing to open the containing folder of a download in Firefox, a download in µtorrent, or a song in foobar always opens explorer instead of DOpus. DOpus is set to replace explorer for all folders. Any idea what the problem could be and how I can fix it?
If you installed 64-bit Vista over the top of 32-bit Vista then you'll need to uninstall your old 32-bit copy of Opus, download the 64-bit version of Opus and install that.
Remember to backup your configuration first as uninstalling Opus wipes the config. Settings -> Backup & Restore.
I didn't have 32 bit Opus previously installed. I reinstalled my whole operating system (I was previously on 32bit Vista), seeing as I switched to 64bit Vista I downloaded 64bit Opus too. There was no existing copy of Opus installed when the current 64 bit copy of Opus was installed. I did import my config from the 32bit version.
Try setting Opus not to replace Explorer, closing the Preferences window, then going back in and setting it to replace Explorer again. That should make it re-write the registry settings that control Explorer Replacement.
If that doesn't fix it, does double-clicking a folder on the Desktop open Opus? Does anything?
That didn't fix it. Double clicking on the desktop opens Opus, as does Win+E.
Do you mean double-clicking an empty space on the Desktop opens Opus, or double-clicking a folder on the Desktop? (Or both?)
I meant double click an empty space, but double clicking on the Recycle Bin, My Computer etc. (either via Start Menu or Desktop) does also open in Opus.
It turns out that if you're using 64-bit Windows and a 32-bit program runs explorer.exe directly then it won't be diverted to Opus.
(Programs which launch folders in the "proper" way -- i.e. ShellExecute on the folder itself with NULL verb -- will trigger Opus whether 32-bit or 64-bit. The problem is only with 32-bit programs which run explorer.exe.)
GPSoftware are aware of the problem. Thanks for raising it as nobody had mentioned it until now.
Since it fits the subject and I have not seen it discussed yet, let me mention a related problem. I use DO 9.1.0.6 (English GUI) under Vista Ultimate 32b (German surface).
When I choose the preference option that DO shall replace Explorer for all purposes, then I cannot access the Windows System Control via the Start Menu any longer but get a Windows error message saying that a (related) registry key is not found.
I think that that must be a bug of DO - or am I overlooking something and can fix it myself? Since it appears to be a pretty serious bug, I have disabled that preference option again for the time being.
The System Control panel seems to open fine for me no matter what I set Explorer Replacement to with the English Vista Ultimate 32-bit.
Anyone else see a problem?
Your hint that the issue does not always occur has motivated me to investigate and now I can report more details:
-
Not replacing Explorer is the only option without the side effect.
-
The side effect of a not opening System Control panel is not a DO bug on the program code level but a conflict of different security philosophies: DO wants to send a message to \Windows\System32\control.exe while I as a user of my PC want to prohibit DO sending messages to any other applications or system applications.
-
In my personal firewall, control.exe may send messages to DO.
-
In my personal firewall, DO may not send messages to control.exe (because I have prohibited DO to send messages to any application).
-
If, for testing purposes, in my personal firewall I allow DO to send a message to control.exe once, then the side effect does not occur: I can access the System Control panel. This is so regardless of which of the three Explorer replacement options I choose in the DO preference options.
-
So far my personal firewall has reported these other events: Indirect Network Access / write memory / from DO to svchost.exe. Indirect Network Access / inter-process call / from DO to (I do not know yet which system application, need to log and test that). Note: What my firewall calls "network access" may be either still local or a connection to the internet. Which it is one has to find out by further study.
Conclusion: Some of DO's actions, if they shall be allowed, require communication with system services. A user needs to judge for himself whether that poses a too great risk of possibly unwanted internet communication. I do not say that DO does connect with the internet (autoupdate being disabled, FTP not used, etc.) but its communication with system services makes it somewhat tricky to verify this, if considered necessary. Using defensive firewall settings might mean that DO then cannot be used while being online and that some DO features cannot be used at all.
Firewalls (configured) like that cause more problems than they prevent IMO.
So, to paraphrase, you've configured your firewall to prevent certain actions and now you're complaining because certain actions are prevented...
Brilliant.
What's the point of stopping a process from sending messages to control.exe anyway, if you're running Vista?
UAC already stops non-admin processes from lauching or sending window messages to admin processes (without a UAC prompt appearing). If it's a non-admin copy of control.exe then there isn't really anything it can do which dopus.exe or any other non-admin process can't do without control.exe. If you grant Opus admin access (e.g. by confirming a UAC prompt) then there's then nothing an admin control.exe can do which dopus.exe can't do if it wanted to.
Seems like pointless paranoia to me, to be honest.
I think it's poor the way firewalls let people configure things like this and then don't say anything when they block actions, too. It makes it look like programs are malfunctioning when they're not. If I was paranoid and wanted to block programs from doing things I'd want to know when they attempted to do them. If it's worth worrying about then it's surely worth knowing about if anything ever tries it. Who knows what else the now untrusted program might be doing? (Or, more likely, it will alert the user to why something they want to work isn't working and allow them to adjust their configuration or at least understand the cause of the problem without digging around.)
I understand your opinion; it requires quite some firewall configuration and logging to get the fitting ruleset. However, once one has that ruleset (for a firewall with a very good rules editor!), it convincingly tells the PC user exactly how and with which applications every program communicates. This is a very efficient means to separate useful programs from malware.
Setting file managers in a personal firewall can be extra difficult though because many file managers love calling libraries that invoke svchost calls or other communication with system services. Contrarily a typical application (text or graphics editor or media software) wants only "global hooks" (i.e., communication via clipboard or program start by clicking a link) and even special applications like process explorer want only the obvious: inter-process call.
I prefer security to convenience; so I do not simply trust a file manager because it is some. Rather I think that also file managers should respect the PC users' demand for security. Otherwise all one's security mechanisms become doubtful when one allows exceptions in form of, e.g., file managers. Regardless of how good a particular software is, one should never trust it 100%, even if just because malware might abuse it:
Malware -> trusted file manager -> svchost -> internet.
But if I block the communication to svchost, then this graph ends prematurely:
Malware -> trusted file manager ||
steve wrote:
So, to paraphrase, you've configured your firewall to prevent certain actions and now you're complaining because certain actions are prevented...
<<
No. Rather before I had no idea what control.exe was supposed to be doing. Now that I have found out I could locate the source of the problem.
leo wrote:
What's the point of stopping a process from sending messages to control.exe anyway, if you're running Vista?
<<
To let the firewall do its inter-program watching job at all, the execution complexity must be restricted. In practice this can be achieved by permitting Windows system services to do all while restricting only one's user applications. So the communication from my user applications to the Windows system services becomes essential with respect to prohibiting such as far as possible. Currently I allow only about half a dozen of white list exceptions to this concept: for additional system services not provided by Windows and for a process explorer. In other words, there is no ordinary application on the white list at all. (Except that I allow some the "global hooks".)
UAC already stops non-admin processes from lauching or sending window messages to admin processes [...] If it's a non-admin copy of control.exe then there isn't really anything it can do which dopus.exe or any other non-admin process can't do without control.exe.
<<
So I had believed some time, too. Until I observed a behaviour like this: InternetExplorer is prohibited direct access to the internet. So what does it do? It tries every running non-admin process for indirect access to the internet via the route of another application. E.g., my, call it, browser.exe would be in memory, capable of sending data to the internet, and be running with the sufficient rights of my currently active Windows standard user account.
If I prohibit Opus -> browser.exe but allow OPus -> control.exe and control.exe -> browser.exe, then this suffices to create an indirect access to the internet (in principle).
Seems like pointless paranoia to me, to be honest. <<
Maybe it is pointless for Opus, maybe for 98 other applications. But the 100th will be malware.
I think it's poor the way firewalls let people configure things like this and then don't say anything when they block actions, too.
<<
There I agree; firewall vendors should inform their customers much better.
[quote="leo"]It turns out that if you're using 64-bit Windows and a 32-bit program runs explorer.exe directly then it won't be diverted to Opus.
(Programs which launch folders in the "proper" way -- i.e. ShellExecute on the folder itself with NULL verb -- will trigger Opus whether 32-bit or 64-bit. The problem is only with 32-bit programs which run explorer.exe.)
GPSoftware are aware of the problem. Thanks for raising it as nobody had mentioned it until now.[/quote]
It there any intension to fix it any time soon? Could a helper program in the background handle this? Virtually all the (non-OS/third part) applications I use are 32 bit, my IM client, music player, internet browser, etc.
Maybe I should install the 32 bit version of Opus (after uninstalling 64 bit version), would that cause any other problems?
GPSoftware said they are going to look into it and want to fix it (assuming it can be fixed, of course; it isn't well understood yet). I don't know how long that will take. Contact them directly if you want more information.
The problem won't affect all 32-bit programs, only those which run explorer.exe directly. For any which have the problem you could try asking their authors to open folders via ShellExecute (with a NULL verb) instead which would fix it.
Since they are explicitly running explorer.exe, rather than asking the OS to open the folders with the registered application, it's a bit like a program opening an image using a hardcoded program instead of your prefered image viewer. Unfortunately a lot of programs do this, though, so Opus tries to intercept the explorer.exe launch, but 64-bit Opus doesn't currently intercept it when launched by 32-bit apps.
You can't install 32-bit Opus on 64-bit Windows. (It'd cause bigger problems if you did.)
Opport, please use the built in quote mechanism - it will make your replies much easier to read.