杂谈系统与VC中的环境变量
在我们在VC里调用外部库写代码时，都会或多或少经历过关于路径设置这个头疼的话题。的确，我曾经几次捉摸，直到现在，才有了一些心得，希望和大家分享。本文有些地方难免有误，还需高手们指正。
首先介绍一下Windows中的几类路径变量:
1. Windows系统的环境变量：顾名思义，就是系统级别的变量，或者从我们编程的角度来讲，作用域就相当于全局变量。
2. Windows用户的环境变量：既然有全局的，那肯定就有局部的了，所以这个变量可以当作是局部变量，当然编写程序的时候局部变量的作用域内是可以覆盖掉同名的全局变量的，这个原理同样是适用于这里的环境变量。当然我说的只是在作用域内，默认是用的局部变量（window用户变量），作用域外就成了全局变量的天下了，而且全局变量即使是在局部变量的作用域内，也可以用的，在编程中，可以用作用域符号区分，所以这要看程序要用什么变量了。
3. 应用程序自己设置的环境变量：这又更进一步，当然自己设置的，一般先用自己的了。
好像越说越糊涂啊，呵呵，也许有些人还没有理解什么是环境变量呢。给你个最恰当的例子，在Windows XP的“我的电脑”上右击鼠标，选择属性。转到高级选项卡，点击环境变量四个字，然后你就找到什么是系统变量什么又是用户变量了。用户变量就是针对每个用户而言的，如果你的登陆名是administrator，那么这个里面的变量就是针对你的，你发现你的这两个变量里面都有很多内容，这些变量实际的作用都是提供给系统和系统以外的程序使用的。
你在开始->运行里面敲入“cmd”，这个就是Windows底下虚拟DOS，你敲入path，发现显示出来什么了？一堆路径，恩!对了，就是一堆路径，这堆路径就是cmd使用的路径，用它来干什么呢？当然是用来找东西了，找可执行文件。比如你写入一个notepad，你会发现记事本弹出来了。为什么它能找到记事本呢？记事本一般在系统盘的Windowssystem32底下有，你应该注意到path路径里面有一个诸如:”c:windowssystem32”这样的路径，对了，环境变量就是提供给程序来使用的，“cmd”程序就是用这个path环境变量来搜索notepad这个文件的，当你写入notepad，Enter之后，他就开始按照顺序查找了，先是当前目录寻找，然后是从path变量中提取出第一个分号前面的内容，然后查找，如果找到结束，如果没有找到继续找。这个只是系统中的一个path变量，并不是说系统的变量都是path，要分清楚概念,他们是包含关系。最后，你还会发现cmd path的路径会有系统和用户的变量。这也就是说它俩个都用了。（不稀奇，应用程序想用什么就用什么）。
Ok，上面说的那么一堆，都是告诉你环境变量的作用是什么。很明显，他们是为程序和系统服务的.
(博主注:到目前位置为止,在我所查找的资料中,还没有一篇文章举例说明自定义的环境变量的用处,都在拿系统定义的path变量来举例;我认为自定义的环境变量,是某个程序要求其最终用户指定某些路径,然后该程序在运行期间,会通过WIN32 API获得这些参数,用于一些其它的操作;我起初认为自定义的环境变量可以在某些程序中做一些路径简化工作,比如我定义了OPenCVDir环境变量,然后在VC的附加目录下包含%OpenCVDir%OpenCV就可以指定要包含头文件的路径,但经试验,是不可以的(Windows的资源管理器可以解释该路径)).
VC所谓的环境变量，它也用到了系统提供的环境变量。先说说VC比较底层的工作原理。VC++ 6之类的软件，都是IDE环境。也就是说它只是个GUI环境，为了方便用户编程使用的，而说道它是怎么来编译程序的，它用的是另外一套比较底层的---基于命令环境的程序。在vc的安装目录里面，一般是都会有一个bin文件夹，里面就有很多可执行程序，其中的cl.exe rc.exe和link.exe三个程序分别是VC代码编译器 资源编译器和链接器。说到底，就是当我们写好程序之后，我们先用cl.exe 来编译源代码为中间文件（.obj) rc.exe来编译资源描述文件为资源文件(.rc),然后link.exe 来链接程序。而平常我们会配置VC工程的一些参数，比如在project菜单里面，有个Setting，我们会配置的一般是link选项卡，这些配置，实际上就是在cl.exe 或者 link.exe 后面加上一些参数而已。例如 /D "strings"这种引号里面字符串，一般都是提供给程序cl.exe 程序的“宏变量”，也就是预编译变量。当你编译完之后，你可以在你的代码工程里面找到一个vc生成的.html网页文件，双击打开，你就会看到vc是如何调用外部底层编译器，编译及其链接文件的。
好了言归正传，对VC环境配置的情况，一般是我们要用其它库的时候，才会做，或者当我们编写Dll，lib的时候才会涉及到的。一般情况下我们不需要做什么，毕竟微软做的“傻瓜”化系统，的确够傻的。VC里面有个配置路径的地方，就是：Tools --> Options... --> Directories 。这个地方就是VC配置环境路径的地方，有几个路径，一个是include路径，一个library路径，和 source路径，常用的就是前俩个，因为至今为止，我都没有用过source路径（source路径据我推测是当我们跟踪调试的时候用的）Include路径，顾名思义，就是include包含文件的路径，library路径呢？当然就是找那些真正函数源代码的地方。下面就找个例子来说说。
首先，你要新建个console模式的hello world吧。
#include <stdio.h>
int main(int argc, char *argv[])
{
printf("Hello World! ");
return 0;
}
这个程序我们学过C语言的都知道是什么，我们要说的是看那个 stdio.h那个文件，它使用"<>"来引起来的，上过课程的人都应该知道"<>" ,和双引号的区别，前面的是直接在系统提供的目的底下寻找stdio.h，而后者还会从当前源程序所在的当前路径进行查找。这是老师们说的，我们也记住了，但至于到底stdio.h在哪里，系统目录到底是什么？我们不知道有几个会想过，当然那些喜欢钻研的人肯定是想过了，但我想70%的人还是没有想过的。呵呵。好先解决第一个问题，所谓的上面说的系统目录是哪里？是我们上面说的系统变量提供的path目录么？这个问题我之前也不清楚，但是经过我的试验，发现这里的所谓的include的系统目录，只是VC配置路径include我提供的目录，也就是上面我提到的Tools --> Options... --> Directories里面的include路径。简而言之，就是当我们用了一个<>来include一个文件的时候，VC编译器就是利用它自己的配置路径查找，进行“一级查找”，注意这里已经上面提到的，它的查找只是一级的，什么意思呢？就是不会查找子文件夹，只会查找一层。那我们就该断定vc里面设置的include路径，其中一个肯定有stdio.h这个文件，到底有没有呢？你要自己去找了。我的路径“D:Program FilesMicrosoft Visual StudioVC98INCLUDE”，这个底下，你会发现一个stdio.h的文件，到底是不是它呢？我们就可以来做试验了，方法很简单，删了它？No！你删了它你再怎么找回来？当然是是rename就可以了嘛，呵呵，我的做法就是rename stdio.h as stdios.h,这样你再次回到刚才的程序，先build -> clean，然后在编译，发现了吗？系统提示说找不到stdio.h这个文件了。上面的过程只是我用试验的方法得出的，至于它有没有找Windows提供的系统变量的path路径?你可以做个试验嘛!怎么做？自己想！然后先不要改回来，把那个文件复制到自己程序的目录里面，更改 #include <stdio.h> 为 #include "stdio.h", 然后将复制过了的文件也改为stdio.h文件，再次编译看看，呵呵，是不是可以用啦？恩，说明老师们说的的确是对的，双引号会找当前目录的文件，但我们应该进一步的想一下，他是否会找window系统提供的环境变量的path路径呢？通过试验，我给你一个结论，不管是尖括号还是双引号，都不会去找的。
博主注:到目前为止,在我查找的所有资料中,还没有一篇文章举例说明自定义环境变量的用处,都在拿系统预定义的path变量来举例;我认为自定义的环境变量,是某个程序要求其最终用户指定某些路径,然后该程序在运行期间,会通过WIN32 API(如GetEnvironmentStrings配合GetEnvironmentVariable使用)获得这些参数后,用于一些其它的操作;我起初认为自定义的环境变量可以在某些程序中做一些路径简化工作,比如我定义了OPenCVDir环境变量后,在VC的附加目录下包含%OpenCVDir%OpenCV就可以指定程序要包含的头文件的路径,但经试验,是不可以的(Windows的资源管理器可以解释该路径).
补充：软件开发 , Vc ,
