Skip to main content

Message Loop

What is Message Loop​

In Windows, the Message Window (or message-based architecture) plays a critical role in communication between different parts of an application or even between separate applications. The underlying mechanism revolves around Windows messages, which are used to notify windows of various events (like user inputs, system requests, or inter-process communication). Here’s a detailed explanation of the architecture:

1. Message Loop (Message Pump)​

Each Windows application has a message loop (or message pump) at its core. This loop continuously checks for messages that are placed in the application's message queue and then dispatches those messages to the appropriate window procedure to be processed.

The typical architecture looks like this:

  • The operating system generates messages (e.g., mouse clicks, keyboard input) or an application sends messages.
  • The messages are placed in a message queue specific to a thread.
  • The message loop extracts messages from the queue and dispatches them to the window procedure for handling.

Here is a simplified code example of the message loop in a Windows application:

MSG msg;
while (GetMessage(&msg, nullptr, 0, 0)) {
    TranslateMessage(&msg);
    DispatchMessage(&msg);
}

2. Window Procedure (WindowProc)​

The Window Procedure is the function that handles messages for a specific window. When the DispatchMessage function is called, it sends the message to the window’s WindowProc. Each window has its own window procedure, which processes messages like WM_PAINT (for drawing), WM_KEYDOWN (for key presses), or custom messages sent by other applications.

An example of a window procedure:

LRESULT CALLBACK WindowProc(HWND hwnd, UINT uMsg, WPARAM wParam, LPARAM lParam) {
    switch (uMsg) {
        case WM_PAINT:
            // Handle painting the window
            break;
        case WM_DESTROY:
            PostQuitMessage(0);
            break;
        default:
            return DefWindowProc(hwnd, uMsg, wParam, lParam);
    }
    return 0;
}

3. Message Queue​

Each thread that creates windows has its own message queue. The queue stores messages (such as mouse clicks, key presses, and system events) and is processed in a first-in, first-out (FIFO) order. When an application sends or posts a message, it places the message in the appropriate thread’s message queue. The GetMessage function retrieves messages from this queue and sends them to the appropriate window.

4. Inter-Process Communication (IPC) via Messages​

Messages in Windows are not limited to communication within a single application. They can also be used for Inter-Process Communication (IPC), enabling one application to send messages to another application.

  • SendMessage: This function can be used to send a message to a window. The sender waits until the receiving window has processed the message. The SendMessage function is synchronous.

  • PostMessage: This is an asynchronous version, where the message is posted to the target window's message queue, and the sender does not wait for the message to be processed.

SendMessage(hwnd, WM_USER + 1, wParam, lParam);   // Synchronous message
PostMessage(hwnd, WM_USER + 1, wParam, lParam);   // Asynchronous message

Here, WM_USER + 1 represents a custom message (you can define custom messages starting from WM_USER).

5. System-Defined Messages​

  • Windows defines many system messages, such as:
    • WM_PAINT: When the window needs to be repainted.
    • WM_DESTROY: When a window is about to be destroyed.
    • WM_KEYDOWN: When a key is pressed.
    • WM_MOUSEMOVE: When the mouse moves.

6. Custom Messages​

Applications can define custom messages to communicate specific events between different parts of the application or between different applications. This is commonly used in scenarios where different threads or processes need to communicate.

Custom messages can be defined like this:

#define WM_CUSTOMMESSAGE (WM_USER + 100)

And can be sent like so:

SendMessage(hwnd, WM_CUSTOMMESSAGE, wParam, lParam);

7. Message Filtering (Hooking)​

In some cases, you might want to intercept messages before they are dispatched to the window procedure. This can be done using message hooks. Hooks allow you to monitor or modify messages globally across all applications or within a single application.

For example:

  • WH_CALLWNDPROC: Allows you to intercept messages before they reach the window procedure.
  • WH_GETMESSAGE: Allows you to intercept messages as they are retrieved from the message queue.

8. Multithreading and Message Windows​

In multithreaded applications, each thread can have its own message queue. When working with multiple threads, you can send messages between threads using PostThreadMessage. This allows different threads to communicate with each other asynchronously.

Summary of the Architecture:​

  1. Message Generation: System or application generates a message (e.g., user input, window event, custom event).
  2. Message Queue: The message is placed in the thread’s message queue.
  3. Message Loop: The message loop continuously retrieves messages from the queue.
  4. Dispatching: The message loop dispatches the message to the appropriate window procedure.
  5. Window Procedure: The window procedure processes the message and performs the corresponding action (such as repainting the window, handling input, etc.).

Use Cases of Message-Based Architecture:​

  • User Interface (UI) handling: User inputs such as clicks, key presses, and resizing events are all handled by messages.
  • Inter-Process Communication (IPC): Messages allow communication between different applications or windows.
  • Multithreading: Messages enable coordination and communication between different threads in an application.

This message-based architecture allows Windows applications to remain responsive to user input and other events without blocking, making it highly scalable for both simple and complex applications.

Use of Message Loop and Web API in same application​

It is possible to create a Windows application that uses both a Message Pump for handling traditional Windows messages (such as GUI events) and a Web API to receive HTTP requests. This kind of hybrid architecture combines two different event handling mechanisms: one for Windows-based message-driven interaction and one for web-based HTTP requests.

Here’s how you can achieve this:

1. Understanding the Two Event Handling Mechanisms​

  • Message Pump (Message Loop): This is part of a traditional Windows application where events like user input (keyboard, mouse) are processed via Windows messages in a message loop.
  • Web API: This would involve hosting a lightweight HTTP server within your application to handle HTTP requests. In most cases, you would use a framework like ASP.NET Core or a simple HTTP listener within the same application.

2. Possible Approaches to Combining a Message Pump and Web API​

