C # call Win32 API Learning Summary

Calling the Win32 API from the. NET Platform

The Win32 API can directly control the core of Microsoft Windows because the API (application programming Interface) is the interface that Microsoft left us to control windows directly.

I. Basic knowledge

The Win32 API is the C language (note, not the C + + language, although C is a subset of the C + + language) function set.

1. Where is the Win32 API function placed?

The Win32 API function is the core of windows, such as the forms, buttons, dialogs, and so on that we see, all relying on the Win32 function to "draw" on the screen, because these controls (sometimes called components) are used by the user to interact with Windows, so controlling the Win32 of those controls The API functions are called "User Interface" functions (Interface Win32 API), or UI functions, and there are functions that are not used for interaction, such as managing processes running on the current system, monitoring the state of hardware systems, etc... These functions have only one set, but can be called by all Windows programs (as long as the permissions of the program are high enough), in short, the API is shared by the program. To achieve the purpose of sharing a set of APIs for all programs, Windows uses a "dynamic link library" approach. It is called a "dynamic link library" because such libraries are called "hop-on-take" rather than "take it with no need" like a static-link library.

WIN32 API functions are placed in the core library files of the Windows system, which are stored as. dll files on the hard disk. The DLL files that we commonly use are user32.dll and Kernel32.dll two files.

These DLL files are written in C, and the source code is compiled by the C language compiler and stored in these DLL files as binary executable code. In order for the program to use these functions, Microsoft releases the SDK for each new operating system, the latest is the Win2003 SP1 SDK, which is said to be released immediately, and has separated the UI APIs from the core library to improve the stability of the system. There are some C-language header files (. h files) in the SDK, which describe what Win32 API functions are in the core DLL files, and when writing the program, put these. h files into your program, and you can use these Win32 API.

The C # language also uses DLL dynamic-link libraries, but these DLLs are. NET version, with "self-descriptive", that is, what functions in their belly have been written in their own metadata, no need to attach an. h file to explain. Now, we have found the key point of the problem: how to use it. The C # language on the Win32 platform to invoke DLL files on the. NET platform. The answer is simple: Use the DllImport feature.

Two. Small trial

Using System;

Using System.Runtime.InteropServices;

Class Program

{

[DllImport ("User32.dll")]

public static extern int MessageBox (int h, string m, string c, int type);

static int Main ()

{

MessageBox (0, "Hello Win32 API", "Big Uncle", 4);

Console.ReadLine ();

return 0;

}

}

1. To use the DllImport feature (which is also a class), it is necessary to use this sentence using System.Runtime.InteropServices;

, import "Run-time interactive services". Oh ~ ~ ~ is the interactive service at runtime not a "dynamic link"? Thanks microsoft!

2. Then we can create an instance of the DllImport class and bind the instance to the function we want to use. This kind of "attribute class" is very strange--do not use MyClass MC = new MyClass () in this form, but instead use the form of [attribute class (parameter list)]; attribute classes cannot exist independently and must be used to modify other targets (in this case, a function that is later modified). Different attributes can be used to modify classes, functions, variables, and so on, and the attribute class instances are compiled without executable code, but are put into metadata for retrieval. In short, you remember the characteristics of the class is very strange, want to know more on MSDN, too lazy to check on the first so remember-do not understand inertia does not affect you learn to ride a bicycle. [DllImport ("User32.dll")] is that we are going to use the Win32 API function in User32.dll this file. Here's the question: How do I know which DLL file that so many API functions are in? This you can find on MSDN, location is Root->win32 and COM development->development guides->windows api->windows api-> Windows API reference->functions by Category. Open this page, you will see a lot of API classification, the API is all here. Open a category, such as dialog Box, in the Functions section, you will see a lot of specific functions, which have the MessageBox function used above, click to enter. You will open a detailed explanation and specific usage of the MessageBox. At the bottom of this page, you can see a small table with a "Minimum DLL Version user32.dll" That means the function is in user32.dll.

3. The next step is our function. There are so many points to calling the Win32 function in C #. First: The name should be exactly the same as the Win32 API. Second: The function must be declared as public static extern type in addition to the corresponding DllImport class modification. Third: The function's return value and parameter type are exactly the same as the Win32 API!

Taking a table from MSDN is a table of commonly used WIN32 data types and. NET Platform data types:

Figure 2 Non-pointer Data Types

WIN32 Types Specification

CLR Type

Char, INT8, SBYTE, Char 8-bit signed integer

System.SByte

short, short int, INT16, short 16-bit signed integer

System.Int16

int, long, long int, INT32, LONG32, BOOL, int 32-bit signed integer System.Int32

__int64, INT64, Longlong 64-bit signed integer

System.Int64

unsigned char, UINT8, UCHAR, BYTE 8-bit unsigned integer

System.Byte

Unsigned short, UINT16, USHORT, WORD, ATOM, WCHAR, __wchar_t

16-bit unsigned integer system.uint16

unsigned, unsigned int, UINT32, ULONG32, DWORD32, ULONG, DWORD, UINT

32-bit unsigned integer system.uint32

Unsigned __int64, UINT64, Dwordlong, ulonglong 64-bit unsigned integer system.uint64

float, float single-precision floating point

System.Single

Double, long double, double double-precision floating point

System.Double

In Win32 This type is an integer with a specially assigned meaning; In contrast, the CLR provides a specific type devoted to this meaning.

With these things, we can turn a WIN32 API function into a C # function. Also take the MessageBox function as an example (see the function table just given), its WIN32 prototype is as follows:

int MessageBox (HWND hwnd, LPCTSTR Lptext, LPCTSTR lpcaption, UINT utype);

Function name: MessageBox will remain unchanged.

return value: Int will remain unchanged (both Win32 and C#,int are 32-bit integers)

Parameter table: h means handle, generally HANDLD is pointer type, WIN32 platform pointer type is 32 bits to store, so in C # exactly corresponds to an int integer. However, since it is a pointer, there is no positive or negative points, the 32-bit should be used to save the value-this way, with a uint (unsigned 32-bit integer) to correspond to the Win32 h type more reasonable. However, as a reminder, int is supported by both C # and. NET CLR, and UINT is supported only by C # and not by the. NET CLR, so this example honestly uses the int type.

As for LPCTSTR is the abbreviation for long Pointer to Constant string, which is plainly--the string. So, with

http://m.blog.csdn.net/article/details?id=50930221

C # call Win32 API Learning Summary