What exactly is a handle in Windows?

I'll write a simplified version in C for you. Take note that fixed sized arrays aren't used anymore, they are dynamic. Also, resources are grouped into pools these days. Not a single resource pool. I also didn't bother checking for malloc() errors. (And in any case, Windows allocates the handle object inside the address space of the program and not in its own address space.) But the ideas are here. An important point here is just how easily the entire resource pool can be "reset" in a fashion that guarantees that all extent handles "owned" by some application will no longer function and can be detected instantly as invalid. It's also VERY EFFICIENT code.

The following code does have a problem that I didn't bother writing more code to deal with. Holes in the array are never used again in the code below. In practice, holes would be linked into linked list which would be exhausted before using the end of the array for new allocations. But that's a trivial detail and I felt getting the point across was more important. Another problem I avoid worrying about is null pointers being passed in. Easy to add.

You can see from the following that a handle may look very much like an address. But that isn't relevant. From your perspective it is a magic number.

#define MAXHANDLES  1000

typedef struct { unsigned int idx; } handleobj;

handleobj * handles[MAXHANDLES];

void * resources[MAXHANDLES];

unsigned int nhandles= 0;

void resethandles( void ) {

    unsigned int i;

    for ( i= 0; i < nhandles; ++i )

        free( handles[i] );

    nhandles= 0;

}

handleobj * createhandlefromresource( void * resource ) {

    handleobj * handle= (handleobj *) malloc( sizeof( handleobj ) );

    resources[ nhandles ]= resource;

    return handles[ handle->idx= nhandles++ ]= handle;

}

int validatehandle( handleobj * handle ) {

    return handle->idx < nhandles && handles[handle->idx] == handle;

}

void releasehandle( handleobj * handle ) {

    if ( handle->idx < nhandles && handles[handle->idx] == handle ) {

        handles[handle->idx]= 0;

        free( handle );

    }

}

void * getresourcefromhandle( handleobj * handle ) {

    if ( handle->idx < nhandles && handles[handle->idx] == handle )

        return resources[handle->idx];

    return 0;

}

The above technique is a "memory marking" method.

It is an ID (identifier) to some object. How it is handled internally is up to the system that creates and returns the handle. Why does a system use seemingly meaningless handles? because the object that a handle represents is very important and it needs to be kept safe. If it gives you the pointer, chances are that you will screw up the data (memory corruption or explicit hacking). Thus, it gives you an abstract value, it does not tell you what the value means, because if it does, chances are that you will try to hack it and might screw up the data it is pointing to. Such an abstract value (reference) is called a "handle". The handle can internally be used as a pointer or an index in to an array or pointer to a node of a linked list. Various versions of Windows is free to redefine how the handled is mapped internally because the application code has no idea about what the handle means. All it does is, get and send handles.

Handle is concept and thus can be implemented in any language.

In Assembly, you would create a library that has a function to create some sort or sorts of objects which then returns a handle. Other functions that operate on the objects, will accept a handle as an argument. You are free to use the handle the way you want, you are also free to change the implementation internally. All this will make sense only if you distributed the library as a binary and restricted the user of your library to use the handle blindly. If you tell the users what the handle means and how one can use to get to the object that it refers to without a warning that the implementation can change in the future so don't hack it, then you have screwed yourself (or your users) because some smarty will hack it and make his/her code vulnerable to breakage in the future (when you change the internal implementation).

A handle is an ID number for something. For example, when you open an existing file or create a new one, the operating system gives you a handle number which represents the file. When you read/write/seek the file, then you specify the handle number when you use a Windows function to access the file. It is much easier than having to specify a path and file name all the time, don't you think? There are other handles as well, such as memory block handles (when you allocate memory), various GUI-related handles, and more. The use of ID handles are important for both you and the internals of the operating system The operating system needs to keep track of GUI objects and other things that you create/access/allocate. For the programmer, he/she has an easy method of specifying which object (file, GUI, etcl) to specify when you wish to access/modify the object via Windows functions.

16 bit Windows use word-sized handles, Win32 use dword-sized handles, and Win64 uses dword-sized handles (Well, the handles are quad-words, but only the lower dword is used). Depending on the handle type, handles may be unique across the local computer. For example, when you create a window with a function like CreateWindowEx(), the handle you receive will be different from the window handles already given out on your computer. Most handles are closed with the CloseHandle() function, but there may be other specific functions for closing a handle, depending on the handle type.

One important thing to remember regarding the ExitProcess() function: The ExitProcess() function will automatically close any object handles that you've received during program execution. In Win9x and earlier Windows versions, you had to be careful with GUI objects in certain cases (e.g. GUI objects that are still selected into windows or memory DCs) because the Windows exit function would not be able to close those the handles --which resulted in memory leaks.

To save memory, you should close handles to objects that are not needed anymore during program execution, but sometimes you don't have to do this. For example, I don't bother to specifically close any open file handles with my program patcher programs before they exit since they are simple "one shot" programs.