Kernel Objects Vs GDI objects
kernel objects :
1.several types of kernel objects, such as access token objects, event objects, file objects, file-mapping objects, I/O completion port objects, job objects, mailslot objects, mutex objects, pipe objects, process objects, semaphore objects, thread objects, and waitable timer
2.Each kernel object is simply a memory block allocated by the kernel and is accessible only by the kernel. This memory block is a data structure whose members maintain information about the object.
3.Kernel objects are owned by the kernel, not by a process.
4.kernel object can outlive the process that created it.
5.The kernel knows how many processes are using a particular kernel object because each object contains a usage count.
6.usage count is one of the data members common to all kernel object types. When an object is first created, its usage count is set to 1. Then when another process gains access to an existing kernel object, the usage count is incremented. When a process terminates, the kernel automatically decrements the usage count for all the kernel objects the process still has open. If the object's usage count goes to 0, the kernel destroys the object. This ensures that no kernel object will remain in the system if no processes are referencing the object.
7.Kernel objects can be protected with a security descriptor.
8.A security descriptor describes who created the object, who can gain access to or use the object, and who is denied access to the object. Security descriptors are usually used when writing server applications; you can ignore this feature of kernel objects if you are writing client-side applications.
9.In addition to kernel objects, your application might use other types of objects, such as menus, windows, mouse cursors, brushes, and fonts. These objects are User objects or Graphics Device Interface (GDI) objects, not kernel objects.
10.How can we identify the object is kernel object or GDI Object ?
The easiest way to determine whether an object is a kernel object is to examine the function that creates the object. Almost all functions that create kernel objects have a parameter that allows you to specify security attribute information, as did the CreateFileMapping function shown earlier.
11.When a process is initialized, the system allocates a handle table for it. This handle table is used only for kernel objects, not for User objects or GDI objects. The details of how the handle table is structured and managed are undocumented.
12.The structure of a process's handle table
Index Pointer to Kernel Object Memory Block Access Mask (DWORD of Flag Bits) Flags (DWORD of Flag Bits)
1 0x???????? 0x???????? 0x????????
2 0x???????? 0x???????? 0x????????
… … …
13.When a process first initializes, its handle table is empty.
14. Difference between CMutex and CSemaphore ?
Shared memory with Single lock is called CMutex
Shared memory with multi lock is called CSemaphore.
15.Closing a Kernel Object - BOOL CloseHandle(HANDLE hobj);
16.Changing a Handle's Flags - call the SetHandleInformation function
1.several types of kernel objects, such as access token objects, event objects, file objects, file-mapping objects, I/O completion port objects, job objects, mailslot objects, mutex objects, pipe objects, process objects, semaphore objects, thread objects, and waitable timer
2.Each kernel object is simply a memory block allocated by the kernel and is accessible only by the kernel. This memory block is a data structure whose members maintain information about the object.
3.Kernel objects are owned by the kernel, not by a process.
4.kernel object can outlive the process that created it.
5.The kernel knows how many processes are using a particular kernel object because each object contains a usage count.
6.usage count is one of the data members common to all kernel object types. When an object is first created, its usage count is set to 1. Then when another process gains access to an existing kernel object, the usage count is incremented. When a process terminates, the kernel automatically decrements the usage count for all the kernel objects the process still has open. If the object's usage count goes to 0, the kernel destroys the object. This ensures that no kernel object will remain in the system if no processes are referencing the object.
7.Kernel objects can be protected with a security descriptor.
8.A security descriptor describes who created the object, who can gain access to or use the object, and who is denied access to the object. Security descriptors are usually used when writing server applications; you can ignore this feature of kernel objects if you are writing client-side applications.
9.In addition to kernel objects, your application might use other types of objects, such as menus, windows, mouse cursors, brushes, and fonts. These objects are User objects or Graphics Device Interface (GDI) objects, not kernel objects.
10.How can we identify the object is kernel object or GDI Object ?
The easiest way to determine whether an object is a kernel object is to examine the function that creates the object. Almost all functions that create kernel objects have a parameter that allows you to specify security attribute information, as did the CreateFileMapping function shown earlier.
11.When a process is initialized, the system allocates a handle table for it. This handle table is used only for kernel objects, not for User objects or GDI objects. The details of how the handle table is structured and managed are undocumented.
12.The structure of a process's handle table
Index Pointer to Kernel Object Memory Block Access Mask (DWORD of Flag Bits) Flags (DWORD of Flag Bits)
1 0x???????? 0x???????? 0x????????
2 0x???????? 0x???????? 0x????????
… … …
13.When a process first initializes, its handle table is empty.
14. Difference between CMutex and CSemaphore ?
Shared memory with Single lock is called CMutex
Shared memory with multi lock is called CSemaphore.
15.Closing a Kernel Object - BOOL CloseHandle(HANDLE hobj);
16.Changing a Handle's Flags - call the SetHandleInformation function
Labels: MFC
posted by Sundar at 12:25 AM
0 Comments:
Post a Comment
<< Home