windows SDK一些回顾和理解

 

几年前学过一点点关于windows SDK和MFC编程的东西，很少用。最近两三天重新又看了一点programming windows 上面的一些内容。

比如关于消息循环机制, 系统给应用程序发送消息。关于设备上下文的理解等问题。

我觉得我们在初期理解一些问题的时候。不妨站在我就是windows操作系统的角度来思考。比如操作系统对HDC这个结构的维护，使得GDI的函数能够正常使用。

 

例子：我是操作系统，如果我要帮应用程序，在我管理的硬件设备（显示器）上显示一个窗口。。首先，你得告诉我你这个窗口要显示成什么样子的。。所以应用程序需要WNDCLASS这个结构体来设计一个窗口；然后我要维护那么多的东西，需要标志你这个窗口的一个东西。于是应用程序需要像我注册一个窗口句柄。这样，我才对我要维护的东西心里有数，操作的时候才知道。显示窗口，更新窗口就不说了。

消息循环在这里也暂时不说。

 

然后来理解一下到设备上下文。

假设，应用程序需要让我在注册好的窗口上画一个圆，画一条线。可是这个操作应该涉及到非常多的东西。比如背景颜色是什么，线的大小，颜色，类型，比如填充模式。。等等，那是不是每一个GDI画图函数都要传递这些东西呢？当然不是，所以我（windows）把一些共性的东西，用一个HDC来维护。这样，只需要给每一个函数，传递一个HDC的句柄。站在操作系统的角度，站在实现的角度，很多问题，概念，就能真正理解地更清楚。比如设备上下文的概念。

 

之所以有这些感觉，操作系统提供的功能，如果最简单的理解，其实这和网络协议栈编写提供的功能也是一样的。也是一个模块（层次），维护一些数据结构，同时给别的模块或用户提供服务（接口API）；同时要使用某些模块给我们提供的服务（API）。

 

所以，站在你是服务使用者的角度，和站在你是那个服务提供者的角度同时思考一些问题，可能会事半功倍。

 

学习和理解这么一些编程机制，多好啊。

 

然后简单总结下这几天看过的一些核心概念的东西吧。

1：事件驱动的消息机制（消息循环机制）的实现方式。其中使用了WndPoc()窗口过程函数。系统给应用程序发送消息的含义：最后的结果是系统调用用户编写的窗口过程。

 

2：设备上下文(device context)。对这个概念的了解。以及这种方式对模块化编程的一些启示

 

3：句柄。系统对资源的一些管理机制。

 

我们在编写某一个程序模块（层次）的时候，思考或者借鉴下windows那种管理维护内部数据结构，以及提供给外界接口的一些编程方式。

 

开发一个模块 = 数据结构 + 算法 + 程序开发平台（程序运行时环境）。

编程遇到问题，想想到底是模块设计的问题；还是以上哪个部分的问题。

 

下面是阅读programming windows的一些摘录文字。主要关于消息机制，设备上下文方面。

 

2011-8-21

How does the application know that the user has changed the window's size? For programmers accustomed to only conventional character-mode programming, there is no mechanism for the operating system to convey information of this sort to the user. It turns out that the answer to this question is central to understanding the architecture of Windows. When a user resizes a window, Windows sends a message to the program indicating the new window size. The program can then adjust the contents of its window to reflect the new size.

"Windows sends a message to the program." I hope you didn't read that statement without blinking. What on earth could it mean? We're talking about program code here, not a telegraph system. How can an operating system send a message to a program?

When I say that "Windows sends a message to the program" I mean that Windows calls a function within the program—a function that you write and which is an essential part of your program's code. The parameters to this function describe the particular message that is being sent by Windows and received by your program. This function in your program is known as the "window procedure."

You are undoubtedly accustomed to the idea of a program making calls to the operating system. This is how a program opens a disk file, for example. What you may not be accustomed to is the idea of an operating system making calls to a program. Yet this is fundamental to Windows' architecture.

Every window that a program creates has an associated window procedure. This window procedure is a function that could be either in the program itself or in a dynamic-link library. Windows sends a message to a window by calling the window procedure. The window procedure does some processing based on the message and then returns control to Windows.

More precisely, a window is always created based on a "window class." The window class identifies the window procedure that processes messages to the window.

 

2011-8-23

A handle, you'll recall, is simply a number that Windows uses for internal reference to an object. You obtain the handle from Windows and then use the handle in other functions. The device context handle is your window's passport to the GDI functions. With that device context handle you are free to paint your client area and make it as beautiful or as ugly as you like.

 

The device context (also called simply the "DC") is really just a data structure maintained internally by GDI.

When a program needs to paint, it must first obtain a handle to a device context. When you obtain this handle, Windows fills the internal device context structure with default attribute values. As you'll see in later chapters, you can change these defaults by calling various GDI functions

 

 

Here's the general procedure: You create a "logical pen," which is merely a description of a pen, using the function CreatePen or CreatePenIndirect. These functions return a handle to the logical pen. You select the pen into the device context by calling SelectObject.

 

A logical pen is a "GDI object," one of six GDI objects a program can create. The other five are brushes, bitmaps, regions, fonts, and palettes.

 

The GDI mapping mode

 

2011-8-24

As the user presses and releases keys on the keyboard, Windows and the keyboard device driver translate the hardware scan codes into formatted messages. However, these messages are not placed in an application's message queue right away. Instead, Windows stores these messages in something called the system message queue. The system message queue is a single message queue maintained by Windows specifically for the preliminary storage of user input from the keyboard and the mouse. Windows will take the next message from the system message queue and place it in an application's message queue only when a Windows application has finished processing a previous user input message.

The reasons for this two-step process—storing messages first in the system message queue and then passing them to the application message queue—involves synchronization. As we just learned, the window that is supposed to receive keyboard input is the window with the input focus. A user can be typing faster than an application can handle the keystrokes, and a particular keystroke might have the effect of switching focus from one window to another. Subsequent keystrokes should then go to another window. But they won't if the subsequent keystrokes have already been addressed with a destination window and placed in an application message queue.

I've discussed what I consider to be the best architecture of a multithreaded program, which is that the primary thread creates all the program's windows, contains all the window procedures for these windows, and processes all messages to the windows. Secondary threads carry out background jobs or lengthy jobs.

Global variables in a multithreaded program, as well as any allocated memory, are shared among all the threads in the program. Local static variables in a function are also shared among all threads using that function. Local automatic variables in a function are unique to each thread because they are stored on the stack and each thread has its own stack.