关于DDK中的编译知识

 本文将分为三个部分进行介绍：1.makefile文件。2.DDK中的编译文件。3.DDK中的编译文件语法。

1. makefile文件

概述
——

什么是makefile？或许很多Winodws的程序员都不知道这个东西，因为那些Windows的IDE都为你做了这个工作，但我觉得要作一个好的和professional的程序员，makefile还是要懂。这就好像现在有这么多的HTML的编辑器，但如果你想成为一个专业人士，你还是要了解HTML的标识的含义。特别在Unix下的软件编译，你就不能不自己写makefile了，会不会写makefile，从一个侧面说明了一个人是否具备完成大型工程的能力。

因为，makefile关系到了整个工程的编译规则。一个工程中的源文件不计数，其按类型、功能、模块分别放在若干个目录中，makefile定义了一系列的规则来指定，哪些文件需要先编译，哪些文件需要后编译，哪些文件需要重新编译，甚至于进行更复杂的功能操作，因为makefile就像一个Shell脚本一样，其中也可以执行操作系统的命令。

makefile带来的好处就是——“自动化编译”，一旦写好，只需要一个make命令，整个工程完全自动编译，极大的提高了软件开发的效率。make是一个命令工具，是一个解释makefile中指令的命令工具，一般来说，大多数的IDE都有这个命令，比如：Delphi的make，Visual C++的nmake，Linux下GNU的make。可见，makefile都成为了一种在工程方面的编译方法。

现在讲述如何写makefile的文章比较少，这是我想写这篇文章的原因。当然，不同产商的make各不相同，也有不同的语法，但其本质都是在“文件依赖性”上做文章，这里，我仅对GNU的make进行讲述，我的环境是RedHat Linux 8.0，make的版本是3.80。必竟，这个make是应用最为广泛的，也是用得最多的。而且其还是最遵循于IEEE 1003.2-1992 标准的（POSIX.2）。

在这篇文档中，将以C/C++的源码作为我们基础，所以必然涉及一些关于C/C++的编译的知识，相关于这方面的内容，还请各位查看相关的编译器的文档。这里所默认的编译器是UNIX下的GCC和CC。

 

关于程序的编译和链接
——————————

在此，我想多说关于程序编译的一些规范和方法，一般来说，无论是C、C++、还是pas，首先要把源文件编译成中间代码文件，在Windows下也就是 .obj 文件，UNIX下是 .o 文件，即 Object File，这个动作叫做编译（compile）。然后再把大量的Object File合成执行文件，这个动作叫作链接（link）。

编译时，编译器需要的是语法的正确，函数与变量的声明的正确。对于后者，通常是你需要告诉编译器头文件的所在位置（头文件中应该只是声明，而定义应该放在C/C++文件中），只要所有的语法正确，编译器就可以编译出中间目标文件。一般来说，每个源文件都应该对应于一个中间目标文件（O文件或是OBJ文件）。

链接时，主要是链接函数和全局变量，所以，我们可以使用这些中间目标文件（O文件或是OBJ文件）来链接我们的应用程序。链接器并不管函数所在的源文件，只管函数的中间目标文件（Object File），在大多数时候，由于源文件太多，编译生成的中间目标文件太多，而在链接时需要明显地指出中间目标文件名，这对于编译很不方便，所以，我们要给中间目标文件打个包，在Windows下这种包叫“库文件”（Library File)，也就是 .lib 文件，在UNIX下，是Archive File，也就是 .a 文件。

总结一下，源文件首先会生成中间目标文件，再由中间目标文件生成执行文件。在编译时，编译器只检测程序语法，和函数、变量是否被声明。如果函数未被声明，编译器会给出一个警告，但可以生成Object File。而在链接程序时，链接器会在所有的Object File中找寻函数的实现，如果找不到，那到就会报链接错误码（Linker Error），在VC下，这种错误一般是：Link 2001错误，意思说是说，链接器未能找到函数的实现。你需要指定函数的Object File.

好，言归正传，GNU的make有许多的内容，闲言少叙，还是让我们开始吧。

 

Makefile 介绍
———————

make命令执行时，需要一个 Makefile 文件，以告诉make命令需要怎么样的去编译和链接程序。

