How Windows 95 Implemented Right-Click Context Menus

When Windows 95 debuted, it fundamentally changed how users interacted with graphical user interfaces by establishing the right-click context menu as a universal standard across the desktop shell. This article examines the technical architecture behind that implementation, detailing how Microsoft moved away from the fragmented interaction models of Windows 3.1 by combining the Win32 messaging pipeline, the Component Object Model (COM), and the centralized Windows Registry to dynamically generate menus tailored to any selected object.

The Shift to an Object-Oriented Desktop

Prior to Windows 95, context-sensitive menus were rare, non-standardized, and implemented arbitrarily by individual applications. Windows 95 reimagined the desktop environment (codenamed "Chicago") as an object-oriented shell where every icon—whether a file, folder, drive, or system utility like the Recycle Bin—was treated as a discrete object with intrinsic properties and applicable actions.

To support this paradigm, the operating system required a system-wide mechanism to query an item for its available actions and present them directly at the cursor coordinates.

The WM_CONTEXTMENU Window Message

At the core of the user input layer was the introduction of the WM_CONTEXTMENU notification in the Win32 API.

Unlike previous approaches that relied strictly on monitoring individual mouse-down events (WM_RBUTTONDOWN), WM_CONTEXTMENU decoupled the user's intent to view a context menu from the physical hardware input. The message was dispatched when:

  1. The user released the right mouse button over a window (WM_RBUTTONUP).
  2. The user pressed the newly introduced Application/Menu key on compatible keyboards.
  3. The user pressed the accessibility shortcut Shift + F10.

When a child control did not handle WM_CONTEXTMENU, the message passed up the hierarchy to its parent window, ensuring consistent behavior across complex shell windows like Windows Explorer.

COM and the IContextMenu Interface

To allow context menus to be modular and extensible by third-party developers, Microsoft built the shell around the Component Object Model (COM). The shell represented context menus using the IContextMenu family of interfaces (IContextMenu, and later IContextMenu2 and IContextMenu3 for owner-drawn items and submenus).

When a user right-clicked an item, the shell executed a standardized sequence:

  1. Instantiation: The shell queried the target file system object or namespace extension for its IContextMenu interface.
  2. Menu Construction (QueryContextMenu): The shell created an empty pop-up menu handle (HMENU) and called IContextMenu::QueryContextMenu. The handler populated this menu with verbs (actions) appropriate to the target's current state, assigning unique command identifiers within an offset range provided by the shell.
  3. Display: The shell displayed the menu using the standard Win32 TrackPopupMenu API.
  4. Execution (InvokeCommand): Once a user clicked an item, the shell invoked IContextMenu::InvokeCommand, passing the selected verb or menu identifier back to the handler to carry out the operation (such as opening, printing, or extracting).

The Registry Architecture

The Windows Registry served as the lookup directory that bound file types to their respective context menu actions. Located primarily under HKEY_CLASSES_ROOT, the system supported both static and dynamic context menu entries.

  • Static Verbs: Simple commands were defined directly in the Registry under a file type's shell subkey (for example, HKEY_CLASSES_ROOT\txtfile\shell\open\command). The shell parsed these keys and automatically added them to the context menu without loading third-party code into memory.
  • Dynamic Handlers (Shell Extensions): Complex items that required conditional logic, dynamic text, or cascading submenus were registered under shellex\ContextMenuHandlers. These entries pointed to the GUID of a registered COM in-process server (a DLL). When right-clicked, the shell dynamically loaded the registered DLL into the Explorer process space to execute its IContextMenu routines.

Built-in System Verbs

By consolidating this functionality under a unified shell architecture, Windows 95 consistently applied baseline system verbs across the entire interface. Features that are standard today—such as "Send To", "Create Shortcut", "Cut", "Copy", and the unified "Properties" dialog—were themselves implemented as shell context menu extensions. This modular design ensured that whether a user clicked a physical hard drive, an unassociated file, or the desktop surface itself, the shell delivered a context-aware menu using the exact same underlying pipeline.