On Fri, Nov 20, 2009 at 10:19 PM, Drew Adams <drew.ad...@oracle.com> wrote: >> Drew, it is just you and me that has reported trouble. Do you have any >> of those or some other program that integrates itself with Windows >> Explorer, or should I say "Shell"? > > Sorry, I don't know what you mean. AFAIK, I have nothing integrated with > Windows > Explorer or "Shell". I do not use Bzr, WinMerge, Tortoise, or Firefox. > > I do have Cywin installed - dunno if that is relevant.
Thanks, no Cygwin is probably not integrated in Windows Explorer / Shell. Windows is, as you know built around interfaces. The windows Shell (or what they call it) is such an interface. This is what `w32-shell-execute' uses by calling ShellExecute. ShellExecute looks into the Registry to find out how to handle a file. There are simple ready-to-use interfaces, like those used by ftype and assoc in cmd.exe, and there are others that ShellExecute will ask for what to do. The answer can be anything. This is for example the way w32 can interact with a vcs system. The vcs system can install itself as an interface for file operations in the registry and do whatever is needed when a user stores or gets a file. And a lot of things can of course go wrong. In this case it looks to me like there is an unsolved conflict between "open" and "file:///" which leads to that nothing is done. But it does not have to be that way. It could be that an operation is decided on, it is tried and an error happens. Those should normally be visible in the Event Viewer if nowhere else. However the fame for writing that part of the code is less than the perhaps a bit easer part of the code that does the usual job.
