Windows 3.11 Mouse Click Processing on Icons

In Microsoft Windows 3.11, processing a mouse click on an icon required a coordinated sequence across hardware interrupts, low-level drivers, the core 16-bit windowing subsystem, and the shell. Because Windows 3.11 operated on a cooperative multitasking architecture over MS-DOS, event routing relied on a single centralized system queue that translated physical hardware signals into targeted window messages, which were then resolved by Program Manager or minimized window handles.

When a user pressed a mouse button, the physical device signaled the computer via a hardware interrupt (typically IRQ 12 for PS/2 mice or IRQ 4/COM1 for serial mice). The MS-DOS mouse interrupt handler caught this signal and passed control to the Windows mouse driver (MOUSE.DRV). Operating in protected mode, MOUSE.DRV converted the raw hardware packets into coordinate deltas and button status flags, then handed this data directly to the input subsystem inside USER.EXE.

USER.EXE converted the low-level mouse status into absolute screen coordinates and checked current system metrics to determine whether the action was a single click or a double-click. If a prior WM_LBUTTONDOWN had occurred within the system double-click time threshold and within a predefined bounding box of pixels, the subsystem prepared a WM_LBUTTONDBLCLK message; otherwise, it prepared a standard WM_LBUTTONDOWN message.

Next, the window manager determined which window should receive the event by performing hit-testing. Unlike modern versions of Windows, the "desktop" in Windows 3.11 had two distinct types of icons:

1. Minimized Application Windows: Running applications that were minimized existed directly on the desktop window (the root window managed by USER.EXE). These icons were actually top-level windows styled with the WS_MINIMIZE flag, drawn to look like standalone icons.
2. Program Items: Shortcuts inside Program Manager (PROGMAN.EXE) resided within Multiple Document Interface (MDI) child windows representing Program Groups.

To identify the target, USER.EXE scanned the window hierarchy using an internal equivalent of WindowFromPoint based on the cursor’s (X, Y) coordinates.

If the click occurred over a minimized application window on the root desktop, the message was directed to that application's window handle (HWND). If the click landed inside an open Program Manager group window, the handle belonged to that MDI group child window.

Once the target window handle was established, USER.EXE placed the formatted message into the application's message queue. Because Windows 3.11 used cooperative multitasking, the target application had to actively retrieve the message via its event loop:

1. The application called GetMessage() to extract the event from the queue.
2. The application called TranslateMessage() to handle any potential keyboard-related conversions.
3. The application called DispatchMessage(), which instructed USER.EXE to call the target window's designated callback function, the Window Procedure (WndProc).

When Program Manager's group window received the message in its WndProc, it mapped the click coordinates against its internal list of program item boundaries. Upon receiving a single click, it redrew the item label in an inverted color state to indicate selection. Upon receiving a double-click (WM_LBUTTONDBLCLK), Program Manager retrieved the associated command line properties for that item and called the Windows API function WinExec() to launch the target executable.