gcook@cps3xx.UUCP (Greg Cook) (06/17/89)
References
Once again I come seeking net wisdom. I am running ms-dos 4.01 on an AT clone with a 40 M hard drive partitioned for the full 40 meg. In my config.sys file I have the following line:
shell =c:\dos\command.com /p /e:800
which replaces command.com with a copy of itself to increase the environment space to 800 bytes. The problem is when I have this line in config.sys ACAD will not run. I get disk read errors and disk full errors.
It will run if I remove this line but then I get a warning when I boot up:
WARNIGN! SHARE should be loaded for large media.
If I leave out the shell command and use install=c:\dos\share.exe then I get the same problems with ACAD.
So my questions are:
1. Am I correct in assuming that the SHELL command automatically installs SHARE?
2. Do I have to have SHARE installed since my HD is partitioned greater than 32 Meg?
3. Besides increasing the environment space, what is the purpose for the SHELL command (using command.com and not some other command processor)?
4. Is there any way I can keep the SHELL command and still run ACAD?
Thanks for the advice!
Greg Cook
gcook@horus.cem.msu.edu cook@frith.egr.msu.eduleefi@microsoft.UUCP (Lee Fisher) (06/20/89)
[For some reason, I was unable to send out my reply yesterday (some
sort of local uulock or something, I guess), and my direct email bounced
too, so lets see if this one works...]
A reply to the recent question about the SHELL statement, DOS 4.0's >32MB
partitions, the installation of SHARE, and the use of AutoCAD in such a
system. First three canned messages giving some general information on DOS
4.0, SHARE.EXE and >32MB partitions:
----- snip ----- snip ----- snip ----- snip ----- snip ----- snip -----
Using SHARE.EXE on MS-DOS 4.0 on Large Media
If you are using MS-DOS 4.0 with a large partition (greater than 32
megabytes), you should run SHARE.EXE in your AUTOEXEC.BAT or use INSTALL
to run SHARE.EXE in your CONFIG.SYS.
If you have a disk that is greater than 32 megabytes in size and you do
not load SHARE.EXE, MS-DOS will issue the following warning:
WARNING! SHARE should be loaded for large media
This warning is issued for support of FCBs (File Control Blocks) in MS-DOS
4.0 on large media. Applications that use FCBs have a fixed data structure
that defines the FCB. Instead of changing the structure of the FCB to
address large media (which would make all existing FCB software unusable),
MS-DOS 4.0 requires that SHARE.EXE to be loaded. When SHARE.EXE is loaded,
an internal file system table is used by the operating system on top of
the application's FCB structure, which allows the operating system to
handle the different size of the FCB structure.
Programs that use file handles don't cause this problem because, unlike
FCBs, the data structure for a file handle is maintained by the operating
system, not the application.
----- snip ----- snip ----- snip ----- snip ----- snip ----- snip -----
How SHARE.EXE Is Loaded with Large Partitions
When MS-DOS 4.0 finds a large partition (more than 32 megabytes) on the
system at boot time, it attempts to load SHARE.EXE. To find SHARE.EXE,
the initialization routine looks at the path in the "SHELL=" statement in
the CONFIG.SYS file. If there is no "SHELL=" statement in the CONFIG.SYS
file, the root directory of the boot disk is checked.
For example, if the CONFIG.SYS file contained the following line, the
initialization code would look in the "C:\DOS" directory for SHARE.EXE:
SHELL=C:\DOS\COMMAND.COM /P
If SHARE.EXE is not found, the following message is issued:
WARNING! SHARE should be loaded for large media
----- snip ----- snip ----- snip ----- snip ----- snip ----- snip -----
Examples of Improper FCB Usage
The use of FCBs is problematic. In addition to obvious problems, such as
lack of subdirectory support, there are other, less obvious problems. FCB
structures are maintained in the data space; therefore, they may be moved
at will. Most importantly, there have never been any "rules for behavior"
for FCB manipulation -- there was no protocol for their usage. This
results in the following misbehavior by an application:
1. Multiple opens of the same file
while (TRUE)
OpenFCB(FCB)
ReadFCB(FCB)
while (TRUE)
OpenFCB(FCB)
WriteFCB(FCB)
2. Multiple opens of different files
while (TRUE)
OpenFCB(FCB[i++])
ReadFCB(FCB)
while (TRUE)
OpenFCB(FCB[i++])
WriteFCB(FCB)
3. Multiple closes of the same file
OpenFCB(FCB)
while (TRUE)
CloseFCB(FCB)
4. I/O after closing file
OpenFCB(FCB)
while (TRUE)
CloseFCB(FCB)
OpenFCB(FCB)
while (TRUE)
WriteFCB(FCB)
Using the MS-DOS SHARE.EXE utility, this behavior is no longer allowed.
SHARE, which is transparent to the application that is using the FCBs,
shadows the FCB I/O requests into file handle I/O requests internally.
Then, it can enforce file system integrity rules with the FCBs alongside
the file handles.
Such improper use of FCBs by an application is discovered when running the
SHARE.EXE utility. This is even more widespread when using MS-DOS 4.0 on a
partition larger than 32 MB, which REQUIRES that SHARE.EXE be loaded.
Whenever possible, use file handle I/O instead of FCB I/O.
----- snip ----- snip ----- snip ----- snip ----- snip ----- snip -----
Regarding your problem with your app, I believe that these above comments
clarify this. I expect the problem is not due to the environment size, but
rather because of the installation of SHARE. Options?
- DOS 4.0 >32MB partitions need to have SHARE.EXE installed.
- DOS 4.0 <32MB partitions do NOT need to have SHARE.EXE installed.
- Some applications do not work with SHARE.EXE installed.
- Therefore, these applications do not work with DOS 4.0 when using
>32MB partitions (since SHARE.EXE is installed).
- Such applications DO work with <32MB partitions with DOS 4.0, when
SHARE.EXE is not installed.
- Choice: either don't use these sorts of applications due to
restrictions imposed by SHARE.EXE and DOS 4.0 >32MB partitions,
OR, don't use DOS 4.0's >32MB partitions due to I/O usages of
such applications.
The only two applications I know of like this is an old version of dBASE
(II?) and of AutoCAD; and I believe that AutoCad has this fixed, but I am
not sure of this.
Please note my disclaimer; this is the weekend so I'm entitled to have my
brain in neutral, I haven't done any DOS stuff in a while, and I often
don't know what I'm talking about... :-}
--
lee fisher, leefi@microsoft.{wa.us,com,uucp,beaver.washington.edu}
{uw-beaver,decvax,decwrl,intelca,sun,tikal,uunet}!microsoft!leefi
disclaimer: Plch vlghajbe', vlta'pu'be', pa'jlHpu'be!