Mail Archives: djgpp-workers/1998/03/19/14:43:02
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
- Raw text -