Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!uunet!dev8n.mdcbbs.com!campbell From: campbell@dev8n.mdcbbs.com (Tim Campbell) Newsgroups: comp.os.msdos.apps Subject: Re: using share in dos4 Message-ID: <1991Feb26.130608.1@dev8n.mdcbbs.com> Date: 26 Feb 91 13:06:08 GMT References: <3603@casbah.acns.nwu.edu> <4870@ruuinf.cs.ruu.nl> <12330@helios.TAMU.EDU> Organization: McDonnell Douglas M&E, Cypress CA Lines: 69 Nntp-Posting-Host: dev8n Nntp-Posting-User: campbell [ quoted text from original message(s) deleted ] > > I'm quoting everything because I don't have access to the original message. > > OK, now IGNORE THE MESSAGE. Straight from Microsoft technical support, as > I had a problem with SHARE.EXE conflicting with another program, there are > exactly two reasons to run SHARE. > > 1. An applications program (such as network stuff) explicitly states that > you MUST run it. MS Windows advises it, but you don't have to if you > don't try anything fancy, like editing the same file twice. > > 2. If you are creating files > 32 MB. The logic to handle these is in > SHARE. > > That's it. Don't run it. Remove it from your hard disk, and ignore the error > message. DANGER WILL ROBINSON! The reason the message is ussed for "large media" is because of the increase in the size of the FAT table. If you have an "old" program (I say "old" because anybody caught doing this in a new program should simply be taken out back and shot - and of course I'm CONFIDENT that NOBODY today would ever do such a stupid thing) - anyway, DOS has two ways to use files. File Descriptors and File Handles. The "handles" method involves your program using a DOS service to open a file and DOS takes care of everything - you just tell DOS what you want to read/write. The "descriptor" method allocates a block of storage in your programs data area which contains a structure filled out with wonderful details about your file. Among this info, are some fields which are essentially pointers to locations on the disk - the same pointers found in the FAT table. The FAT tables had 12 or 16bit entries depending on which version of DOS you used. But when the 32Mb barrier needed to be broken, a larger FAT was needed. The "file descripter" no longer had adequate space to store this new larger value. The danger here is that the old program could overflow the value IF IT ATTEMPTS TO ACCESS (for any reason) ANY PORTION OF A FILE LOCATED BEYOND THE 32MB PORTION OF YOUR DISK! This problem *might* go completely unnoticed. It *might* cause no problem at all. But there is a very good chance that it *will* corrupt data in unsuspecting locations of your disk. I strongly suspect you either mis-understood the person at Microsoft, or whoever you spoke with was inexperienced and misunderstood either you, or the problem. In any case, it is not safe to follow the instructions MS gave you. I know folks who were "confident" they didn't have any software with this problem. Upon closer examination, they were suprised to learn that a few of the programs they had, did use the "file descriptors" and would have created problems had they used them. I apologize for the length of this messge. There seems to be a lot of problems with this one subject due to ignorance of exactly what SHARE is, what it does, how it works, why it's needed, etc. Much of this is IBM & MS's fault - I've read their (practicly non-existent) documentation on SHARE - which when summarized, basically says you should use the program with no explanation or reason why. It becomes much more obvious that you should use the program once you understand the detail. -Tim --------------------------------------------------------------------------- In real life: Tim Campbell - Electronic Data Systems Corp. Usenet: campbell@dev8.mdcbbs.com @ McDonnell Douglas M&E - Cypress, CA also: tcampbel@einstein.eds.com @ EDS - Troy, MI CompuServe: 71631,654 Prodigy: MPTX77A P.S. If anyone asks, just remember, you never saw any of this -- in fact, I wasn't even here.