使用C语言和Windows API编写程序指南

需积分: 9 32 浏览量更新于2024-07-25 收藏 7.47MB PDF 举报

"《Windows 5th》是关于如何编写在Microsoft Windows 98、Windows NT 4.0和Windows NT 5.0操作系统上运行的程序的指南，主要使用C语言并利用Windows的原生应用程序编程接口（APIs）。本书强调了理解Windows APIs的重要性，即使你最终选择其他方式来编写代码，这一知识也是必要的。书中提到，Windows 98是基于32位Intel微处理器（如486和Pentium）的IBM兼容个人计算机的标准图形操作系统，而Windows NT则是一个在PC兼容机和某些RISC工作站上运行的增强版。阅读本书之前，读者应具备Windows 98的用户视角知识，因为编写应用程序需要理解其用户界面。" 在《Windows 5th》中，作者首先介绍了开始编程前的准备工作。书中的第一个章节"Getting Started"指出，虽然不是唯一的方法，但使用C语言和Windows APIs编写程序是最常见的方式之一，尤其对于想要深入理解Windows操作系统的开发者来说，掌握Windows APIs至关重要。Windows APIs是一组函数和结构，允许程序员直接与操作系统交互，实现诸如窗口创建、事件处理、图形绘制等功能。 Windows 98作为当时的最新版本，提供了丰富的用户界面，这对于开发人员来说，意味着需要对窗口、菜单、对话框等元素有深入的理解。而Windows NT则是针对企业级环境设计的操作系统，具有更高的稳定性和安全性，适用于服务器和高性能计算平台。因此，开发者不仅需要了解基本的编程技术，还需要理解这两种不同Windows版本之间的差异，以便编写能在这些平台上运行的兼容代码。书中的内容将涵盖如何利用C语言和Windows APIs创建各种类型的Windows应用程序，包括控制台应用程序、窗口应用程序以及可能涉及多线程和网络通信的更复杂程序。学习这些知识需要一定的C语言基础，同时对操作系统的基本原理有所了解，例如进程、线程的概念，以及内存管理和输入/输出处理。在开发过程中，作者建议读者熟悉Windows的用户交互模式，这包括鼠标的使用、菜单操作、窗口管理等，因为应用程序的用户体验是评估其质量的重要标准。此外，开发环境的选择也是关键，可能会涉及到Visual Studio或其他C编译器的使用。通过《Windows 5th》，读者可以学习到如何编写高效的Windows程序，并且理解如何利用Windows APIs来实现高级功能，如动态链接库的使用、系统资源的管理以及错误处理等。这本书对于那些希望从底层理解和控制Windows程序开发的开发者来说，是一份宝贵的参考资料。

WINUSERAPI int WINAPI MessageBoxA (HWND hWnd, LPCSTR lpText,

LPCSTR lpCaption, UINT uType) ;

And here's MessageBoxW:

WINUSERAPI int WINAPI MessageBoxW (HWND hWnd, LPCWSTR lpText,

LPCWSTR lpCaption, UINT uType) ;

Notice that the second and third parameters to the MessageBoxW function are pointers to wide-character strings.

You can use the MessageBoxA and MessageBoxW functions explicitly in your Windows programs if you need to mix and

match ASCII and wide-character function calls. But most programmers will continue to use MessageBox

, which will be the

same as MessageBoxA or MessageBoxW depending on whether UNICODE is defined. Here's the rather trivial code in

WINUSER.H that does the trick:

#ifdef UNICODE

#define MessageBox MessageBoxW

#else

#define MessageBox MessageBoxA

#endif

Thus, all the MessageBox function calls that appear in your program will actually be MessageBoxW functions if the

UNICODE identifier is defined and MessageBoxA functions if it's not defined.

When you run the program, Windows links the various function calls in your program to the entry points in the various

Windows dynamic-link libraries. With just a few exceptions, however, the Unicode versions of the Windows functions are

