---------------------------------------------------------------------
GENEALOGY OF SHARE

    Share is an extension to MS-DOS that was introduced in DOS 3.x.
For Microsoft DOS this was 3.0, for others OEM's it varied from 3.1
through 3.3 [2]. The major purpose was to provide a mechanism for more
than one program to access a file simultaneously. This had become
critical because DOS 3.x was the first version to provide network
capability in DOS. Thus there could be several workstations accessing
the same file and some methodology to prevent several workstations from
corrupting data in a file needed to be implemented. This had been a
minor problem previously because DOS could only run one program at a
time on a single computer. So by default it was impossible to get to a
situation where 2 programs on the same computer could access a file at
the same time (this is not actually true. TSR's can pop up and open a
file your running program has open. This is one of the reasons why
TSR's that do file input/output must be written very carefully).

    The access to files was controlled with two purposes in mind. The
first was to deny access to a file from one program if a different
program opened the file exclusively for itself. The second purpose was
for several programs purposely open the file in a shared basis so they
all could access the information.  This also provided the ability for
one program to "lock" parts of the file so it could update or change
that part of the file. This locking is used in a lot of programs like
a multiple user database ( Btrieve, Access, Paradox, etc.).

    What actually happened has lead to a lot of confusion. First,
Microsoft's LAN system never took off based upon DOS. Novell Netware
was already doing LAN's and they implemented their file sharing
differently. Novell already had LAN's before DOS 3.x came out.
Banyan's LAN is actually UNIX. They implemented sharing in UNIX so it
looked like share functionally through the DOS file system access. So
share was not used much. This was during the mid 1980's.

    Then DOS 4.x came out. It was the first version of MS-DOS that
allowed hard disk partitions greater than 32 Mb. Other OEM's (Compaq
3.31 and Wyse 3.1 had partitions greater than 32 Mb by other
non-standard ways).  The old 32 Mb limit was based upon older programs
accessing files using the old FCB's (File Control Blocks the only
method prior to DOS 2.0). The capability to use FCB's on partitions
greater was put into share, because it was already doing something
similar. If you did not have share loaded in DOS 4.x, DOS would give
you a warning (and even search your root directory and load
it if it finds it). People did not understand these messages and ran
fine for months. Then one day they ran a program that used FCB's to
access a file past 32 Mb. Instead it wrapped around and corrupted your
disk. Hopefully not something vital. (i.e. access on the first sector
past 32 Mb, would wrap to the boot sector of your disk. The next
couple would get the file allocation table. Later sectors would get
files, maybe the 2 hidden DOS file or COMMAND.COM. Later areas would
get other files.). On program that uses FCBS is COMMAND.COM. It uses
FCBS to get the volume label. 4DOS does not. The versions this affects
needs to be investigated. [1]

    These warning messages without problems for a while gave share a
bad name. Some thought it was needed some thought it was not. The
reason for share in DOS 4.x, was not adequately documented. Also
some seldom used DOS functions in DOS 4.x themselves used FCB's. In
DOS 5.0 the FCB's functionality was moved into the 2 DOS hidden files
where it should have been all along. Now SHARE was back to it's
original functions, but a lot of misconceptions have been spread about
share.

    But now along comes Windows 3.0 and because of its 386 enhanced
mode it took off in popularity. It allowed the running of multiple
windows and DOS programs with the ability to access same files at the
same time on the local hard disk. So Microsoft stated that you had to
have share loaded before starting Windows. Some people did this, some
did not. Some tried to load share after Windows was started in a DOS
session, and got the response that "Share is already loaded". A look
at the documentation showed very little information about share.

    When DOS 5.0 came out, share functionally was moved into DOS
hidden files and the annoying warning messages at boot time went away.
[4] Some people loaded share as stated in the Windows manuals, some
took it out of their AUTOEXEC.BAT because they did not know what it
did. Some people had problems, some did not. Those that had problems
blamed Windows 3.0, because of the reputation it got with UAE's and
other unsolved crashes.

    Microsoft came out with Windows 3.1, and the number of Windows
