Windows SDK (2)

Note: The following is an excerpt from instructor Hou Jie's in-depth introduction to MFC. The original article is based on vc5.0, Which is outdated but does not affect the whole.

Windows program description

Windows programs are divided into two parts: "program code" and "user interface resources". The two parts are finally integrated into a complete EXE file using connectors. So-called UI

Source refers to the functional menu, dialog box appearance, program icon, cursor shape, and so on. The actual content (Binary Code) of these UI resources is generated using various tools and with various extensions

Exist, such as .icow..bmp and. cur. Programmers must describe them in a so-called resource description file (. Rc. After the RC Compiler (RC. EXE) reads the description of the RC file

There is a UI resource file to generate a. Res file, which is combined with the program code. This is a complete Windows Executable File.

(. Lib)

Windows supports dynamic connections. In other words, the Windows API functions called by the application are linked during the "execution period. So, the "connection period"

What is the function library required? What are there? It is not the extension file named. dll that is used to dynamically link the function library (DLL, dynamic link library ).

.Exe,. dll,. Fon,. Mod,. DRV, And. ocx are all so-called dynamic concatenation function libraries. Functions called by Windows programs can be divided into C runtimes and Windows API

Two major parts.

Their Naming rules and timing are as follows:

■ Libc. Lib-this is the static join version of the C Runtime function library.

■ Msvcrt. Lib-this is the dynamic connection version of the C Runtime function library (msvcrt40.dll)

Import function library. If you join this function library, msvcrt40.dll must be present during program execution.

Another group of functions, Windows API, is provided by the operating system itself (mainly the three windows modules gdi32.dll, user32.dll and kernel32.dll. Although

State join occurs only during the execution period. However, during the connection period, the connector still needs to prepare appropriate information for the caller (the application itself) before it can be executed.

Smoothly jump to the DLL for execution. If the function library to which the API belongs has not been loaded, the system knows to load the function library first. Put the appropriate information in the so-called "import"

Function library. The import function libraries corresponding to the three 32-bit windows modules are gdi32.lib, user32.lib, and kernel32.lib.

Since the development of windows, some new API functions (such as common dialog and toolhelp) are not added in the three modules of GDI, user, and kernel,

Instead, it is placed in commdlg. dll and toolhelp. dll. If you want to use these APIs, you must add the import function library corresponding to these DLLs, such

Comdlg32.lib and th32.lib.

Refer:

1. msvc: concepts related to compilation, linking, loading, and library

2. Analysis and Solution of the problem that has been defined in msvcrtd. Lib (msvcr90d. dll), such as -- error lnk2005: XXX

(. H)

All Windows programs must contain windows. h. Unless you know exactly what API actions require header files, for convenience, a single windows. h

That's it. However, windows. h only takes care of the API functions provided by the three modules. If you use other system DLLs, such as commdlg. dll or mapi. dll

TAPI. dll and so on, you have to include the corresponding header file, such as commdlg. H, mapi. H, or TAPI. h.

Event-driven, message-based

Windows programs are driven by external events. In other words, the program keeps waiting (using a while loop), waiting for any possible input, and then making judgments

And then proceed with proper processing. After the above "input" is captured by the operating system, it enters the program in the form of a message (a data structure. How does the operating system capture peripheral settings?

What happens to the backup (such as the keyboard and mouse? Oh, the user module is in charge of various peripheral drivers, and each has its own detection loop. If you divide the various input points obtained by the application

Messages generated by hardware devices (such as moving the mouse or pressing the keyboard), placed in the system queue, and

Messages sent by Windows programs are stored in application queue. From the application's perspective, a message is a message, where it comes from or where it is stored.

There is no big difference in implementation. The program calls the getmessage API to obtain a message, and the life of the program is promoted by it. All GUI systems, including unix x Windows

And the expression manager of OS/2, like this, is a message-based event-driven system.

Figure: Relationship between windows program ontology and Operating System

It is conceivable that every Windows program should have a loop as follows:

MSG;

While (getmessage (& MSG, null )){

Translatemessage (& MSG );

Dispatchmessage (& MSG );

}

// All the above functions are Windows API functions

Message, that is, the MSG structure shown above, is a data format defined in Windows:

/* Queued message structure */

Typedef struct tagmsg

{

Hwnd;

Uint message; // wm_xxx, such as wm_mousemove, wm_size...

Wparam;

Lparam;

DWORD time;

Point pt;

} MSG;

Window Process Functions

The main character of receiving and processing messages is the window. Each window should have a function responsible for message processing, and the programmer must be responsible for designing this so-called "window function" (Window Function)

Procedure, or window function ). If the window gets a message, the window function must determine the type of the message and determine the processing method.

These are the most important concepts in Windows programming. As for the generation and display of Windows, it is very simple, with a dedicated API function responsible. Later we will see the windows program

How to present the acquired, distributed, and processed messages.

Program entry point winmain

Main is the entry point of the General C program:

Int main (INT argc, char * argv [], char * envp []);

{

...

}

Winmain is the entry point of the Windows program:

Int callback winmain (hinstance, hinstance hprevinstance,

Lpstr lpcmdline, int ncmdshow)

{

...

}

In Win32, callback is defined as _ stdcall, which is a function call habit. It is related to the order in which parameters are pushed to the stack and the responsibility of processing stacks. Other function calls

There are also _ Pascal and _ cdecl.

Refer:

C/C ++: function compilation method and call conventions

When the Windows Shell detects that the user wants to execute a Windows program, it calls the loader to load the program and then calls C startup code,

The latter then calls winmain to start executing the program. The four parameters of winmain are passed in by the operating system.

Registration of window category and emergence of window

At first, the windows program must do some initialization work, in order to generate the application's work stage: window. This is not difficult because the createwindow function is complete.

The whole huge project is fully arranged. However, before a window is generated, its properties must be set first. The so-called properties include the "appearance" and "behavior" of the window, the border, color, and label of the window.

The question, position, and so on are the appearance of the window, and the response after the window receives the message is its behavior (specifically, the window function itself ). The program must use the API function before creating a window.

Registerclass sets attributes (we call this action a registration window category ). Registerclass requires a large data structure wndclass as the parameter,

Createwindow requires 11 additional parameters.

Figure: registerclass and createwindow

 

After the initialization is complete, winmain enters the so-called message loop:

While (getmessage (& MSG ,...)){

Translatemessage (& MSG); // converts keyboard messages

Dispatchmessage (& MSG); // dispatch a message

}

The translatemessage is used to convert a keyboard message. The dispatchmessage sends the message to the window function for processing. The function name is not specified, but the message can be passed

Sent in, isn't it very mysterious? This is because when a message occurs, the operating system has marked the window according to the current status, and the window category of the window has clearly indicated the window

The interface function (that is, the function specified by WC. lpfnwndproc), so dispatchmessage has its own context to be searched. Dispatchmessage is assisted by the user module.

Send the message to the window function.

Where does dispatchmessage in a message loop distribute messages? It is sent to the window function of the window through the assistance of the user module. Window functions usually use

The switch/case method determines the message type to determine the disposal method. Because it is called by the Windows System (we have not called this function anywhere in the application ),

This is a call back function, which means a function called by a Windows system in your program. Although these functions are designed by you, they will never be called by you.

They are for Windows.

When the program is in progress, the message is captured by the input device through the message loop, the source is sent to the window and then sent to the window function. The size of window functions may be very large or refined.

The number of messages that interest the window varies depending on the number of messages.

As for the form of window functions, it must be:

Lresult callback wndproc (hwnd,

Uint message,

Wparam,

Lparam)

Note that all messages must be processed. Therefore, the default: In the switch/case command must call defwindowproc, which is a preset message in windows.

Functions.

Dialog Box

Windows dialogs are divided into two types based on their relationship with the parent window:

1. "allow the parent window to be exclusive until the dialog box ends". This is called the modal dialog box.

2. "parent window and dialog box run together", which is called the modeless dialog box. The modal dialog box is commonly used.

To make a dialog box, the programmer must prepare two things:

1. dialog box template ). This is the appearance of a dialog box defined in the RC file. The dialog box size, Font, and internal control groups are determined in various ways.

Parts, where and so on.

2. Dialog Box function (dialog procedure ). Its type is very similar to window functions, but it usually only processes messages wm_initdialog and wm_command. Pair

Each control component in the dialog box is also a small window, with its own window functions, which communicate with its manager (parent window, that is, the dialog box) through messages. All control components

Wm_command indicates the control component and notification ). The activation and termination of the Modal Dialog Box depend on

Two API functions: dialogbox and enddialog.

 

Figure: creation, operation, and end of the dialog box

RC file

The RC file is a place where resources are described in text. Common resources include icon, cursor, bitmap, Font, dialog, menu, toolbar,

Accelerator, string, and versioninfo. New resources may also be added. The text description must pass through the RC compiler to generate usable binary code.

Summary window lifecycle:

1. createwindow is called during program initialization, and a window is created for the program as the screen stage of the program. After a window is generated in createwindow, it is sent out.

Wm_create is directly assigned to the window function, and the latter can perform initialization actions at this time (such as configuring memory, opening files, and reading initial data ...).

2. When the program is alive, it continuously uses getmessage To Capture messages from the message storage column. If the message is wm_quit, getmessage returns 0 and ends the WHILE LOOP

And end the entire program.

3. dispatchmessage distributes messages to window functions through the help and supervision of the Windows User Module. The message will be identified and processed here.

4. The program continues to perform 2 and 3. Actions.

5. When the user presses the close command item in the System menu, the system sends the wm_close command. Generally, the window function of the program does not intercept this message, so defwindowproc processes it.

6. After receiving wm_close, defwindowproc calls destroywindow to clear the window. Destroywindow itself sends wm_destroy again.

7. The program's standard response to wm_destroy is to call postquitmessage.

8. If postquitmessage has no other actions, only the wm_quit message is sent to get the getmessage in the message loop. For example, step 2 ends the message loop.

Figure: Window Lifecycle