首先，我们用一个示例来说明Makefile的书写规则。以便给大家一个感兴认识。这个示例来源于GNU的make使用手册，在这个示例中，我们的工程有8个C文件，和3个头文件，我们要写一个Makefile来告诉make命令如何编译和链接这几个文件。我们的规则是：
    1）如果这个工程没有编译过，那么我们的所有C文件都要编译并被链接。
    2）如果这个工程的某几个C文件被修改，那么我们只编译被修改的C文件，并链接目标程序。
    3）如果这个工程的头文件被改变了，那么我们需要编译引用了这几个头文件的C文件，并链接目标程序。

只要我们的Makefile写得够好，所有的这一切，我们只用一个make命令就可以完成，make命令会自动智能地根据当前的文件修改的情况来确定哪些文件需要重编译，从而自己编译所需要的文件和链接目标程序。

一、Makefile的规则

在讲述这个Makefile之前，还是让我们先来粗略地看一看Makefile的规则。

    target ... : prerequisites ...
            command
            ...
            ...

    target也就是一个目标文件，可以是Object File，也可以是执行文件。还可以是一个标签（Label），对于标签这种特性，在后续的“伪目标”章节中会有叙述。

    prerequisites就是，要生成那个target所需要的文件或是目标。

    command也就是make需要执行的命令。（任意的Shell命令）

这是一个文件的依赖关系，也就是说，target这一个或多个的目标文件依赖于prerequisites中的文件，其生成规则定义在command中。说白一点就是说，prerequisites中如果有一个以上的文件比target文件要新的话，command所定义的命令就会被执行。这就是Makefile的规则。也就是Makefile中最核心的内容。

说到底，Makefile的东西就是这样一点，好像我的这篇文档也该结束了。呵呵。还不尽然，这是Makefile的主线和核心，但要写好一个Makefile还不够，我会以后面一点一点地结合我的工作经验给你慢慢到来。内容还多着呢。：）

二、一个示例

正如前面所说的，如果一个工程有3个头文件，和8个C文件，我们为了完成前面所述的那三个规则，我们的Makefile应该是下面的这个样子的。

    edit : main.o kbd.o command.o display.o \
           insert.o search.o files.o utils.o
            cc -o edit main.o kbd.o command.o display.o \
                       insert.o search.o files.o utils.o

    main.o : main.c defs.h
            cc -c main.c
    kbd.o : kbd.c defs.h command.h
            cc -c kbd.c
    command.o : command.c defs.h command.h
            cc -c command.c
    display.o : display.c defs.h buffer.h
            cc -c display.c
    insert.o : insert.c defs.h buffer.h
            cc -c insert.c
    search.o : search.c defs.h buffer.h
            cc -c search.c
    files.o : files.c defs.h buffer.h command.h
            cc -c files.c
    utils.o : utils.c defs.h
            cc -c utils.c
    clean :
            rm edit main.o kbd.o command.o display.o \
               insert.o search.o files.o utils.o

反斜杠（\）是换行符的意思。这样比较便于Makefile的易读。我们可以把这个内容保存在文件为“Makefile”或“makefile”的文件中，然后在该目录下直接输入命令“make”就可以生成执行文件edit。如果要删除执行文件和所有的中间目标文件，那么，只要简单地执行一下“make clean”就可以了。

在这个makefile中，目标文件（target）包含：执行文件edit和中间目标文件（*.o），依赖文件（prerequisites）就是冒号后面的那些 .c 文件和 .h文件。每一个 .o 文件都有一组依赖文件，而这些 .o 文件又是执行文件 edit 的依赖文件。依赖关系的实质上就是说明了目标文件是由哪些文件生成的，换言之，目标文件是哪些文件更新的。

在定义好依赖关系后，后续的那一行定义了如何生成目标文件的操作系统命令，一定要以一个Tab键作为开头。记住，make并不管命令是怎么工作的，他只管执行所定义的命令。make会比较targets文件和prerequisites文件的修改日期，如果prerequisites文件的日期要比targets文件的日期要新，或者target不存在的话，那么，make就会执行后续定义的命令。

这里要说明一点的是，clean不是一个文件，它只不过是一个动作名字，有点像C语言中的lable一样，其冒号后什么也没有，那么，make就不会自动去找文件的依赖性，也就不会自动执行其后所定义的命令。要执行其后的命令，就要在make命令后明显得指出这个lable的名字。这样的方法非常有用，我们可以在一个makefile中定义不用的编译或是和编译无关的命令，比如程序的打包，程序的备份，等等。

作者Blog： http://blog.csdn.net/haoel/

 

2.DDK中的编译文件