not implemented in Windows 98. The functions have entry points, but they usually return an error code. It is up to an

application to take note of this error return and do something reasonable.

Windows' String Functions

As I noted earlier, Microsoft C includes wide-character and generic versions of all C run-

time library functions that require

character string arguments. However, Windows duplicates some of these. For example, here is a collection of string

functions defined in Windows that calculate string lengths, copy strings, concatenate strings, and compare strings:

ILength = lstrlen (pString) ;

pString = lstrcpy (pString1, pString2) ;

pString = lstrcpyn (pString1, pString2, iCount) ;

pString = lstrcat (pString1, pString2) ;

iComp = lstrcmp (pString1, pString2) ;

iComp = lstrcmpi (pString1, pString2) ;

These work much the same as their C library equivalents. They accept wide-character strings if the UNICODE identifier is

defined and regular strings if not. The wide-character version of the lstrlenW function is implemented in Windows 98.

Using printf in Windows

Programmers who have a background in character-mode, command-

line C programming are often excessively fond of the

printf

function. It's no surprise that printf shows up in the Kernighan and Ritchie "hello, world" program even though a

simpler alternative (such as puts) could have been used. Everyone knows that enhancements to "hello, world" will need

the formatted text output of printf eventually, so we might as well start using it at the outset.

The bad news is that you can't use printf in a Windows program. Although you can use most of the C run-time library in

Windows programs—

indeed, many programmers prefer to use the C memory management and file I/O functions over the

Windows equivalents—Windows has no concept of standard input and standard output. You can use fprintf in a Windows

program, but not printf.

The good news is that you can still display text by using sprintf and other functions in the sprintf family. These functions

work just like printf, except that they write the formatted output to a character string buffer that you provide as the

function's first argument. You can then do what you want with this character string (such as pass it to MessageBox).

If you've never had occasion to use sprintf (as I didn't when I first began programming for Windows), here's a brief

rundown. Recall that the printf function is declared like so:

int printf (const char * szFormat, ...) ;

The first argument is a formatting string that is followed by a variable number of arguments of various types

corresponding to the codes in the formatting string.

The sprintf function is defined like this:

int sprintf (char * szBuffer, const char * szFormat, ...) ;

The first argument is a character buffer; this is followed by the formatting string. Rather than writing the formatted result

in standard output, sprintf stores it in szBuffer. The function returns the length of the string. In character-mode

programming,

printf ("The sum of %i and %i is %i", 5, 3, 5+3) ;

is functionally equivalent to

char szBuffer [100] ;

sprintf (szBuffer, "The sum of %i and %i is %i", 5, 3, 5+3) ;

puts (szBuffer) ;

In Windows, you can use MessageBox rather than puts to display the results.

Almost everyone has experience with printf

going awry and possibly crashing a program when the formatting string is not

properly in sync with the variables to be formatted. With sprintf, you still have to worry about that and you also have a

new worry: the character buffer you define must be large enough for the result. A Microsoft-specific function named

_snprintf

solves this problem by introducing another argument that indicates the size of the buffer in characters.

A variation of sprintf is vsprintf, which has only three arguments. The vsprintf function is used to implement a function of

your own that must perform printf-like formatting of a variable number of arguments. The first two arguments to vsprintf

are the same as sprintf: the character buffer for storing the result and the formatting string. The third argument is a

pointer to an array of arguments to be formatted. In practice, this pointer actually references variables that have been

stored on the stack in preparation for a function call. The va_list, va_start, and va_end macros (defined in STDARG.H)

help in working with this stack pointer. The SCRNSIZE program at the end of this chapter demonstrates how to use these

macros. The sprintf function can be written in terms of vsprintf like so:

int sprintf (char * szBuffer, const char * szFormat, ...)

{

int iReturn ;

va_list pArgs ;

va_start (pArgs, szFormat) ;

iReturn = vsprintf (szBuffer, szFormat, pArgs) ;

va_end (pArgs) ;

return iReturn ;

}

