C / C++ / MFC

9-Dec-10 22:08

You may go with ~~WM_USER~~ WM_APP (see discussion below) based message.
Since such messages are 'private', only your application and the DLLs know the protocol: (AFAIK) you may just enforce such a protection mechanism.
Smile | :)

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]

modified on Friday, December 10, 2010 6:16 AM

Rajesh R Subramanian9-Dec-10 23:43

9-Dec-10 23:43

Oops! That ain't correct. Smile | :)

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.

CPallini9-Dec-10 23:48

9-Dec-10 23:48

Nope. That is correct you can't get any better using RegisterWindowMessage for private (i.e. inside same process) messages.
Smile | :)

Rajesh R Subramanian9-Dec-10 23:51

9-Dec-10 23:51

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.

CPallini10-Dec-10 0:11

10-Dec-10 0:11

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.
Smile | :)

Rajesh R Subramanian10-Dec-10 0:24

10-Dec-10 0:24

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. Smile | :)

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.

CPallini10-Dec-10 0:41

10-Dec-10 0:41

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 #define used in WM_APP + messages) is as error prone as typing, for instance WM_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).
Smile | :)

Rajesh R Subramanian10-Dec-10 0:54

10-Dec-10 0:54

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. Smile | :)

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.

CPallini10-Dec-10 1:02

10-Dec-10 1:02

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

Rajesh R Subramanian9-Dec-10 23:42

9-Dec-10 23:42

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.

CPallini9-Dec-10 23:50

9-Dec-10 23:50

That would ensure uniqueness, for well behaving app, not for Spy++ & go hacks... Roll eyes | :rolleyes:

Rajesh R Subramanian9-Dec-10 23:53

9-Dec-10 23:53

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).

Smile | :)

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.

CPallini10-Dec-10 0:21

10-Dec-10 0:21

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_USER is right (I've fixed the OP), anyway, there's nothing wrong using WM_APP in the OP scenario (Dr.Newcomer warns about 'clients using DLLs with conflicting messages...') and the mechanism is the same of the WM_USER one.
Smile | :)

Rajesh R Subramanian10-Dec-10 0:25

10-Dec-10 0:25

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 | :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.

CPallini10-Dec-10 0:23

10-Dec-10 0:23

Rajesh R Subramanian wrote:
Oh well, if you decide to hack

Oh, no. Unfortunately I'm really poor as hacker... $Shucks | :-\$

Rajesh R Subramanian10-Dec-10 0:30

10-Dec-10 0:30

[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.

Gary R. Wheeler11-Dec-10 1:31

Gary R. Wheeler

11-Dec-10 1:31

None of these approaches are inherently more 'secure' than any other.

WM_APP is a little better than WM_USER, because a number of the builtin Windows controls use messages in the WM_USER range.

Both WM_USER and WM_APP messages are easier to detect using Windows Spy++, since they have fixed values.

RegisterWindowsMessage is 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 to RegisterWindowsMessage and 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 between WM_APP and 0xBFFF and pass that to your DLL's via a conventional function call at initialization time.

Software Zen: delete this;
Fold With Us![^]