Hi,
I recently had some difficulty getting an embedded R session running
on Windows, due to the way that R Sys.getenv works, which I would
consider a bug. Even if you do not agree, then you may still want to
document it for future users who might be bitten.
As outlined in R-exts (?8.2.2):
http://cran.r-project.org/doc/manuals/r-release/R-exts.html#Calling-R_002edll-directly
R_HOME/bin needs to be in the PATH environmental variable (by the way,
I actually found that I needed R_HOME/binR_ARCH instead: you may want
to update this).
There are 2 ways to get & set environmental variables in Windows (I
just discuss the UTF16 "widechar" methods):
1) the Win32 interface, using GetEnvironmentVariableW, SetEnvironmentVariableW
https://msdn.microsoft.com/en-us/library/windows/desktop/ms683188%28v=vs.85%29.aspx
2) the POSIX-style interface, using _wgetenv, _wputenv
https://msdn.microsoft.com/en-us/library/tehxacec.aspx
The problem arises due to the fact that these don't quite do the same
thing: the POSIX-style interface, used by R, operates at the runtime
level (msvcrt), which makes its own copy of the environmental
variables.
Now, this is not a problem when R is running by itself, as it uses the
interface in a consistent manner. The problem arises when you try to
run R embedded within another program: as the copy is made at the
start of the process (i.e. the calling program), any subsequent
changes (such as setting the PATH variable as required) won't be
reflected in the msvcrt copy (used by R). Further complications could
arise if there are multiple msvcrt libraries loaded (not an uncommon
situation, unfortunately).
This is all a long-winded way of saying: for ease of embedding R, it
would probably be better to use the Win32 interface, instead of the
current POSIX-style interface on Windows.
Best,
Simon
