You can use the IsWindow() function to determine if the window has been closed (i.e., destroyed).
Although this works in the most of the case, it is not "safe": when a window is destroyed its handle becomes invalid and the is ID (the handle value) can be reused by the system for another subsequently created window.
If you don't look at all that while happening, IsWindow may return TRUE, but the window may not be the one you intended.
(I mean: "my name (handle) is the same of my grandfather, I was born after his death, and I live in what it was his house. But I'm not him"! But if you send a letter to him, I'll read it as mine and, hopefully, I can understand the misleading only from the context".)
I am looking for code sample which will explain how to actually pass handles from parent to child process.
A child process can inherit handles from its parent process. An inherited handle is valid only in the context of the child process. To enable a child process to inherit open handles from its parent process, use the following steps.
1.Create the handle with the bInheritHandle member of the SECURITY_ATTRIBUTES structure set to TRUE.
2.Create the child process using the CreateProcess function, with the bInheritHandles parameter set to TRUE.
Can someone please share some code sample which would help me understand how to actually use the passed handle in child process.
You described how to make the handle available in the child process, but you still need to tell the child the numerical value of the HANDLE. A common way of doing this is to pass the value as a command line parameter.
This is what I was looking for. Handles are copied in the process table of the child process if the inherit flag is set to true but how would the child process know which handle is pointing to which kernel object and which to use.
"To use a handle, the child process must retrieve the handle value and "know" the object to which it refers. Usually, the parent process communicates this information to the child process through its command line, environment block, or some form of interprocess communication."
I was looking for an sample code showing the above step(highlighted in bold).
When you create an object (like a mutex) you can specify a "name".
In the child process you can retrieve another handle to that same object with OpenMutex[^], or whatever similar and coherent with the type of object) by giving it that name (that is supposed to be unique at least between all your entangled processes).
Note that the returned value may be different, due to the fact the the handle value is an "index of a table of indexes" that is different in the various processes.
The documentation talks improperly of inheritance of handles. What are inherited are the objects the handle refers to.
After reading it, I would say you can apply the same principle to STL by using the registry entry “std\:\:.*=nostepinto” instead of “ATL\:\:.*=nostepinto”. I haven't tried though. In any case, before trying this I'd create a restore point or whatever else you usually do to undo an unlucky change. It is an undocumented feature after all, and even if it weren't, manually editing the registry isn't for the weak of heart.
UNICODE is actually a set of code-points whose cardinality requires 21 bits.
When encoded in sequence of 1 bye is called UTF-8 and when encoded as sequence of two bytes is called UTF-16.
In UTF-8 coding may vary from 1 to 4 bytes (and remains identical for code-points between 0 and 127, aka ASCII)
In UTF-16 coding may be 2 or 4 bytes (and is TWO for the most of Latin, Cyrillic and Greek characters, as many simplified Chinese).
UNICODE==2bytes is a misconception that originated at the time Windows included Unicode APIS using 16bits since -at that time- Unicode specs where not so wide.
Actually, reading 2bytes does not necessarily means "read a character".
I'm sorry for you and for Microsoft, but the one and only entitled to say what Unicode was, is and will be is www.unicode.org[^]
The page you linked is a very shame for Microsoft. A technical document like that cannot be written without specifying in the page itself a data when it was written (hey ... they speak about their new amazing Windows NT 3.5 ...) and for this sole fault should disqualify M$ of whatever authority in the field.
1) Unicode is not a Microsoft product. What UNICODE is is defined by www.unicode.org[^]
2) Microsoft use to encode UNICODE into 16-bits units. That is a technique well defined by the UNICODE standard itself, known as UTF-16. Essentially, every code not in the range 0xD800-0xDFFF and lower than 0xFFFF is code as itself.
Every other greater that 0xFFFF is broken in two 10-bits chunks, or-ed with 0xD800 and 0xDC00 respectively.
The range 0xD800 - 0xDFFF is called "UNICODE surropgate" and does not contain valid codepoints.
So you can have single unicode characters requiring two wchar_t in sequence to be represented and sequences of two wchar_t representing a single character, with code greater than 0xFFFF (typical for CJK - Chinese, Japanese, Corean characters).
How can I check if a dll exist in c++ before I try to load it with dllHandle = LoadLibraryW(m_sFileName)? Sometimes it looks like that the LoadLibraryW call hangs the calling thread if the dll doesn't exist on the disc.
If you a priori know where the DLL should be then your strategy might be good. On the other hand if you need to follow the same procedure the OS does for searching the DLL then you'll meet the same hanging conditions, I suppose.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
It's probably more important to investigate why the program hangs. LoadLibrary() should merely search through all paths in the PATH variable to find the named DLL. If it hangs during that process then there is something wrong with your system.
Hi, the problem occurs when the user do sleep/resume test with the computer. We try to load the dll with LoadLibrary and a few milliseconds after the LoadLibrary call the user puts the system into sleep. Maybe thats why I got the problem?
Of cours not, are you stupid or??? It very difficult to know when the user puts the system into sleep. And I don't see the meaning of your comment, you have no idea how big our application is and how it work.
The application stops working ~1/100 sleep resume tests.