1

This question on StackOverflow presents a minimal Win32 program written in C which launches some processes (Notepad and Calc) using CreateProcess.

The OP's issue is that the windows of these programs appear in the background, behind the Explorer window from where the sample program is launched.

Though the question is closed as a duplicate, the OP came up with a solution which is not found in the referenced answer. The solution consists of aadding a single TranslateMsg call to the program, before the CreateProcess calls:

MSG msg;
TranslateMessage(&msg);

With this in place, the windows of the launched processes pop into the foreground, as expected.

My question is: can someone who has a bit of knowledge about Windows internals explain how this TranslateMessage call is helping?

The call is not even well-defined in the above usage; TranslateMessage is supposed to operate on a message pulled from the message queue. The msg object is not even initialized. The trick still works if we change this to MSG msg = { 0 }. There seems to be a bug/hack in Windows based on the idea that if a process never calls TranslateMessage then it's a background process, and the window of any process spawned by it goes to the background. Even a useless call to TranslateMessage with garbage data is sufficient to fool this kludge.

Community
  • 1
Kaz
  • 3,612
  • 1
  • 19
  • 30
  • I think the real question is "who writes Windows programs using the Win32 API in 2016?" –  Jul 01 '16 at 01:59
  • 2
    @Snowman That snark actually has good answers. For instance, people who write library or programming language run-time middleware have excellent reasons to be working at that level. There we can solve issues like this that the users above won't even see. – Kaz Jul 01 '16 at 03:59

1 Answers1

2

The Windows system for determining whether or not an application is allowed to take focus is somewhat arcane (due to basically consisting of a bunch of heuristics for determining whether the user is likely to want an application to take focus) and mostly undocumented (as the windows ui designers like to maintain the flexibility to tweak stuff like this with each new version, which is easier if there is no documented behaviour that would need to be changed). My understanding of it is that to take focus, an application must be started by a process that either currently has focus or would be allowed to take focus. This much is reasonably well understood. The following, however, is pure hypothesis to attempt to explain the behaviour you point out:

  • checking whether a process is allowed to take focus only works if the process has a thread with a message queue
  • message queues are lazily allocated when they are needed (this is documented behaviour)
  • TranslateMessage triggers allocation even if it doesn't do anything with the message it is passed (pure guesswork)

If this is right, there are two important consequences:

  • TranslateMessage could be switched to any message-queue-handling function (eg PeekMessage)
  • Because the fact that this works relies on an undocumented implementation detail of TranslateMessage, it cannot be relied upon working in future versions of Windows (which may decide to conserve resources by not allocating a message queue in this situation - or in fact ignoring the allocation in any situation, as TranslateMessage is documented as only working on messages returned by GetMessage et al so should be able to assume the queue exists)

It therefore seems to me that you should not use this solution, at least in the situation that my assumptions above are true, at which point we can conclude that changing the call to a call to PeekMessage would be the most logical action.

Jules
  • 17,754