Input and Windows Events

The DAClass window procedure is the boundary between the Win32 message queue and the client’s asynchronous event system. It handles a fixed set of 15 message values. Keyboard and mouse messages update immediate window or screen state, then enter the EventMan worker queue. Activation, palette, socket, virus-check, and destruction messages remain on the window thread.

High-level operation

Message-pump boundary

app_win_main blocks in GetMessageA, calls TranslateMessage, and sends each retrieved message through DispatchMessageA. The registered DAClass procedure is win_main_window_proc. This is an event-driven pump, not the rendering or game-tick loop. Timer work runs on the event-dispatcher worker described in Internal Event Routing.

The window procedure returns 0 for every message it recognizes. All other messages go to DefWindowProcA. This includes WM_CLOSE, so the default procedure destroys the window and the resulting WM_DESTROY case posts WM_QUIT. It also includes WM_CHAR, WM_PAINT, WM_SETFOCUS, WM_KILLFOCUS, WM_TIMER, and WM_QUERYNEWPALETTE. TranslateMessage can therefore produce a WM_CHAR, but the client has no explicit text-message branch here.

Complete handled-message table

All handler locations below are inside Darkages.exe:0x0045BDC0 win_main_window_proc.

The last two rows are the only application-defined messages recognized by this window procedure.

Mouse input and message time

Every handled mouse message first performs the same software-cursor update under the critical section at screen-pane offset +0x534. The procedure restores the old cursor area with sub_49D850, calls ui_screen_pane_set_cursor_position, then draws or presents the new cursor area through the entry at sub_49D120. This occurs before EventMan input blocking is checked.

Coordinate handling has several exact quirks:

• The low word of lParam is zero-extended. Values at least 640 become 639. The apparent negative clamp cannot be reached after zero extension.
• The high word is obtained with a logical shift and is neither sign-extended nor clamped.
• WM_MOUSEWHEEL goes through the same coordinate path. Windows supplies wheel coordinates in screen space, but this procedure does not call ScreenToClient before treating them like the other mouse coordinates.

Each message then calls GetMessageTime and places that 32-bit timestamp in the EventMan work record. Mouse movement allocates and transfers ownership of an eight-byte pair stored internally as (y, x), matching the screen-pane cursor calls. Button messages use the most recently stored coordinates. The worker divides a signed wheel delta by 120 before dispatching its mouse Event.

EventMan field +0x4B0 bit 0 blocks movement, wheel, button-down, and key-down queueing. Releases are deliberately different: left-button up, right-button up, and key up still queue while input is blocked. Button state is held at +0x4B4, with bit 0 for left and bit 1 for right.

The worker recognizes double-clicks itself rather than relying on WM_LBUTTONDBLCLK or WM_RBUTTONDBLCLK, neither of which is handled. It compares the new down timestamp with its stored timestamp and requires total horizontal plus vertical movement of at most two pixels. It dispatches mouse subtypes 1 and 2 for left single and double down, 3 for left up, 4 and 5 for right single and double down, 6 for right up, and 7 for wheel. Mouse movement uses subtype 0.

Keyboard input

The client queues physical scan codes rather than the wParam virtual-key value. Bits 16 through 23 of lParam supply the scan byte. If KF_EXTENDED bit 24 is set, the procedure adds 0x80 and keeps the low byte. A resulting zero is ignored. Repeat count and previous-key-state fields do not suppress repeated key-down messages.

uint8_t input_scan_code(uint32_t key_data)
{
    uint8_t scan_code = (uint8_t)(key_data >> 16);

    if ((key_data & 0x01000000U) != 0) {
        scan_code = (uint8_t)(scan_code + 0x80U);
    }

    return scan_code;
}

WM_SYSKEYDOWN and WM_SYSKEYUP contain one special path. If wParam is VK_F4, the Alt-context bit 29 is set, and Darkages.exe:0x0043DE20 returns a nonnull UI object, the code rewrites the scan byte to 0x10, clears the extended and Alt-context bits, and preserves selected high transition bits. The down and up messages then continue through their ordinary paths. The code establishes the remap but does not establish its original design intent.

On the EventMan worker, event_dispatch_key_down marks the scan code pressed, applies the client’s scan-code mapping and modifier tables, and dispatches key subtype 8 when the mapped value is nonzero. event_update_key_up clears pressed and modifier state but does not dispatch a key-up Event to panes.

Activation, palette, and shutdown messages

