Windows Programming

The answer is that Windows offers a set of functions that manipulate these structures in well-defined ways. These kernel objects are always accessible via these functions. When you call a function that creates a kernel object, the function returns a handle that identifies the object.

Kernel object data structures are accessible only by the kernel

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 objects.

Whenever you call a function that accepts a kernel object handle as an argument, you pass the value returned by one of the Create* functions. Internally, the function looks in your process’s handle table to get the address of the kernel object you want to manipulate and then manipulates the object’s data structure in a well-defined fashion.

Well, yes and no. It is possible for a process to leak resources (such as kernel objects) while the process runs. However, when the process terminates, the operating system ensures that any and all resources used by the process are freed—this is guaranteed. For kernel objects, the system performs the following actions: When your process terminates, the system automatically scans the process’s handle table. If the table has any valid entries (objects that you didn’t close before terminating), the system closes these object handles for you. If the usage count of any of these objects goes to zero, the kernel destroys the object.

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. Some members (security descriptor, usage count, and so on) are the same across all object types, but most are specific to a particular object type. For example, a process object has a process ID, a base priority, and an exit code, whereas a file object has a byte offset, a sharing mode, and an open mode.

HANDLE CreateThread(…),HANDLE CreateFile(..),HANDLE CreateFileMapping(..)HANDLE CreateSemaphore(..)etcAll functions that create kernel objects return process-relative handles that can be used successfully by any and all threads that are running in the same process.

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.

If your process calls a function that creates a kernel object and then your process terminates, the kernel object is not necessarily destroyed. Under most circumstances, the object will be destroyed; but if another process is using the kernel object your process created, the kernel knows not to destroy the object until the other process has stopped using it

An event is in signaled state means that it has the capacity to release the threads waiting for this event to be signaled. An event is in non signaled state means that it will not release any thread that is waiting for this particular event.example in our project: when user clicks the image application icon double simultaneously. Two image application windows were created. so PAIG created an event and set it to non-signaled state. Then the image application will reset the event to signaled state, after this all the threads are released.

Synchronization object s are use to co-ordinate the execution of multiple threads. Which kernel objects are use for Thread Synchronization on different processes? - Event, Mutex, Semaphore

Takes an entry in one process’s handle table and makes a copy of the entry into another process’s handle table

Method available for sharing kernel objects across process boundaries is to name the objects. Below are the kernel named objects:

1) mutex,

2) Events,

3) semaphore,

4) waitableTimers,

5)file mapping,

6)job object.

There are APIs to create these objects with last parameter as the object name.

It means that the handle value that identifies a kernel object is identical in both the parent and the child processes.

The most important reason was robustness. If kernel object handles were system-wide values, one process could easily obtain the handle to an object that another process was using and wreak havoc on that process. Another reason for process-relative handles is security. Kernel objects are protected with security, and a process must request permission to manipulate an object before attempting to manipulate it. The creator of the object can prevent an unauthorized user from touching the object simply by denying access to it

This function first checks the calling process’s handle table to ensure that the index (handle) passed to it identifies an object that the process does in fact have access to. If the index is valid, the system gets the address of the kernel object’s data structure and decrements the usage count member in the structure; if the count is zero, the kernel destroys the kernel object from memory.

Handle value is actually the index into the process’s handle table that identifies where the kernel object’s information is stored.

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. When a process first initializes, its handle table is empty. Then when a thread in the process calls a function that creates a kernel object, such as CreateFileMapping , the kernel allocates a block of memory for the object and initializes it; the kernel then scans the process’s handle table for an empty entry

Kernel objects are owned by the kernel, not by a process