Windows core programming Reading Notes (1)

I sorted out judge's needs and existing bugs late last night and found that I was getting deeper and deeper in the quagmire of Judge. Many problems were not solved by a reference-based reading, therefore, we decided to carefully read "Windows core programming" to gain a deep understanding of Windows-related programming knowledge.

I. 3.2.2 disable kernel objects

If you pass an invalid handle to closehandle, either of the two situations will occur. If the process runs normally, closehandle returns false, while getlasterror returns error_invalid_handle. If the process is troubleshooting an error, the system will notify the debugging program to exclude it.

This description may explain a bug in judge that only appears in debug mode.

Ii. 9.1 waiting Functions

Below is the function wa I t f o r m u l t I p L e o B j e c t s and Wa I t f o r s I n g l e o B j E c t functions are very similar, the difference is that it allows the calling thread to view the notified status of several kernel objects at the same time:


DWORD waitformultipleobjects (DWORD dwcount,
Const handle * phobjects,
Bool fwaitall,
DWORD dwmilliseconds );
The d w c o u n t parameter is used to specify the number of kernel objects to be viewed by the function. This value must be 1 and m a x I m u m _ wa I t _ o B j e c T S (defined as 6 4 in the WI n d o W S header file). The p H o B j e c T S parameter is a pointer to the array of the kernel object handle.
The wa I t f o r m u l t I p L e o B j e c T S function can be used in two different ways. One way is to let the thread enter the waiting state until any of the specified kernel objects changes to the notified State. Another way is to let the thread enter the waiting state until all specified kernel objects change to the notified State. The F wa I tal l parameter tells the function how you want it to be used. If t r u e is passed for this parameter, the function will not allow the calling thread to run until all objects are notified.

The function of the d w m I l I s e c o n d S parameter and Its Role in wa I t f o r s I n g l e o B j e c t identical. If the specified time is reached while waiting, the function will return at any time. Similarly, I n f I n I t e is usually passed for this parameter, but be careful when writing the code to avoid deadlocks.

The Return Value of the Wa I t f o r m u l t I p L e o B j e c T S function tells the calling thread why it is rescheduled. The possible return values are wa I t _ fa I l e d and wa I t _ t I m e o u t. The functions of these two values are clear. If t r u e is passed for the F wa I tal l parameter and all objects are in the notified State, the returned value is wa I t _ o B j e c T _ 0. If f wa I t a l passes fa L S E, this function returns once any object changes to the notified State. In this case, you may want to know which object has changed to the notified State. The returned values are wa I t _ o B j e c T _ 0 and (wa I t _ o B j e c T _ 0 + D W C o u n t-1) between. In other words, if the returned value is not wa I t _ t I m e o u t, it is not wa I t _ fa I l e d, then we should subtract wa I t _ o B j e c T _ 0 from the return value. The resulting number is the index in the handle array passed to wa I t f o r m u l t I p L e o B j e c t s as the second parameter. This index indicates which object has changed to the notified status. The following is some sample code to illustrate this situation:


Handle H [3];
H [0] = hprocess1;
H [1] = hprocess2;
H [2] = hprocess3;
Dword dw = waitformultipleobjects (3, H, false, 5000 );
Switch (DW)
{
Case wait_failed:
// Bad call to function (invalid handle ?)
Break;

Case wait_timeout:
// None of the objects became signaled within 5000 milliseconds.
Break;

Case wait_object_0 + 0:
// The process identified by H [0] (hprocess1) terminated.
Break;

Case wait_object_0 + 1:
// The process identified by H [1] (hprocess2) terminated.
Break;

Case wait_object_0 + 2:
// The process identified by H [2] (hprocess3) terminated.
Break;
}

If f wa I t a l parameter is passed, wa I t f o r m u l t I p L e o B j e c t s scans the handle array from index 0, at the same time, the first object that has been notified is in the wait state for termination. This may produce some results that you don't want. For example, by passing three process handles to the function, your thread will wait for the three sub-processes to terminate. If the process with the index 0 in the array stops running, wa I t f o r m u l t I p L e o B j e c t s will return. At this time, the thread can do anything it needs, and then loop repeatedly, waiting for another process to stop running. If the thread passes the same three handles, the function immediately returns wa I t _ o B j e c T _ 0 again. The Code cannot run correctly unless you delete the handle that has received the notification. Use waitformultipleobjects to rewrite my judge so that when the thread is aborted, the thread can be aborted by itself, rather than killed by other threads. This can solve another bug.

