Windows 3.11 Program Manager Launch Parameters

In Microsoft Windows 3.11, Program Manager managed application launch parameters by pairing user-defined command lines with the 16-bit Windows execution subsystem. Users configured static arguments or interactive prompts directly through program item properties, which Program Manager bundled into a command string and passed to the underlying operating system APIs to launch the target executable with the designated parameters.

Configuration via Program Item Properties

Program Manager (PROGMAN.EXE) served as the primary shell in Windows 3.11. To assign launch parameters to an application, users selected a program icon and navigated to File > Properties (or pressed Alt+Enter) to open the Program Item Properties dialog.

The configuration relied on two key fields:

  • Command Line: Contained the path to the executable followed by any launch flags, switches, or file paths (e.g., C:\WINDOWS\NOTEPAD.EXE C:\CONFIG.SYS).
  • Working Directory: Defined the initial active directory where the application executed, ensuring relative path parameters resolved properly.

Static Arguments and Interactive Prompts

Windows 3.11 supported both static and variable parameters:

  • Static Parameters: Arguments hardcoded directly into the Command Line field were sent unconditionally to the application every time the icon was executed.
  • The Question Mark (?) Dynamic Prompt: If an administrator or user placed a ? anywhere after the executable name in the Command Line field (e.g., NOTEPAD.EXE ?), Program Manager intercepted the execution request. Before launching the program, it displayed an interactive dialog box asking the user to supply the remainder of the command line, enabling dynamic, runtime argument input.

The Underlying Execution Mechanism

When a user launched a configured icon, Program Manager handled the execution through the 16-bit Windows kernel:

  1. String Assembly: Program Manager parsed the Command Line field. If a dynamic ? prompt was used, it concatenated the user’s input into the main command string.
  2. Calling WinExec: Program Manager passed the resulting null-terminated string to the 16-bit Windows API function WinExec(LPCSTR lpCmdLine, UINT uCmdShow). Alternatively, it used LoadModule, which populated a parameter block containing an environment segment and command-line tail.
  3. Delivery to WinMain: The Windows kernel loaded the application and called its entry point, WinMain. The third parameter of WinMain, LPSTR lpCmdLine, received the launch arguments as a single, unparsed raw string containing everything typed after the executable's name.

Unlike standard C main(int argc, char *argv[]) conventions found in DOS or modern runtime libraries, 16-bit Windows did not automatically tokenize the parameters into an array. The target application's runtime initialization routines (or the developer's custom parsing logic) were responsible for tokenizing the raw lpCmdLine string into distinct options and file paths.

File Associations and Extensions

Program Manager also handled parameters implicitly through Windows file associations. If a user entered a document file directly into the Command Line field or the File > Run dialog (such as REPORT.WRI), Program Manager referenced the [Extensions] section of WIN.INI or the 16-bit Registration Database (REG.DAT). Once the associated handler was identified, Program Manager automatically substituted the document's path as the launch argument for the associated executable.