Xref: utzoo comp.os.msdos.programmer:3594 comp.binaries.ibm.pc.d:12659 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!xstor!bang!iverson From: iverson@bang.uucp (Tim Iverson) Newsgroups: comp.os.msdos.programmer,comp.binaries.ibm.pc.d Subject: Re: Why load "SHARE" (was Re: program to break 32MB barrier) Message-ID: <1991Feb24.034603.5560@bang.uucp> Date: 24 Feb 91 03:46:03 GMT References: <1078@rna.UUCP> <1991Feb13.130613.13467@csc.canberra.edu.au> Reply-To: iverson@xstor.com Followup-To: comp.os.msdos.programmer Organization: House of the Smoking Gun Lines: 27 In article otto@tukki.jyu.fi (Otto J. Makela) writes: >In article <1991Feb13.130613.13467@csc.canberra.edu.au> act@softserver.canberra.edu.au (Andrew Turner) writes: >> 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. Sure they did. Check out comp.com. >Well, I know that DEL, the COMMAND.COM builtin uses FCB wildcards to get the >job done quickly. Does anyone with a large hard disk care to try this ? > > Otto J. Makela Works fine. The delete function doesn't exercise the bug, only read and write do. If you'd like to find out if a program uses FCBs, just set the device open/close bit in the DOS "kernel"; as well as causing open/close calls to go to the driver, it also has the side effect of disabling FCBs. When a program uses FCBs, you'll see an 'abort, retry' message (sorry, DOS can't ignore this one!). If you don't like hacking your "OS", you could use a recent copy of the SpeedStor device driver with the /nofcb option. This has roughly the same effect. - Tim Iverson iverson@xstor.com -/- uunet!xstor!iverson