wwitt@adara.intel.com (06/15/91)
Hello everybody, A short while ago I posted a question regarding SHARE to this newsgroup. I needed to know what exactly DOS 4's SHARE does when an application program uses FCBs (instead of handles) to request that a file be opened on a large partition. I received some good information from the net and like to thank all of you who replied. I also got some requests for a summary, so here it goes... As expected, SHARE intercepts file-open requests that use FCBs and secretly translates them, such that the request is successful, even if the file that is being addressed is on a large partition (or network drive) outside of the disk address range that is accessible by the old FCB mechanism. I suppose if SHARE is not run and a program uses FCBs on a large drive, strange behavior including disk corruption could be the result. An alternative to SHARE exists. A program called NOSHARE (written by Tom Almy; see below) simply lets FCB file-opens fail, such that no damage to the disk can occur. However, the application that attempted to open a file with an FCB now breaks. By the way, now that DOS 5 is available, note that it does not need SHARE for large partitions. The functionality to handle FCBs gracefully is built in. As I don't have the time to go into this matter with more depth myself at the moment, I've appended to this posting some of the replies I received. Note that if you sent me mail and it is not included below, it does not mean that your input was not useful or appreciated. Thanks again to everybody who replied to my original posting. Wolf --- Stephen C. Trier <trier@usenet.INS.CWRU.Edu> ============================================ [...] SHARE contains the code for using FCB's on network drives. Since this already implies some trickery, using this for bigger-than-32 Meg drives makes sense. (It would involve the same layer of extra indirection.) All I know about the FCB interaction, I find in _Undocumented DOS_, by Schulman et al. Apparently, there's a list of "system FCB's", which are identical to entries in the system file table used by stream I/O. When a user makes an FCB call, the FCB information is translated into one of the system FCB's, a normal or close-to-normal I/O call is made, and then the information is copied back out of the system FCB, into the user's traditional FCB. My guess is that share inserts itself into the translation process, faking up addresses that are small enough to fit into the 16 bit limits of a CP/M-style FCB. _Undocumented DOS_ includes a list of locations patched by SHARE.EXE, with calling conventions for the SHARE routines. It also comments that "SHARE directly accesses DOS internals", which seems to say that they don't really know exactly what SHARE does. Much of the information on SHARE is probably in Ralf Brown's Interrupt List, since this is coming from the Interrupt List appendix of the book. Tom Almy <toma%sail.labs.tek.com@RELAY.CS.NET> ============================================== [...] It [SHARE] actually manages the file by translating the FCB calls to handle calls. SHARE also implements file sharing, which is unfortunately incompatible with some programs. NOSHARE (which I wrote) [...] doesn't translate the calls but instead causes open and create calls to indicate failure. If you run NOSHARE, when you find a program which doesn't work, you toss it (it is probably very old anyway). John Porter <2195bm@gmuvax.gmu.edu> =================================== SHARE intercepts all DOS calls dealing with FCBs, and translates them (not with Int 21h) to Handle type calls. I say not with int 21h, because SHARE interacts intimately with the DOS kernel; like most of the external DOS commands which go TSR, SHARE and DOS know each others' internals, so don't need the Int 21h (or any other interrupt interface). In fact, I shouldn't say that SHARE actually hooks Int 21h; I think it is called by the existing handler in the kernel when FCB calls are made. (Getting all this?) To increase complexity again, let me amend the earlier statement about how the kernel and extension (like SHARE) communicate: typically it is via Int 2Fh, the Multiplex interrupt. Sorry I don't have the book in front of me, or I could go into very gory detail... Anyway, not loading SHARE for large volumes will be dangerous iff you have program(s) which use FCBs, and any sector of any file so accessed is beyond the 32M boundary. There realy [sic] is no reason NOT to load SHARE anyway (if you have a large volume); the amount of memory it takes up is small, and certainly worth the added security for a large amount of data. Note that the Windows program has its own built-in version of SHARE, so if, for example, you run no DOS programs except Windows, there is no compelling reason to load the non-Windows SHARE. As for the Network interface purpose of SHARE, it remains dormant until activated by some call to a network-related function, such as Get Machine Name. This fact is, however, ~useless to the average programmer. If you need more info on SHARE than what I've outlined above, I'd be glad to help in any way I can; also I strongly recommend the book "Undocumented DOS", by Shulman; 1990 Addison-Wesley. Brian R. Town <town@hpspkla.spk.hp.com> ======================================= Basically, you need share whenever you run an old program (that uses FCB's) on a machine that has a disk with >32Meg partion(s). You may however, use NOSHARE as a replacement to stop these programs from hurting your disk. I think SHARE has mainly to do with networking, but it also has this fix in it (or rather, the fix is a side effect of something they had to do anyway). Personally, I run NOSHARE. I have confirmed that it stops programs from using FCB's by trying to run an old old version of Word Star. If I run this program with SHARE, then everything would be OK. If I run this program without SHARE (or NOSHARE) then I am probably going to corrupt my disk. If I try to run this program (or any other using the old FCB's) it will terminate with an error message, thus keeping me from trashing my disk. There is no way to know (easily) that a program uses FCB's, so I wouldn't take any chances. Use NOSHARE. It is very small and an effective savegaurd [sic]. => Wolf Witt, Design Engineer <=> You say there is a bug in this chip? <= => i860 Focus Group, Intel Corp. <=> No, no, you don't understand... <= => wwitt@smdvx1.intel.com <=> This is a feature! <= => Intel knows nothing about what I say or do, but they pay me anyway. <=