Re: w32 does not have emacsclient/server - getting paper size

[Lennart Borgman]

Jason Rumney wrote:

> Lennart Borgman <address@hidden> 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.