problems went down considerably. But there were still some files
getting corrupted. It was now becoming clearer that despite the
instructions from Microsoft, many people were NOT loading share before
Windows and corrupting their data files. Some people were just using
what was provided them, some thought they knew better, some could not
find any good technical background in the literature.  But many
Microsoft applications do allow sharing of files and depend upon
share's protection. Access will not let you into a database in write
access, if share is not loaded. Word of Windows 6.0 and Excel 6.0
reportedly also check for share and will balk if they do not find it
loaded. [4]

    SHARE functionality will be a basic part of Chicago (DOS 7 and
Windows 4.0 combined). [4] A strong hint is Windows for Workgroups
3.11. It does not need share. It loads a protected mode program (32
bit Vxd) called VSHARE.386 that handles the functionality of share for
Windows. This file is also distributed as part of the Word for Windows
6.0a upgrade package.  Microsoft distributed a "Product Services
Application Note". It describes a version VSHARE.386 that is compatible
with Windows 3.1 and Windows for Workgroups 3.11. This version of
VSHARE.386 is 3.11.0.401.  The file for VSHARE.386 is 1-11-94  12:00a
at 14933 bytes. This file is installed into your \WINDOWS\SYSTEM
sub-directory. You add a "device=vshare.386" to your SYSTEM.INI in the
[386Enh] section. The note also says that SHARE.EXE must be removed
from your AUTOEXEC.BAT.  There is no information about what might
happen if you have both SHARE.EXE and VSHARE.386 installed. Hopefully,
VSHARE.386 is smart enough to take control. The standard installation
of Access installs share.exe with configurations to take about 15K of
base memory. VSHARE.386 uses extended memory instead (how much?). Some
reports seem to indicate that VSHARE.386 may take up more base memory
when Windows loads. Some user have reported the following setting
but the use is uncertain:

        IGNORESHARINGVIOLATIONS=True / False (default to False)
        SOFTCOMPATMODE=
        TRADITIONALDEVICESHARING=
        ENABLESHARINGPOPUPS=

IGNORESHARINGVIOLATION=TRUE has allowed to open a locked file twice
when set to true, according to one report.

---------------------------------------------------------------------
HOW SHARE WORKS

    For background we will discuss how share works, giving heavy
emphasis to the user configurable command line argument. Share looks
like a TSR you load in your autoexec.bat or load from the command
line. It chains onto the multiplex interrupt for communication with
other programs.  But underneath, it is NOT a TSR in the normal sense.
It attaches itself to COMMAND.COM and becomes an unextractable part of
it even though it is usually located in a separate section of memory.
In COMMAND.COM, share writes it memory locations so COMMAND.COM can
locate it directly in memory. Thus it becomes part of COMMAND.COM. If
you use the old MARK/RELEASE before SHARE like most other TSR's, you
are heading for disaster. When you release SHARE, COMMAND.COM still
thinks share is loaded, and it also thinks it knows where. So next
time a program accesses a file, COMMAND.COM goes to share's old
location. The odds are different program is there and instant computer
hang. Once share is loaded it is part of COMMAND.COM, it must stay
loaded, at that memory location. The only way to safely remove it is
to reboot the computer, and of course not have share in your
AUTOEXEC.BAT. [4]

    During SHARE's execution, it requires memory space to store two
data tables. The amount of space for these tables and consequently
their resulting capacity is controlled at invocation by two parameters
/F and /L. If one or both parameters are missing then defaults are
used [explained below]. The defaults are fine for most applications,
but can easily be violated by a large number of users or applications
that behave in certain ways. Unfortunately, when SHARE runs out of
space to do its job, applications seldom report the correct error
message. Therefore, a good understanding of what these parameters mean
can solve a lot of related problems.

When a file is opened for use in a program. SHARE in conjunction with
DOS performs a number of checks on the request.  First, if not already
in use by another user, SHARE enters the complete pathname for the
file in its internal table and assigns that entry an internal handle
number. It then enters in a second table the handle and a number which
represents the file area being used and how it is being used by this
particular application. This construction is called a LOCK! If the
file being used had already been opened by another user, it already
has an entry in the table and a unique handle. In this situation,
SHARE scans the lock table for LOCKS which match this file, then makes
a determination on whether or not to grant the file request based on
possible LOCK collisions. [3] DOS will try to open the file several
times before it gives up on a sharing violation. This is the reason
why our Scheduler Publisher LAN program has not gotten any sharing
violations when writing to the log file. If another user's program is
writing it's one line to the file, a second user cannot open it. But
the first user will finish the write and release the file before the
DOS times out try to open the file for the second user.

THE /F PARAMETER:
    The first data table that SHARE maintains is a two dimensional
