Windows for Workgroups: How VSHARE.386 Manages File Sharing

This article has been archived. It is offered "as is" and will no longer be updated.
kbusage kbtshoot
The Windows for Workgroups file sharer, VSHARE.386, contains severalimprovements over the MS-DOS file sharing utility, SHARE.EXE. Theseimprovements allow Windows for Workgroups to share files in a mannersimilar to other network operating systems.

This article defines the file sharer (NOT the file server) and itsfunction in the operating system.
More information
To be able to allow multiple users or programs concurrent access tofiles and resources, an operating system must provide two basicservices:

  • Arbitration of access requests
  • Updating of in-memory information that describes resources
Under MS-DOS, these two functions are handled by a component known asthe file "sharer." This component is separate from the MS-DOS kernel.For MS-DOS versions 3.00 and later, this functionality is provided bythe terminate-and-stay-resident (TSR) program, SHARE.EXE. MicrosoftWindows for Workgroups version 3.1 when running in Enhanced Mode,replaces this with a new program, VSHARE.386.

VSHARE.386 is intended as a drop-in replacement for SHARE.EXE. BecauseVSHARE is an Enhanced Mode virtual device driver (VxD), it hasfeatures which improve file sharing under Enhanced Mode. Because itwas designed to work with Windows for Workgroups, VSHARE has featuresto make it "friendlier" than SHARE.EXE, especially in the area ofaccess control. If SHARE.EXE is loaded and you start Windows forWorkgroups in Enhanced Mode, VSHARE takes over as file sharer untilyou exit Windows. If you usually run Windows for Workgroups inEnhanced Mode, you may not need to run SHARE.EXE at all (this can save5K or more of conventional memory).

For each file open on the local computer, MS-DOS maintains a copy ofinformation about the file in memory. This includes both globalinformation that pertains to the file on disk, such as the file'slocation on disk and its size, and local information that pertains toeach open instance of the file, such as the application's filepointer. If a file is opened by multiple programs, and one applicationchanges a global attribute of the file, the sharer updates theinformation for all file handles open on that file.

NOTE: The file handles that applications use to keep track of filespoint to the copies of information about files maintained by MS-DOS inmemory.

If the real mode sharer SHARE.EXE is present without VSHARE, then allinformation needed to open a file must be in memory at all times, evenwhen Enhanced Mode virtual memory is being used. (Virtual memory cannotbe swapped into or out of memory while MS-DOS is busy with a filesystem request.) When you use VSHARE instead of (or in addition to)SHARE, file open information for multiple Virtual Machines (VMs) doesnot need to be in memory at the same time, only when each VM isactive. (MS-DOS applications run in separate VMs, and the Windows forWorkgroups file server runs its own separate VM.)

NOTE: This means you can use the Enhanced Mode PerVMFiles setting withVSHARE, which means you can open more files using VSHARE than usingSHARE when running Windows for Workgroups in Enhanced Mode. See the"Microsoft Windows Resource Kit," version 3.1, for a discussion of thePerVMFiles setting.

Unlike SHARE (which uses global conventional memory), VSHARE usesextended memory to store its copy of open file information. Thisgreatly increases the number of open files that Windows forWorkgroups, especially the server, can work with at once. Applicationswhich use file locking, such as Microsoft Mail, are less likely to runout of file locks with VSHARE than with SHARE.

Because Windows for Workgroups is designed to function as a peerserver, the access control rules used by SHARE have been relaxedsomewhat in VSHARE. SHARE forbids the opening of "compatibility mode"files while a "sharing" file is open, and vice versa. SHARE forbidsthe opening of "compatibility mode" files from different machines orVMs. Since a large percentage of MS-DOS applications and Windowsapplications still use compatibility mode, SHARE prevents the Windowsfor Workgroups server from operating effectively with several clientsconnected to one server (the only way SHARE could operate in thisenvironment is if all the files on the server had read-onlyattributes). This makes it inconvenient for network administrators toset up directories of shared files on a network file server.

Using VSHARE, a compatibility mode read request can be active fromdifferent machines and at the same time as most sharing requests. Thismakes it easy to set up a directory of shared files under Windows forWorkgroups. The access rules are only relaxed for "safe" accessrequests. If a process tries to open a file to write to it, forexample, the more restrictive set of rules is used.

This new file access behavior is known as "softcompat mode." Theremay be a reason to disable this, if there is a conflict with an olderapplication that has problems with the new access rules. This can bedone by placing "SOFTCOMPATMODE=FALSE" in the [386ENH] section of theWindows SYSTEM.INI file. There are no applications known to requirethis setting.

It is necessary to use a file sharer on any machine being used as afile server or peer server. If an access violation happens on aserver and "Sharing Violation" error message appears, it interfereswith server performance. This is because MS-DOS is in a criticalsection while the error message pop-up is visible. For this reason,VSHARE disables sharing violation pop-up messages on MS-DOS versions4.01 and greater. If this causes problems, you can add the"ENABLESHARINGPOPUPS=TRUE" setting to the [386ENH] section of theWindows SYSTEM.INI file. There are no applications known to requirethis setting.

The file sharer can also be used to control access to MS-DOS devicedrivers, if these are opened using MS-DOS file system calls. WithSHARE present, it is possible to get sharing violations on the NUL andCON devices. VSHARE does not generate sharing violation error messageswhen you access these devices. You can restore SHARE device sharingfunctionality by adding "TRADITIONALDEVICESHARING=TRUE" to the[386ENH] section of the Windows SYSTEM.INI file. There are noapplications known to require this setting.

Some applications are incompatible with file access checking. Ingeneral, it is not recommended that you run such applications underWindows for Workgroups, especially while the file server is running.You can use the SYSTEM.INI switch "IGNORESHARINGVIOLATIONS=TRUE" todiagnose such problems that occur when VSHARE is installed. Thisswitch turns off file access checking for all files and devices in thesystem. Use this switch to diagnose problems only; you should not useit to correct problems. It usually causes more problems than itsolves. If any application refuses to run with SHARE or VSHAREinstalled, contact the application vendor for assistance.

Sometimes problems occur where a "network aware" version of anapplication does not keep application documents open. Theseapplications attempt to arbitrate document access by using a semaphoreor marker in the document file or on disk. This technique usuallyfails in a multi-user network environment due to synchronizationproblems. In order to write an application properly to handle multi-user or multi-application access to data files, the first instance ofthe application accessing any data file should KEEP THE FILE OPEN toallow the file sharer and MS-DOS to communicate to subsequentapplications that the file is in use. This suggestion applies equallyto SHARE and VSHARE. There is no way that the file sharer can knowthat a file is "busy" unless it is actually kept open by theapplication.

Troubleshooting Tip

If problems with file sharing are suspected, remember that the filesharer responsible for a specific file is the sharer running on themachine where the file is physically located. If file sharing problemsoccur while you access a file on a network drive, modifying the VSHAREsettings on the local machine will not help.
3.10 tshoot

Article ID: 90239 - Last Review: 01/10/2015 10:54:49 - Revision: 2.0

Microsoft Windows for Workgroups 3.1

  • kbnosurvey kbarchive KB90239