Message-Id: Comments: Authenticated sender is From: "Salvador Eduardo Tropea (SET)" Organization: INTI To: vheyndri AT rug DOT ac DOT be, Eli Zaretskii , djgpp-workers AT delorie DOT com Date: Tue, 24 Mar 1998 09:20:11 +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: <35178776.630E@rug.ac.be> Precedence: bulk Vik Heyndrickx wrote: > Salvador Eduardo Tropea (SET) wrote: > > > > Vik Heyndrickx 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. Was posted here (djgpp-workers). I don't have it right now but basically it defines a new variable (__djgpp_share_flags) where you can put the default share flags. Then if you call open without specifying any share flag (the fopen case) open uses the __djgpp_share_flags. So the patch doesn't affect any working program, but allows to my editor define: int __djgpp_share_flags=... to deny any thing. > > > 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? From my point of view: Yes that's a buggy thing. From the reality: In UNIX the default behavior is more like COMPAT mode without share (you have functions to lock, set access rights, etc, but you must fine tune it) so I don't know if one (or more) GNU programs could break with share flags. > > 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) Well perhaps POSIX stablish some protection scheme (don't know if the glibc features are POSIX), but normally ANSI is VERY generic and that looks like an specific topic. > > 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? Currently my patch uses a variable defined to 0 in one .o file (inside libc) so it doesn't affect to old programs, you just need to redefine the variable in your code overwriting the one in libc. 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