Jason Rumney wrote:
Lennart Borgman <[EMAIL PROTECTED]> writes:
HKLM\Software\Microsoft\Windows\CurrentVersion\App Paths\.
I see. The path is not as unpredictable as I thought. However, gs.exe
or gswin32.exe is not listed in my registry, even though I have it
installed, so this is not useful for finding ghostscript.
Yes, at the moment not, but I think this is something the authors of
this packages should be noted of.
Also, these keys are documented as being extra paths for that
application to find its DLLs. Since the directory where the executable
resides is automatically searched, it is not necessary to include that
path in this key, so it is not a reliable way to find the executable.
I do not think it is only for DLLs. I can not say that MS is very clear
in their documentation, some info is hard to find. But look here, this
page says that ShellExecute looks in App Paths:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellcc/platform/shell/programmersguide/shell_basics/shell_basics_extending/fileassociations/fa_perceived_types.asp
If you have firefox installed (and you do not have it in your path) you
can try this:
Open "Start Menu - Run" and enter firefox.exe.
It will start Firefox. However just typing "firefox.exe" in a cmd.exe
window does not work. This could be by intent (backward compatibility,
trying to behave as other shells) or just a bug.
In any case I believe that looking in App Paths for an entry could be
useful -- and this behaviour would be in accordance with what
ShellExecute does. Unfortunately it is for many applications more
difficult to find the path. This is actually one of the reasons I think
there should be a way to read the Registry from elisp.
_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