用DDK编译驱动，需要两个文件的支持，一个是MakeFile文件，这个文件是通用的。而Source文件则根据每个驱动程序而不同，转了一篇讲解如何编写这两个文件的文章，感谢原作者。

---

学习和编写WDM 驱动程序对谁而言都是一件具有挑战的事情，需要恒心和毅力。当你入门后你会发现这是一件多么令人兴奋的事情。但是如何使用WDM的编译环境从而开始WDM 学习的旅程？对一个初学者来说这个门槛可不低。安装完DDK后，可以用 [开始]->[Development kit]->[Windows XX DDK]->[check/free Build Environment]来启动编译环境，由于DDK没用提供IDE环境(当然你可以使用配置后的VC或DriverStudio这另当别论)，对于我们 这些孕育在Xp时代的程序员来说这无疑是件难事。为什么?因为编译一个WDM程序除了.cpp .h 源文件外至少还需要：
                               makefile文件
                               sources 文件
这两个文件本应该由IDE自动帮我们生成，如VC就为我们的所有工程生成了makefile,sources,xx.rc文件,平时我们根本不需要了解他 们就可以编译我们的工程。可DDK没有工具为我们生成这两个文件，但DDK编译程序的时候又需要他们，俗话说得好“我不如地狱谁入地狱”，我们就来编写这 两个文件:
      
一. makefile (没有扩展名，它名字就叫makefile),内容如下:

C++代码

1. # DO NOT EDIT THIS FILE!!!   Edit .\sources. if you want to add a new source  
2. # file to this component.   This file merely indirects to the real make file  
3. # that is shared by all the components of NT.  
4. #  
5. !INCLUDE $(NTMAKEENV)\makefile.def  

值得高兴的是，WDM程序使用的所有makefile都这样写，我们只需写一个，编译时把它拷贝到工作目录下就行了

二. sources文件就需要我们根据不同的场合修改了，不过基本模板如下:

C++代码

1. TARGETNAME=驱动程序名    //(不含扩展名)      
2. TARGETPATH=obj         // 固定不变      
3. TARGETTYPE=DRIVER      // 固定不变(表明，连接成*.sys文件)      
4. DRIVERTYPE=WDM         // 为 Win32 Driver Model 驱动      
5. INCLUDES=$(BASEDIR)\inc\ddk;$(BASEDIR)\inc   // 源程序可能使用的DDK头文件所在的目录,多个目录用“;” 隔开,多个文件用 '空格' 隔开   

其中“$(BASEDIR)”指DDK当前的安装目录，例如当前DDK安装在D:上，则$(BASEDIR) 就是 “D:\DDK”，所以上面的INCLUDES可以翻译成D:\DDK\inc\ddk; D:\DDK\inc

  

三. 不得不注意的3个讨厌问题:
      1. 编译时必须保证 makefile,sources和源程序在同一目录下
      2. 编写sources文件时，其中的”=”两边不能有空格
      3. 如果上面的问题还不够讨厌，那么下面这个问题可以讨厌的让人放弃学习DDK：工程的工作目录的绝对路径中不能出现空格，如 “C:\Documents and Settings\MyProgramme\”将不能被DDK编译器编译，而且表面上看来DDK好像是完成的编译，实际上它什么都没做!

DDK Build的DIRS和SOURCE文件

2009-12-15 17:25:00|  分类： NT底层研究 |  标签： |字号大中小 订阅

这次不得不说说DDK编译时使用的dirs和sources文件了，因为下午再次用到的时候又糊涂了……

ps 本文不用来阐述 dirs和sources文件的语法，因为那个不是本文目的。本文只是记录下如何使用dirs和sources文件对工程进行模块划分和编译而已。

大概4个月之前吧，因为项目里的文件越来越多，加上可能要再添几个人手过来一起做的缘故，打算将驱动程序项目的文件组织重新划分下，之前都是100多个文件直接平躺在一级目录下，不优雅不好分工合作。花了我大概3个小时左右吧，终于搞定，几个月过来又给忘记了。。。寒，赶紧记下来先吧。

DDK Build编译的时候，使用3个文件来描述被编译的源码，其中SOURCES和Makefile是必须的，而DIRS则只在划分目录的时候有用。Makefile在这里作用并不大但是必须和SOURCES文件成对出现，关键还是SOURCES和DIRS

文件。

