NewDeal Technical Support Document 236
If your computer is not attached to a network and you do not use a task switcher, you may not need to use SHARE. The SHARE.EXE command loads file-sharing and locking support in network and multitasking environments. It prevents more that one application or user from writing to the same file at the same time, thus avoiding a potentially damaging situation such as file corruption.
If you're using DR-DOS, see the DR-DOS section below.
install=c:\dos\SHARE.EXE /f:4096somewhere in the file, as long as it is on a separate line.
c:\dos\SHARE.EXE /f:4096near the beginning of the file.
We prefer loading SHARE in the AUTOEXEC.BAT file rather than in the CONFIG.SYS file.
You should never have to increase the number
higher than 10240. In order to save system resources, you want
to use the smallest number that prevents the overflow error message.
DR-DOS
If you encounter this error, you need to increase the number of
file locks used by SHARE.EXE in the AUTOEXEC.BAT file. Change the line
c:\drdos\sharein your AUTOEXEC.BAT to read
c:\drdos\share /l:40If the error persists, increase the number in increments of 20. You should not need to raise the number higher than 80. Refer to your DR-DOS manual for more information regarding file locks and TaskMAX.
If you aren't on a network, don't have a task-switcher active, and don't have a disk partition larger than 32 megabytes while using DOS 4.0, then you may not need to load SHARE.EXE.
SHARE.EXE makes sure that if one DOS application (either on the local machine or over a network) says no other application should write to a file while it's got the file open, then no other application is allowed to open the file for writing until the first application has closed the file.
SHARE.EXE serves an additional purpose for DOS 4.0 when a program is run under it using the "FCB" method of accessing files, rather than the "handle" method. The FCB method uses a block of memory within the program itself to keep track of which file is open and where in the file the program last accessed it. FCBs don't deal with the hierarchical directory structure that was introduced with DOS 2.0. They also have a limited amount of space that cannot handle the 32-bit sector and cluster numbers required to manipulate a partition that's larger than 32 MB. SHARE.EXE mangles these FCBs to prevent the sector numbers stored within them from wrapping at the 32 MB boundary back to the start of the disk and trashing things.
MS DOS 4.01 loads SHARE just because a large-partition is defined. It may be loaded by an INSTALL command in the CONFIG.SYS file or as a TSR in the AUTOEXEC.BAT file. But if you have a DOS partition over 32 MB and you don't install SHARE you may generate a DOS "WARNING" message. If you have not installed SHARE, DOS 4.01 will search the root directory for it and then AUTO-LOAD it.
If you use "modern" programs all the time, you may have never run into problems using Large-Partitions (over 32MB) without SHARE loaded.
The deal is that the old file FCB's cannot hold pointer information in their "reserved fields" for files that in disk locations past 32 MB. When used in a large-partition environment, FCB's are okay as long as the file is physically WITHIN the 32 MB range of the partition. However, if part of the file is past the 32 MB range, say in the 38th megabyte area of the partition, the FCB doesn't give an error, it just rolls the pointer value over, through zero, and gives DOS a garbage value as an internal disk pointer. The next disk read gives junk to your program, the next disk write corrupts your disk.
The reason SHARE is the solution is because it was already doing the required fix for a different reason in small partitions. To give file sharing protection in multi-user environments, SHARE would make a copy of a program's FCB in a new local copy within SHARE and perform the file open from SHARE's copy of the FCB. In so doing, it technically owned the file and could effectively perform traffic-cop duty regarding multi-access activity on the file.
Since old programs using hard coded FCB's needed a way to run in Large-Partitions, something had to be done about the FCB disk pointer problem. The solution was to copy the original FCB from within the program to a new "extended" format of the FCB in the operating system. The extended form of the FCB with larger fields would be able to support Large-Partitions and any other extensions in the future.
This FCB copy capability was already in existence in the current SHARE facility. SHARE was upgraded to not just copy the FCB into its own area for file access control but to copy it into an extended FCB format, when applicable, for Large-Partition access.
You can never be positive if a program is using File Handles via Extended File IO or old FCB's (though if you can specify a path, it's 99.44% likely to be extended file IO). Since the use of FCB's in Large-Partitions, when accessing the disk area past 32 MB, will corrupt the disk, IBM said "this is serious" and even forced the bootup process to automatically search for SHARE in the root directory if it had not been explicitly loaded in the CONFIG.SYS file.
SHARE is helpful in systems using Large-Partitions because even some newer versions of DOS still use old FCB's internally for some unspecified internal disk functions.