Windows core programming Chapter 3 Kernel Object details

I have been admiring this book for a long time, but I have never understood it before... Now I feel a little basic. Looking back, I feel a little confused ....

For more information about kernel objects, see Chapter 3.

Getcurrentprocess returns a pseudo handle (familiar with getcurrentdirectory and suffering a loss. The path of the process working directory is not the same as the path of the process's image file EXE, especially when it is setProgramThe system directory is the default working directory for processes after the startup and restart. Please note that getmodulefilename should be used ...), I personally tested it. In fact, the handle obtained every time is 0 xfffffff, which is specially provided for this process, we know that there is a big difference between a kernel object and a user object or a GDI object: The kernel object is closely related to a process. For example, a window belongs to another process, as long as we get the handle of this window, we can operate on this window (this window is different from the kernel object, so we can perform this conveniently ), but if an object is the kernel object of another process, you get the handle of the kernel object in the local process, and then operate on it, it is wrong, the reason is that the kernel object is closely related to the process, and other objects are exceptions. Of course, Microsoft is doing this for obvious purpose, which can provide the robustness of the operating system, indeed.

Of course, if you only implement operations in the current process, the pseudo handle obtained by getcurrentprocess is enough. What if we implement inter-process communication? At this time, the fake handle cannot meet the requirements. The book says a function duplicatehandle, which is competent and he can convert the fake handle into a true one.

There are no examples in the book.CodeSo I was a little confused at the beginning, and I didn't understand how to switch at the beginning. So I read this chapter three times .....

 

Test:

# Include <windows. h> <br/> # include <stdio. h> <br/> void main () <br/>{< br/> handle hprocess = getcurrentprocess (); <br/> handle htargethandle; <br/> duplicatehandle (hprocess, & htargethandle, 0, false, duplicate_same_access); <br/> printf ("% x/N", htargethandle ); <br/> closehandle (htargethandle); <br/> system ("pause"); </P> <p>}

Do not close the pseudo handle, but msdn says:
The pseudo handle need not be closed when it is no longer needed. calling the closehandle function with a pseudo handle has no effect. if the pseudo handle is duplicated by duplicatehandle, the duplicate handle must be closed.
Therefore, you must add
Closehandle (htargethandle );

This should be the case. If not, throw bricks.

In fact, this method uses duplicatehandle, and it feels a bit ruined by this API. In fact, this function is very powerful, with letters, and copies the handle, we can copy the handle of a kernel object (such as the product called by a file Kernel Object createfile ("the complete set of empty objects") to the system process on XP, the process ID is 4 or 8, and it seems to be 4 on XP, so we can achieve a very low-key effect: This file cannot be moved, modified, renamed, delete and so on, but it protects the security of these files. Of course, you must have certain permissions.

The road is long ...... Bricks are endless.