Non-English is included here.  The main reason for the environment variables
is to allow non-English.  The names of the three environment variables
listed here

"ProgramFiles(x86)" ;; always 32 on 64 bit OS, nil on 32 bit OS
"ProgramW6432"      ;; always 64 on 64 bit OS, nil on 32 bit OS
"ProgramFiles"      ;; always 32 on 32 bit OS, depends on 32 or 64 process
on 64 bit OS
are always these pseudo-English character strings.  The values of the
variables, that is the
directory names on the computer, are language-specific.
I gave the English values in my previous email.

On Thu, Feb 3, 2011 at 3:45 PM, Rodney Sparapani <rsparapa@mcw.edu> wrote:

> On 02/ 3/11 01:44 PM, RICHARD M. HEIBERGER wrote:
>
>> Not quite.
>>
>> "c:/Program Files" is visible to the 32-bit applications.
>> The issue is environment variables.
>>
>> The difference is that, for 32 bit applications
>> getenv("ProgamFiles")
>> is evaluated to "c:/Program Files (x86)",
>> and for 64-bit applications
>> getenv("ProgamFiles")
>> is evaluated to "c:/Program Files".
>>
>>
>> See the comments in ess-site.el lines 531-557 for the glorious details.
>> This all works correctly in 32bit emacs running on the 64-bit machine.
>> Opening 64-bit R inside an *R* window in the 32-bit emacs works correctly.
>>
>>
>>
>> The comment about putting a .lnk file is completely consistent with Paul's
>> suggestion.
>> The .lnk (shortcut) file is a native Windows way of doing something
>> similar
>> to a soft link in
>> Unix terminology.
>>
>>
> Ok, but what about non-English locales?  I think that's why we need
> the ProgramFiles environment variable, correct?  I'm not trying to be
> a pest, I'm just trying to figure this out.
>
>
> Rodney
>
> ______________________________________________
> ESS-help@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/ess-help
>

	[[alternative HTML version deleted]]

