Sender:	vheyndri AT rug DOT ac DOT be
Message-Id:	<35162397.5E5@rug.ac.be>
Date:	Mon, 23 Mar 1998 09:55:51 +0100
From:	Vik Heyndrickx <Vik DOT Heyndrickx AT rug DOT ac DOT be>
Mime-Version:	1.0
To:	"Salvador Eduardo Tropea (SET)" <salvador AT inti DOT gov DOT ar>
Cc:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>, djgpp-workers AT delorie DOT com
Subject:	Re: DOS sharing behaviour, a guide
References:	<m0yFl9F-000S2lC AT inti DOT gov DOT ar>

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.

> > 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.

-- 
 \ Vik /-_-_-_-_-_-_/   
  \___/ Heyndrickx /          
   \ /-_-_-_-_-_-_/

- Raw text -