The va_start macro sets pArg to point to the variable on the stack right above the szFormat argument on the stack.

So many early Windows programs used sprintf and vsprintf that Microsoft eventually added two similar functions to the

Windows API. The Windows wsprintf and wvsprintf functions are functionally equivalent to sprintf and vsprintf, except

that they don't handle floating-point formatting.

Of course, with the introduction of wide characters, the sprintf functions blossomed in number, creating a thoroughly

confusing jumble of function names. Here's a chart that shows all the sprintf functions supported by Microsoft's C run-

time library and by Windows.

In the wide-character versions of the sprintf functions, the string buffer is defined as a wide-character string. In the wide-

character versions of all these functions, the formatting string must be a wide-

character string. However, it's up to you to

make sure that any other strings you pass to these functions are also composed of wide characters.

A Formatting Message Box

The SCRNSIZE program shown in Figure 2-3 shows how to implement a MessageBoxPrintf function that takes a variable

number of arguments and formats them like printf.

Figure 2-3. The SCRNSIZE program.

ASCII Wide-Character Generic

Variable Number

of Arguments

Standard Version sprintf swprintf _stprintf

Max-Length Version _snprintf _snwprintf _sntprintf

Windows Version wsprintfA wsprintfW wsprintf

Pointer to Array

of Arguments

Standard Version vsprintf vswprintf _vstprintf

Max-Length Version _vsnprintf _vsnwprintf _vsntprintf

Windows Version wvsprintfA wvsprintfW wvsprintf

SCRNSIZE.C

/*-----------------------------------------------------

SCRNSIZE.C -- Displays screen size in a message box

-----------------------------------------------------*/

The program displays the width and height of the video display in pixels by using information obtained from the

GetSystemMetrics function. GetSystemMetrics is a useful function for obtaining information about the sizes of various

objects in Windows. Indeed, in Chapter 4 I'll use the GetSystemMetrics function to show you how to display and scroll

multiple lines of text in a Windows window.

Internationalization and This Book

Preparing your Windows programs for an international market involves more than using Unicode. Internationalization is

beyond the scope of this book but is covered extensively in Developing International Software for Windows 95 and

Windows NT by Nadine Kano (Microsoft Press, 1995).

This book will restrict itself to showing programs that can be compiled either with or without the UNICODE identifier

defined. This involves using TCHAR for all character and string definitions, using the TEXT macro for string literals, and

taking care not to confuse bytes and characters. For example, notice the _vsntprintf call in SCRNSIZE. The second

argument is the size of the buffer in characters. Typically, you'd use sizeof (szBuffer). But if the buffer has wide

characters, that's not the size of the buffer in characters but the size of the buffer in bytes. You must divide it by sizeof

(TCHAR).

Normally in the Visual C++ Developer Studio, you can compile a program in two different configurations: Debug and

Release. For convenience, for the sample programs in this book, I have modified the Debug configuration so that the

UNICODE identifier is defined. In those programs that use C run-time functions that require string arguments, the

_UNICODE identifier is also defined in the Debug configuration. (To see where this is done, choose Settings from the

Project menu and click the C/C++ tab.) In this way, the programs can be easily recompiled and linked for testing.

All of the programs in this book—whether compiled for Unicode or not—run under Windows NT. With a few exceptions,

the Unicode-compiled programs in this book will not run under Windows 98 but the non-Unicode versions will. The

programs in this chapter and the first chapter are two of the few exceptions. MessageBoxW is one of the few wide-

character Windows functions supported under Windows 98. If you replace _vsntprintf in SCRNSIZE.C with the Windows

