Sender: vheyndri AT rug DOT ac DOT be
Message-Id: <35178776.630E@rug.ac.be>
Date: Tue, 24 Mar 1998 11:14:14 +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: vheyndri AT rug DOT ac DOT be, 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: <m0yH7DN-000S2sC AT inti DOT gov DOT ar>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk

Salvador Eduardo Tropea (SET) wrote:
> 
> Vik Heyndrickx <Vik DOT Heyndrickx AT rug DOT ac DOT be> wrote:
> 
> > 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.

Have I had a chance to see that final patch, I don't recall I have? I
cannot find it anywhere.

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

So programs compiled with other compilers are buggy under (hmmm)
multitasking OS'es, what's your point?

> In my opinion the actual patch
> (where you select the flag) is the one that will generate less problems.

Well I haven't seen it, but from your description here:
It seems indeed a good idea to use the sharing mode COMPAT by default,
and and flag controlling whether a more enhanced sharing interface
should be used. This way old programs won't be broken and newer and
older corrected programs can benefit from this new behaviour.
It is some pitty that ANSI has no way of controlling this sharing
behaviour. It seems that those ANSI committee people have been
brain-washed by AT&T (That's not only a funny remark, I also mean it)

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

Can't a crt1 startup flag be used to control this behaviour?

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