Many Win32 API functions use a LPCTSTR parameter as resource name or type. For example, a trivial one: HICON LoadIcon(HINSTANCE hInstance, LPCTSTR lpIconName); And the documentation for the lpIconName states that: Pointer to a null-terminated string that contains the name of the icon resource to be loaded. Alternatively, this parameter can contain the resource identifier in the low-order word and zero in the high-order word. Use the MAKEINTRESOURCE macro to create this value. Now, how the LoadIcon code knows to diferentiate between a resource string name and a predefined constant like IDI_ASTERISK which is defined as: #define IDI_ASTERISK MAKEINTRESOURCE(32516) We are used to the wizard generated resource IDs in our applications but a resource can have any null terminated string as name and type too. Look to the FindResource function for example. All resource Win32API functions use the macro IS_INTRESOURCE(id) BOOL IS_INTRESOURCE( WORD wInteger ); #define I...

Each time when you use a win32 API which uses a HANDLE remember that the handle Must be valid (not closed). It is important to understand the concepts of the handle being signaled and being closed. Signaled state refers to the handle state. It can be signaled or unsignaled. Wait functions for example, like WaitForSingleObject, block current thread until the object gets signaled. A handle is said to be closed when its reference count reaches zero value. When this happens the handle is closed and doing any waiting on it is error prone. A handle is a pointer on an object. Wait functions check the state of the object, hence it is a must that the handler (the pointer) is valid. Otherwise, waiting functions wont work properly (while waiting on an invalid handle, you might wait indefinetly). One example of bogus use is with MFC AfxBeginThread function. Its default behaviour is to auto 'delete' the thread, i.e to close its handle. Its bad to use the returned handle after the thread is ...