There are a few approaches to combine both the Message Pump and Web API into one application:

A. Multithreading: Separate Thread for the Web API​

One straightforward way is to run the Message Pump in the main thread (the UI thread) and host the Web API on a separate thread. Windows applications typically handle their message loop in the main thread, while a background thread can be used to handle HTTP requests via an embedded web server.

  • Main Thread: Handles the message loop for the Windows UI.
  • Secondary Thread: Hosts the Web API using a web server like ASP.NET Core or an HTTP listener.
Code Example:​

  1. Message Pump (UI Thread): This would be the typical message loop for a Windows Forms, WPF, or custom Windows application that processes user input and system messages.

    MSG msg;
    while (GetMessage(&msg, nullptr, 0, 0)) {
        TranslateMessage(&msg);
        DispatchMessage(&msg);
    }

  2. Web API (Secondary Thread): In the secondary thread, you could start an HTTP listener or an ASP.NET Core Web API to listen for incoming HTTP requests.

    using Microsoft.AspNetCore.Hosting;
    using Microsoft.Extensions.Hosting;

    // Start a simple Web API in a background thread
    Thread webApiThread = new Thread(() =>
    {
        CreateHostBuilder(args).Build().Run();
    });
    webApiThread.Start();

    public static IHostBuilder CreateHostBuilder(string[] args) =>
        Host.CreateDefaultBuilder(args)
            .ConfigureWebHostDefaults(webBuilder =>
            {
                webBuilder.UseStartup<Startup>();  // Use ASP.NET Core Web API startup class
            });

B. Using Asynchronous Models​

Since Windows message loops and Web APIs can both operate asynchronously, you can use asynchronous programming models to handle HTTP requests without blocking the message loop.

  • In this case, you can use async/await in the .NET context or run an HTTP listener asynchronously within a Windows application.
  • This model allows both the UI (with the message loop) and the Web API (handling HTTP requests) to run efficiently without requiring explicit multithreading.

3. Hosting a Web API in a Desktop Application (ASP.NET Core)​

You can embed a lightweight ASP.NET Core Web API server within a Windows desktop application. ASP.NET Core can run in any type of .NET application (not just web apps) and can listen to HTTP requests.

Here’s how you can combine both a message loop and a Web API using ASP.NET Core:

  1. Add ASP.NET Core to the Application:

    • Install ASP.NET Core NuGet packages to support web hosting within your application.

  2. Configure and Run the Web API: In your Windows application, start the ASP.NET Core server in the background:

    public class Program
    {
        public static void Main(string[] args)
        {
            // Start the Windows message loop in the main thread
            var msgLoopThread = new Thread(() =>
            {
                MSG msg;
                while (GetMessage(&msg, IntPtr.Zero, 0, 0))
                {
                    TranslateMessage(&msg);
                    DispatchMessage(&msg);
                }
            });
            msgLoopThread.Start();

            // Start the Web API server in a background thread
            var webApiThread = new Thread(() =>
            {
                CreateHostBuilder(args).Build().Run();
            });
            webApiThread.Start();
        }

        public static IHostBuilder CreateHostBuilder(string[] args) =>
            Host.CreateDefaultBuilder(args)
                .ConfigureWebHostDefaults(webBuilder =>
                {
                    webBuilder.UseStartup<Startup>();  // Web API configuration
                });
    }

  3. Handling HTTP Requests: Your ASP.NET Core Web API can handle HTTP requests as usual. Here’s an example Startup.cs class for your Web API:

    public class Startup
    {
        public void ConfigureServices(IServiceCollection services)
        {
            services.AddControllers();  // Add support for controllers
        }

        public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
        {
            if (env.IsDevelopment())
            {
                app.UseDeveloperExceptionPage();
            }

            app.UseRouting();

            app.UseEndpoints(endpoints =>
            {
                endpoints.MapControllers();  // Map HTTP requests to controllers
            });
        }
    }

    Then, create a controller to handle HTTP requests:

    [ApiController]
    [Route("api/[controller]")]
    public class MyController : ControllerBase
    {
        [HttpGet]
        public IActionResult Get()
        {
            return Ok("Hello from Windows app Web API!");
        }
    }

4. Using HttpListener for Simpler Scenarios​

For simpler scenarios where you don't need the full power of ASP.NET Core, you can use HttpListener. This is a lightweight HTTP server provided by the .NET framework that allows applications to handle HTTP requests without setting up a full web server.

HttpListener listener = new HttpListener();
listener.Prefixes.Add("http://localhost:5000/");
listener.Start();

Thread listenerThread = new Thread(() =>
{
    while (true)
    {
        var context = listener.GetContext();  // Wait for a request
        var response = context.Response;
        string responseString = "Hello World!";
        byte[] buffer = System.Text.Encoding.UTF8.GetBytes(responseString);
        response.ContentLength64 = buffer.Length;
        response.OutputStream.Write(buffer, 0, buffer.Length);
        response.OutputStream.Close();
    }
});
listenerThread.Start();

5. Considerations​

  • Concurrency: Make sure to handle concurrency properly when dealing with multiple threads (UI thread and Web API thread). Use locks, synchronization, or thread-safe data structures if necessary.
  • Port Binding: Ensure the Web API is hosted on an appropriate port that does not conflict with other services running on the system.
  • Performance: Be mindful of CPU usage and performance, especially if the UI and Web API threads need to communicate or share resources.

Conclusion​

Yes, you can create a Windows application that uses both a Message Pump for handling Windows messages and a Web API for handling HTTP requests. By using multithreading or asynchronous models, you can combine both mechanisms effectively. Using ASP.NET Core or HttpListener as the web server component provides flexibility depending on the complexity and needs of your application.