动态连接库与UG二次开发.doc

动态连接库与UG二次开发 2009-06-03 02:16:29 来源: 作者: 【大 中 小】 浏览:10次 评论:0条 一开始，接课题啥都不懂，跑到这里问了一些问题，许多网友很热心，名字记不住，但心里挺感激他们。现在混到这份上了，从一穷二白，到多少懂了些东西，所以想搞一点东西出来回报社会。呵呵。 UG自身的功能，我不熟悉，但首先要肯定，它们不难。就是个门槛的问题。UG二次开发的门槛算是比较高的。WIN32 API，MFC，DLL，C/C+，要想做高层次的开发，这些多少得懂一些。否则，就老老实实的呆在UG的环境里做个良民。而第一道门槛，就是动态连接库的问题。开发出来的东西，就是以DLL装到UG中的，理解DLL，很有必要。如果觉得没必要，看到这儿，兄弟您就可以打住了。 1。静态连接库 想先做个比喻来说这个事。 食堂里给1000个人做好了相同的午餐之后，是把它们逐份送到这1000个人手中，还是召集这些人到食堂里吃？ 倘若采用第一种方式，那么需要考虑的问题有两个： （1） 效率问题：送饭的人得够数，倘若派俩小伙去送，送到黄昏也不见得就送完。 （2） 意外问题：假如饭都送出去了，突然发现厨师误在饭菜中放了些亚硝酸盐。及时通知吃饭的兄弟也不是件易事，总会有许多人死翘翘。 倘若采用第二种方式，那么上面这两个问题都可以很容易的得到解决。只不过想吃午饭的个别懒人得动弹动弹走走路了。 言归正传： 一开始没有动态连接库，只有静态连接库（再往前了说，也没有静态连接库）。不知道各位有多少人在DOS系统上写过程序，我上学的时候用TC写过hello world，但那时没有人跟俺讲静态连接库是啥，估计和我们老师有点菜有关系，自己不努力看书更有关系。所以现在如果还有同志不懂，那么就往下看看吧。讲的不对的地方，请发悄悄话给俺，偷偷指正。 静态连接库：程序员可以将公用模块的代码写成一个一个子程序（函数），编译成obj文件，最后将多个obj文件连接成一个lib文件。当用户程序中需要使用这些公用模块时，就包含它们的lib文件包进去，用户在自己的程序中只需要指定所需要的函数名称，编译器会在编译时，从lib中抽出对应的子程序代码-复制到用户程序中去。这样搞的最大的好处就是不必一遍遍重写相同功能的代码。这种连接方法就是静态连接。（回想一下，第一次在Turbo C下，printf(“Hello,World!”)时的情景，printf从哪来？是从lib中来的）。 Lib应该是一群懒惰的程序员想出来的。说白了，就是让编译器替我们copy别人写过的代码！正是因为这种copy，暴露了Lib显而易见的缺点。 缺点1：试想假如你的机器上有1000个程序需要用到同一个静态连接库中的某个函数，由于静态连接库中的函数代码是复制到用户可执行文件中的，所以这1000个可执行文件中就会重复包含1000份相同的代码，硬盘空间就被浪费了。由于DOS系统是单任务系统，静态连接库的使用只表现在硬盘空间的浪费上了。而Windows系统是多任务的，假如把这1000个程序都装到内存中，那么就会装入1000份相同的代码！要是有象硬盘那么大的内存就好了！ 缺点2：如果1000个程序需要用到同一个静态连接库中的某个函数。后来发现这个函数有问题，需要修正。改就改吧，于是就把静态连接库文件改改，编译一下。完事了么？没有！还得把这1000个程序全部重新编译一遍！ 看到这儿，再回头看看前面的比喻，是不是有点贴切了。用食堂来比喻，还是不太对，应该用看电影来比喻！ 2。动态连接库： 动态连接库（DLL）应该是随着windows95的出现而出现的。它的出现，恰恰弥补了静态连接库的缺点。 动态的连接库在程序设计过程中所起的作用与静态连接库的作用相同，都是提供一大堆函数供不爱写重复代码的程序员们使用，另外操作系统也是以DLL的形式提供接口函数的。 UG OPEN/API是什么？就是一群DLL提供的一大堆函数。 动态连接库与静态连接库，是以不同的手段来达到相同的目的。 静态连接库是将库中的代码复制到它的可执行文件中，首先它要占用多余的磁盘空间。而动态连接库只是在可执行文件运行时，才将库的代码调入内存。如果许多程序共用一个同一个动态连接库时，WINDOWS操作系统会在内存中仅保留一份库代码，通过分页机制，将这份代码映射到不同的进程空间中。这样，无论多少程序使用这样的一个库，库代码实际占用的内存永远只有一份。 让那1000个人到食堂里去吃饭吧，安全，而且效率高，浪费的资源亦少。 内存分页机制： 大家应该明白，程序运行时是需要操作系统的内存管理机制为其分配一段连续的程序（进程）空间，这就象一个人如果要跑步，那么你得给他安排一个操场。但是DOS操作系统对程序的空间分配是个很让当时的程序员头疼的问题。那时，他们的全部程序活动空间最多拥有600KB左右的内存可以使用。也许对DOS程序不太熟悉的兄弟不知道DOS中还有一种叫做“内存驻留”程序的东西，这种程序只要不释放，它就固定在内存中，倘若这种东西驻留在内存的中间位置，那么它就会将内存一分为二，这样程序员所写的程序，其活动空间也就300K左右。如果内存驻留程序再多一些，内存就被它们给搞的7零8乱，也许会导致程序员所写的程序没有足够的运行空间了！把一个人囚禁在小于他躯体体积的空间，这个人会怎样？ Windows系统不害怕内存被切割的破碎，它在内存碎片的基础上创建一个逻辑结构来管理。村民们可以居住在村子的任意角落，但是村长手里的名册上，他们是挨个被列出来的。DOS系统好象是直接到一个村子中去寻找某个村民，它在乱七八糟的街巷中迷路之后，就放弃寻找了。而windows系统要聪明一些，它会首先拜访这个村子的村长，村长去查他掌管的村民花名册，然后就能找到这个村民的家庭住址，最后就可以揪出这家伙。 WINDOWS系统中，所谓的内存分页，就是内存被分割成4KB大小（我记得是这个数）的N个页面，每个页面都可以类比为一个村民的住址。村长和他手里的花名册，就是内存分页机制。 总结一下，内存分页机制，就是在物理内存的基础上创建一个逻辑结构来管理它们。无论内存有多碎，但是在这个逻辑结构上，它们是连续的。 动态连接库是被映射到其他应用程序空间中执行的，它和连接它的应用程序可以看成是一体的。 WINDOWS系统中，每个程序都可以拥有自己的4G空间（实际上也就2G），而动态连接库没有自己的私有空间，它们扮演人民公仆的角色。 在32位的windows操作系统中，每个进程都可以有4GB的运行空间。该空间中可以存放操作系统代码，系统DLL，还有用户自己开发的DLL的代码，再除去其他一些乱七八糟的空间，最后剩下的，就是程序自己的私有空间了。说它是私有空间，就是说只有这个运行中的程序（进程）自己可以访问，其他的进程靠边站。DLL是没有私有空间的，它们是公仆啊，所有进程都可以访问它们。所以它们和内存映射文件，全局共享变量等等东西一起呆在内存公共区域中。 另外应当注意，DLL中的非共享变量不会被映射到各进程中去，而是被分配在各进程的私有空