How Windows 3.11 Handled Print Drag and Drop

In Microsoft Windows 3.11, users could print documents seamlessly by dragging files from File Manager and dropping them directly onto the Print Manager icon or window. This article explains the technical mechanics behind this process, examining how the operating system utilized the 16-bit Shell API, the Windows Registration Database, and Dynamic Data Exchange (DDE) to interpret dropped items, summon the appropriate authoring applications, and automatically route jobs to the print queue.

The Shell Drag-and-Drop Subsystem

Windows 3.1 introduced a standardized shell drag-and-drop mechanism implemented in SHELL.DLL. For an application to participate as a drop target, it had to explicitly notify the operating system using the Windows API. When Print Manager (PRINTMAN.EXE) initialized, it invoked the DragAcceptFiles function, registering its window handle (HWND) with the operating system as an eligible drop target for file-based payloads.

When a user dragged a document from File Manager (WINFILE.EXE) and released the mouse over Print Manager, the Windows messaging subsystem posted a WM_DROPFILES message to Print Manager's main window procedure. This message contained an internal handle (HDROP) referencing a system-allocated memory structure containing the paths of the dropped files.

Extracting File Metadata

Upon receiving the WM_DROPFILES message, Print Manager retrieved the file information using the following sequence:

  1. Querying Files: It called DragQueryFile with an index parameter to determine the number of files dropped and subsequently extracted the full file path for each item.
  2. Releasing Resources: Once the file paths were safely copied into memory, Print Manager called DragFinish to release the memory structure associated with the HDROP handle.

Because Print Manager was merely a spooler interface and lacked built-in renderers for third-party file formats, it could not print documents directly on its own. It required an intermediary step to translate file data into printer-specific control codes.

File Associations and the Registration Database

To determine how to print a dropped file, Print Manager consulted the Windows Registration Database (REG.DAT), along with the [Extensions] section of WIN.INI. In Windows 3.11, REG.DAT acted as the 16-bit predecessor to the Windows Registry, storing associations between file extensions, programmatic identifiers (ProgIDs), and shell verbs.

Print Manager checked for a defined print verb mapped to the file's extension. For example, if a .WRI file was dropped, the registration entry for Write documents defined the exact execution command or protocol required to instruct Write (WRITE.EXE) to process the file without user intervention.

Automated Printing via Command Lines and DDE

Depending on how the registered application was configured in REG.DAT, Print Manager executed the print operation through one of two methods:

  • Command-Line Parameters: For simpler applications, the registration database defined a direct execution string containing the /p or /print switch (such as NOTEPAD.EXE /p %1). Print Manager executed the application in a minimized or hidden state via WinExec. The spawned application loaded the specified file, rendered the pages to the default printer driver, and automatically terminated upon completion.
  • Dynamic Data Exchange (DDE): For more sophisticated applications, such as Microsoft Word or Excel, Print Manager used DDE messaging. If the application was not already active, Print Manager launched it minimized. It then initiated a DDE conversation using the application name and the System topic, sending standard DDE execute macros—commonly formatted as [FileOpen("%1")][FilePrint()][FileExit()] or [Print("%1")].

Through these commands, the native application communicated with the Windows Graphic Device Interface (GDI) and the configured printer driver to generate raw spool data. The resulting spool files were dispatched back to the Windows 3.11 Print Manager spool queue, completing the drag-and-drop workflow.