Purpose of the SHARE.EXE Command in MS-DOS 6.22

This article explains the purpose, functionality, and importance of the SHARE.EXE command in MS-DOS 6.22. It covers how the utility manages file sharing and record locking, why it was essential for networking and multitasking environments like Microsoft Windows 3.1, and how it was implemented in DOS system configurations.

The primary purpose of SHARE.EXE in MS-DOS 6.22 is to install support for file sharing and record locking on local drives and network shares. Because MS-DOS was fundamentally designed as a single-tasking, single-user operating system, it lacked built-in mechanisms to coordinate access when more than one program or user attempted to read from or write to the same file simultaneously. Running SHARE.EXE loads a terminate-and-stay-resident (TSR) program into memory that intercepts DOS file-access interrupts (specifically Interrupt 21h) to enforce file integrity and prevent data corruption.

File locking allows an application to reserve an entire file for exclusive use, preventing other programs from opening or modifying it until the first program closes it. Record locking goes a step further by allowing a program to lock specific byte ranges within a single file. This capability was vital for multi-user database engines, such as dBASE, FoxPro, or Paradox, where multiple users or processes needed to read and update different records in the same database table at the same time without overwriting each other's changes.

In MS-DOS 6.22, SHARE.EXE was most commonly required in two scenarios: Local Area Network (LAN) environments and multitasking operating environments like Windows 3.1 or 3.11. When a machine acted as a peer-to-peer server using networking software like Microsoft LAN Manager or the Microsoft Workgroup Connection, SHARE.EXE ensured that remote network users could not corrupt shared files. Similarly, running Windows 3.1 allowed multiple applications to run concurrently; features like Object Linking and Embedding (OLE 2.0) and Microsoft Mail explicitly required SHARE.EXE to be loaded before Windows started to prevent simultaneous write conflicts.

Users typically loaded SHARE.EXE during system startup by adding it either to the CONFIG.SYS file using the INSTALL command:

INSTALL=C:\DOS\SHARE.EXE

or by invoking it directly within AUTOEXEC.BAT:

C:\DOS\SHARE.EXE

The command supported optional switches, primarily /F:space to allocate the amount of memory (in bytes) reserved for file-sharing information, and /L:locks to specify the maximum number of files that could be locked simultaneously. In modern virtualization and DOS emulation environments, SHARE.EXE or its emulated equivalent remains a requirement when running legacy multi-user software to avoid file-access violations.