How does the message loop use streams?
I'm a little confused and wondering if I was misinformed, in a separate post I was told: "New threads are only created when you make them explicitly. C ++ programs are single-threaded by default." When I open my program that does not explicitly create new threads in ollydbg, I noticed several times that there are often 2 threads. I wanted to understand how the message loop works without stopping execution, the explanation I got was not enough to explain how it works.
Does the message loop create a new thread or take over the main thread? If it accepts the main thread, does it do so after everything else is done regardless of the order of the code? If it doesn't, but still occupies the main thread, does it spawn a new thread so the program can execute instead of getting stuck in the message loop?
EDITOR: Solved most of my questions to experiment. The message loop takes up the main thread and any code after the code:
while (GetMessage (&messages, NULL, 0, 0))
{
TranslateMessage(&messages);
DispatchMessage(&messages);
}
return messages.wParam;
Will not execute unless something special is done to make it execute, because the program gets stuck in the message loop. Placing an infinite loop in a window procedure that is being run causes the program to crash. I still don't understand the mystery of multiple threads when in olly to the extent I would prefer, though.
source to share
Perhaps the place to start is to understand that the "message loop" is not; that's really just what thread does.
Themes in Windows usually fall into one of two categories: those that have their own interface, and those that do background work (such as network operations).
A simple UI application usually has only one thread, which is the UI thread. For the UI to work, the thread needs to wait until there is any input to be processed (mouse click, keyboard input, etc.), handle the input (e.g. update the state and redraw the window) and then come back waiting for more entrance. This whole act of "waiting for input, processing, repeating" is a message loop. (Also worth mentioning at this point is the message queue: each thread has its own input queue that stores the input messages for the thread, and the thread's act of "waiting for input" is really checking if there is anything in the queue, and if not, then wait.) In win32 say if a thread is actively handling input in this way, it also said it is "pumping messages ".
Typical simple core Windows application code first does basic initialization, creates the main window, and then waits for I / O and the process. This usually happens until the user closes the main window, after which the thread exits the loop and continues executing the code that appears after that, which is usually the cleanup code.
A common architecture in Windows applications is to have a main UI thread - this is usually the main thread, and it creates and owns the entire UI and has a message loop that sends messages to the entire UI created by the thread, if the application needs to do something that can potentially block, for example, reading from a socket, a worker thread is often used for this purpose: you do not want the UI thread to block (for example, waiting for input from a socket) as it will not process input during this time, and the user the interface will end up unresponsive.
You could write an application that had more than one UI thread, and each thread that creates windows would need its own message chain, but this is a pretty advanced technique and not all that useful for most basic applications.
The other threads you see are most likely some kind of helper threads created by Windows to perform background tasks; and for the most part you can ignore them. If you initialize COM, for example, windows can create a worker thread to manage some internal COM data, and can also create some invisible HWNDs.
source to share
Typically, the thread that launches the program starts the message loop, taking over the main thread. Anything outside of processing messages or updating the UI is usually done by other threads. The extra thread you see, even if your application does not create threads, could be generated by a library or operating system. Windows will create threads inside your process to handle events such as dispatching events to your message loop.
source to share