Or how to determine if a given message was posted/sent programmatically by another thread or simply another process?
By post and send I mean functions PostMessage and SendMessage
The Windows API does not keep track of the originator of a message. So the only way to know where a message comes from would be to directly hook the (Post|Send)Message functions in every running process.
Related
tldr Why don't I receive PBT_APMRESUMEAUTOMATIC, PBT_APMRESUMESUSPEND, and PBT_APMSUSPEND as the payload to service events of type SERVICE_ACCEPT_POWEREVENT?
I'm trying to detect when a windows device as woken back up from sleep. I have a constellation of processes that interact via IPC, which includes both UI applications with an event handler function provided to RegisterClassEx and services using RegisterServiceCtrlHandlerExW.
My preference is to receive these events in a service. My understanding is that I can get SERVICE_ACCEPT_POWEREVENT in dwControlsAccepted, and can then distinguish specific kinds of power event by looking at the dwEventType parameter, as per these docs https://learn.microsoft.com/en-us/windows/win32/api/winsvc/nc-winsvc-lphandler_function_ex. However, I only ever receive PBT_APMPOWERSTATUSCHANGE, corresponding to fiddling with the power cord on the laptop. I expected to also receive some combination of PBT_APMRESUMEAUTOMATIC, PBT_APMRESUMESUSPEND, and PBT_APMSUSPEND.
When testing on the UI side, I do get WM_POWERBROADCAST events of any kind. Obviously I've missed some part of setup there. Again, the process that actually needs this info is a service, so I would have to IPC the event to a service if this is what ended up working.
For full credit, I also experimented with SERVICE_CONTROL_CONTINUE and SERVICE_CONTROL_PAUSE (enabled via SERVICE_ACCEPT_PAUSE_CONTINUE), but never receive these events at all. I had expected those to correlate with sleeping the laptop but apparently not.
I have a program that shuts down another application when certain conditions are met. Now most of the time everything works out fine, but sometimes the app is writing to a file and leaves it in a half finished state and has no way of recovering it on restart. I thought that one could send soft close signals and escalate after certain timeouts to more aggressive close signals, going trough a list like this:
1. WM_CLOSE
2. WM_QUIT
3. WM_DESTROY
4. TerminateProcess().
Now I know that the program has no code to handle any signal it receives. Is there a possibility that certain FileHandler under Windows react gracefully on such soft signals or is there no use to sending those, if the app does not handle them explicitly?
This article says:
NOTE: A console application's response to WM_CLOSE depends on whether or not it has installed a control handler.
Does this mean if no control handler is installed sending 1-4 is just as good as sending 4 directly?
I have a main application and 4 client applications, I communicate back to the main application using SendMessage.
I can use any three of the client apps without any problems but as soon as I add a forth I get access violations and stackoverflow errors.
My question: is there a maximum for the number of apps that can send using SendMessage to a single application?
I am using Delphi XE2 and Windows 8
My question is, is there a maximum for the number of apps that can send using SendMessage to a single application?
No there is not. Your problem is not related to the number of processes sending messages.
One likely explanation for an access violation when processing messages is that your message contains a pointer to memory that is only valid in the address space of the sending process. But that's a wild guess since we have no code.
I've got no idea how window hooks work at the "system level". MSDN only touches what's going on very briefly:
A hook is a point in the system message-handling mechanism where an
application can install a subroutine to monitor the message traffic in
the system and process certain types of messages before they reach the
target window procedure.
My best guess is something like below:
Before each message is added to the message queue for a window, it'll first send the message to the global/local hooks, which may do something, depending on their hook procedures. After all global hooks and local hooks, the message is finally added to the window message queue.
However, MSDN says that for some of the types of hooks, it will monitor events, notifications etc.
An example is the WH_MOUSE_LL hook:
Installs a hook procedure that monitors low-level mouse
input events. For more information, see the LowLevelMouseProc hook
procedure.
When they say events, are we talking window messages, or do they mean something else?
Am I all wrong?
Yes, this is a mechanism for windows messages, you can process this data (messages) before they reach target window procedure (message loop).
If you want hook other process windows you can simply do this in DLL, and use DLL injection for inject your library to other process.
I am porting a library to Windows. In a function I need to block on the arrival of a WM_DEVICECHANGE message.
What options are available for doing this? As my code resides in a library I have little-to-no information on the current set-up (so if it is a Console application, a regular GUI application, if my code is being run in a spawned thread, and so on). Therefore what is the best way to wait for the arrival of a specific message?
Blocking and receiving Windows messages are mutually incompatible. You get messages by pumping a message loop. Since you cannot rely on the app pumping one, you'll need to do this yourself.
You will need to create a thread. Create a hidden window in that thread then run the standard message loop. The window procedure for that window can see the WM_DEVICECHANGE message. It can do what ever it needs to do, within the constraints of running inside a separate thread. Like setting an event to signal that a function should stop blocking.
The message is probably sent using BroadcastSystemMessage(). You could create a hidden top-level window and its window proc would probably get this message. I'm not sure; but that's what I'd try first.