The application-level activation message is WM_ACTIVATEAPP, not WM_ACTIVATE. A zero wParam invokes a render-object virtual method, minimizes the window with SW_MINIMIZE, emits a 2000 Hz beep for 100 ms, and clears app_window_active. A nonzero wParam repeats the Brothers Speeder top-level-window check. A match sets app_shutdown_requested, posts quit, and posts WM_CLOSE. Otherwise the client restores a 640 by 480, 8-bit presentation configuration, uses SW_RESTORE, sets app_window_active, and calls ui_screen_pane_activate.

WM_PALETTECHANGED is ignored when the sender in wParam is the main window or when no screen pane exists. Otherwise render_screen_pane_load_palette reads 256 RGB entries from legend.pal, preserves the system-reserved palette entries at both ends, applies the palette, and marks the screen palette dirty. The procedure then calls the small screen-pane apply entry at Darkages.exe:0x0049D0E0.

WM_DESTROY only posts WM_QUIT. It does not perform subsystem cleanup itself. The message loop returns to app_win_main, which calls app_shutdown as described in Startup and Shutdown.

Application-defined messages

WM_USER + 2 is registered by net_connect_configured_server through WSAAsyncSelect with FD_READ | FD_CLOSE. win_main_window_proc uses only LOWORD(lParam): FD_READ calls net_queue_receive, and FD_CLOSE calls net_handle_disconnect. Other network-event values are ignored. The procedure also ignores the socket in wParam and the WSAGETSELECTERROR value in the high word of lParam. The receive and framing path is documented in Networking.

WM_USER + 0x2046 belongs to the process/module virus-check worker. app_virus_check_module_callback copies the first reported module name into the 256-byte app_virus_report_module buffer and posts the message with that pointer in wParam. The window procedure formats it as a quoted name. A zero wParam instead inserts app_virus_check_failure_detail into a Korean format string whose meaning is, “Could not perform the virus scan. ( %s ) Would you like to continue?”

The report is sent to the first available target in this order: the object returned by sub_4AD130, dword_4F51AC, then receiver. The procedure allocates a 0x554-byte report object and initializes it with sub_498CE0. If no target exists, it calls MessageBoxA with caption LOD and type MB_OK. The subsequent IDCANCEL shutdown test is not reachable through an ordinary MB_OK message box, although the code contains it.

Code-level flow

Dispatch and default processing

app_win_main
  -> GetMessageA
  -> TranslateMessage
  -> DispatchMessageA
      -> win_main_window_proc
          -> explicit handler for one of 15 message values
          -> DefWindowProcA for every other value

Darkages.exe:0x0045BDC0 win_main_window_proc is a direct comparison chain rather than a jump table. Its four parameters have the normal WNDPROC contract. Every explicit branch returns zero.

Mouse queue and worker path

win_main_window_proc
  -> sub_49D850
  -> ui_screen_pane_set_cursor_position
  -> sub_49D120
  -> event_manager_get_instance
  -> GetMessageTime
  -> event_queue_mouse_*                  work code 4 through 9
      -> util_thread_queue posting path
          -> event_process_work_item
              -> event_dispatch_mouse_*   Event subtype 0 through 7
                  -> event dispatcher pane routing

Keyboard queue and worker path

WM_KEYDOWN or WM_SYSKEYDOWN
  -> scan-code normalization
  -> event_queue_key_down                 work code 0x0A
      -> event_process_work_item
          -> event_dispatch_key_down      key subtype 8 when mapping succeeds

WM_KEYUP or WM_SYSKEYUP
  -> scan-code normalization
  -> event_queue_key_up                   work code 0x0B
      -> event_process_work_item
          -> event_update_key_up          state update, no pane Event

event_dispatch_key_down stores pressed state in the per-scan-code table beginning at EventMan offset +0x390. It combines the active modifier byte at +0x490 with mapping tables at +0x90, +0x190, and +0x290. One internal mapped value, 0x88 with state bit 0 set, also sets app_shutdown_requested and posts WM_CLOSE before the key Event is dispatched.

Socket and virus-check messages

net_connect_configured_server
  -> WSAAsyncSelect(..., WM_USER + 2, FD_READ | FD_CLOSE)
      -> win_main_window_proc
          -> net_queue_receive
          -> net_handle_disconnect

app_virus_check_thread
  -> module scanner callback
      -> app_virus_check_module_callback
          -> PostMessageA(..., WM_USER + 0x2046,
                          app_virus_report_module, 0)
              -> win_main_window_proc
                  -> active UI report receiver
                  -> MessageBoxA fallback

The module callback posts only the first infected-module name because it first requires app_virus_report_module[0] == 0. It also clears the virus-check continuation flag after posting, which causes the worker’s loaded scanner callbacks to stop their traversal.

Function table