Message-Id:	<m0yH7DN-000S2sC@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:	vheyndri AT rug DOT ac DOT be, Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>,
	djgpp-workers AT delorie DOT com
Date:	Mon, 23 Mar 1998 10:27:27 +0000
MIME-Version:	1.0
Subject:	Re: DOS sharing behaviour, a guide
In-reply-to:	<35162397.5E5@rug.ac.be>

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


> Salvador Eduardo Tropea (SET) wrote:
> > 
> > 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
> 
> No! This includes MSDOS up to v7.10 (no Win). But of course a second
> open from a different program is difficult to test there.
> 
> > > * 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.
> 
> I think your patch should not specify DENYNONE, but DENYWRITE. It better
> simulates the compatibility mode behaviour. But, your patch won't help a
> bit in this case when the file was already open in compatibility mode.
> That is the mean reason why I think that all open functions never should
> use the compatibility mode.

That was the idea, but as it can produce problems the final patch doesn't use a 
predefined value and the user must select what s/he want to use.
 
> > > 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)
> 
> My decision is that it is a doubtful feature. I scanned the libc sources
> for this and this could never occur in the latest alpha release.
> Note also that this is the only possibility for successfully opening a
> file in some open mode while read/write access that normally are
> expected to proceed, fail.
> 
> > 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.
> 
> The fact is that opening in COMPAT mode such a program IS broken under
> several OS versions.
> I see no way to solve both of these problems, but it seems that an
> unconditional share flag solves it better.

Remmember that other compilers use COMPAT mode. In my opinion the actual patch 
(where you select the flag) is the one that will generate less problems. 
Perhaps the modifications that you say can be introduced but conditionally, I 
mean having a flag to enable it.
The main problem is to know if one or more applications will be affected by it. 
In my case one of my applications needed modifications and I'M using DENYWRITE 
and not DENYNONE.

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-soft AT usa DOT net set AT computer DOT org
CQ: 2951574
Address: Curapaligue 2124, Caseros, 3 de Febrero
Buenos Aires, (1678), ARGENTINA
TE: +(541) 759 0013

- Raw text -