table that stores the COMPLETE PATHNAME for each open file and an
associated handle number. SHARE needs enough memory to store the full
pathname of each open file plus eleven bytes for the handle and
overhead. The parameter represents the amount of space IN BYTES to
reserve for this table. You can find a worst case scenario by writing
the pathname (before drive redirection) of the longest filename in the
deepest sub-directory, adding eleven bytes and multiplying by the
number of FILES in your CONFIG.SYS. For example, my longest pathname
is: "C:\utility\diags\clocks\uscal.dat" and my FILES= in CONFIG.SYS is
40. The pathname contains 33 characters + 11 = 44. 44 * 40 = 1760. So
at worst case, the /F should read /F:1760. By default /F starts at
2048, which should be enough for FILES= of 65 or less.  In actual
practice, DOS is usually not called upon to maintain more than fifty
files open at once.[3]

THE /L PARAMETER:
    This is the more important part, pay attention! Each open
file also requires at least one lock but could have dozens. Each
time an application requests a portion of a file (such as a
record in a database) a lock on only that portion of the file
that contains the desired information is issued. The lock remains
in effect until the application program specifically removes it.
In Dbase and Foxbase (and others), there is a program imposed
restriction of only one lock used in each database file (two get
used really). However, in other programs like FoxPro/LAN and
Btrieve, an unlimited number of locks can be issued on each
file. [Well, unlimited is limited to the number of small chunks
that a file can be broken up into.] So with these programs, one
could have ten open databases with say fifty record locks in
each. This means that SHARE would be maintaining 510 locks plus
maybe a dozen or so extra locks for other open support files. WOW
522 locks!! The /L parameter specifies the maximum number of
locks that can be used and defaults to a paltry sixty. Each lock
requires that seven bytes be reserved in memory. Locks are harder
to predetermine, but since they are cheap it pays to be generous
with them. [3] Note, there are several programs in use at DCPP that
use databases. Some of them are not apparent. MailMan uses a
Btrieve data base (to store the local address book?).

---------------------------------------------------------------------
PROBLEMS WITH SHARE

    The single most problem with share is that people do not
understand the complexity that running more than one program on a
computer can interact with each other. This has been compounded by the
lack of documentation, and some "red herring" error messages (or lack
of them). Even with that there are some problems that DOS/SHARE can
surface during normal operations.

1-Share will only let you write to file handles that the program
  has open. Older versions of DOS, would let a program write to a file
  it had opened and subsequently closed. With share, this is now
  enforced, because share only lets a program write to files it still
  has open. It is legal for program "A" to close file #1, and program
  "B" have it open, so share disallows writing to closed file handles.
  There are some commercial programs that write to closed files and
  thus "are broken when share is loaded".  [4]

2-Share records all files a program has open inside data areas
  in share (the size of the areas can be changed when share is
  loaded). When a program opens the file share records it. When
  a program closes a file, share takes it out of its database.
  If a program terminates without closing files (like terminating
  a DOS session in Windows, not shutting down the program and
  exiting the DOS session), share is NOT notified to clean up
  the file handles of the terminated program. OS/2 and NT handle
  the cleanup properly, Desqview does (???).
  There is a program that can free orphaned file handles. This is
  in "Undocumented DOS" 1st and 2nd editions, but it does not
  correct any of the information in SHARE. [4]

  This is compounded more by some crash-proofing in Banyan Vines.
  Banyan Vines keeps the files opened by a user on a network
  drive somewhere on the server. It is probably with the File
  Services for that particular file service. This information
  is stored in non-volatile storage (maybe cached). If a server
  reboots while an application has files open on the server, that
  application will still have those files open after the server
  is up and running. So a program on a workstation that has files
  open on the server can ride out a server re-boot and sometimes
  a crash. In practical matters this seldom works. The reason is
  the user does something that requires the application to access
  the files while the server is down. The application cannot
  access the file and generates a DOS critical error. The user
  usually closes the application because the application requires
  immediate access. If the server goes down, and nothing is done
  in the application (do not touch the keyboard!), when the server
  comes back up (the file services), the connections between the
  workstation and the server (file services) will be restored
  invisible to the application program.
  NOTE: This means that when the server comes back up it has
        your files open. This also works when the workstation
        is rebooted!
  When a workstation is rebooted, the server keeps the files open
  for that user ID. If that user does nothing, the files are open
  to that user. If someone tries to access the files (in exclusive
  mode), other users will be denied access "sharing violation".
  Banyan keeps these file open UNTIL THE USER LOGS ON AGAIN. Since
  Banyan sees the user is logging in again it then resets the
  previously files open by that user to closed. This has been
  verified by experiment several times under version 3.5 and 4.0
  (if my memory serves me correct). In all cases it was only on
  one server and on the same file service.

