这里是我问的两个registry项。**
HKEY_LOCAL_MACHINE\Software\R-core\R\Current Version HKEY_LOCAL_MACHINE\Software\R-core\R\version\InstallPath 当从命令行（或者从emacs或者statconnDCOM ）启动R时，它使用Windows的Path环境variables中首先出现的任何版本。 相比之下，双击*.Rdata文件使用HKEY_CLASSES_ROOT相关文件关联项所指向的版本。
但是什么时候使用了两个HKEY_LOCAL_MACHINE条目？
编辑： Brian Diggs指向使用（和修改）这些registry项的一捆Windows *.bat文件，但我仍然感兴趣是否更接近'核心'R使用这些。 （我希望答案是“不”）。
**如R for Windows FAQ中所述 ，这些条目可以在安装过程中（通过单击“保存registry中的版本号”）或稍后从命令行（通过在$RHOME\bin键入$RHOME\bin ）来设置。
一组使用这些程序的程序是R批处理文件
这些程序通过（1）检查环境变量（R_HOME，R_MIKTEX，R_TOOLS）或者（2）设置R的版本（以及R Tools和miktex的版本），如果没有设置它们则在注册表中查找。
主要编辑：
看起来这些注册表项主要是供外部应用程序使用的。
这就是我为什么这么想的原因。
grep在R源中的HKEY_LOCAL_MACHINE在三个文件中出现了四个命中。 文件 – "extra.c" ， "extra.c"和"rhome.c" – 都位于R-2.15.0/src/gnuwin/或其子目录中。
相关情况似乎是在R-2.15.0/src/gnuwin/rhome.c ，C函数get_R_HOME使用它。 该功能被设计为
/ *从环境或注册表中获取R_HOME：用于嵌入式应用程序* /
并且它只在R_HOME是否在“C环境空间”或“Windows API环境空间”中找到时在注册表中进行搜索。
get_R_HOME反过来只出现在另外两个文件"R-2.15.0/src/gnuwin/embeddedR.c"和"R-2.15.0/src/gnuwin/front-ends/rtest.c" 。 （根据其常驻readme文件， "R-2.15.0/src/gnuwin/front-ends/"是使“将R DLL链接到其他应用程序”成为可能）
R的* NIX起源和强调可移植性使得任何接近R的核心功能的东西似乎不太可能取决于注册表项。 （这个项目显然更具投机性。）
除非我另有说明，否则这足以说服我注册表项目的唯一目的是为外部应用程序提供指针，特别是那些使用嵌入式R实例的指针。