Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!munnari.oz.au!manuel!csc.canberra.edu.au!news From: act@softserver.canberra.edu.au (Andrew Turner) Newsgroups: comp.binaries.ibm.pc.d Subject: Re: Why load "SHARE" (was Re: program to break 32MB barrier) Message-ID: <1991Feb13.130613.13467@csc.canberra.edu.au> Date: 13 Feb 91 13:06:13 GMT References: <5489@husc6.harvard.edu> <140@thor.UUCP> <1078@rna.UUCP> Sender: news@csc.canberra.edu.au Distribution: comp Organization: University of Canberra Lines: 115 In article <1078@rna.UUCP> marc@rna.UUCP (Marc Johnson) writes: >In article <140@thor.UUCP> scjones@thor.UUCP (Larry Jones) writes: >>In article <5489@husc6.harvard.edu>, albert@endor.uucp (David Albert) writes: >>> Why is it the case that "SHARE must be loaded for large media" in >>> MS-DOS 4.01? I ran my computer with a full 40Meg hard disk for a >>> month without SHARE loaded, with no problems. Might something bad >>> have happened if I continued? >> >>SHARE is needed to allow the old DOS 1.0 FCB functions to work right >>on a large partition -- if it is not loaded, they wrap around and trash >>the partition. Since they are significantly faster in some cases than >>the newer functions that were supposed to replace them, they are still >>widely used. If you have a large partition and don't load SHARE, you're >>living on borrowed time. On the other hand, there's a small piece of >>public domain software that replaces SHARE -- rather than making the FCB >>functions work right, it intercepts the calls and returns a failure >>status (and also puts out a message indicating that it happened, I >>believe). That way you don't trash the disk and it takes up a whole lot >>less space. I don't remember the name, but it's undoubtedly on SIMTEL. >>---- >>Larry Jones, SDRC, 2000 Eastman Dr., Milford, OH 45150-2789 513-576-2070 >>Domain: scjones@thor.UUCP Path: uunet!sdrc!thor!scjones >>Do you think God lets you plea bargain? -- Calvin > >YIKES!!! >I have had problems with SHARE on my 126Mbyte disk when running Windows 3.0. >So, I removed SHARE from my config, and have noticed no other problems. >But I am concered about this comment "living on borrowed time"! It doesn't >seem to need SHARE to run fine, and with SHARE loaded, Windows has problems. >What gives? Also, when my PC arrived from the manufacturer, SHARE was not >in the config - obviously they didn't seem to think it was needed. > >Anyone have a definitive answer on this???? > >marc > >=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >= Marc Johnson BITNET: rna!marc@rockvax.bitnet = >= Rockefeller Univ. Neurobiology UUCP: ...cmcl2!rna!marc = >= New York City INTERNET: marc%rna@rocky2.rockefeller.edu = >= (129.85.2.1) = >= = >= "Gimme the beat boys and free my soul, I wanna get lost in your rock & roll = >= ...and drift away" = >=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= If you use "modern" programs all the time you may never run into problems using Large-Partitions(over 32M). BUT BEWARE!!!!!!!!!!!!!!!! The deal is that the old FCBs cannot hold pointer information in its "reserved fields", on files that are located past 32 M. When used in a Large-Partition environment, FCB's can be okay as long as the file is physically within the 32M range of the partition. However, if part of the file is past the 32M 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, the FCBs zero, and it gives Dos a new garbage value as an internal disk pointer - Yippee. The next disk read gives junk to your program, the next disk write junks your disk. It's great fun. The reason Share is the solution is that 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 the programs FCB in a new local copy within Share and perform the file open from Share's copy of the FCB. In doing so, it technically owned the file, and could effectively perform traffic-cop duty regarding multi-access activity on the file. Since old programs using hardcoded 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 FCB's 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 programs they run everyday, you can never be positive if a program is using File Handles via extended File FCB's or old FCB's. (Actually if you specify a path, it's 99.44% likely to be extended file FCB's using a file handle.) Since the use of FCB's in Large-FCB's, when accessing the disk past 32M will corrupt the poor user's disk, IBM is alleged to have said(disclaimer here): "this is serious", and even forced the FCB's process to automatically search for Share in the root directory if it had not been explicity loaded in the config file. AAAHHHHHHHH...and that explains why "modern" people 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 with Large-Partitions is this: An IBM Dos programmer is alleged to have said that even today Dos itself still uses some of the old FCB's 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 to some day wipe out your hard disk. My ego would like to take credit for this stuff but I lifted it out of an article in an Aussie magazine subscription "PC Support Advisor" witten by a Richard Fink, RainTree Computer Systems, PO Box 2339, Mill Valley, CA 94941 USA. So there!!! :-( :-( :-( Grimace, Groan, Moan Grunt. Apologies for the length of this article, but maybe this will be definitive enough. There's sure still to be disbelievers. -- Andrew Turner :-) | E-mail : act@csc.canberra.edu.au Comp. Services Centre | +61 6 2522414 / +61 6 2522401 University of Canberra |________________ fax +61 6 2522400 P.O. Box 1 BELCONNEN ACT 2616 AUSTRALIA |