DOS 4.01 SHARE Service Question
         ===============================
 
I know the purpose of SHARE in multi-user, multi-tasking and
network environments.  But MS-DOS 4.01 seems to feel that SHARE
must be loaded just because a Large-Partition is defined.  It
may be loaded either via the 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's and you don't install SHARE you
generate a DOS  "WARNING....."  message.  DOS even goes so far
that if you have not installed SHARE it will search the root
directory for it and then AUTO-LOAD it !!  Now THAT is a real
first !  Why...
 
I ran without it for months on a 100MB partition with absolutely
no problem.  Then I got afraid of that constant boot-up warning
and put it back in my CONFIG file.  Of course it is a pain at times
because it can interfere with reasonable desired file access-
such as backing up a file that has not been openned with the proper
Shared Read access by the owning TSR program.  Not that you want to
actually back that file up but that it causes an error msg and
requires an operator response to continue.  That's  all fine for
the original intended purpose of SHARE but now what does it do for
partitions over 32 MB that is not needed in <32 MB partitions ?
Anybody know ?
 
Remember it's NOT required to operate with Large Partitions.  I've
run for months without it...  what was I missing ?
                                       -Ric
-----------------------------------


Well like so many I made the trek to COMDEX a few weeks ago and
gave some effort to finding the answer to this profound question
of life and the need to SHARE.  Microsoft didn't know the answer.
IBM was staffed by a techie who said "I really don't know the
answer to that, I just include it too."  So I insisted and persisted
and made many at the IBM stand feel increasingly squirmy as nobody
knew the answer.  How stupid they must have felt that somebody
was here asking a dumb DOS question when "we" all knew it nolonger
mattered...  that OS/2 was now the Real Thing.
 
THEN one day they gave a freebie day at COMDEX to an original DOS
programmer who worked on DOS 4.01 !  He quietly and completely
explained the answer...  It's VERY interesting.
                              ~~~~

If you use "modern" programs all the time, you may have
never run into problems using Large-Partitions (over 32MB)
without SHARE loaded.  But beware...
 
The deal is that the old file FCB's cannot hold pointer
information in it's "reserved fields", on files that are
located on disk locations past 32MB's.  When used in a
Large-Partition environment, FCB's can be okay as long as
the file is physically WITHIN the 32MB range of the partition.
However if part of the file is past the 32MB range, say in
the 38th megabyte area of the partition, the FCB doesn't
chuck-up or give an error, it just rolls the pointer value
over, thru zero, and gives DOS a new garbage value as an
internal disk pointer.  The next disk read gives junk to
your program, the next disk write corrupts your disk.
It's Great Fun.
 
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 had to be given a
way to run in Large-Partitions something had to be done to
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 that would be in control by 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 existance in the
current SHARE facility.  SHARE was just upgraded to not just
copy the FCB into it's own area for file access control but to
copy it into an extended FCB format, when applicable, for
Large-Partition access.
 
As nobody knows the internal code of the program's they run
everyday, you can never be positive if a program is using File
Handles via Extended File IO or old FCB's.  (Actually, if you
can specify a path, it's 99.44% likely to be extended file IO
using a File Handle.)  Since the use of FCB's in Large-Partions,
when accessing the disk area past 32 MB will corrupt the poor
user's 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 file.
 
Ahhhh.... and that explains why such "modern" people as myself
who had used only "modern" programs with File Handles (no FCB's)
never had any problems.
Right.  But not completely safe.
 
Just lucky.  The reason SHARE is an ABSOLUTE NECESSITY in systems
using Large-Partitions is this:

     My IBM DOS programmer says that even today DOS itself still
     uses some old FCB's internally for some unspecified internal
     disk functions !

     God help us, Microsoft sure didn't.

     DOS still runs some original DOS 1.1 file access code that
     REQUIRES SHARE in order not to, on some day, wipe out your
     hard disk !!!
 
So if you're getting the SHARE WARNING at bootup friends, stick
it back in your config file, or just put it in the root directory
of you're C drive, and just eat the bytes it takes in memory...
Fact is, we've got no choice.
                               -Ric

------------------------------------------------------------------
Permission granted to distribute in unmodified form.
Copyright (C) 1990 RainTree Computer Systems.