3-Microsoft Word for Windows (2.0?), does not free its file
  handles when it closes a file when the file is left upon the
  list of recently opened file. Upon exiting Word, the file handles
  are released. This has been reported by others.

4-If you terminate a DOS session under Windows 3.1 enhanced mode,
  Windows will not close the files. Share will think the terminated
  session still has the file opened/locked (hey no one told SHARE!)
  This can also happens when a DOS program crashes like when it
  encounters a "System Integrity Error - Invalid Instruction"
  (which is really a 06h fault).

5-Windows for Work Groups handles file sharing internally.
  There maybe problems with caching of the data on servers.

6-In DOS the old method of detecting share was for a program to
  call Int. 2F (the multiplexing interrupt) with the proper
  information. If share was loaded it would respond. Share
  uses this to detect if itself is already loaded. If loaded
  share will not load itself again (or change parameters).
  Since Windows 386 enhanced mode does not want you to load
  share in a DOS windows, Windows will answer yes, EVEN IF
  SHARE IS NOT LOADED BEFORE WINDOWS. It says there is share
  support, even when there is not any.

7-There is an article in the Knowledge Base:Windows SDK that deals
  with detecting share in Windows.  It goes like this:

  To determine under enhanced mode Windows whether SHARE is
  installed, call Interrupt 21h Function 5Ch to lock a region
  of a file. This function is available only when SHARE is
  installed, and unlike using the OpenFile function with
  sharing modes, the lock region function always fails with
  error 1 (invalid function) if SHARE is not loaded.

  Perform the following six steps to determine whether SHARE is
  loaded:

  a. Create a temporary file using MS-DOS Interrupt 21h
     Function 5Ah.

  b. Lock a region of the returned temporary file using MS-DOS
     Int. 21h Function 5Ch. Set AL = CX = DX = SI = 0 and DI = 1.

  c. If the call in step 2 returns with the carry flag set and
     AX = 1, SHARE is not loaded. Move to step 5.

  d. SHARE is loaded. Unlock the region of the file using MS-DOS
     Int. 21h Function 5Ch. Set CX = DX = SI = 0 and AL = DI = 1.

  e. Close the file using MS-DOS Interrupt 21h Function 3Eh.

  f. Delete the file using MS-DOS Interrupt 21h Function 41h.

  This appears to be the test the Access uses to test for SHARE.
  If the entire test does not pass, then Access gives the message
  "Share must be loaded". This if steps a through f are not
  successful.  However, if the first step fails (unable to open
  the temporary file), share still says "Share must be loaded".
  If on the server the user does not have access right to create
  the file, Access does not think share is loaded.  Under Banyan
  Vines, you can have write access to your database, but still not
  be able to create a temporary file in that same sub-directory.
  This was the initial problem noticed when Master Scheduling
  started their program to replace the quarterly report. We got
  the message "Share must be loaded" when a user did not have write
  access to the directory, therefore we though an Access database
  always needed share. In reality, the Access engine in Visual
  Basic did not test share functionality properly. [5]

8-I have yet to see any information if share on a local workstation
  will provide any functionality on a network drive. Hopefully, share
  is smart enough to detect network drives, and not add any files
  opened on the network drive to its tables (assuming the network
  has taken care of the sharing functionality for all users in files
  on the network drive).

9-VSHARE.386 has been reported to let WINWORD 6.0a to open more than
  copy of WINWORD without the "share must be loaded message". There
  is no information on how VSHARE.386 is to be configured. Does it
  require some statements like SHARE.EXE or can it re-configure
  itself on the fly?

10-Even in the age of the information super highway, there are still
  idiots driving 40 MPH in the fast lane with their left hand
  blinker turned on. [6]




[1] Richard Fink 03/05/90 of RainTree Computer Systems
[2] Kirsten of Borland posted on BIX
[3] Tom Fillimerica of Fillimerica, Incorporated
[4] "Undocumented DOS" 2nd edition December 1993, Andrew Schulman
[5] Post on BIX by rpreuninger 1/14/94
[6] anon
[7] Microsoft(R) Product Support Services Application Note (Text File)
    WW1000: VSHARE.386 FOR WINDOWS(TM)