Using WM_USER, WM_APP or RegisterWindowMessage
-
Oops! That ain't correct. :)
It was ever thus, the Neophiles will always rush out and get 'The Latest Thing' at a high price and with all the inherent faults - Dalek Dave.
Nope. That is correct you can't get any better using
RegisterWindowMessagefor private (i.e. inside same process) messages. :)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
[My articles] -
The correct way is to use RegisterWindowMessage(). That would ensure the uniqueness of messages. Read the details here: http://www.flounder.com/messages.htm
yccheok wrote:
What happen if there is an external process (another exe), trying to FindWindow of my Windows application, and send the message with same ID? I wish not to respond, as I am only interested message from DLLs within my own process.
If you use RegisterWindowMessage(), then the 'other executable' won't know what would be the ID of this unique message.
It was ever thus, the Neophiles will always rush out and get 'The Latest Thing' at a high price and with all the inherent faults - Dalek Dave.
That would ensure uniqueness, for well behaving app, not for
Spy++ & gohacks... :rolleyes: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
[My articles] -
Nope. That is correct you can't get any better using
RegisterWindowMessagefor private (i.e. inside same process) messages. :)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
[My articles]The messages are not within the same executable, and therefore I don't consider it as 'private'. The OP is talking about an executable and a DLL, and is particularly concerned that someone else should not be sending the same message. RegisterWindowMessage() will provide a secure way to accomplish this as the ID is generated at runtime, and the 'other executable' won't know it.
It was ever thus, the Neophiles will always rush out and get 'The Latest Thing' at a high price and with all the inherent faults - Dalek Dave.
-
That would ensure uniqueness, for well behaving app, not for
Spy++ & gohacks... :rolleyes: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
[My articles]Oh well, if you decide to hack, you could do it anyway. But the idea is to keep it as sane as possible. Also, WM_USER + based messages are obsolete (read it in the essay I linked to). :)
It was ever thus, the Neophiles will always rush out and get 'The Latest Thing' at a high price and with all the inherent faults - Dalek Dave.
-
The messages are not within the same executable, and therefore I don't consider it as 'private'. The OP is talking about an executable and a DLL, and is particularly concerned that someone else should not be sending the same message. RegisterWindowMessage() will provide a secure way to accomplish this as the ID is generated at runtime, and the 'other executable' won't know it.
It was ever thus, the Neophiles will always rush out and get 'The Latest Thing' at a high price and with all the inherent faults - Dalek Dave.
Rajesh R Subramanian wrote:
The messages are not within the same executable, and therefore I don't consider it as 'private'.
The DLL is mapped in the executable address space, isn't it?
Rajesh R Subramanian wrote:
The OP is talking about an executable and a DLL, and is particularly concerned that someone else should not be sending the same message. RegisterWindowMessage() will provide a secure way to accomplish this as the ID is generated at runtime, and the 'other executable' won't know it.
Using Spy++ (or another hook mechanism) you may know about. :)
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
[My articles] -
Oh well, if you decide to hack, you could do it anyway. But the idea is to keep it as sane as possible. Also, WM_USER + based messages are obsolete (read it in the essay I linked to). :)
It was ever thus, the Neophiles will always rush out and get 'The Latest Thing' at a high price and with all the inherent faults - Dalek Dave.
Rajesh R Subramanian wrote:
But the idea is to keep it as sane as possible. Also, WM_USER + based messages are obsolete (read it in the essay I linked to).
The point about
WM_USERis right (I've fixed the OP), anyway, there's nothing wrong usingWM_APPin the OP scenario (Dr.Newcomer warns about 'clients using DLLs with conflicting messages...') and the mechanism is the same of theWM_USERone. :)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
[My articles] -
Oh well, if you decide to hack, you could do it anyway. But the idea is to keep it as sane as possible. Also, WM_USER + based messages are obsolete (read it in the essay I linked to). :)
It was ever thus, the Neophiles will always rush out and get 'The Latest Thing' at a high price and with all the inherent faults - Dalek Dave.
Rajesh R Subramanian wrote:
Oh well, if you decide to hack
Oh, no. Unfortunately I'm really poor as hacker... :-\
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
[My articles] -
Rajesh R Subramanian wrote:
The messages are not within the same executable, and therefore I don't consider it as 'private'.
The DLL is mapped in the executable address space, isn't it?
Rajesh R Subramanian wrote:
The OP is talking about an executable and a DLL, and is particularly concerned that someone else should not be sending the same message. RegisterWindowMessage() will provide a secure way to accomplish this as the ID is generated at runtime, and the 'other executable' won't know it.
Using Spy++ (or another hook mechanism) you may know about. :)
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
[My articles]CPallini wrote:
The DLL is mapped in the executable address space, isn't it?
So, are you telling that using a hardwired message ID is better than having the OS register a dynamic ID for us? Also, the DLL could be mapped into my address space, but it's still a different entity. If I keep on assigning WM_USER + based messages for all my handlers, that would certainly be 1. Poor programming technique 2. Could be error prone, as I might accidentally type in something else (and there are a few more points that the article discusses) 3. Some messages based at WM_USER + have been obsolete, which means that I could possibly collide into what's a standard windows message. 4. And the worst thing is that SOMEONE ELSE can come up with the same message ID and send it to you. (with dynamic creation, it's different, AND unique each time).
CPallini wrote:
Using Spy++ (or another hook mechanism) you may know about.
Like I said, if you would want to hack, there's no limits to it. :)
It was ever thus, the Neophiles will always rush out and get 'The Latest Thing' at a high price and with all the inherent faults - Dalek Dave.
-
Rajesh R Subramanian wrote:
But the idea is to keep it as sane as possible. Also, WM_USER + based messages are obsolete (read it in the essay I linked to).
The point about
WM_USERis right (I've fixed the OP), anyway, there's nothing wrong usingWM_APPin the OP scenario (Dr.Newcomer warns about 'clients using DLLs with conflicting messages...') and the mechanism is the same of theWM_USERone. :)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
[My articles]CPallini wrote:
there's nothing wrong using WM_APP in the OP scenario
Well, yes and no. I'm not saying it's WRONG, but there's a better way. Dr. Newcomer, I and Ray Ozzie discussed this over a coffee. Just Kidding. :laugh:
It was ever thus, the Neophiles will always rush out and get 'The Latest Thing' at a high price and with all the inherent faults - Dalek Dave.
-
Rajesh R Subramanian wrote:
Oh well, if you decide to hack
Oh, no. Unfortunately I'm really poor as hacker... :-\
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
[My articles][Jeremy Clarkson Voice] Some say that it's impossible for the stig Carlo to hack his way out of wet socks. [/Jeremy Clarkson Voice]
It was ever thus, the Neophiles will always rush out and get 'The Latest Thing' at a high price and with all the inherent faults - Dalek Dave.
-
CPallini wrote:
The DLL is mapped in the executable address space, isn't it?
So, are you telling that using a hardwired message ID is better than having the OS register a dynamic ID for us? Also, the DLL could be mapped into my address space, but it's still a different entity. If I keep on assigning WM_USER + based messages for all my handlers, that would certainly be 1. Poor programming technique 2. Could be error prone, as I might accidentally type in something else (and there are a few more points that the article discusses) 3. Some messages based at WM_USER + have been obsolete, which means that I could possibly collide into what's a standard windows message. 4. And the worst thing is that SOMEONE ELSE can come up with the same message ID and send it to you. (with dynamic creation, it's different, AND unique each time).
CPallini wrote:
Using Spy++ (or another hook mechanism) you may know about.
Like I said, if you would want to hack, there's no limits to it. :)
It was ever thus, the Neophiles will always rush out and get 'The Latest Thing' at a high price and with all the inherent faults - Dalek Dave.
Rajesh R Subramanian wrote:
1. Poor programming technique
Nope. Unless Microsoft itself is encouraging poor programming techniques.
Rajesh R Subramanian wrote:
2. Could be error prone, as I might accidentally type in something else (and there are a few more points that the article discusses)
Typing
MY_OWN_MESSAGE(typical#defineused inWM_APP +messages) is as error prone as typing, for instanceWM_PAINT.Rajesh R Subramanian wrote:
3. Some messages based at WM_USER + have been obsolete, which means that I could possibly collide into what's a standard windows message.
I already acknowledged this very point.
Rajesh R Subramanian wrote:
4. And the worst thing is that SOMEONE ELSE can come up with the same message ID and send it to you. (with dynamic creation, it's different, AND unique each time).
That's true, as correctly pointed out by Dr.Newcomer, only if you're distributing your DLLs and them are being used by clients that uses, at the same time, other 'sending messages DLLs' (I find rather hard to fit this in the OP scenario). :)
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
[My articles] -
Rajesh R Subramanian wrote:
1. Poor programming technique
Nope. Unless Microsoft itself is encouraging poor programming techniques.
Rajesh R Subramanian wrote:
2. Could be error prone, as I might accidentally type in something else (and there are a few more points that the article discusses)
Typing
MY_OWN_MESSAGE(typical#defineused inWM_APP +messages) is as error prone as typing, for instanceWM_PAINT.Rajesh R Subramanian wrote:
3. Some messages based at WM_USER + have been obsolete, which means that I could possibly collide into what's a standard windows message.
I already acknowledged this very point.
Rajesh R Subramanian wrote:
4. And the worst thing is that SOMEONE ELSE can come up with the same message ID and send it to you. (with dynamic creation, it's different, AND unique each time).
That's true, as correctly pointed out by Dr.Newcomer, only if you're distributing your DLLs and them are being used by clients that uses, at the same time, other 'sending messages DLLs' (I find rather hard to fit this in the OP scenario). :)
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
[My articles]CPallini wrote:
Typing MY_OWN_MESSAGE (typical #define used in WM_APP + messages) is as error prone as typing, for instance WM_PAINT.
No, it was a different point I was trying to make. Say if you're copy pasting a bunch of messages, you could accidentally define two different messages with the same ID while editing those. And coming to the... Wait, I think this is stretching far too much for very little. Now we need to decide who of us gets the 'nitpick of the week' award. :)
It was ever thus, the Neophiles will always rush out and get 'The Latest Thing' at a high price and with all the inherent faults - Dalek Dave.
-
CPallini wrote:
Typing MY_OWN_MESSAGE (typical #define used in WM_APP + messages) is as error prone as typing, for instance WM_PAINT.
No, it was a different point I was trying to make. Say if you're copy pasting a bunch of messages, you could accidentally define two different messages with the same ID while editing those. And coming to the... Wait, I think this is stretching far too much for very little. Now we need to decide who of us gets the 'nitpick of the week' award. :)
It was ever thus, the Neophiles will always rush out and get 'The Latest Thing' at a high price and with all the inherent faults - Dalek Dave.
Rajesh R Subramanian wrote:
And coming to the... Wait, I think this is stretching far too much for very little. Now we need to decide who of us gets the 'nitpick of the week' award.
I'm sending the following message about:
#define (WM_APP + 5) WM_RAJESH_IS_DA_WINNER
:laugh: :-D :laugh:
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
[My articles] -
Currently, I have a Windows EXE application, with several loaded DLLs. DLLs need to communicate with my windows application through PostMessage and SendMessage. The Windows EXE application + DLLs are all within a single process. The message should be private among EXE and DLLs. I was wondering, should I use + WM_USER based message + WM_APP based message or RegisterWindowMessage and why? What happen if there is an external process (another exe), trying to FindWindow of my Windows application, and send the message with same ID? I wish not to respond, as I am only interested message from DLLs within my own process.
None of these approaches are inherently more 'secure' than any other.
WM_APPis a little better thanWM_USER, because a number of the builtin Windows controls use messages in theWM_USERrange. BothWM_USERandWM_APPmessages are easier to detect using Windows Spy++, since they have fixed values.RegisterWindowsMessageis slightly more difficult to detect, since the value can change each time the message is created (the first time it is called with a given string, a new value is created; further calls with that string get the same value). A determined hack could look for calls toRegisterWindowsMessageand duplicate your string. One option would be to use a randomly-generated string (such as a GUID) that your application and your DLL's could agree on. A simpler alternative would be to generate a random number betweenWM_APPand0xBFFFand pass that to your DLL's via a conventional function call at initialization time.Software Zen:
delete this;
Fold With Us![^] -
None of these approaches are inherently more 'secure' than any other.
WM_APPis a little better thanWM_USER, because a number of the builtin Windows controls use messages in theWM_USERrange. BothWM_USERandWM_APPmessages are easier to detect using Windows Spy++, since they have fixed values.RegisterWindowsMessageis slightly more difficult to detect, since the value can change each time the message is created (the first time it is called with a given string, a new value is created; further calls with that string get the same value). A determined hack could look for calls toRegisterWindowsMessageand duplicate your string. One option would be to use a randomly-generated string (such as a GUID) that your application and your DLL's could agree on. A simpler alternative would be to generate a random number betweenWM_APPand0xBFFFand pass that to your DLL's via a conventional function call at initialization time.Software Zen:
delete this;
Fold With Us![^]After reading Joseph M. Newcomer's article (http://www.flounder.com/messages.htm), he is favoring in using
RegisterWindowsMessageHowever, there are some concern that,RegisterWindowsMessagemay lead to resource exhaustion. http://stackoverflow.com/questions/1192204/can-abusing-registerwindowmessage-lead-to-resource-exhaustion My situation is, I have a EXE with multiple DLLs. Each DLLs doesn't aware of each other DLL. Hence, the situation might happen if I am using WM_APP (Joseph M. Newcomer mark WM_USER as obsolute) DLL_A.dll is sending DDL_A_REFRESH_MY_VIEW_MSG (WM_APP + 100) DLL_B.dll is sending DDL_B_REFRESH_MY_VIEW_MSG (WM_APP + 100) Does this mean,RegisterWindowsMessagewill be the best choice, even my communication only tend to within a single process? -
After reading Joseph M. Newcomer's article (http://www.flounder.com/messages.htm), he is favoring in using
RegisterWindowsMessageHowever, there are some concern that,RegisterWindowsMessagemay lead to resource exhaustion. http://stackoverflow.com/questions/1192204/can-abusing-registerwindowmessage-lead-to-resource-exhaustion My situation is, I have a EXE with multiple DLLs. Each DLLs doesn't aware of each other DLL. Hence, the situation might happen if I am using WM_APP (Joseph M. Newcomer mark WM_USER as obsolute) DLL_A.dll is sending DDL_A_REFRESH_MY_VIEW_MSG (WM_APP + 100) DLL_B.dll is sending DDL_B_REFRESH_MY_VIEW_MSG (WM_APP + 100) Does this mean,RegisterWindowsMessagewill be the best choice, even my communication only tend to within a single process?You might try using something like this:
int WM_DLL_A_REFRESH = RegisterWindowsMessage("DLL_A:Refresh");
Software Zen:
delete this;
Fold With Us![^]
