lane@cs.dal.ca (John Wright/Dr. Pat Lane) (09/25/89)
I've been having so much trouble with DOS 4.0 on machines at work that
I'm sure I'll never use it at home (or anywhere I have any say about it).
I think its all a plot by IBM/Microsoft to get people to use OS/2!!!
Nevertheless, I'd like to ask some simple (I hope) questions. I have here,
BTW, a 386 clone (Cache-32 motheboard, Chips & Technologies chipset, AMI
386 BIOS with RAM shadowing, 2 Megs of RAM, 130 Meg hard disk and Microsoft
MS-DOS 4.01.
1. We have the hard disk partitioned as one big drive. When DOS boots
it says "Warning: SHARE should be loaded for large media". Why? I'm
not using a network so I don't need special handling for file sharing
or locking.
In the manual under SHARE it says: "SHARE is automatically loaded if
you have a hard disk greater than 32 Megabytes in a single partition".
In fact, this only happens if SHARE.EXE is in the root directory of the
boot disk. In my case, it is, of course, in C:\DOS and is not loaded
automatically.
2. It also says with SHARE loaded, "FCBS control is activated". What does
that mean? They refer you to the section of the manual for FCBS= in
CONFIG.SYS but SHARE is not mentioned at all there. I have noticed that
with at least some programs I have that open files with FCBs, the opens fail
unless SHARE is loaded. This happens regardless of the FCBS= settings.
What's goin' on?
3. I take it from the explanation of FCBS= that DOS (and not just DOS 4 but
earlier versions as well), if it runs out of FCBS for an open FCB request,
and assuming that the second FCBS= parameter has not been used, will simply
close the last FCB file it opened (or would it be the first FCB file opened)
in hopes that the application won't crash because of it. Is that correct?
4. Back to SHARE, I note that it also implements checking for diskette
switches and checks for the same disk volume name. I wonder why they
didn't put this into DOS proper and why they bundled it with a program
to be used on networked systems?
5. With FASTOPEN, the optional second parameter value is the number of
"file extent entries". What is a file extent?
5b. If I'm using expanded memory for the cache, it should be exactly 16K
(the size of an EMS page). What are suitable values for the FASTOPEN
parameters in this case.
6. What are the implications of using BUFFERS=x,8? Will it improve system
performance? Are there any dangers?
7. I'm using EMM386.SYS to use my extended mwmory as expanded memory. The
first odd thing I notice here is that with EMM386 loaded, whenever I do
a soft boot (Ctrl-Alt-Del or one of those REBOOT.COM pgms), it does a hard
boot, going through the memory check, etc. whereas normally it would skip
those.
I assume that my 2 Megs is mapped continously from 0 to 1FFFFF so that I
have 640K base memory followed by 384K ROM shadow memory followed by 1024K
extended memory. However, the most that EMM386 will allocate is 912K, 112K
less than 1024K. EMM386 reports on loading that it has allocated 912K (or
whatever was requested) of extended memory plus 384K of "system memory" for
a total of 1296K (assuming the 912K or more was requested) of available
expanded memory.
MEM reports, 1296K total EMS memory with 912K free. It always lists one EMS
"handle", numbered 0, with no name and 384K allocated to it. Further, MEM
reports 1024K total extended memory with 64K available. This would indicate
that 960K is used. Since 912K is used by EMM386 there is 48K unaccounted
for. If I request less than 912K expanded memory, the amount of extended
memory used is still 48K more than the amount EMM386 says it has allocated.
8a. What is the 384K of "system memory allocated" and what is EMS handle 0
and are they related? Applications using EMS only see the 912K or whatever
extended memory was allocated. Why does EMM386 claim this is "available"
expanded memory when it is in fact allocated to handle 0. Or is this some
new meaning of the word "available" with which I was not aware of? :-)
8b. Where is allocated but unaccounted for 48K of extended memory going?
8c. Why does EMM386 refuse to allocate more than 112K less than the total
amount of extended memory, thus leaving at least 64K free. Is this the
first 64K of extended memory, left free for HIMEM.SYS?
HIMEM.SYS (which was documented only in a README file on one of the DOS
diskettes) supposedly makes the first 64K of extended memory available to
MSDOS programs. I understand that it does this by tweaking the hardware
in some way that may not work on all machines. When I load HIMEM.SYS (which
I normally do not), it reports "64K High Memory Area is available". Thus,
I assume that it works on my machine. I've heard somewhere that this 64K
can only be used for loading one device driver or resident program at a time.
I also understand that HIMEM.SYS implements a scheme, called XMS, for
managing extended memory in a way similar to the LIM standard for expanded
memory. I've heard that there is not much software that supports this
standard and even the other DOS programs that use extended memory (like
EMM386.SYS) ignore it.
9a. How does one make use of the 64K High Memory Area? Just loading
HIMEM.SYS before the other drivers and resident programs does not change
the amount of memory any of them use. I just lose the amount of memory
taken up by the HIMEM.SYS.
9b. Loading HIMEM.SYS does not change the amount of available extended
memory reported by MEM. Shouldn't it be 64K less?
9c. Is it safe to use HIMEM.SYS with EMM386.SYS (since EMM386 seems to
leave 64K of extended memory available)?
9d. Is it safe to use HIMEM.SYS period?
10. Would the combination of HIMEM.SYS and XMS2EMS.SYS do the same as
EMM386.SYS (and work on a 286 as well)?
11. Does EMM386.SYS work OK or would I be better off with a 3rd party pgm
like QEMM.SYS from DeskView or 386-to-the-Max.
12. SELECT will not let me choose expanded memory support even if I load
EMM386.SYS before running it. How come?
I realise I'm asking alot here - and some of it i've asked before - but,
hey, inquiring (and frustrated) minds want to know.
Muchly appreciate any help with these.
--
John Wright ////////////////// Phone: 902-424-3805 or 902-424-6527
Post: c/o Dr Pat Lane, Biology Dept, Dalhousie U, Halifax N.S., CANADA B3H-4H8
Cdn/Eannet:lane@cs.dal.cdn Uucp:lane@dalcs.uucp or {uunet watmath}!dalcs!lane
Arpa:lane%dalcs.uucp@uunet.uu.net Internet:lane@cs.dal.cabaird@cod.NOSC.MIL (John M. Baird) (09/26/89)
From article <1989Sep25.101739.26600@cs.dal.ca>, by lane@cs.dal.ca (John Wright/Dr. Pat Lane): For your long list of questions asked about DOS 4.0, answers to the first few [taken from a local DOS on-line help program]. Hope this helps. John Baird, Naval Ocean Systems Center, San Diego, CA -------- > > 1. We have the hard disk partitioned as one big drive. When DOS boots > it says "Warning: SHARE should be loaded for large media". Why? > In fact, this only happens if SHARE.EXE is in the root directory of the > boot disk. > [part of BOOT topic help]: [new DOS 4.0] If an INSTALL=SHARE line was not present in the CONFIG.SYS file, and any disk partition is >= 32 Mbytes (32 million characters), the SHARE program will be read into memory from disk (either from the root directory of the default disk if there was no CONFIG.SYS file, or from the file specified by the SHELL line). The need for this step is discussed in the CONFIG FCBS topic. > > 2. It also says with SHARE loaded, "FCBS control is activated". What does > that mean? > > 3. I take it from the explanation of FCBS= that DOS, if it runs out of > FCBS for an open FCB request, and assuming that the second FCBS= parameter > has not been used, will simply close the last FCB file it opened (or would > it be the first FCB file opened) in hopes that the application won't crash > because of it. Is that correct? > [CONFIG FCBS topic]: FCBS=x,y This line supports file control blocks (FCB). Very early versions of DOS controlled file access with FCBs. Later versions use file handles, instead. New programs use handles, but since older ones use FCBs, DOS still supports their use. x specifies the maximum number of FCBS to support, minimum of 1, maximum of 255, default of 4. When a program requests an FCB and they are all in use, DOS will reassign the least recently used one. y specifies the minimum number of FCBS that will never be reassigned by DOS when a program requests an FCB and all FCBS are in use. This prevents an FCB from being closed by a program other than the one using that file. x should be > than y by 8 or more. If you set x < y, DOS probably won't run at all. If an old program using FCBs is run on a computer which uses DOS 4.0 or later and a disk partition of >= 32 Mbytes (32 million characters), the SHARE command must be executed before using the program, or the program won't run. > > 4. Back to SHARE, I note that it also implements checking for diskette > switches and checks for the same disk volume name. I wonder why they > didn't put this into DOS proper and why they bundled it with a program > to be used on networked systems? > [from SHARE topic]: SHARE [/F:n][/L:n] The SHARE external command allows DOS to support: file sharing among programs [across multiple diskettes on one computer or across a network of computers] and old programs to use disk partitions >= 32 Mbytes (32 million characters. See the CONFIG FCBS topic for more information. [new DOS 4.0] SHARE can be installed with an INSTALL=SHARE line in the CONFIG.SYS file, or it can be executed in the AUTOEXEC.BAT file. [Not supported in OS/2] > > 5. With FASTOPEN, the optional second parameter value is the number of > "file extent entries". What is a file extent? > INSTALL=[d:][pathname]FASTOPEN.EXE [d:[=f]] ... [new DOS 3.3] or INSTALL=[d:][pathname]FASTOPEN.EXE [d:[=(f,r)] ... [/X] [new DOS 4.0] This external program speeds up access to files by saving information about them in memory. d: specifies a disk to save information about. Drive letters defined by JOIN, SUBST, or ASSIGN may not be used, nor may drives on another computer in a network. f specifies the number of directory and file entries to save for d:. Default 34, minimum 10, maximum 999. r specifies the number of range entries to be saved to reduce reads to the disk, between 1 and 999. A range entry holds locations of blocks of data for a file on disk which are continuous (adjacent, contiguous). /X specifies that the information should be kept in expanded memory. Use only if the BUFFERS line in CONFIG.SYS also has the /X option. See the NEW_TERMS MEMORY topic for more about expanded memory. (f and e should be s150.) > > 6. What are the implications of using BUFFERS=x,8? Will it improve system > performance? Are there any dangers? > [BUFFERS topic]: BUFFERS BUFFERS=n BUFFERS=n,m [/X] [new DOS 4.0] n specifies the number of disk buffers that DOS allocates in memory during the boot process. The default value for DOS versions prior to 3.2 is 2. Later versions have a default of five or more, depending on how much memory your PC has. For most programs, 2 is NOT enough. The maximum value is 99 (pre DOS 3.2), or 255 (DOS 3.2 and later). If you have a hard disk, n should be at least 10, and usually no more than 20 are needed. m specifies the number of consecutive buffers to read in addition to the one being requested, when data must be read from disk. The default value is 0, the maximum value is 8, a value of 2 or 3 is recommended. If data is already in a buffer, it will be used rather than reading it from the disk. /X specifies that the buffers should be placed in expanded memory. When /X is present, n can be up to 10000. A disk buffer is an area of memory that is used to store data read in from or to be written to disk. The primary use of buffers by DOS is to save information about your disks and the directories on them. For a program that reads or writes small blocks of data to the disk frequently and in some order, rather than jumping around a lot, additional buffers can increase the speed of the program. For instance, a database program may run more efficiently if you have allocated 15 or 20 buffers.
baird@cod.NOSC.MIL (John M. Baird) (09/26/89)
While we are asking questions about DOS 4.0, what are filesys.exe and ifsfunc.exe? They are on the release diskettes, but I can't find any mention of them in the accompanying documents. They seem to have something to do with PC networks, but what??? John Baird, Naval Ocean Systems Center, San Diego, CA
cs4g6ag@maccs.dcss.mcmaster.ca (Stephen M. Dunn) (09/28/89)
John Wright/Dr. Pat Lane writes about MS-DOS 4.01:
$1. We have the hard disk partitioned as one big drive. When DOS boots
$it says "Warning: SHARE should be loaded for large media". Why? I'm
$not using a network so I don't need special handling for file sharing
$or locking.
$In the manual under SHARE it says: "SHARE is automatically loaded if
$you have a hard disk greater than 32 Megabytes in a single partition".
$In fact, this only happens if SHARE.EXE is in the root directory of the
$boot disk. In my case, it is, of course, in C:\DOS and is not loaded
$automatically.
I don't know why DOS wants SHARE loaded for large disks, but the fact is
that it does. You've also answered your own question - it prints the message
"Warning: SHARE should be loaded for large media" because it can't auto-
matically load SHARE (I imagine ... I've never bothered tracking down the
precise reason for this message)
Time to add a question of my own: why did they put SHARE into DOS rather
than into Microsoft Networks? That's the approach Novell, for one, took -
you don't need to load SHARE to have network file sharing; their network
program handles it.
$2. It also says with SHARE loaded, "FCBS control is activated". What does
$that mean? They refer you to the section of the manual for FCBS= in
$CONFIG.SYS but SHARE is not mentioned at all there. I have noticed that
$with at least some programs I have that open files with FCBs, the opens fail
$unless SHARE is loaded. This happens regardless of the FCBS= settings.
$What's goin' on?
Well, FCBs (to the best of my knowledge about them) have no file sharing
information in them. With SHARE loaded, it presumably has to do something
in order to keep track of file sharing info on files opened with FCBs. This
would probably be the cause of your problems/message.
$3. I take it from the explanation of FCBS= that DOS (and not just DOS 4 but
$earlier versions as well), if it runs out of FCBS for an open FCB request,
$and assuming that the second FCBS= parameter has not been used, will simply
$close the last FCB file it opened (or would it be the first FCB file opened)
$in hopes that the application won't crash because of it. Is that correct?
I haven't studied this, either, but it's something like that ... if you
run out of FCBs, DOS will (in the case mentioned) close one of the other
FCBs in order to free one up, and it would seem logical that it would
pick the oldest one in the hopes that it was opened by a program and
never closed although the program has finished using it.
$4. Back to SHARE, I note that it also implements checking for diskette
$switches and checks for the same disk volume name. I wonder why they
$didn't put this into DOS proper and why they bundled it with a program
$to be used on networked systems?
Actually, in DOS 4, it probably checks the serial number rather than the
volume label, as the former is virtually unique while the latter can be
found often on more than one disk (especially in the null case!)
I don't know why, either ... but then, I don't pretend to understand
many things that Microsoft does.
$6. What are the implications of using BUFFERS=x,8? Will it improve system
$performance? Are there any dangers?
I don't know what the latter number does, but the former has fairly great
effects on system performance, apparently. The more powerful your machine
(and the more files you plan to have open at any given time), the higher it
should be. On AT-class machines, I usually set it between 10 and 12, although
I've heard that the recommended value is around 8.
No dangers to having too many or too few buffers, except that it will
affect system performance and a huge number of buffers will eat up memory
(for a reasonably small number of buffers, the amount of memory eaten up
is not something to worry about).
As for the other questions, John already knows I don't know the
answers.
--
Stephen M. Dunn cs4g6ag@maccs.dcss.mcmaster.ca
**********************************************************************
<std_disclaimer.h> = "\nI'm only an undergraduate!!!\n";
"VM is like an orgasm: the less you have to fake, the better." - S.C.mk@vall.dsv.su.se (Magnus Karlson) (10/02/89)
FCB's are not supported for large disk partions, insted SHARE will emulate them using handels if loaded. That is why FCB programs will fail without SHARE loaded. Magnus Karlson@vall