Windows 3.11 SCR Screen Saver Support Explained

This article explores how Microsoft Windows 3.11 implemented and executed screen savers using the .SCR file extension. In Windows 3.1x, screen savers were not proprietary animation formats but standard 16-bit executable programs disguised under a different extension. Managed by the Desktop Control Panel and configured via Windows initialization files, these modules relied on shared SDK libraries to handle idle detection, configuration interfaces, and password protection to prevent cathode-ray tube (CRT) monitor phosphor burn-in.

The Architecture of .SCR Files

Beneath the .SCR file extension, a Windows 3.11 screen saver was a standard 16-bit New Executable (NE) format binary, identical in internal structure to an .EXE file. Microsoft used the .SCR extension solely to differentiate screen savers from regular desktop applications.

To be detected by the operating system, .SCR files were placed in the primary Windows directory (typically C:\WINDOWS) or the C:\WINDOWS\SYSTEM directory. When the user opened the Desktop settings inside the Control Panel (CONTROL.EXE), the system scanned these directories for any files ending in .SCR, extracted their description strings from the module's resource table, and populated the screen saver drop-down menu.

Command-Line Execution Modes

Windows 3.11 launched screen saver executables with specific command-line arguments depending on the user's actions. An .SCR file needed to parse these flags to determine which window mode to present:

  • /s: Run the screen saver. Windows invoked this switch when the system remained idle past the configured timeout limit, or when the user clicked the "Test" button in the Control Panel. The module created a full-screen window covering the desktop, hid the mouse cursor, and rendered its visual routines.
  • /c: Display configuration. Windows passed this flag when the user clicked the "Setup" button in the Desktop Control Panel. The screen saver invoked its embedded modal dialog box, allowing users to configure settings such as speed, density, or custom text.

If an .SCR file was launched with no flags (such as when double-clicked in File Manager), it typically defaulted to configuration mode.

System Integration and INI Files

Windows 3.11 tracked screen saver selections using system configuration files, primarily SYSTEM.INI and CONTROL.INI:

  • SYSTEM.INI: The [boot] section contained the key SCRNSAVE.EXE=path\to\saver.scr. The system boot environment referenced this entry to load the designated screen saver.
  • CONTROL.INI: Stored individual screen saver parameters, color schemes, and password settings. Each screen saver had its own dedicated section, such as [Screen Saver.Marquee], where module-specific variables were maintained.

Idle tracking was managed by the core Windows graphical subroutines. Windows monitored user interaction through global event queues; if no mouse movement or keyboard input was registered within the timeout threshold set in CONTROL.INI, Windows called the WinExec API to launch the configured .SCR file with the /s parameter.

The Role of SCRNSAVE.LIB

To simplify development, Microsoft provided a static link library in the Windows Software Development Kit (SDK) called SCRNSAVE.LIB. Rather than writing boilerplate code for Windows event management, developers linked this library to handle system-level requirements automatically:

  1. DefScreenSaverProc: Similar to DefWindowProc, this specialized procedure intercepted basic input events. It monitored mouse coordinates, button clicks, and keystrokes, instantly closing the screen saver window and restoring the desktop when interaction occurred.
  2. Password Verification: If the user enabled password protection in the Control Panel, SCRNSAVE.LIB handled the comparison routines, halting exit until the correct password was entered.
  3. Registration and Instantiation: The library provided the default WinMain entry point, which parsed the /s and /c command-line switches and routed execution either to the developer's rendering loop (ScreenSaverProc) or configuration dialog procedure (ScreenSaverConfigureDialog).

By standardizing these behaviors inside an executable format, Windows 3.11 achieved a modular screen saver architecture that was lightweight, backwards-compatible, and straightforward for third-party developers to implement.