按键盘上方向键 ← 或 → 可快速上下翻页，按键盘上的 Enter 键可回到本书目录页，按键盘上方向键 ↑ 可回到本页顶部！
————未阅读完？加入书签已便下次继续阅读！
。LIB
text file
C runtime； 曾经有的程序，现已不需要
C runtime；
DLL Import； LINKER
DLL Import；
binary file 。EXE
。EXE
图 1…1 一个32位Windows SDK 程序的开发流程
4
…………………………………………………………Page 67……………………………………………………………
Win32 程序开发流程
Windows UI User Interface RC
程序分为「程序代码」和「 （ ）资源」两大部份，两部份最后以
EXE 图 UI
编译器整合为一个完整的 文件（ 1…1）。所谓 资源是指功能菜单、对话框
外貌、程序图标、光标形状等等东西。这些UI 资源的实际内容（二进制代码）系借助各
种工具产生，并以各种扩展名存在，如。ico、。bmp 、。cur 等等。程序员必须在一个所谓
。rc RC RC。EXE RC UI
的资源描述档（ ）中描述它们。 编译器（ ）读取 档的描述后将所有
资源档集中制作出一个。RES 档，再与程序代码结合在一起，这才是一个完整的Windows
可执行档。
。LIB
需要什么函数库 （ ）
众所周知Windows 支持动态联结。换句话说，应用程序所调用的Windows API 函数是
在「执行时期」才联结上的。那么，「联结时期」所需的函数库做什么用？有哪些？
并不是延伸档名为。dll 者才是动态联结函数库（DLL ，Dynamic Link Library ），事实
上。exe 、。dll、。fon、。mod、。drv、。ocx 都是所谓的动态联结函数库。
Windows C Runtimes Windows API C
程序调用的函数可分为 以及 两大部份。早期的
Runtimes 并不支持动态联结，但Visual C＋＋ 4。0 之后已支持，并且在32 位操作系统
中已不再有small/medium/large 等内存模式之分。以下是它们的命名规则与使用时机：
LIBC。LIB C Runtime
■ 这是 函数库的静态联结版本。
MSVCRT。LIB C Runtime MSVCRT40。DLL
■ 这是 函数库动态联结版本（ ）的
import 函数库。如果联结此一函数库，你的程序执行时必须有MSVCRT40。DLL
在场。
另一组函数，Windows API ，由操作系统本身（主要是Windows 三大模块GDI32。DLL 和
USER32。DLL 和KERNEL32。DLL ）提供（注）。虽说动态联结是在执行时期才发生「联
5
…………………………………………………………Page 68……………………………………………………………
结」事实，但在联结时期，联结器仍需先为调用者（应用程序本身）准备一些适当的信
息，才能够在执行时期顺利「跳」到DLL 执行。如果该API 所属之函数库尚未加载，
系统也才因此知道要先行加载该函数库。这些适当的信息放在所谓的「import 函数库」
中。32 位Windows 的三大模块所对应的import 函数库分别为GDI32。LIB 和USER32。LIB
和KERNEL32。LIB 。
注：谁都知道，Windows 95 是16/32 位的混合体，所以旗下除了32 位的GDI32。DLL 、
USER32。DLL KERNEL32。DLL 16 GDI。EXE USER。EXE
和 ， 又有 位的 、 和
KRNL386。EXE 。32 位和16 位两组DLLs 之间以所谓的thunking layer 沟通。站在纯
粹APIs 使用者的立场，目前我们不必太搭理这个事实。
Windows 发展至今，逐渐加上的一些新的API 函数（例如mon Dialog、ToolHelp ）
并不放在GDI 和USER 和KERNEL 三大模块中，而是放在诸如MDLG。DLL 、
TOOLHELP。DLL 之中。如果要使用这些APIs ，联结时还得加上这些DLLs 所对应的
import 函数库，诸如DLG32。LIB 和TH32。LIB 。
很快地，在稍后的范例程序！ §Generic！ ¨ 的makefile 中，你就可以清楚看到联结时期所需
的各式各样函数库（以及各种联结器选项）。
需要什么头文件 （ ）
。H
所有Windows 程序都必须包含WINDOWS。H 。早期这是一个巨大的头文件，大约有5000
Visual C＋＋ 4。0 WINDOWS。H
行左右， 已把它切割为各个较小的文件，但还以 总括之。
除非你十分清楚什么API 动作需要什么头文件，否则为求便利，单单一个WINDOWS。H
也就是了。
不过，WINDOWS。H 只照顾三大模块所提供的API 函数，如果你用到其它system DLLs，
例如MDLG。DLL 或MAPI。DLL 或TAPI。DLL 等等，就得包含对应的头文件，例如
MDLG。H 或MAPI。H 或TAPI。H 等等。
6
…………………………………………………………Page 69……………………………………………………………
以消息为基础，以事件驱动之 （ ， ）
message based event driven
Windows 程序的进行系依靠外部发生的事件来驱动。换句话说，程序不断等待（利用一
个while 回路），等待任何可能的输入，然后做判断，然后再做适当的处理。上述的「输
入」是由操作系统捕捉到之后，以消息形式（一种数据结构）进入程序之中。操作系统
如何捕捉外围设备（如键盘和鼠标）所发生的事件呢？噢，USER 模块掌管各个外围的
驱动程序，它们各有侦测回路。
如果把应用程序获得的各种「输入」分类，可以分为由硬件装置所产生的消息（如鼠标
system queue Windows
移动或键盘被按下），放在系统队列（ ）中，以及由 系统或其它
Windows 程序传送过来的消息，放在程序队列（application queue ）中。以应用程序的眼
光来看，消息就是消息，来自哪里或放在哪里其实并没有太大区别，反正程序调用
GetMessage API 就取得一个消息，程序的生命靠它来推动。所有的GUI 系统，包括UNIX
的X Window 以及OS/2 的Presentation Manager ，都像这样，是以消息为基础的事件驱
动系统。
可想而知，每一个Windows 程序都应该有一个回路如下：
MSG msg；
while （GetMessage （&msg； NULL； NULL； NULL）） ｛
TranslateMessage （&msg）；
DispatchMessage （&msg）；
｝
// 以上出现的函数都是Windows API 函数
消息，也就是上面出现的MSG 结构，其实是Windows 内定的一种资料格式：
/* Queued message structure */
typedef struct tagMSG
｛
HWND hwnd；
UINT message； // WM_xxx WM_MOUSEMOVE WM_SIZE。。。
，例如 ，
WPARAM wParam；
LPARAM lParam；
DWORD time；
POINT pt；
｝ MSG；
7
…………………………………………………………Page 70……………………………………………………………
接受并处理消息的主角就是窗口。每一个窗口都应该有一个函数负责处理消息，程序员
必须负责设计这个所谓的「窗口函数」（window procedure，或称为window function ）。
如果窗口获得一个消息，这个窗口函数必须判断消息的类别，决定处理的方式。
Windows
以上就是 程序设计最重要的观念。至于窗口的产生与显示，十分简单，有专
API Windows
门的 函数负责。稍后我们就会看到 程序如何把这消息的取得、分派、处
理动作表现出来。
MYAPP。EXE
WinMain（hInst； hPrev； 。。。）
｛
MSG msg；