C / C++ / MFC

7-Jul-07 23:06

MSDN states that sending a message is done directly to a message windows procedure rather than message queue. If that is true then is it true that GetMessage/PeekMessage is valid only for messages that are placed into message queue by postmessage.

Also if we want to direct a message to another process will both PostMessage/SendMessage work. What is the difference?

mid=57418-Jul-07 0:13

mid=5741

8-Jul-07 0:13

from MSDN:

The SendMessage function sends the specified message to a window or windows. It calls the window procedure for the specified window and does not return until the window procedure has processed the message.

The PostMessage function places (posts) a message in the message queue associated with the thread that created the specified window and returns without waiting for the thread to process the message.

The WindowProc function is an application-defined function that processes messages sent to a window. The WNDPROC type defines a pointer to this callback function. WindowProc is a placeholder for the application-defined function name.

The DispatchMessage function dispatches a message to a window procedure. It is typically used to dispatch a message retrieved by the GetMessage function.

Bogdan Apostol8-Jul-07 0:38

8-Jul-07 0:38

In addition to what Michael posted, both APIs are adding messages to the thread's message queue, thus can be retrieved using GetMessage() and PeekMessage(). As MSDN says, on Vista there's a small exception for this behaviour:
"Microsoft Windows Vista and later.
...
If the specified window was created by the calling thread, the window procedure is called immediately as a subroutine.
..."
Best regards,

Bornish
ESRI Developer Network

Compilers demystified - Function pointers in Visual Basic 6.0
Enables the use of function pointers in VB6 and shows how to embed native code in a VB application.

tom groezer8-Jul-07 4:54

8-Jul-07 4:54

What about the other part of the question
Also if we want to direct a message to another process will both PostMessage/SendMessage work. What is the difference?

mid=57419-Jul-07 5:30

mid=5741

9-Jul-07 5:30

Do you understand English? PostMessage() returns without waiting for the thread to process the message. SendMessage() does not return until the window procedure has processed the message. PostMessage() is a non-blocking call. SendMessage() is a blocking call. Regardless of Microsoft's implementation details, both calls go to the same place -- the window procedure of the window to which you are sending (or posting) the message.

jbalaji849-Aug-07 21:18

jbalaji84

9-Aug-07 21:18

hi Tom,

did u get the answer for your question,
"if we want to direct a message to another process will both PostMessage/SendMessage work?"

If so, can you reply that to me?
I dont think postmessage/sendmessage works across processes.
it that right?
Thanks in advance.
cheers....!

Balaji

Randor 8-Jul-07 6:57

Randor

8-Jul-07 6:57

tom groezer wrote:
MSDN states that sending a message is done directly to a message windows procedure rather than message queue.

Hi again,

It seems others tend to paste MSDN snippets, however I'll try to explain it as I understand it. Lets just hope that I understand it correctly Smile | :)

Its quite complicated... and this is only a summary.

SendMessage() ... It will completely bypass the message que and ultimately call the window Proc directly. The message is never placed into the message que. Instead it is placed into a seperate FIFO stack of "nonqueued messages" which is technically not the normal message que.

The following functions generate nonqueued messages:
SendMessage, SendMessageCallback, SendMessageTimeout, SendNotifyMessage, BroadcastSystemMessage, BroadcastSystemMessageEx... maybe more I dunno.

PostMessage()... always places the message into the standard windows message que and returns immediately.

tom groezer wrote:
If that is true then is it true that GetMessage/PeekMessage is valid only for messages that are placed into message queue by postmessage.

GetMessage() and PeekMessage() checks for both queued and nonqueued messages. Meaning regardless of whether they are sent by SendMessage() or PostMessage() you can filter them.

tom groezer wrote:
Also if we want to direct a message to another process will both PostMessage/SendMessage work. What is the difference?

You should use PostMessage(). If you use SendMessage() and the other application is blocked... your SendMessage() will never return. But there are alternatives... SendMessageTimeout() and such.

Best Wishes,
-Randor (David Delaune)

Bogdan Apostol8-Jul-07 8:59

8-Jul-07 8:59

David, in my opinion, your interpretation does not make any sense. Why? Because when SendMessage is used across thread boundaries, it cannot be processed in the sender's thread, thus... must be queued, and processed by the receiving window's thread, whenever it is reached. That's why SendMessage may hang if the receiver thread (other than sending one) is busy... not processing queued messages. If fact, I can tell you from experience that it happen once to redraw a window, but to return the wrong value from the window procedure, thus the paint message was not removed from the queue. In that case, any other thread using SendMessage to communicate with this window was blocked, not only the thread that created the window.
Your explaination with a secondary FIFO doesn't hold, because a thread's context can't change "suddenly". If there is a message queue (also FIFO) which GetMessage() and PeekMessage() are using, when and how a secondary FIFO can be processed? No OS would suspend a thread's execution while processing a message from the queue, or even while waiting for a new message, and "suddenly" call a window procedure with a message sent through SendMessage! Remember, I'm not talking here about sending a message to a window belonging to the same thread where the call is made.
Indeed, when the window belongs to the same thread, it makes perfect sense to call the window procedure immediatelly, because the developer would expect that SendMessage() returns only after the message is processed, so... the thread execution depends on the processing of that message, before any other message already existing in the queue at that point in time. I don't even understand why MSDN says that such behaviour is for "Vista or later", because, when I think about it,... it cannot be otherwise.
Regards,

Bornish
ESRI Developer Network

Compilers demystified - Function pointers in Visual Basic 6.0
Enables the use of function pointers in VB6 and shows how to embed native code in a VB application.

Randor 8-Jul-07 9:06