SOURCES文件用于描述其所在目录下，有哪些文件参与编译，编译的结果应该是什么（是一个lib还是一个sys？），输出目录在哪里，要传递给编译器的各种定义和选项分别是什么，等等。这里有一个概念需要特别的注意，就是由一个SOURCES文件描述的其实就是一个单独的小工程，Build最后会参照SOURCES文件的设置，产生一个指定的目标文件(dll ? lib ? exe ? sys ? 都有可能，完全依赖于SOURCES文件的写法)。

DIRS文件用于描述，在当前目录下，需要被编译的子目录有哪些。注意！DIRS文件和SOURCES文件不能共存在同一个目录下。

举例：工程DDKTest，由3个子模块和一个主模块构成，目录结构如下：

DDKTest

├─Mod_A

├─Mod_B

├─Mod_C

└─Mod_Main

└─dirs      //这里必须有一个dirs文件，告诉DDK的build工具, 当前目录下有哪些文件夹参与编译

dirs的内容是这样：

DIRS = Mod_A Mod_B Mod_C Mod_Main

4个文件夹名字之间以空格间隔，也可以使用 \ 连行符分隔成多行去书写。

在 Mod_A ，Mod_B，Mod_C，Mod_Main 这4个文件夹下，分别含有一个SOURCES文件，每一个用于

告诉Build，自身目录内有哪些文件参与编译，在编译时传递给编译和链接器的参数又是什么，最后要生

成的目标文件是什么类型，等等。

在这个例子中，Mod_A、Mod_B、Mod_C 都是子模块，因此我让他们都生成为lib文件，也就是静态库

文件。而对于Mod_Main ，由于是主模块，因此我们用它生成.sys文件，但是在Mod_Main的

SOURCES文件中，我们必须告诉Build，其他3个子模块生成的lib文件在哪里，并且要求链接器在链接时找到这3个子模块生成的lib，这样才能完整的编译完整个DDKTest项目。

我当时在最后一步这里没搞明白，看看都编译通过生成了6个lib，最后一个主模块一编译挺ok ，一链接一大堆的各种找不到，很是郁闷的。

总结下，其实就是将每个模块都单独的编译成一个lib，最后由主模块在生成目标文件时，和所有已编译好的lib进行链接即可。

长年只玩IDE环境的同学可能对此不是很了解，其实很多IDE也提供命令行编译的，比如VS系列。

3.DDK中的编译文件语法

TARGETLIBS

这个宏用于设置连接时所用到的LIB库目录.

这个文件路径必须是绝对地址才行(MSDN上说的)

比如:

TARGETLIBS=$(SDK_LIB_PATH)\kernel32.lib \
           $(SDK_LIB_PATH)\advapi32.lib \

TARGETLIBS=../../lib/i386/SysDll.lib     #相对路径也可以啊,尝试时发现的

TARGETPATHLIB

编译DLL类型的文件时,指定其对应的LIB所在的目录

TARGETNAME

TARGETPATHLIB=../../lib

定义驱动名,或DLL名字.

TARGETPATH

定义所有生成文件放置的目录.

例如:

TARGETPATH=../../bin 

TARGETTYPE

定义最终文件类型

当要创建一个Dll时,那么此类型值设置为LIBRARY或DYNLINK

值	定义	生成文件后缀
PROGRAM	应用层程序,不输出任何函数.	.EXE
PROGLIB	应用层程序,同时也有输出函数	.EXE
DYNLINK	动态库文件可以输出函数, 其它二进制文件可以引用这些函数, 标记这不是一个独立的.EXE文件.	.dll
LIBRARY	生成一个静态库,这个文件中包含了函数的内容,其它程序在静态LINK时把这些函数都编译进对应的文件. 当你要生成一个动态库时,同时也会生成一个LIB. 但当你想生成一个静态库时,那么只生成一个LIB文件.	.LIB
EXPORT_DRIVER	一个内核下的DLL, 相当于应用层的DLL,同时生成LIB文件 要有对应的DriverEntry函数 否则出错.	.Sys
DRIVER_LIBRARY	内核状态下的静态库, 包含了函数说明和代码. 相当于应用层的静态库 不能有DriverEntry函数, 否则在LINK时会出现DriverEntry重复的错误.	.Lib
DRIVER	驱动程序	.sys
MINIPORT	驱动程序但不连接 Ntoskrnl.lib或hal.lib	.sys
GDI_DRIVER	图像驱动程序 连接win32k.sys	.dll