Date: Fri, 01 Dec 2000 09:44:25 +0200 From: "Eli Zaretskii" Sender: halo1 AT zahav DOT net DOT il To: pjfarley AT banet DOT net Message-Id: <1659-Fri01Dec2000094425+0200-eliz@is.elta.co.il> X-Mailer: Emacs 20.6 (via feedmail 8.3.emacs20_6 I) and Blat ver 1.8.6 CC: snowball3 AT bigfoot DOT com, djgpp-workers AT delorie DOT com In-reply-to: <5.0.1.4.0.20001130210206.0259eb60@pop5.banet.net> (pjfarley AT banet DOT net) Subject: Re: Locking fcntl() and flock() patches References: <5 DOT 0 DOT 1 DOT 4 DOT 0 DOT 20001129230443 DOT 0259fec0 AT pop5 DOT banet DOT net> <5 DOT 0 DOT 1 DOT 4 DOT 0 DOT 20001130210206 DOT 0259eb60 AT pop5 DOT banet DOT net> Reply-To: djgpp-workers AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk > Date: Thu, 30 Nov 2000 21:33:32 -0500 > From: "Peter J. Farley III" > > If there are no read locks, and we simulate them with write locks... > well, maybe not, after all. If the locks are regional, then another > process won't be able to change that region, after all. I see your > point. Maybe we can just translate the read locks to write locks and > be done with it. That's what I thought we should do. > >The detection part is easy: Int 2Fh with AX=1000h will tell you if > >SHARE is installed (and DTRT on Windows as well, AFAIK). > > Well, that's interesting. Do we then *want* to act as a no-op when > SHARE is not installed, and always return success? I think so. The only case where this loses is on Windows 3.X where someone uninstalled SHARE.EXE. We can document this special case and be done with it. > That still has the > disadvantage for new coding with erroneous locking logic that it won't > catch the error(s) until the program is run in a locking environment. We can document this as well. Anyway, whoever writes code that needs locking should test it in the environment where locking works, right?