Message-Id: <m0yFl9F-000S2lC@inti.gov.ar>
Comments: Authenticated sender is <salvador AT natacha DOT inti DOT gov DOT ar>
From: "Salvador Eduardo Tropea (SET)" <salvador AT inti DOT gov DOT ar>
Organization: INTI
To: Vik Heyndrickx <Vik DOT Heyndrickx AT rug DOT ac DOT be>,
        Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>, SET <salvador AT inti DOT gov DOT ar>,
        djgpp-workers AT delorie DOT com
Date: Thu, 19 Mar 1998 16:41:09 +0000
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: DOS sharing behaviour, a guide
In-reply-to: <3510E470.5F2@rug.ac.be>
Precedence: bulk

Vik Heyndrickx <Vik DOT Heyndrickx AT rug DOT ac DOT be> wrote:

> * if no sharing is installed (SHARE.EXE, vshare.386 or whatever):
> DOS can't care less what we pass as sharing mode, it simple ignores it
> and a consecutive open always succeeds. DOS is not a protective
> operating system, isn't it.

I got the same results, but just put clear that "DOS" means MSDOS < v7.00

> * with SHARE.EXE from DOS6.22:
> a second open in compatibility mode always fails, or when the first open
> was in compatibility mode this second open also fails always. There is
> nothing we can do about that (in the second program).

Yes, that's the reason because I created the patch for open. My editor can't 
open the help files twice because of that.

> * with vshare.386 in Win3.1
> a second open in compatibility mode always fails when the first file was
> also opened in compatibility mode, except when both prg's opened the
> file for reading only.
> * Win95
> identical to vshare.386 from Win3.1 when it concerns the fact whether an
> open command succeeds. It also has a fourth access mode, but of less
> importance to us.
> 
> Third:
> Remark: when the second upon occurs in the same program in compatibility
> mode the call usually succeeds, from a different program usually not.
> 
> A file that just has been created (with CREAT, CREATNEW, CREATTEMP) can
> be considered as being opened for r/w in compatibility mode (which is
> the same as r/w + deny-read) (Eli, that where you asked for).
> 
> The EXTENDED OPEN function is featurative or ***buggy*** (I'll decide
> upon that this weekend):
> You can successfully create a non-read/only file for reading only, and
> fail to write to it afterwards (see the reason why I need a weekend to
> decide whether it is a bug)
> Further details on this EXT. OPEN function will follow later on when
> they come in :-)
> Anyway some of our libc functions might fail because of this.
> 
> Preliminary conclusions:
> if we have to open a file for:
> 	reading
> 		open it for reading and specify DENYWRITE (that avoids the SET patch)
> 	writing
> 		open it for writing and specify DENYALL
>         r/w
> 		open it for r/w and specify DENYALL
> This way we INCREASE the chance that a file can be opened
> successfully.        
> 
> That's all, If you've questions or remarks feel free to ask me
> personnaly. When it contains something it concerns us all I'll CC
> workers.

Ok, but what about stupid programs that opens the same file more than ones in 
the same code? I detected this stupid behavior in my own code when I used my 
patch. Of course it was a *bug* but could break a working program, in fact my 
programs stoped saving the desktop file after using the DENYWRITE.

So I don't know if an uncoditional share flag is a good idea.

SET
------------------------------------ 0 --------------------------------
Visit my home page: http://set-soft.home.ml.org/
or
http://www.geocities.com/SiliconValley/Vista/6552/
Salvador Eduardo Tropea (SET). (Electronics Engineer)
Alternative e-mail: set-sot AT usa DOT net - ICQ: 2951574
Address: Curapaligue 2124, Caseros, 3 de Febrero
Buenos Aires, (1678), ARGENTINA
TE: +(541) 759 0013