Path: utzoo!attcan!lsuc!maccs!cs4g6ag From: cs4g6ag@maccs.dcss.mcmaster.ca (Stephen M. Dunn) Newsgroups: comp.sys.ibm.pc Subject: Re: Questions about DOS 4.0 Message-ID: <2521AA86.17446@maccs.dcss.mcmaster.ca> Date: 28 Sep 89 05:22:13 GMT References: <1989Sep25.101739.26600@cs.dal.ca> Reply-To: cs4g6ag@maccs.dcss.mcmaster.ca (Stephen M. Dunn) Organization: McMaster University, Hamilton, Ontario Lines: 84 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 **********************************************************************= "\nI'm only an undergraduate!!!\n"; "VM is like an orgasm: the less you have to fake, the better." - S.C.