The pointer is actually a kind of "handle", but because the pointer has a more special meaning at the same time - it actually corresponds to an address in the memory - so the pointer is usually not called a "handle", but the pointer also has the function of deriving a large amount of data from a 32-bit value, and has the same function as the "handle".
There are many kernel objects in the Windows system (the objects here are not exactly equivalent to the "objects" in the term "object-oriented programming", although they are really similar in essence), such as opened files, created threads, and program windows. These important objects are certainly not 4 bytes or 8 bytes enough to fully describe, they have a large number of attributes. In order to save the state of such an "object", it often requires hundreds or even thousands of bytes of memory space, so how to transfer these data between programs or between sub-processes (functions) inside the program? Dragging these hundreds of thousands of byte copies is obviously a waste of efficiency. If the first addresses of these objects are passed, there are two disadvantages:
1) The kernel object itself is exposed, so that the program (rather than the operating system kernel) can also arbitrarily modify the internal state of the object, which is obviously not allowed by the operating system kernel;
2) The operating system has the responsibility to organize the memory regularly. If some memory is cleaned once and the objects are moved away, an error will occur.
Therefore, the Windows operating system adopts further indirection: set up a table in the address space of the process, which stores some numbers and an address corresponding to this number, and uses that address to refer to the actual object. There is no regular relationship between this number and that address in terms of value, it is just a mapping. In the Windows system, this number is called "handle".
Handle is widely used in Windows. Unless otherwise specified, the Handle mentioned below will be limited to the context of processes and threads.
Handle
Handle itself is a 32-bit unsigned integer, which is used to represent a kernel object. It does not point to the actual kernel object, and it is never possible for a user-mode program to obtain the actual address of a kernel object (in general). So what's the point of Handle? It is actually used as an index to look up the actual address of the corresponding kernel object in a table. So where is this table? Each process has such a table, called the handle table. The first entry in the table is the handle to the process itself, which is why you call GetCurrentProcess() always returns 0×7FFFFFFF.
Simply put, Handle is an integer value used to "indirectly" represent a kernel object. You can use handle in the program to represent the kernel object you want to operate. The kernel objects here include: event (Event), thread, process, Mutex, etc. Our most common is the file handle (file handle).
Another thing to note is that Handle is only meaningful within the process it belongs to. It doesn't make sense to pass a handle owned by one process to another process. If you have to do this, you need to use DuplicateHandle().