Randor

8-Jul-07 9:06

I believe my explanation to be correct.

The MSDN:
http://msdn2.microsoft.com/en-us/library/ms644927.aspx[^]

Heres what Raymond Chen had to say about it.
http://blogs.msdn.com/oldnewthing/archive/2004/11/19/266664.aspx[^]

Best Wishes,
-Randor (David Delaune)

Bogdan Apostol8-Jul-07 10:43

Get exact memory usage of a process.

8-Jul-07 10:43

Thanks David for the links... especially the second one!
It is interesting to see different opinions about an "old new subject" such as message queueing. We might fight over nothing here, since I kinda agree with one of the conclusions mentioned in that discussion thread: it seems to be an implementation detail. Point taken regarding the non-queueing messages! Indeed, sent messages are different since are not stored as messages posted, and also not returned by GetMessage. My logic still says that they are "somehow" queued... and how is indeed "an implementation" detail. All this confusion is set by MSDN, which is not comprehensive on the subject, and also contradicting itself in the documentation of GetQueueStatus()[^], when describing QS_SENDMESSAGE. As you well described, sent messages are different then posted ones, having higher priority, and still being queued (maybe separately, or could be inserted ahead of the posted ones) because they can't be processed by receiving thread "immediately" (as MSDN is misleading us).
Please have a look at "The Algorithm for Extracting Messages from a Thread's Queue" section at "Waking a Thread[^]" sub-chapter from a book called "Programming Applications for MS Windows, 4th edition" by Jeffrey Richter, and tell me if you agreed with what says there... at least partially. It was published by Microsoft Press[^]!
Thanks,

Bornish
ESRI Developer Network

Compilers demystified - Function pointers in Visual Basic 6.0
Enables the use of function pointers in VB6 and shows how to embed native code in a VB application.

zecodela7-Jul-07 23:03

zecodela

7-Jul-07 23:03

Hi All,
I am debugging my application by printing the Working Set at the specific point with the function provided in psapi.h
My purpose is to check which part of my application used up the memory.
However, just look at the Working Set is not very conclusive. I found if allocated 1k memory in the app but the Working Set may not grow up 1k accordingly. It will grow eventually(say allocated 10 times 1k, Working Set will grow up around 10k.)
In the psapi.h, there are several values such PageFault, PagedPool, Pagefile... i can see those values will change each time when allocating memory. I guess the result of memory allocation action has reflected in those values.
What i want to ask is any formula to calculate the exact memory usage of the application? say, i do "new char[128]" the memory usage result will grow up 128byte immediately.

Any reply will be appreciated!

Thanks!

Jim

Re: Get exact memory usage of a process.

Bogdan Apostol8-Jul-07 1:09

8-Jul-07 1:09

When you allocate 128 bytes through "new char[128]", you may not commit any new page of memory!!!
My point is that memory allocation is done by the heap manager used by your module. For example, if CRT is the heap manager (msvcrt.dll) you're linking with, all "malloc / new" kind of instructions will be handled by that library, which may reuse previously released memory, or return an address of already commited memory. The heap manager keeps track of your allocations, and commits pages of memory only when needed. For example, on first allocation, a number of pages are commited to support the request. On those pages there's still room for more allocations. Thus, next allocation, if small enough, will not commit more pages, but use the existing commited pages.
There're plenty of online resources explaining how a "heap manager" implementation works:
http://blogs.technet.com/askperf/archive/2007/06/26/what-a-heap-of-part-one.aspx[^]
http://en.wikipedia.org/wiki/Chunking_(computing)[^]
http://www.blackhat.com/presentations/bh-usa-06/BH-US-06-Marinescu.pdf[^]
http://www.freshpatents.com/Methods-systems-and-computer-program-products-for-managing-a-memory-by-storing-external-objects-in-a-dynamic-heap-dt20051215ptan20050278496.php[^]
Best regards,

Bornish
ESRI Developer Network

Compilers demystified - Function pointers in Visual Basic 6.0
Enables the use of function pointers in VB6 and shows how to embed native code in a VB application.

WM_COPYDATA message

tom groezer7-Jul-07 22:35

7-Jul-07 22:35

Does WM_COPYDATA use some kind of shared memory concept when it uses the structure COPYDATASTRUCT?

Bogdan Apostol8-Jul-07 1:20

8-Jul-07 1:20

When sending WM_COPYDATA message to another application, lParam must point to a COPYDATASTRUCT, and the passed data must not contain any addresses (pointers or references) that would not be available in the other process. Until the thread sending the message returns from the call, the data structure should be either locked or not modified by other threads of the calling process. The data received by the other process cannot modify / return any of the structure's content. The reason behind all these is that the OS is copying the given structure as a block, from the calling process to the receiving process. It is like calling WriteProcessMemory, on some temp variable (thread stack address) in the target process. The communication is one way!
Regards,

Bornish
ESRI Developer Network

Compilers demystified - Function pointers in Visual Basic 6.0
Enables the use of function pointers in VB6 and shows how to embed native code in a VB application.

tom groezer8-Jul-07 5:08

8-Jul-07 5:08

While using the structure could we say that the OS implements one as a shared memory?

Randor 8-Jul-07 5:50

Randor

8-Jul-07 5:50

Yes.

The way I understand it... when you post a WM_COPYDATA message, the kernel creates a temporary memory mapped file containing the bytes at the location specified relative to the senders address space. This memory mapped file is accessable to the recieving application. Upon SendMessage() returning the memory mapped file is marked for deletion.

Best Wishes,
Randor (David Delaune)

Bogdan Apostol8-Jul-07 8:35