Iii. 17.1.2 share static data between multiple instances of executable files or DLL

I can create a section called "s h a r e d", which contains a single L O N G value, as shown below:

# Pragma data_seg ("shared ")
Long g_linstancecount = 0;
# Pragma data_seg ()
When the compiler compiles this code, it creates a new section called s h a r e d, and put all the initialized (I n I t I a L Z e d) data variables it sees after the compilation instructions into this new section. In the above example, the variable is placed in section s h a r e d. The # pragma dataseg () line after the variable tells the compiler to stop putting initialized variables into the s h a r e d Section and start to put them back to the default data section. Remember that the compiler only puts initialized variables in the new section. For example, if I delete the initialization variable from the previous code segment (as shown in the following code), the compiler will put the variable in a section other than section S H a r e d.

# Pragma data_seg ("shared ")
Long g_linstancecount;
# Pragma data_seg ()
Microsoft's Visual C ++ compiler provides an A l o c a t e specifier, allowing you to put uninitialized data into any section you want. See the following code:

// Create shared section & have compiler place initialized data in it.
# Pragma data_seg ("shared ")

// Initialized, in shared Section
Int A = 0;

// Uninitialized, not in shared Section
Int B;

// Have compiler stop placing initialized data in shared section.
# Pragma data_seg ()

// Initialized, in shared Section
_ Declspec (allocate ("shared") int C = 0;

// Uninitialized, in shared Section
_ Declspec (allocate ("shared") int D;

// Initialized, not in shared Section
Int e = 0;

// Uninitialized, not in shared Section
Int F;
The comment above clearly specifies the section in which the specified variable will be placed. To make the rules declared by a l o c a t e take effect correctly, you must first create a section. If you delete the first line # pragma data_seg in the preceding code, the above Code will not be compiled.
The most common reason for putting variables in their own sections is perhaps to share these variables among multiple images in the. e x e or d l files. According to the default settings, each image in the. e x e or d l file has its own set of variables. However, you can combine any variables that you want to share among all images of this module into its own section. When grouping variables, the system does not create a new instance for each image of the. e x e or d l file.

Just telling the compiler to put some variables into their own sections is not enough to share these variables. You must also tell the linked program that the variables in a section need to be shared. To perform this operation, you can use the/s e c t I o n switch on the command line of the linked program:


/Section: name, attributes
After the colon, add the name of the section you want to change its attributes. In our example, we want to change the attributes of section s h a r e d. Therefore, create the following link PROGRAM switch:

/Section: shared, RWS
After the comma, we set the required attributes. R represents r e a D, W represents w e I t E, E represents e x e c u t e, and s represents S H a r e d. The preceding switch indicates that data in section s h a r e d can be read, written, and shared. If you want to change the attributes of multiple sections, you must set the/s e c t I o n switch multiple times, that is, you need to set a/s e c t I o n switch for each section of the attribute to be changed.
You can also use the following syntax to embed the link PROGRAM switch into your source code:


# Pragma comment (linker, "/section: shared, RWS ")
This line of code tells the compiler to embed the above string into the section named ". d r e c t v e. When the linked Program. when o B j modules are combined, each link program needs to be viewed. O ". d r e c t v e "section, and require all strings to be passed to the link program as command line parameters. I always use this method because it is very convenient. If you port the source code file to a new project, you do not have to remember to set the link PROGRAM switch in the Project Settings dialog box of Visual C ++.
Although you can create a shared section, m I c r o s o f t does not encourage you to use the shared section for two reasons. First, using this method to share memory may damage the system security. Second, shared variables mean that errors in one application may affect the operation of another application because they cannot prevent an application from randomly writing data into a data block.

This method can be used to share memory data between two processes.