Windows 3.11 Cut and Paste Keyboard Shortcuts

In Microsoft Windows 3.11, processing keyboard shortcuts for cutting and pasting text relied on a cooperative multitasking pipeline that translated hardware interrupts into standardized window messages. When a user pressed a shortcut—such as the legacy IBM CUA keys (Shift+Delete, Shift+Insert) or the newer standard combinations (Ctrl+X, Ctrl+V)—the operating system routed the physical input through a dedicated keyboard driver, converted the keystrokes via accelerator tables, and handed the execution over to edit control procedures that directly communicated with the Windows Clipboard API.

1. Hardware Interrupts and Driver Translation

The process began at the hardware level. When a user pressed a key combination, the keyboard controller generated hardware interrupt IRQ 1.

The Windows 3.11 keyboard driver (KEYBOARD.DRV) intercepted this interrupt and processed the raw scancodes. The driver tracked the status of modifier keys (Control, Shift, and Alt) in internal state tables. Using the ToAscii API function, the driver converted the scancodes and modifier states into Windows virtual-key codes, generating low-level messages such as WM_KEYDOWN, WM_KEYUP, and WM_SYSKEYDOWN. These messages were then placed into the system's message queue.

2. The Message Loop and Accelerator Tables

Each running 16-bit application maintained its own message loop using standard API calls: GetMessage, TranslateMessage, and DispatchMessage.

To process keyboard shortcuts without requiring every window to parse individual keystrokes, applications used an accelerator table loaded via LoadAccelerators. Inside the message loop, the function TranslateAccelerator inspected incoming WM_KEYDOWN messages:

  • If a shortcut like Ctrl+V or Shift+Insert was detected, TranslateAccelerator consumed the keystroke message.
  • It immediately converted the keystroke into a WM_COMMAND message containing a specific menu identifier (such as ID_EDIT_PASTE) and sent it directly to the active window's procedure (WndProc).

3. Edit Control Handling

If the active control was a standard text box—implemented by Windows 3.11's built-in EDIT control class—it handled shortcut processing natively.

The edit control's internal window procedure listened both for command messages from application menus and for direct keystroke messages:

  • Ctrl+X or Shift+Delete triggered text removal and clipboard export.
  • Ctrl+C or Ctrl+Insert triggered text duplication to the clipboard.
  • Ctrl+V or Shift+Insert triggered text retrieval and insertion.

When identified, the control internally translated these events into standard clipboard control messages: WM_CUT, WM_COPY, and WM_PASTE.

4. Interfacing with the Clipboard API

Once a WM_CUT or WM_PASTE message was triggered, the edit control executed the actual data transfer through the Windows Clipboard subsystem:

  • For Cutting Text: The control calculated the byte length of the selected text and allocated a global memory block using GlobalAlloc with the GMEM_MOVEABLE and GMEM_DDESHARE flags. It copied the selected characters into this block, locked it with GlobalLock, and called OpenClipboard(hWnd). The control then called EmptyClipboard() to clear previous data, followed by SetClipboardData(CF_TEXT, hGlobalMemory) to store the new text. Finally, it called CloseClipboard() and deleted the selected characters from the screen buffer.
  • For Pasting Text: The control called OpenClipboard(hWnd) and queried whether plain text was available using IsClipboardFormatAvailable(CF_TEXT). If available, it called GetClipboardData(CF_TEXT) to obtain the memory handle, locked the memory to read the string pointer, inserted the text into its local text buffer at the current caret position, called CloseClipboard(), and repainted the control to show the updated text.