function wprintf (you'll also have to eliminate the second argument to the function), the Unicode version of SCRNSIZE.C

#include <windows.h>

#include <tchar.h>

#include <stdio.h>

int CDECL MessageBoxPrintf (TCHAR * szCaption, TCHAR * szFormat, ...)

{

TCHAR szBuffer [1024] ;

va_list pArgList ;

// The va_start macro (defined in STDARG.H) is usually equivalent to:

// pArgList = (char *) &szFormat + sizeof (szFormat) ;

va_start (pArgList, szFormat) ;

// The last argument to wvsprintf points to the arguments

_vsntprintf (szBuffer, sizeof (szBuffer) / sizeof (TCHAR),

szFormat, pArgList) ;

// The va_end macro just zeroes out pArgList for no good reason

va_end (pArgList) ;

return MessageBox (NULL, szBuffer, szCaption, 0) ;

}

int WINAPI WinMain (HINSTANCE hInstance, HINSTANCE hPrevInstance,

PSTR szCmdLine, int iCmdShow)

{

int cxScreen, cyScreen ;

cxScreen = GetSystemMetrics (SM_CXSCREEN) ;

cyScreen = GetSystemMetrics (SM_CYSCREEN) ;

MessageBoxPrintf (TEXT ("ScrnSize"),

TEXT ("The screen is %i pixels wide by %i pixels high."),

cxScreen, cyScreen) ;

return 0 ;

}

will not run under Windows 98 because Windows 98 does not implement

wprintfW

As we'll see later in this book (particularly in Chapter 6, which covers using the keyboard), it is not easy writing a

Windows program that can handle the double-

byte character sets of the Far Eastern versions of Windows. This book does

not show you how, and for that reason some of the non-Unicode versions of the programs in this book do not run

properly under the Far Eastern versions of Windows. This is one reason why Unicode is so important to the future of

programming. Unicode allows programs to more easily cross national borders.

Chapter 3

Windows and Messages

In the first two chapters, the sample programs used the MessageBox function to deliver text output to the user. The

MessageBox function creates a "window." In Windows, the word "window" has a precise meaning. A window is a

rectangular area on the screen that receives user input and displays output in the form of text and graphics.

The MessageBox function creates a window, but it is a special-purpose window of limited flexibility. The message box

window has a title bar with a close button, an optional icon, one or more lines of text, and up to four buttons. However,

the icons and buttons must be chosen from a small collection that Windows provides for you.

The MessageBox function is certainly useful, but we're not going to get very far with it. We can't display graphics in a

message box, and we can't add a menu to a message box. For that we need to create our own windows, and now is the

time.

A Window of One's Own

Creating a window is as easy as calling the CreateWindow function.

Well, not really. Although the function to create a window is indeed named CreateWindow and you can find

documentation for this function at /Platform SDK/User Interface Services/Windowing/Windows/Window

Reference/Window Functions, you'll discover that the first argument to CreateWindow

is something called a "window class

name" and that a window class is connected to something called a "window procedure." Perhaps before we try calling

CreateWindow, a little background information might prove helpful.

An Architectural Overview

When programming for Windows, you're really engaged in a type of object-

oriented programming. This is most evident in

the object you'll be working with most in Windows, the object that gives Windows its name, the object that will soon

seem to take on anthropomorphic characteristics, the object that might even show up in your dreams: the object known

as the "window."

The most obvious windows adorning your desktop are application windows. These windows contain a title bar that shows

the program's name, a menu, and perhaps a toolbar and a scroll bar. Another type of window is the dialog box, which

may or may not have a title bar.

Less obvious are the various push buttons, radio buttons, check boxes, list boxes, scroll bars, and text-entry fields that

adorn the surfaces of dialog boxes. Each of these little visual objects is a window. More specifically, these are called "child

windows" or "control windows" or "child window controls."

The user sees these windows as objects on the screen and interacts directly with them using the keyboard or the mouse.

Interestingly enough, the programmer's perspective is analogous to the user's perspective. The window receives the user

input in the form of "messages" to the window. A window also uses messages to communicate with other windows.

Getting a good feel for messages is an important part of learning how to write programs for Windows.

Here's an example of Windows messages: As you know, most Windows programs have sizeable application windows.

That is, you can grab the window's border with the mouse and change the window's size. Often the program will respond

to this change in size by altering the contents of its window. You might guess (and you would be correct) that Windows

itself rather than the application is handling all the messy code involved with letting the user resize the window. Yet the

application "knows" that the window has been resized because it can change the format of what it displays.

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—

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. The use of a window class allows multiple windows to be based on the same

window class and hence use the same window procedure. For example, all buttons in all Windows programs are based on

the same window class. This window class is associated with a window procedure located in a Windows dynamic-link

library that processes messages to all the button windows.

In object-oriented programming, an object is a combination of code and data. A window is an object. The code is the

window procedure. The data is information retained by the window procedure and information retained by Windows for

each window and window class that exists in the system.

A window procedure processes messages to the window. Very often these messages inform a window of user input from

the keyboard or the mouse. For example, this is how a push-button window knows that it's being "clicked." Other

messages tell a window when it is being resized or when the surface of the window needs to be redrawn.

When a Windows program begins execution, Windows creates a "message queue" for the program. This message queue

stores messages to all the windows a program might create. A Windows application includes a short chunk of code called

the "message loop" to retrieve these messages from the queue and dispatch them to the appropriate window procedure.

Other messages are sent directly to the window procedure without being placed in the message queue.

If your eyes are beginning to glaze over with this excessively abstract description of the Windows architecture, maybe it

will help to see how the window, the window class, the window procedure, the message queue, the message loop, and

the window messages all fit together in the context of a real program.

The HELLOWIN Program

Creating a window first requires registering a window class, and that requires a window procedure to process messages

to the window. This involves a bit of overhead that appears in almost every Windows program. The HELLOWIN program,

shown in Figure 3-1, is a simple program showing mostly that overhead.

Figure 3-1. The HELLOWIN program.

HELLOWIN.C

/*------------------------------------------------------------

HELLOWIN.C -- Displays "Hello, Windows 98!" in client area

------------------------------------------------------------*/

#include <windows.h>

LRESULT CALLBACK WndProc (HWND, UINT, WPARAM, LPARAM) ;

int WINAPI WinMain (HINSTANCE hInstance, HINSTANCE hPrevInstance,

PSTR szCmdLine, int iCmdShow)

{

static TCHAR szAppName[] = TEXT ("HelloWin") ;

HWND hwnd ;

MSG msg ;

WNDCLASS wndclass ;

wndclass.style = CS_HREDRAW | CS_VREDRAW ;

wndclass.lpfnWndProc = WndProc ;

wndclass.cbClsExtra = 0 ;

wndclass.cbWndExtra = 0 ;

wndclass.hInstance = hInstance ;

wndclass.hIcon = LoadIcon (NULL, IDI_APPLICATION) ;

wndclass.hCursor = LoadCursor (NULL, IDC_ARROW) ;

wndclass.hbrBackground = (HBRUSH) GetStockObject (WHITE_BRUSH) ;

wndclass.lpszMenuName = NULL ;

wndclass.lpszClassName = szAppName ;

if (!RegisterClass (&wndclass))

{

MessageBox (NULL, TEXT ("This program requires Windows NT!"),

szAppName, MB_ICONERROR) ;

return 0 ;

}

hwnd = CreateWindow (szAppName, // window class name

TEXT ("The Hello Program"), // window caption

WS_OVERLAPPEDWINDOW, // window style

CW_USEDEFAULT, // initial x position

剩余1010页未读，继续阅读

shu27s

粉丝: 4
资源: 7

使用C语言和Windows API编写程序指南

Microsoft Visual C++ 2005 SP1 Redistributable Package

Programming Windows 5th(unlock、未加密)

《Programing Windows 5th》

windows via c/c++(5th) 中文版

learning python 5th

c++ primer 5th 英文高清版

analysis with an introduction to proof, 5th

introduction to linear algebra 5th习题解答

modern control engineering 5th答案

computer networks - 5th edition

最新资源