RE: Cygwin B20 - fseek under gcc fails to reposition on text files

RE: Cygwin B20 - fseek under gcc fails to reposition on text files

[Earnie Boyd]

Ok I appoligize.

Here is the "Microsoft VC++ Run-Time Library Reference" quote:

For streams opened in text mode, fseek has limited use, because
carriage return-linefeed translations can cause fseek to produce
unexpected results.  The only fseek operations guaranteed to work on
streams opened in text mode are:

* Seeking with an offset of 0 relative to any of the origin values.

* Seeking from the beginning of the file with an offset value returned
from a call to ftell.

Also in text mode, CTRL+Z is interpreted as an end-of-file character
on input.  In files opened for reading/writing, fopen and all related
routines check for a CTRL+Z at the end of the file and remove it if
possible.  This is done because using fseek and ftell to move within
an file that ends in CTRL+Z may cause fseek to behave improperly near
the end of the file.

---

Based on the documentation then I'll have to agree that your programs
isn't behaving as the documentation states that it should.  But, which
is wrong, fseek or ftell?

Sorry for speaking out of line,
Earnie.

---Peter Kabal <kabal@ece.mcgill.ca> wrote:
>
> I did.  I quote from Harbison and Steele, Fourth edition, p 353.
> 
> "The following, more limited set of calls is permitted on text streams
> by ISO C:
> 
> fseek (stream, 0L, SEEK_SET)
> fseek (stream, 0L, SEEK_CUR)
> fseek (stream, 0L, SEEK_END)
> fseek (stream, 0L, ftell_pos, SEEK_SET)  at a position returned by a
>     previous call to ftell for stream.
> "
> 
> I <did> read the docs about "text mode processing"!  Your comment was
> unwarranted and warrants an apology.
> 
> > -----Original Message-----
> > From: Earnie Boyd [ mailto:earnie_boyd@yahoo.com ]
> > Sent: February 16, 1999 8:28 AM
> > To: kabal@ece.mcgill.ca
> > Cc: cygwin users
> > Subject: Re: Cygwin B20 - fseek under gcc fails to reposition on
text
> > files
> > 
> > 
> > 
> > You need to read the docs about "text mode processing".  This is
> > exactly the expected behavior.  If you're going to use these
functions
> > then you must process in binary mode.
> > 
> > Regards,
> > Earnie.
> > 
> > ---Peter Kabal <kabal@ECE.McGill.CA> wrote:
> > >
> > > Consider a text file (CR/LF line endings).  Read a line, save the
> > > current position, seek to end-of-file, seek to the saved position,
> > > read a line.  The second read does not return the second line of
> > > the file.
> > > 
> > > A shell script which tests the problem is included below:
> > >
---------------------------------------------------------------------
> > > #!/bin/sh
> > > #
> > > # Test fseek bug
> > > # On Cygwin 20.1, a file is not correctly repositioned after
seeking
> > to the
> > > # end-of-file on a text file (CR/LF line endings).
> > > 
> > > cat > tfrepos.c << EoF
> > > #include <stdio.h>
> > > int main (int argc, char *argv[])
> > > {
> > >   FILE *fp;
> > >   long int pos, size;
> > >   char line[200];
> > >   char *p;
> > > 
> > >   fp = fopen (argv[1], "r");
> > >   p = fgets (line, 200, fp);
> > >   printf (" Line: %s", p);
> > > 
> > >   pos = ftell (fp);
> > >   fseek (fp, 0L, SEEK_END);
> > >   fseek (fp, pos, SEEK_SET);
> > > 
> > >   p = fgets (line, 200, fp);
> > >   printf (" Line: %s", p);
> > > 
> > >   return 0;
> > > }
> > > EoF
> > > 
> > > # Run the test program with the c-program as input
> > > gcc tfrepos.c -o tfrepos
> > > ./tfrepos tfrepos.c
> > > 
> > > # Clean up
> > > rm -f tfrepos tfrepos.c
> > >
---------------------------------------------------------------------
> > > 
> > > Peter Kabal  kabal@ECE.McGill.CA
> > > Dept. Electrical & Computer Eng.
> > > McGill University 
> > > 
> > 
> > _________________________________________________________
> > DO YOU YAHOO!?
> > Get your free @yahoo.com address at http://mail.yahoo.com
> > 
> > 
> 

_________________________________________________________
DO YOU YAHOO!?
Get your free @yahoo.com address at http://mail.yahoo.com

Re: Cygwin B20 - fseek under gcc fails to reposition on text files

[Christopher Faylor]

On Tue, Feb 16, 1999 at 07:41:34AM -0800, Earnie Boyd wrote:
>
>Ok I appoligize.
>
>Here is the "Microsoft VC++ Run-Time Library Reference" quote:
>
>For streams opened in text mode, fseek has limited use, because
>carriage return-linefeed translations can cause fseek to produce
>unexpected results.  The only fseek operations guaranteed to work on
>streams opened in text mode are:
>
>* Seeking with an offset of 0 relative to any of the origin values.
>
>* Seeking from the beginning of the file with an offset value returned
>from a call to ftell.
>
>Also in text mode, CTRL+Z is interpreted as an end-of-file character
>on input.  In files opened for reading/writing, fopen and all related
>routines check for a CTRL+Z at the end of the file and remove it if
>possible.  This is done because using fseek and ftell to move within
>an file that ends in CTRL+Z may cause fseek to behave improperly near
>the end of the file.
>
>---
>
>Based on the documentation then I'll have to agree that your programs
>isn't behaving as the documentation states that it should.  But, which
>is wrong, fseek or ftell?
>
>Sorry for speaking out of line,

This does sound like a bug.  We'll try to look into this, time permitting.

If anyone else wants to take a stab at this (Corinna?) I'd be very grateful.

-chris

Re: Cygwin B20 - fseek under gcc fails to reposition on text files

[DJ Delorie]

> >* Seeking with an offset of 0 relative to any of the origin values.

This means fseek(file, 0, SEEK_SET) or fseek(file, 0, SEEK_END).

> >* Seeking from the beginning of the file with an offset value returned
> >from a call to ftell.

This allows the library to read() through the file instead of seeking,
to compensage for CR/LF conversions.  If you seek from the end of the
file, these rules do not guarantee success.

The problems are usually in ftell(), since with buffered I/O it's
nearly impossible to determine what actual file position corresponds
to a character in the middle of a stdio buffer.  DJGPP could only
solve this problem by having stdio open *all* files as binary, and
managing the conversion after the buffering.

Re: Cygwin B20 - fseek under gcc fails to reposition on text files

[DJ Delorie]

> >* Seeking with an offset of 0 relative to any of the origin values.

This means fseek(file, 0, SEEK_SET) or fseek(file, 0, SEEK_END).

> >* Seeking from the beginning of the file with an offset value returned
> >from a call to ftell.

This allows the library to read() through the file instead of seeking,
to compensage for CR/LF conversions.  If you seek from the end of the
file, these rules do not guarantee success.

The problems are usually in ftell(), since with buffered I/O it's
nearly impossible to determine what actual file position corresponds
to a character in the middle of a stdio buffer.  DJGPP could only
solve this problem by having stdio open *all* files as binary, and
managing the conversion after the buffering.

Re: Cygwin B20 - fseek under gcc fails to reposition on text files

[Corinna Vinschen]

Christopher Faylor wrote:
> 
> On Tue, Feb 16, 1999 at 07:41:34AM -0800, Earnie Boyd wrote:
> >
> >Here is the "Microsoft VC++ Run-Time Library Reference" quote:
> >
> >For streams opened in text mode, fseek has limited use, because
> >carriage return-linefeed translations can cause fseek to produce
> >unexpected results.  The only fseek operations guaranteed to work on
> >streams opened in text mode are:
> >
> >* Seeking with an offset of 0 relative to any of the origin values.
> >
> >* Seeking from the beginning of the file with an offset value returned
> >from a call to ftell.
> >
> >Also in text mode, CTRL+Z is interpreted as an end-of-file character
> >[...]

This is the _documentation_ of M$. In fact their code doesn't do the right
thing! As the ftell of newlib, it works without special calls of the
underlying OS, only calls to `_lseek()' are performed.  The only difference
between M$ and newlib is, that M$ performs additional counting of \n in
case of text file processing. It's done in the already translated buffer,
so the result is crap, as in newlib. Only their hit count is better.

> >Based on the documentation then I'll have to agree that your programs
> >isn't behaving as the documentation states that it should.  But, which
> >is wrong, fseek or ftell?
> 
> This does sound like a bug.  We'll try to look into this, time permitting.
> 
> If anyone else wants to take a stab at this (Corinna?) I'd be very grateful.

We have three possible choices:

1st: We are not performing the same errors as M$. We do our own, so we let
     it as it is.

2nd: M$-compatible errors, so we let ftell count \n, too. This would result
     in more often correct telling.

3rd: The full stdio code in newlib has to be changed. The buffer is used
     anyway in binary mode, every call has to use new counting and
     translation methods than the current one.
     Because this has to be done _very_ cautious, it's a long time change.

For the near future, I would prefer the second choice. Other opinions?

Regards,
Corinna


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Cygwin B20 - fseek under gcc fails to reposition on text files

[DJ Delorie]

> 3rd: The full stdio code in newlib has to be changed. The buffer is used
>      anyway in binary mode, every call has to use new counting and
>      translation methods than the current one.
>      Because this has to be done _very_ cautious, it's a long time change.

FYI, DJGPP does it this way, and you're right, it was a big change.

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Cygwin B20 - fseek under gcc fails to reposition on text files

[DJ Delorie]

> 3rd: The full stdio code in newlib has to be changed. The buffer is used
>      anyway in binary mode, every call has to use new counting and
>      translation methods than the current one.
>      Because this has to be done _very_ cautious, it's a long time change.

FYI, DJGPP does it this way, and you're right, it was a big change.

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Cygwin B20 - fseek under gcc fails to reposition on text files

[J. J. Farrell]

> From: Corinna Vinschen <corinna.vinschen@cityweb.de>
> 
> Christopher Faylor wrote:
> > 
> > On Tue, Feb 16, 1999 at 07:41:34AM -0800, Earnie Boyd wrote:
> > >
> > >Here is the "Microsoft VC++ Run-Time Library Reference" quote:
> > >
> > >For streams opened in text mode, fseek has limited use, because
> > >carriage return-linefeed translations can cause fseek to produce
> > >unexpected results.  The only fseek operations guaranteed to work on
> > >streams opened in text mode are:
> > >
> > >* Seeking with an offset of 0 relative to any of the origin values.
> > >
> > >* Seeking from the beginning of the file with an offset value returned
> > >from a call to ftell.
> > >
> > >Also in text mode, CTRL+Z is interpreted as an end-of-file character
> > >[...]
> 
> This is the _documentation_ of M$. In fact their code doesn't do the right
> thing! As the ftell of newlib, it works without special calls of the
> underlying OS, only calls to `_lseek()' are performed.  The only difference
> between M$ and newlib is, that M$ performs additional counting of \n in
> case of text file processing. It's done in the already translated buffer,
> so the result is crap, as in newlib. Only their hit count is better.
> 
> We have three possible choices:
> 
> 1st: We are not performing the same errors as M$. We do our own, so we let
>      it as it is.
> 
> 2nd: M$-compatible errors, so we let ftell count \n, too. This would result
>      in more often correct telling.
> 
> 3rd: The full stdio code in newlib has to be changed. The buffer is used
>      anyway in binary mode, every call has to use new counting and
>      translation methods than the current one.
>      Because this has to be done _very_ cautious, it's a long time change.
> 
> For the near future, I would prefer the second choice. Other opinions?

This isn't just a question of compatibility with MS, it's one of
conformance to Standard C - we should aim to get it right, in the
long term at least, whether we like it or not!

Here are a couple of extracts from C89 which describe how this
lot should work on text streams - it's perhaps safer to base an
implementation on what comes from the horse's mouth rather than
what MS's documentation says, though MS looks basically OK in
this case:

   4.9.9.2  int fseek(FILE *stream, long int offset, int whence)

   For a text stream, either <offset> shall be zero, or <offset>
   shall be a value returned by an earlier call to the <ftell>
   function on the same stream and <whence> shall be <SEEK_SET>.


   4.9.9.4  long int ftell(FILE *stream)

   The <ftell> function obtains the current value of the file
   position indicator for the stream pointed to by <stream>. 
   For a text stream, its file position indicator contains
   unspecified information, usable by the <fseek> function for
   returning the file position indicator for the stream to its
   position at the time of the <ftell> call; the difference
   between two such return values is not necessarily a meaningful
   measure of the number of characters written or read.

Do we do fgetpos/fsetpos right for both binary and text? The
definition of ftell/fseek for text is essentially the same as
fgetpos/fsetpos for both types - so I would guess there's either
a problem with fgetpos/fsetpos as well, or we could pinch
something from it for the ftell/fseek text case.


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Cygwin B20 - fseek under gcc fails to reposition on text files

[J. J. Farrell]

> From: Corinna Vinschen <corinna.vinschen@cityweb.de>
> 
> Christopher Faylor wrote:
> > 
> > On Tue, Feb 16, 1999 at 07:41:34AM -0800, Earnie Boyd wrote:
> > >
> > >Here is the "Microsoft VC++ Run-Time Library Reference" quote:
> > >
> > >For streams opened in text mode, fseek has limited use, because
> > >carriage return-linefeed translations can cause fseek to produce
> > >unexpected results.  The only fseek operations guaranteed to work on
> > >streams opened in text mode are:
> > >
> > >* Seeking with an offset of 0 relative to any of the origin values.
> > >
> > >* Seeking from the beginning of the file with an offset value returned
> > >from a call to ftell.
> > >
> > >Also in text mode, CTRL+Z is interpreted as an end-of-file character
> > >[...]
> 
> This is the _documentation_ of M$. In fact their code doesn't do the right
> thing! As the ftell of newlib, it works without special calls of the
> underlying OS, only calls to `_lseek()' are performed.  The only difference
> between M$ and newlib is, that M$ performs additional counting of \n in
> case of text file processing. It's done in the already translated buffer,
> so the result is crap, as in newlib. Only their hit count is better.
> 
> We have three possible choices:
> 
> 1st: We are not performing the same errors as M$. We do our own, so we let
>      it as it is.
> 
> 2nd: M$-compatible errors, so we let ftell count \n, too. This would result
>      in more often correct telling.
> 
> 3rd: The full stdio code in newlib has to be changed. The buffer is used
>      anyway in binary mode, every call has to use new counting and
>      translation methods than the current one.
>      Because this has to be done _very_ cautious, it's a long time change.
> 
> For the near future, I would prefer the second choice. Other opinions?

This isn't just a question of compatibility with MS, it's one of
conformance to Standard C - we should aim to get it right, in the
long term at least, whether we like it or not!

Here are a couple of extracts from C89 which describe how this
lot should work on text streams - it's perhaps safer to base an
implementation on what comes from the horse's mouth rather than
what MS's documentation says, though MS looks basically OK in
this case:

   4.9.9.2  int fseek(FILE *stream, long int offset, int whence)

   For a text stream, either <offset> shall be zero, or <offset>
   shall be a value returned by an earlier call to the <ftell>
   function on the same stream and <whence> shall be <SEEK_SET>.


   4.9.9.4  long int ftell(FILE *stream)

   The <ftell> function obtains the current value of the file
   position indicator for the stream pointed to by <stream>. 
   For a text stream, its file position indicator contains
   unspecified information, usable by the <fseek> function for
   returning the file position indicator for the stream to its
   position at the time of the <ftell> call; the difference
   between two such return values is not necessarily a meaningful
   measure of the number of characters written or read.

Do we do fgetpos/fsetpos right for both binary and text? The
definition of ftell/fseek for text is essentially the same as
fgetpos/fsetpos for both types - so I would guess there's either
a problem with fgetpos/fsetpos as well, or we could pinch
something from it for the ftell/fseek text case.


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re[2]: Cygwin B20 - fseek under gcc fails to reposition on text files

[Paul Sokolovsky]

Hello Corinna,

Corinna Vinschen <corinna.vinschen@cityweb.de> wrote:

[]

CV> We have three possible choices:

CV> 1st: We are not performing the same errors as M$. We do our own, so we let
CV>      it as it is.

CV> 2nd: M$-compatible errors, so we let ftell count \n, too. This would result
CV>      in more often correct telling.

CV> 3rd: The full stdio code in newlib has to be changed. The buffer is used
CV>      anyway in binary mode, every call has to use new counting and
CV>      translation methods than the current one.
CV>      Because this has to be done _very_ cautious, it's a long time change.

CV> For the near future, I would prefer the second choice. Other opinions?

    Let me support 3rd way, in rather flamy passages, however.

    So, for more than twenty years MS maintains myth about "special
format" of text files of their systems. It's hardly believable. Since
my old XT I quite nicely handled any text files - be they Unix \xa,
Mac \xd, or "dos" \xd\xa . So there's nothing special to talk about
"special" format of text files. Most tools available handled any type,
and conversion between formats was quite feasible. With win32, such
problems are ceased at all - I don't have no line endings problems, no
encoding problems, even that unicode seams to be here.

   And here we come to most interesting questions - that fact that MS
maintains aforementioned myth is not surprising, but that myth is
carefully maintained by outside crew too! Just listen to those GNUers
telling us that text files here are "special" and they must dirty
workaround that! Just see peoples advocating data stream corruption on
most basic system level!

   But what if stop that play and acknowledge that some guys have done
quite well and it's useless to try to not notice that. \r\n textfiles
should be handled properly where they belong - e.g. in textutils, but
never in core system, leading just to corruption.

   So, what I argue:

1. Text/binary file notion on most basic, POSIX level should be
   abandoned.
2. That has nothing to do with stdio level - since default accessors for
   that level are single-character oriented, it doesn't hurt much
   stuffing single test there.

(Note that this indeed DJ Delorie's idea as of DJGPP lib, pushed further
to exterminating textuality on POSIX level at all)

3. All stuff working with textfiles and using POSIX level either should
   be taught accept any line-endings or reimplented in stdio.

4. Until then, there're fromdos/todos filters.


   And finally, from where all this stuff might be originated - it may
be done whatever wanted, but if, when writing to console we get clobbered
output without carrage returns, it doesn't cost a cent. That's where
myth of win32 speciality breaks down - Win32 console, as any other
console in cooked mode (Linux, say) performs implicit cr after lf,
when there's no explicit.

   Just run following (tested only on Win95/Win95OSR2 to be honest):

--------
#include <windows.h>

char str[]="\nline1\nline2\nline3\n";

void main()
{
  DWORD dummy;
  WriteFile(STD_OUTPUT_HANDLE,str,sizeof(str)-1,&dummy,NULL);
  WriteFile(STD_ERROR_HANDLE,str,sizeof(str)-1,&dummy,NULL);
}
--------


CV> Regards,
CV> Corinna


Best regards,
 Paul                            mailto:paul-ml@is.lg.ua


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Cygwin B20 - fseek under gcc fails to reposition on text files

[DJ Delorie]

>    And finally, from where all this stuff might be originated - it may
> be done whatever wanted, but if, when writing to console we get clobbered
> output without carrage returns, it doesn't cost a cent. That's where
> myth of win32 speciality breaks down - Win32 console, as any other
> console in cooked mode (Linux, say) performs implicit cr after lf,
> when there's no explicit.

To add fact to the myth, if you bring up such a file (\n without \r)
in notepad, it does not do the right thing - it very explicitly looks
for the CR/LF pair to mean a line ending, and no other ending will do.

Batch files also cannot have NL endings - they need CR/LF endings.

Of course, this really just means that the programmers were
short-sighted, but it's still a fact we must live with.

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Cygwin B20 - fseek under gcc fails to reposition on text files

[Larry Hall]

At 01:07 PM 2/17/99 -0500, DJ Delorie wrote:
>Batch files also cannot have NL endings - they need CR/LF endings.

You sure about that?  In my binary mounted environment I tried:

D:\tmp>cat b.bat
echo hello

D:\tmp>b

D:\tmp>echo hello
hello

D:\tmp>od -h b.bat
0000000 6365 6f68 6820 6c65 6f6c 000a
0000013

D:\tmp>

Hm...


Larry Hall                              lhall@rfk.com
RFK Partners, Inc.                      (781) 239-1053
8 Grove Street                          (781) 239-1655 - FAX
Wellesley, MA  02482-7797               http://www.rfk.com

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Cygwin B20 - fseek under gcc fails to reposition on text files

[DJ Delorie]

> You sure about that?  In my binary mounted environment I tried:

Under Win95, try two lines:

	echo hi
	dir

I *know* DOS has this problem, I suspect Win95 shares it.  NT does not.

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Cygwin B20 - fseek under gcc fails to reposition on text files

[Larry Hall]

At 10:18 PM 2/17/99 -0500, DJ Delorie wrote:
>
>> You sure about that?  In my binary mounted environment I tried:
>
>Under Win95, try two lines:
>
>	echo hi
>	dir
>
>I *know* DOS has this problem, I suspect Win95 shares it.  NT does not.
>

Ah, forgot about that!  I'm on NT!;-)


Larry

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Cygwin B20 - fseek under gcc fails to reposition on text files

[Larry Hall]

At 10:18 PM 2/17/99 -0500, DJ Delorie wrote:
>
>> You sure about that?  In my binary mounted environment I tried:
>
>Under Win95, try two lines:
>
>	echo hi
>	dir
>
>I *know* DOS has this problem, I suspect Win95 shares it.  NT does not.
>

Ah, forgot about that!  I'm on NT!;-)


Larry

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Cygwin B20 - fseek under gcc fails to reposition on text files

[DJ Delorie]

> You sure about that?  In my binary mounted environment I tried:

Under Win95, try two lines:

	echo hi
	dir

I *know* DOS has this problem, I suspect Win95 shares it.  NT does not.

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Cygwin B20 - fseek under gcc fails to reposition on text files

[Larry Hall]

At 01:07 PM 2/17/99 -0500, DJ Delorie wrote:
>Batch files also cannot have NL endings - they need CR/LF endings.

You sure about that?  In my binary mounted environment I tried:

D:\tmp>cat b.bat
echo hello

D:\tmp>b

D:\tmp>echo hello
hello

D:\tmp>od -h b.bat
0000000 6365 6f68 6820 6c65 6f6c 000a
0000013

D:\tmp>

Hm...


Larry Hall                              lhall@rfk.com
RFK Partners, Inc.                      (781) 239-1053
8 Grove Street                          (781) 239-1655 - FAX
Wellesley, MA  02482-7797               http://www.rfk.com

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Cygwin B20 - fseek under gcc fails to reposition on text files

[DJ Delorie]

>    And finally, from where all this stuff might be originated - it may
> be done whatever wanted, but if, when writing to console we get clobbered
> output without carrage returns, it doesn't cost a cent. That's where
> myth of win32 speciality breaks down - Win32 console, as any other
> console in cooked mode (Linux, say) performs implicit cr after lf,
> when there's no explicit.

To add fact to the myth, if you bring up such a file (\n without \r)
in notepad, it does not do the right thing - it very explicitly looks
for the CR/LF pair to mean a line ending, and no other ending will do.

Batch files also cannot have NL endings - they need CR/LF endings.

Of course, this really just means that the programmers were
short-sighted, but it's still a fact we must live with.

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Cygwin B20 - fseek under gcc fails to reposition on text files

[Corinna Vinschen]

Paul Sokolovsky wrote:
>     So, for more than twenty years MS maintains myth about "special
> format" of text files of their systems. It's hardly believable. Since
> my old XT I quite nicely handled any text files - be they Unix \xa,
> Mac \xd, or "dos" \xd\xa . So there's nothing special to talk about
> "special" format of text files. Most tools available handled any type,
> and conversion between formats was quite feasible. With win32, such
> problems are ceased at all - I don't have no line endings problems, no
> encoding problems, even that unicode seams to be here.

As a matter of fact: Peter's c example, which opens this thread, does
not work with VC++, if the newline is not \r\n. Look into the source
of M$-ftell(), it can't work.

The best way would be to throw away and ignore any newline with
more than one single character.

But let's get serious.

IMHO, above all text file processing should be done according to the
underlying OS and it's vendor, also if this is wretched.

The second choice has the advantage, to be easy to implement.

The third choice should be implemented, if s.o. has nothing important
to do.

Regards,
Corinna


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re[2]: Cygwin B20 - fseek under gcc fails to reposition on text files

[Paul Sokolovsky]

Hello Corinna,

Corinna Vinschen <corinna.vinschen@cityweb.de> wrote:

>>     So, for more than twenty years MS maintains myth about "special
>> format" of text files of their systems. It's hardly believable. Since

CV> The best way would be to throw away and ignore any newline with
CV> more than one single character.

    Yes, and bad thing is that people came say, from Unix, and don't knowing
that here text files are special, but constantly getting binary file
corruptions when filtering gifs, piping gzips, etc. may think that way is
right ;-(

CV> But let's get serious.

CV> IMHO, above all text file processing should be done according to the
CV> underlying OS and it's vendor, also if this is wretched.

    Bad thing is that issue very minor. People might don't care what
line-endings text files have, they might don't care that there's
notepad and bat files. And when their favorite vi chokes on that \r at
the end (or beginning? ;-) ) of line they might teach him chop it -
after all, that's not notepad. But they might think that wrapping each
command piping binary files in shell script setting CYGWIN (having
spent some nice time trying to understand why their files are
corrupted and asking maillist why this bug) is too awkward.

   Of course, that far too imaganable picture, just like my previous
massage has, just like several years ago cygwin itself was only
imaganable. I don't believe that things enpictured by me will be, or
even should be, done to cygwin. I just wanted to hyperbolize it,
showing that changing itself is not an edge alternative, all
determained by ammount of changes, and there might be the golden mean,
exactly what you'll do. (That's just because I have a ho that Cygnus
guys quite conservative - I remember Christopher Faylor's hesitating
in cygwin-developer whether correcting bug won't break user (or
customer) code. Maybe you, Corinna, as leading contributor, and DJ, as
author of alternative approach, and working for Cygnus, have other
opinions).

   But there still that idea - there maybe niche that cygwin doesn't
fill - to be more unixish despite be less winnish.

CV> The second choice has the advantage, to be easy to implement.

CV> The third choice should be implemented, if s.o. has nothing important
CV> to do.

CV> Regards,
CV> Corinna

    Thanks for not taking previous text as profanity, that's was just rebellion
humoresqe, just forgot adding trailing disclaimer ;-)


Best regards,
 Paul                            mailto:paul-ml@is.lg.ua


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Cygwin B20 - fseek under gcc fails to reposition on text files

[Christopher Faylor]

On Thu, Feb 18, 1999 at 06:38:46PM +0200, Paul Sokolovsky wrote:
>    Bad thing is that issue very minor. People might don't care what
>line-endings text files have, they might don't care that there's
>notepad and bat files. And when their favorite vi chokes on that \r at
>the end (or beginning? ;-) ) of line they might teach him chop it -
>after all, that's not notepad. But they might think that wrapping each
>command piping binary files in shell script setting CYGWIN (having
>spent some nice time trying to understand why their files are
>corrupted and asking maillist why this bug) is too awkward.

Actually, as far as pipes are concerned, they default to binmode
unless overridden by CYGWIN so this should not be an issue.

>   Of course, that far too imaganable picture, just like my previous
>massage has, just like several years ago cygwin itself was only
>imaganable. I don't believe that things enpictured by me will be, or
>even should be, done to cygwin. I just wanted to hyperbolize it,
>showing that changing itself is not an edge alternative, all
>determained by ammount of changes, and there might be the golden mean,
>exactly what you'll do. (That's just because I have a ho that Cygnus
>guys quite conservative - I remember Christopher Faylor's hesitating
>in cygwin-developer whether correcting bug won't break user (or
>customer) code. Maybe you, Corinna, as leading contributor, and DJ, as
>author of alternative approach, and working for Cygnus, have other
>opinions).

I have no idea what, specifically, you are referring to but it is
interesting that you find it "quite conservative" to consider caring
about breaking somebody's code.  You are probably referring to my
soliciting of opinions on the subject of breaking API compatibility
with a new cygwin DLL.  This was obviously a subject which deserved
careful consideration and it was something that I was willing to do.
In fact, it is something that *will* occur in a future release.

Regardless, if you look at the ChangeLog in the last year, you'll find
that I'm the author of a lot of radical changes in Cygwin.

I am not at all opposed to the idea of somebody fixing ftell/fseek
to work as Microsoft has documented them or as DJGPP has currently
implemented things.  I've written a stdio layer myself and I know
that this is not a trivial undertaking, though.  Certainly no
one at Cygnus has the time right now to undertake this.

Currently, Corinna, Mumit, and a couple of other people are the only
outside contributers to the project.  Everyone else seems to be in
"Cygwin doesn't work the way I think it should when I run program X.
Here's the error message." mode.

I'm collecting the error messages and hope to investigate problems but
the reality is that this is a volunteer effort for DJ and me.  Our
real jobs don't offer much time for tracking down net problems.

-chris

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re[2]: Cygwin B20 - fseek under gcc fails to reposition on text files

[Paul Sokolovsky]

Hello Christopher,

Christopher Faylor <cgf@cygnus.com> wrote:

[]

CF> Currently, Corinna, Mumit, and a couple of other people are the only
CF> outside contributers to the project.  Everyone else seems to be in
CF> "Cygwin doesn't work the way I think it should when I run program X.
CF> Here's the error message." mode.

    With other opinions expressed in this thread, I'd like to add
following: it's quite understood that most people are in that mode -
they are using cygwin as their tool, something like car, and are not
concerned, or able to, how it's functioning. Hopefully, that's what
you wanted - to give people nice tool, to keep balance with such toys
like msvc, delphi, etc.

    But when someone wants to fix or add something to cygwin, here
comes another problem - it's high enough threshold to be able to do
so. Even higher threshold to make it acceptable for inclusion back.
By this I mean whole technology issues - not Cygwin technology, I call
it GNU technology - configuration/setup methods, coding styles (not
just mere conventions for identifier naming / block indentation, but
modularization conventions, from source modules thru libs to
executables, etc.) And all that are obstacles to contributing. But of
course I don't say that's bad - there must be order and who willing to
contribute should know and accept it, but it requires time, and
potential contributors may not have it, just the same as developers
may not ;-) .

    Ok, I turn down considering problems of open-source
development, this is hardly appropriate place for it.

CF> I'm collecting the error messages and hope to investigate problems but
CF> the reality is that this is a volunteer effort for DJ and me.  Our
CF> real jobs don't offer much time for tracking down net problems.

CF> -chris


Best regards,
 Paul                            mailto:paul-ml@is.lg.ua


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Cygwin participation threshold

[DJ Delorie]

> Hopefully, that's what you wanted - to give people a nice tool,

I think it would be more accurate to replace "give" with "share with".

As a bit of history, Cygnus had a purely business reason to create
cygwin.  Doing so let us host our tools on 95/NT platforms, which
meant more customers (i.e. more money).  AFAIK, releasing cygwin to
the net had two reasons: the first philosophical, in that we like to
share; and the second practical, in that the more people using cygwin
the more paid support contracts we'll get.

>     But when someone wants to fix or add something to cygwin, here
> comes another problem - it's high enough threshold to be able to do
> so. Even higher threshold to make it acceptable for inclusion back.

DJGPP has a much higher threshold (it's much more complicated), but
there are far more people contributing to djgpp than to cygwin.  If
anyone can figure out *why*, let us know! ;-) I think it's social -
djgpp contributors just know that they'll get a friendly reception to
their contributions, good or bad, so they aren't as hesitant to send
stuff in.

> By this I mean whole technology issues - not Cygwin technology, I
> call it GNU technology - configuration/setup methods, coding styles
> (not just mere conventions for identifier naming / block
> indentation, but modularization conventions, from source modules
> thru libs to executables, etc.) And all that are obstacles to
> contributing.

Even so, I'd rather people contribute what they can instead of just
sulking off in a corner and getting nowhere.  We're not going to laugh
at you for bad style (I hope).  More likely, we'll explain how to
change what you've got to work better with what we've got (it's called
"learning").  Cooperation is a two-way street!  If you're willing to
do *anything*, we'll probably meet you half-way.

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Cygwin participation threshold

[Carl Zmola]

> DJGPP has a much higher threshold (it's much more complicated), but
> there are far more people contributing to djgpp than to cygwin.  If
> anyone can figure out *why*, let us know! ;-) I think it's social -
> djgpp contributors just know that they'll get a friendly reception to
> their contributions, good or bad, so they aren't as hesitant to send
> stuff in.

That could be part of it.  The fact that a company is in charge of 
coordinating the efforts has an effect.

In the past the main reason I didn't even investigate contributing is :
Because of the feeling that contributions are unwanted, and that someone
else is making money of of my work.

After a little investigation, I found that these wern't valid concerns, but
they are a first line of resistance.  

Carl 
zmola@campbellsci.com

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Cygwin participation threshold

[Fergus Henderson]

> DJGPP has a much higher threshold (it's much more complicated), but
> there are far more people contributing to djgpp than to cygwin.  If
> anyone can figure out *why*, let us know! ;-) I think it's social -
> djgpp contributors just know that they'll get a friendly reception to
> their contributions, good or bad, so they aren't as hesitant to send
> stuff in.

I think the licensing may well have something to do with it.
DJGPP is licensed under a quite liberal license.
Cygwin, on the other hand, is only licensed under the GPL
or for a fee.  For libraries, the GPL is quite restrictive.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "Binaries may die
WWW: < http://www.cs.mu.oz.au/~fjh >  |   but source code lives forever"
PGP: finger fjh@128.250.37.3        |     -- leaked Microsoft memo.

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Cygwin participation threshold

[Fergus Henderson]

> DJGPP has a much higher threshold (it's much more complicated), but
> there are far more people contributing to djgpp than to cygwin.  If
> anyone can figure out *why*, let us know! ;-) I think it's social -
> djgpp contributors just know that they'll get a friendly reception to
> their contributions, good or bad, so they aren't as hesitant to send
> stuff in.

I think the licensing may well have something to do with it.
DJGPP is licensed under a quite liberal license.
Cygwin, on the other hand, is only licensed under the GPL
or for a fee.  For libraries, the GPL is quite restrictive.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "Binaries may die
WWW: < http://www.cs.mu.oz.au/~fjh >  |   but source code lives forever"
PGP: finger fjh@128.250.37.3        |     -- leaked Microsoft memo.

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Cygwin participation threshold

[DJ Delorie]

> That could be part of it.  The fact that a company is in charge of 
> coordinating the efforts has an effect.

What effect?  I would think that having a company back a project would
be *good*, since they have more to lose if it fails.

> In the past the main reason I didn't even investigate contributing
> is : Because of the feeling that contributions are unwanted, and
> that someone else is making money of of my work.
>
> After a little investigation, I found that these wern't valid
> concerns, but they are a first line of resistance.

How did you get these impressions?  If there is a way for us to make
sure people get the right impressions up front, perhaps that would
save people a bit of grief.

However, let's get one thing straight: Cygnus *is* making money off
your work, at least indirectly.  However, in return we're giving a lot
of technology and effort (in the form of cygwin, since we do most of
the work on it) back to the community (you).  I'd like to think this
is a fair exchange.  Do you think this is a fair exchange?

As for contributions, we definitely want them, but keep in mind that
it's our responsibility to the cygwin community (you), as the "keepers
of cygwin", to ensure that anything added to cygwin doesn't make it
worse.  The preferred method of dealing with these types of
contributions is to work with the author until they meet our
standards, rather than simply rejecting it.

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Cygwin participation threshold

[DJ Delorie]

> That could be part of it.  The fact that a company is in charge of 
> coordinating the efforts has an effect.

What effect?  I would think that having a company back a project would
be *good*, since they have more to lose if it fails.

> In the past the main reason I didn't even investigate contributing
> is : Because of the feeling that contributions are unwanted, and
> that someone else is making money of of my work.
>
> After a little investigation, I found that these wern't valid
> concerns, but they are a first line of resistance.

How did you get these impressions?  If there is a way for us to make
sure people get the right impressions up front, perhaps that would
save people a bit of grief.

However, let's get one thing straight: Cygnus *is* making money off
your work, at least indirectly.  However, in return we're giving a lot
of technology and effort (in the form of cygwin, since we do most of
the work on it) back to the community (you).  I'd like to think this
is a fair exchange.  Do you think this is a fair exchange?

As for contributions, we definitely want them, but keep in mind that
it's our responsibility to the cygwin community (you), as the "keepers
of cygwin", to ensure that anything added to cygwin doesn't make it
worse.  The preferred method of dealing with these types of
contributions is to work with the author until they meet our
standards, rather than simply rejecting it.

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Cygwin participation threshold

[Christopher Faylor]

On Mon, Feb 22, 1999 at 11:30:59AM +0000, Carl Zmola wrote:
>
>> DJGPP has a much higher threshold (it's much more complicated), but
>> there are far more people contributing to djgpp than to cygwin.  If
>> anyone can figure out *why*, let us know! ;-) I think it's social -
>> djgpp contributors just know that they'll get a friendly reception to
>> their contributions, good or bad, so they aren't as hesitant to send
>> stuff in.
>
>That could be part of it.  The fact that a company is in charge of 
>coordinating the efforts has an effect.
>
>In the past the main reason I didn't even investigate contributing is :
>Because of the feeling that contributions are unwanted, and that someone
>else is making money of of my work.
>
>After a little investigation, I found that these wern't valid concerns, but
>they are a first line of resistance.  

It is interesting that you felt this way at first.  I wonder if the reason
has anything to do with the name "Cygwin" which sounds so similar to "Cygnus".

The reason I am saying this is because hundreds of people have contributed to
the linux project and *many* companies make money from linux.

cgf

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Cygwin participation threshold

[Fergus Henderson]

On 23-Feb-1999, Christopher Faylor <cgf@cygnus.com> wrote:
> On Mon, Feb 22, 1999, Carl Zmola wrote:
> >
> >The fact that a company is in charge of 
> >coordinating the efforts has an effect.
> >
> >In the past the main reason I didn't even investigate contributing is :
> >Because of the feeling that contributions are unwanted, and that someone
> >else is making money of of my work.
> >
> >After a little investigation, I found that these wern't valid concerns, but
> >they are a first line of resistance.  
> 
> It is interesting that you felt this way at first.  I wonder if the reason
> has anything to do with the name "Cygwin" which sounds so similar to "Cygnus".
> 
> The reason I am saying this is because hundreds of people have contributed to
> the linux project and *many* companies make money from linux.

Yes, but you can write and distribute proprietry applications or even
proprietry kernel modules for Linux without paying anyone a license fee.
The same is not true for Cygwin (although it *was* true once, back around
version b16, when it was called gnu-win32).

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "Binaries may die
WWW: < http://www.cs.mu.oz.au/~fjh >  |   but source code lives forever"
PGP: finger fjh@128.250.37.3        |     -- leaked Microsoft memo.

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Cygwin participation threshold

[Christopher Faylor]

On Thu, Feb 25, 1999 at 12:51:48AM +1100, Fergus Henderson wrote:
>On 23-Feb-1999, Christopher Faylor <cgf@cygnus.com> wrote:
>> On Mon, Feb 22, 1999, Carl Zmola wrote:
>> >
>> >The fact that a company is in charge of 
>> >coordinating the efforts has an effect.
>> >
>> >In the past the main reason I didn't even investigate contributing is :
>> >Because of the feeling that contributions are unwanted, and that someone
>> >else is making money of of my work.
>> >
>> >After a little investigation, I found that these wern't valid concerns, but
>> >they are a first line of resistance.  
>> 
>> It is interesting that you felt this way at first.  I wonder if the reason
>> has anything to do with the name "Cygwin" which sounds so similar to "Cygnus".
>> 
>> The reason I am saying this is because hundreds of people have contributed to
>> the linux project and *many* companies make money from linux.
>
>Yes, but you can write and distribute proprietry applications or even
>proprietry kernel modules for Linux without paying anyone a license fee.
>The same is not true for Cygwin (although it *was* true once, back around
>version b16, when it was called gnu-win32).

True, but that is not the point.  I believe this whold thread started
because I lamented the lack of people contributing directly to cygwin
development.  The many contributors to the linux kernel do not do so
because it is possible to develop proprietary code for linux.

I don't consider companies who create proprietary kernel modules as
contributing to linux development in any way.  Possibly they help indirectly
by getting the word out about linux but that is a secondary and, IMO, very
minor benefit.

cf

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Cygwin participation threshold

[Weiqi Gao]

Christopher Faylor wrote:
> 
> True, but that is not the point.  I believe this whold thread started
> because I lamented the lack of people contributing directly to cygwin
> development.  The many contributors to the linux kernel do not do so
> because it is possible to develop proprietary code for linux.
> 
> I don't consider companies who create proprietary kernel modules as
> contributing to linux development in any way.  Possibly they help indirectly
> by getting the word out about linux but that is a secondary and, IMO, very
> minor benefit.

Windows is too complicated.  It usually takes a sharp individual a long
time (four years?) to become really proficient in Windows.  And that
proficiency usually last a very short time (two years).  All of their
knowledge would have been gained through the continued (and expensive)
subscription to MSDN.  They usually don't feel compelled to contribute
to anything.

It's the culture.  Groups of Windows developers would sit around bashing
Unix.  An ActiveX DLL is the highest ideal that they can attain. 
Putting the "copy file" animation into every program is their idea of
fun.  Their world evolved around OLE, COM, ActiveX, DirectX, ODBC, DAO,
RDO, ADO, DCOM, MVM.

They would ask: "what's the point of Cygwin?"  And you answer "so that
Cygnus can host GNU tools on NT for embedded programming."  They open up
their MSDN case, thumb through the couple dozen or so CDs inside and
find WindowsCE.  "We have Visual Basic and Windows CE.  And Microsoft
told me that's all I need for embedded programming," they would say.  "I
don't care what you think of me, but as far as I'm concerned, Microsoft
invented the PC in 1980.  They invented GUI and the Mouse in 1989.  They
invented TCP/IP in 1992. And they invented the Internet in 1995."

There's a huge mass of them out there is a fact of life.  The only way
to turn their heads around and even look at something non-Microsofty is
to show them a huge amount of money.  "What's there in it for me?" is
their motto, or they wouldn't have become Windows programmers.

If you don't believe me, look at (or just imagine) the latest CNN/USA
Today poll.

--
Weiqi Gao
weiqigao@a.crl.com

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Cygwin participation threshold

[Fergus Henderson]

On 24-Feb-1999, Weiqi Gao <weiqigao@a.crl.com> wrote:
> 
> Windows is too complicated.  It usually takes a sharp individual a long
> time (four years?) to become really proficient in Windows.  And that
> proficiency usually last a very short time (two years).  All of their
> knowledge would have been gained through the continued (and expensive)
> subscription to MSDN.  They usually don't feel compelled to contribute
> to anything.

That doesn't explain why they contribute more to djgpp than to cygwin.

> It's the culture.  Groups of Windows developers would sit around bashing
> Unix.

But that could well explain it.

One thing that might help would be better mingw32 support.
That might encourage people who would otherwise use djgpp
to use cygwin instead.  But I suppose they still wouldn't
be likely to contribute to the winsup stuff.

Someone else also commented that people who use cygwin probably
run Linux when they can, and so don't get much chance to play
around with cygwin.  I think that is another very likely explanation.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "Binaries may die
WWW: < http://www.cs.mu.oz.au/~fjh >  |   but source code lives forever"
PGP: finger fjh@128.250.37.3        |     -- leaked Microsoft memo.

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Cygwin participation threshold

[Weiqi Gao]

Fergus Henderson wrote:
> 
> On 24-Feb-1999, Weiqi Gao <weiqigao@a.crl.com> wrote:
> >
> > Windows is too complicated.  It usually takes a sharp individual a long
> > time (four years?) to become really proficient in Windows.  And that
> > proficiency usually last a very short time (two years).  All of their
> > knowledge would have been gained through the continued (and expensive)
> > subscription to MSDN.  They usually don't feel compelled to contribute
> > to anything.
> 
> That doesn't explain why they contribute more to djgpp than to cygwin.

There is a sense of the "power of personality" in the DJGPP project. 
For example, DJ never complained about not enough people contributing. 
And Eli Zarreskii(?) had never gone into an argument with a user,
contributing or not.  He's been sending out ten pieces of emails per day
for three(?) years now, and fifty percent of them are "Read the FAQ". 
He's accumulated quite a bunch "lose your temper for free" card now!

DOS is also more primitive, simpler, and more UNIX like than Windows. 
And DJGPP is more kernel like than wrapper/call forwarder/translator
like than Cygwin.  It is higher on the Cool scale than Cygwin.  It's
almost the "GNU operating system with the DJGPP kernel".

> > It's the culture.  Groups of Windows developers would sit around bashing
> > Unix.
> 
> But that could well explain it.
> 
> One thing that might help would be better mingw32 support.
> That might encourage people who would otherwise use djgpp
> to use cygwin instead.  But I suppose they still wouldn't
> be likely to contribute to the winsup stuff.
> 
> Someone else also commented that people who use cygwin probably
> run Linux when they can, and so don't get much chance to play
> around with cygwin.  I think that is another very likely explanation.

Historically, UNIX has gathered all the free software writers because it
is accessible and had a free software culture.  DOS and Windows lacks
it.

Here's a challenge: Name as many as you can, any widely spread free
software (in the FSF free speech sense) packages that's originated from
DOS/Windows.  The closest I can come up is an editor called the PFE
(Programmers File Editor) which is a Notepad clone.  But you can't get
the source of it.

The fact that Microsoft "owns" Windows might have something to do with
it.

--
Weiqi Gao
weiqigao@a.crl.com

--
Quote of the day:
  --Which is worse, ignorance or indifference
  --I don't know, and I don't care.

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re[2]: Cygwin participation threshold

[Paul Sokolovsky]

Hello Weiqi,

Weiqi Gao <weiqigao@a.crl.com> wrote:


WG> There is a sense of the "power of personality" in the DJGPP project. 
WG> For example, DJ never complained about not enough people contributing. 
WG> And Eli Zarreskii(?) had never gone into an argument with a user,
WG> contributing or not.  He's been sending out ten pieces of emails per day
WG> for three(?) years now, and fifty percent of them are "Read the FAQ". 
WG> He's accumulated quite a bunch "lose your temper for free" card now!

     If you imply current discussion, I don't think you're right. I
haven't heard any complaints about not enough people contributing
from Cygwin people. Instead, they was so attentive to explain this. I
don't think that's bad. Such discussion may help them to make cygwin
better and make cygwin users better understand cygwin and its
developers. As for latter, I think it's an important privilege open
source community (and companies) give their members (and users), which
many other organizations unable to give.

WG> DOS is also more primitive, simpler, and more UNIX like than Windows. 
WG> And DJGPP is more kernel like than wrapper/call forwarder/translator
WG> like than Cygwin.  It is higher on the Cool scale than Cygwin.  It's
WG> almost the "GNU operating system with the DJGPP kernel".

    I agree with you about DJGPP. I however disagree about Win32. My
argument is "They tried hard and they tried long and what they did is
exactly POSIX (I prefer that term) system, but it advertizes its
POSIXness in rather strange and shy words". I may only feel pity that
cygwin can't teach it speak loud and eloquently.

WG> Here's a challenge: Name as many as you can, any widely spread free
WG> software (in the FSF free speech sense) packages that's originated from
WG> DOS/Windows.  The closest I can come up is an editor called the PFE
WG> (Programmers File Editor) which is a Notepad clone.  But you can't get
WG> the source of it.

    From such observations I devised that "two types" theory. ;-)

WG> The fact that Microsoft "owns" Windows might have something to do with
WG> it.

    But God with that they own it. What may displease some people is
observation that they own all end user sector of computer industry,
and more frightenly - attitudes of those users.

WG> --
WG> Weiqi Gao
WG> weiqigao@a.crl.com


Best regards,
 Paul                            mailto:paul-ml@is.lg.ua


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re[2]: Cygwin participation threshold

[Paul Sokolovsky]

Hello Weiqi,

Weiqi Gao <weiqigao@a.crl.com> wrote:


WG> There is a sense of the "power of personality" in the DJGPP project. 
WG> For example, DJ never complained about not enough people contributing. 
WG> And Eli Zarreskii(?) had never gone into an argument with a user,
WG> contributing or not.  He's been sending out ten pieces of emails per day
WG> for three(?) years now, and fifty percent of them are "Read the FAQ". 
WG> He's accumulated quite a bunch "lose your temper for free" card now!

     If you imply current discussion, I don't think you're right. I
haven't heard any complaints about not enough people contributing
from Cygwin people. Instead, they was so attentive to explain this. I
don't think that's bad. Such discussion may help them to make cygwin
better and make cygwin users better understand cygwin and its
developers. As for latter, I think it's an important privilege open
source community (and companies) give their members (and users), which
many other organizations unable to give.

WG> DOS is also more primitive, simpler, and more UNIX like than Windows. 
WG> And DJGPP is more kernel like than wrapper/call forwarder/translator
WG> like than Cygwin.  It is higher on the Cool scale than Cygwin.  It's
WG> almost the "GNU operating system with the DJGPP kernel".

    I agree with you about DJGPP. I however disagree about Win32. My
argument is "They tried hard and they tried long and what they did is
exactly POSIX (I prefer that term) system, but it advertizes its
POSIXness in rather strange and shy words". I may only feel pity that
cygwin can't teach it speak loud and eloquently.

WG> Here's a challenge: Name as many as you can, any widely spread free
WG> software (in the FSF free speech sense) packages that's originated from
WG> DOS/Windows.  The closest I can come up is an editor called the PFE
WG> (Programmers File Editor) which is a Notepad clone.  But you can't get
WG> the source of it.

    From such observations I devised that "two types" theory. ;-)

WG> The fact that Microsoft "owns" Windows might have something to do with
WG> it.

    But God with that they own it. What may displease some people is
observation that they own all end user sector of computer industry,
and more frightenly - attitudes of those users.

WG> --
WG> Weiqi Gao
WG> weiqigao@a.crl.com


Best regards,
 Paul                            mailto:paul-ml@is.lg.ua


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Cygwin participation threshold

[Weiqi Gao]

Fergus Henderson wrote:
> 
> On 24-Feb-1999, Weiqi Gao <weiqigao@a.crl.com> wrote:
> >
> > Windows is too complicated.  It usually takes a sharp individual a long
> > time (four years?) to become really proficient in Windows.  And that
> > proficiency usually last a very short time (two years).  All of their
> > knowledge would have been gained through the continued (and expensive)
> > subscription to MSDN.  They usually don't feel compelled to contribute
> > to anything.
> 
> That doesn't explain why they contribute more to djgpp than to cygwin.

There is a sense of the "power of personality" in the DJGPP project. 
For example, DJ never complained about not enough people contributing. 
And Eli Zarreskii(?) had never gone into an argument with a user,
contributing or not.  He's been sending out ten pieces of emails per day
for three(?) years now, and fifty percent of them are "Read the FAQ". 
He's accumulated quite a bunch "lose your temper for free" card now!

DOS is also more primitive, simpler, and more UNIX like than Windows. 
And DJGPP is more kernel like than wrapper/call forwarder/translator
like than Cygwin.  It is higher on the Cool scale than Cygwin.  It's
almost the "GNU operating system with the DJGPP kernel".

> > It's the culture.  Groups of Windows developers would sit around bashing
> > Unix.
> 
> But that could well explain it.
> 
> One thing that might help would be better mingw32 support.
> That might encourage people who would otherwise use djgpp
> to use cygwin instead.  But I suppose they still wouldn't
> be likely to contribute to the winsup stuff.
> 
> Someone else also commented that people who use cygwin probably
> run Linux when they can, and so don't get much chance to play
> around with cygwin.  I think that is another very likely explanation.

Historically, UNIX has gathered all the free software writers because it
is accessible and had a free software culture.  DOS and Windows lacks
it.

Here's a challenge: Name as many as you can, any widely spread free
software (in the FSF free speech sense) packages that's originated from
DOS/Windows.  The closest I can come up is an editor called the PFE
(Programmers File Editor) which is a Notepad clone.  But you can't get
the source of it.

The fact that Microsoft "owns" Windows might have something to do with
it.

--
Weiqi Gao
weiqigao@a.crl.com

--
Quote of the day:
  --Which is worse, ignorance or indifference
  --I don't know, and I don't care.

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Cygwin participation threshold

[Fergus Henderson]

On 24-Feb-1999, Weiqi Gao <weiqigao@a.crl.com> wrote:
> 
> Windows is too complicated.  It usually takes a sharp individual a long
> time (four years?) to become really proficient in Windows.  And that
> proficiency usually last a very short time (two years).  All of their
> knowledge would have been gained through the continued (and expensive)
> subscription to MSDN.  They usually don't feel compelled to contribute
> to anything.

That doesn't explain why they contribute more to djgpp than to cygwin.

> It's the culture.  Groups of Windows developers would sit around bashing
> Unix.

But that could well explain it.

One thing that might help would be better mingw32 support.
That might encourage people who would otherwise use djgpp
to use cygwin instead.  But I suppose they still wouldn't
be likely to contribute to the winsup stuff.

Someone else also commented that people who use cygwin probably
run Linux when they can, and so don't get much chance to play
around with cygwin.  I think that is another very likely explanation.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "Binaries may die
WWW: < http://www.cs.mu.oz.au/~fjh >  |   but source code lives forever"
PGP: finger fjh@128.250.37.3        |     -- leaked Microsoft memo.

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Cygwin participation threshold

[Weiqi Gao]

Christopher Faylor wrote:
> 
> True, but that is not the point.  I believe this whold thread started
> because I lamented the lack of people contributing directly to cygwin
> development.  The many contributors to the linux kernel do not do so
> because it is possible to develop proprietary code for linux.
> 
> I don't consider companies who create proprietary kernel modules as
> contributing to linux development in any way.  Possibly they help indirectly
> by getting the word out about linux but that is a secondary and, IMO, very
> minor benefit.

Windows is too complicated.  It usually takes a sharp individual a long
time (four years?) to become really proficient in Windows.  And that
proficiency usually last a very short time (two years).  All of their
knowledge would have been gained through the continued (and expensive)
subscription to MSDN.  They usually don't feel compelled to contribute
to anything.

It's the culture.  Groups of Windows developers would sit around bashing
Unix.  An ActiveX DLL is the highest ideal that they can attain. 
Putting the "copy file" animation into every program is their idea of
fun.  Their world evolved around OLE, COM, ActiveX, DirectX, ODBC, DAO,
RDO, ADO, DCOM, MVM.

They would ask: "what's the point of Cygwin?"  And you answer "so that
Cygnus can host GNU tools on NT for embedded programming."  They open up
their MSDN case, thumb through the couple dozen or so CDs inside and
find WindowsCE.  "We have Visual Basic and Windows CE.  And Microsoft
told me that's all I need for embedded programming," they would say.  "I
don't care what you think of me, but as far as I'm concerned, Microsoft
invented the PC in 1980.  They invented GUI and the Mouse in 1989.  They
invented TCP/IP in 1992. And they invented the Internet in 1995."

There's a huge mass of them out there is a fact of life.  The only way
to turn their heads around and even look at something non-Microsofty is
to show them a huge amount of money.  "What's there in it for me?" is
their motto, or they wouldn't have become Windows programmers.

If you don't believe me, look at (or just imagine) the latest CNN/USA
Today poll.

--
Weiqi Gao
weiqigao@a.crl.com

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Cygwin participation threshold

[Fergus Henderson]

On 24-Feb-1999, Christopher Faylor <cgf@cygnus.com> wrote:
> On Thu, Feb 25, 1999, Fergus Henderson wrote:
> >Yes, but you can write and distribute proprietry applications or even
> >proprietry kernel modules for Linux without paying anyone a license fee.
> >The same is not true for Cygwin (although it *was* true once, back around
> >version b16, when it was called gnu-win32).
> 
> True, but that is not the point.  I believe this whold thread started
> because I lamented the lack of people contributing directly to cygwin
> development.

You also asked why.  I believe that licensing may be one of the reasons why.
So I don't think my comment is beside the point.  You may disagree with me,
but I think we're talking about the same topic.

> The many contributors to the linux kernel do not do so
> because it is possible to develop proprietary code for linux.

That may not be their direct motivation, but I do think it is a
significant factor.  I think that if it were impossible to develop
proprietry code for Linux, then Linux would have a much smaller user
base, and there would be far fewer contributors to Linux.

> I don't consider companies who create proprietary kernel modules as
> contributing to linux development in any way.

The ability to create proprietry kernel modules is of little importance.
The ability to create proprietry applications is of much greater importance.

> Possibly they help indirectly
> by getting the word out about linux but that is a secondary and, IMO, very
> minor benefit.

I agree that the benefits are indirect and secondary.  However,
I don't think they should be ignored.

In addition to getting the word out, companies which develop proprietry
applications (or kernel modules) often also help

	(1) by using Linux, and in the process sometimes reporting
	    and/or fixing bugs in the kernel and/or the various
	    open-source applications that are part of Linux; sometimes
	    they will even add whole new features which are needed for
	    their proprietry application (or module); and

	(2) by providing software (or drivers) which other people need,
	    and thus encouraging those other people to use Linux,
	    leading to the same benefits as (1).

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "Binaries may die
WWW: < http://www.cs.mu.oz.au/~fjh >  |   but source code lives forever"
PGP: finger fjh@128.250.37.3        |     -- leaked Microsoft memo.

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Cygwin participation threshold

[Lam Pui Yuen]

done !

On Thu, 25 Feb 1999, Fergus Henderson wrote:

> On 24-Feb-1999, Christopher Faylor <cgf@cygnus.com> wrote:
> > On Thu, Feb 25, 1999, Fergus Henderson wrote:
> > >Yes, but you can write and distribute proprietry applications or even
> > >proprietry kernel modules for Linux without paying anyone a license fee.
> > >The same is not true for Cygwin (although it *was* true once, back around
> > >version b16, when it was called gnu-win32).
> > 
> > True, but that is not the point.  I believe this whold thread started
> > because I lamented the lack of people contributing directly to cygwin
> > development.
> 
> You also asked why.  I believe that licensing may be one of the reasons why.
> So I don't think my comment is beside the point.  You may disagree with me,
> but I think we're talking about the same topic.
> 
> > The many contributors to the linux kernel do not do so
> > because it is possible to develop proprietary code for linux.
> 
> That may not be their direct motivation, but I do think it is a
> significant factor.  I think that if it were impossible to develop
> proprietry code for Linux, then Linux would have a much smaller user
> base, and there would be far fewer contributors to Linux.
> 
> > I don't consider companies who create proprietary kernel modules as
> > contributing to linux development in any way.
> 
> The ability to create proprietry kernel modules is of little importance.
> The ability to create proprietry applications is of much greater importance.
> 
> > Possibly they help indirectly
> > by getting the word out about linux but that is a secondary and, IMO, very
> > minor benefit.
> 
> I agree that the benefits are indirect and secondary.  However,
> I don't think they should be ignored.
> 
> In addition to getting the word out, companies which develop proprietry
> applications (or kernel modules) often also help
> 
> 	(1) by using Linux, and in the process sometimes reporting
> 	    and/or fixing bugs in the kernel and/or the various
> 	    open-source applications that are part of Linux; sometimes
> 	    they will even add whole new features which are needed for
> 	    their proprietry application (or module); and
> 
> 	(2) by providing software (or drivers) which other people need,
> 	    and thus encouraging those other people to use Linux,
> 	    leading to the same benefits as (1).
> 
> -- 
> Fergus Henderson <fjh@cs.mu.oz.au>  |  "Binaries may die
> WWW: < http://www.cs.mu.oz.au/~fjh >  |   but source code lives forever"
> PGP: finger fjh@128.250.37.3        |     -- leaked Microsoft memo.
> 
> --
> Want to unsubscribe from this list?
> Send a message to cygwin-unsubscribe@sourceware.cygnus.com
> 
> 


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Cygwin participation threshold

[Lam Pui Yuen]

dear all,
sorry for this wrong reply mail.
Regs.

> done !
> 
> On Thu, 25 Feb 1999, Fergus Henderson wrote:
> 
> > On 24-Feb-1999, Christopher Faylor <cgf@cygnus.com> wrote:
> > > On Thu, Feb 25, 1999, Fergus Henderson wrote:
> > > >Yes, but you can write and distribute proprietry applications or even
> > > >proprietry kernel modules for Linux without paying anyone a license fee.
> > > >The same is not true for Cygwin (although it *was* true once, back around
> > > >version b16, when it was called gnu-win32).
> > > 
> > > True, but that is not the point.  I believe this whold thread started
> > > because I lamented the lack of people contributing directly to cygwin
> > > development.
> > 
> > You also asked why.  I believe that licensing may be one of the reasons why.
> > So I don't think my comment is beside the point.  You may disagree with me,
> > but I think we're talking about the same topic.
> > 
> > > The many contributors to the linux kernel do not do so
> > > because it is possible to develop proprietary code for linux.
> > 
> > That may not be their direct motivation, but I do think it is a
> > significant factor.  I think that if it were impossible to develop
> > proprietry code for Linux, then Linux would have a much smaller user
> > base, and there would be far fewer contributors to Linux.
> > 
> > > I don't consider companies who create proprietary kernel modules as
> > > contributing to linux development in any way.
> > 
> > The ability to create proprietry kernel modules is of little importance.
> > The ability to create proprietry applications is of much greater importance.
> > 
> > > Possibly they help indirectly
> > > by getting the word out about linux but that is a secondary and, IMO, very
> > > minor benefit.
> > 
> > I agree that the benefits are indirect and secondary.  However,
> > I don't think they should be ignored.
> > 
> > In addition to getting the word out, companies which develop proprietry
> > applications (or kernel modules) often also help
> > 
> > 	(1) by using Linux, and in the process sometimes reporting
> > 	    and/or fixing bugs in the kernel and/or the various
> > 	    open-source applications that are part of Linux; sometimes
> > 	    they will even add whole new features which are needed for
> > 	    their proprietry application (or module); and
> > 
> > 	(2) by providing software (or drivers) which other people need,
> > 	    and thus encouraging those other people to use Linux,
> > 	    leading to the same benefits as (1).
> > 
> > -- 
> > Fergus Henderson <fjh@cs.mu.oz.au>  |  "Binaries may die
> > WWW: < http://www.cs.mu.oz.au/~fjh >  |   but source code lives forever"
> > PGP: finger fjh@128.250.37.3        |     -- leaked Microsoft memo.
> > 
> > --
> > Want to unsubscribe from this list?
> > Send a message to cygwin-unsubscribe@sourceware.cygnus.com
> > 
> > 
> 
> 
> --
> Want to unsubscribe from this list?
> Send a message to cygwin-unsubscribe@sourceware.cygnus.com
> 
> 


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Cygwin participation threshold

[Lam Pui Yuen]

dear all,
sorry for this wrong reply mail.
Regs.

> done !
> 
> On Thu, 25 Feb 1999, Fergus Henderson wrote:
> 
> > On 24-Feb-1999, Christopher Faylor <cgf@cygnus.com> wrote:
> > > On Thu, Feb 25, 1999, Fergus Henderson wrote:
> > > >Yes, but you can write and distribute proprietry applications or even
> > > >proprietry kernel modules for Linux without paying anyone a license fee.
> > > >The same is not true for Cygwin (although it *was* true once, back around
> > > >version b16, when it was called gnu-win32).
> > > 
> > > True, but that is not the point.  I believe this whold thread started
> > > because I lamented the lack of people contributing directly to cygwin
> > > development.
> > 
> > You also asked why.  I believe that licensing may be one of the reasons why.
> > So I don't think my comment is beside the point.  You may disagree with me,
> > but I think we're talking about the same topic.
> > 
> > > The many contributors to the linux kernel do not do so
> > > because it is possible to develop proprietary code for linux.
> > 
> > That may not be their direct motivation, but I do think it is a
> > significant factor.  I think that if it were impossible to develop
> > proprietry code for Linux, then Linux would have a much smaller user
> > base, and there would be far fewer contributors to Linux.
> > 
> > > I don't consider companies who create proprietary kernel modules as
> > > contributing to linux development in any way.
> > 
> > The ability to create proprietry kernel modules is of little importance.
> > The ability to create proprietry applications is of much greater importance.
> > 
> > > Possibly they help indirectly
> > > by getting the word out about linux but that is a secondary and, IMO, very
> > > minor benefit.
> > 
> > I agree that the benefits are indirect and secondary.  However,
> > I don't think they should be ignored.
> > 
> > In addition to getting the word out, companies which develop proprietry
> > applications (or kernel modules) often also help
> > 
> > 	(1) by using Linux, and in the process sometimes reporting
> > 	    and/or fixing bugs in the kernel and/or the various
> > 	    open-source applications that are part of Linux; sometimes
> > 	    they will even add whole new features which are needed for
> > 	    their proprietry application (or module); and
> > 
> > 	(2) by providing software (or drivers) which other people need,
> > 	    and thus encouraging those other people to use Linux,
> > 	    leading to the same benefits as (1).
> > 
> > -- 
> > Fergus Henderson <fjh@cs.mu.oz.au>  |  "Binaries may die
> > WWW: < http://www.cs.mu.oz.au/~fjh >  |   but source code lives forever"
> > PGP: finger fjh@128.250.37.3        |     -- leaked Microsoft memo.
> > 
> > --
> > Want to unsubscribe from this list?
> > Send a message to cygwin-unsubscribe@sourceware.cygnus.com
> > 
> > 
> 
> 
> --
> Want to unsubscribe from this list?
> Send a message to cygwin-unsubscribe@sourceware.cygnus.com
> 
> 


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Cygwin participation threshold

[Lam Pui Yuen]

done !

On Thu, 25 Feb 1999, Fergus Henderson wrote:

> On 24-Feb-1999, Christopher Faylor <cgf@cygnus.com> wrote:
> > On Thu, Feb 25, 1999, Fergus Henderson wrote:
> > >Yes, but you can write and distribute proprietry applications or even
> > >proprietry kernel modules for Linux without paying anyone a license fee.
> > >The same is not true for Cygwin (although it *was* true once, back around
> > >version b16, when it was called gnu-win32).
> > 
> > True, but that is not the point.  I believe this whold thread started
> > because I lamented the lack of people contributing directly to cygwin
> > development.
> 
> You also asked why.  I believe that licensing may be one of the reasons why.
> So I don't think my comment is beside the point.  You may disagree with me,
> but I think we're talking about the same topic.
> 
> > The many contributors to the linux kernel do not do so
> > because it is possible to develop proprietary code for linux.
> 
> That may not be their direct motivation, but I do think it is a
> significant factor.  I think that if it were impossible to develop
> proprietry code for Linux, then Linux would have a much smaller user
> base, and there would be far fewer contributors to Linux.
> 
> > I don't consider companies who create proprietary kernel modules as
> > contributing to linux development in any way.
> 
> The ability to create proprietry kernel modules is of little importance.
> The ability to create proprietry applications is of much greater importance.
> 
> > Possibly they help indirectly
> > by getting the word out about linux but that is a secondary and, IMO, very
> > minor benefit.
> 
> I agree that the benefits are indirect and secondary.  However,
> I don't think they should be ignored.
> 
> In addition to getting the word out, companies which develop proprietry
> applications (or kernel modules) often also help
> 
> 	(1) by using Linux, and in the process sometimes reporting
> 	    and/or fixing bugs in the kernel and/or the various
> 	    open-source applications that are part of Linux; sometimes
> 	    they will even add whole new features which are needed for
> 	    their proprietry application (or module); and
> 
> 	(2) by providing software (or drivers) which other people need,
> 	    and thus encouraging those other people to use Linux,
> 	    leading to the same benefits as (1).
> 
> -- 
> Fergus Henderson <fjh@cs.mu.oz.au>  |  "Binaries may die
> WWW: < http://www.cs.mu.oz.au/~fjh >  |   but source code lives forever"
> PGP: finger fjh@128.250.37.3        |     -- leaked Microsoft memo.
> 
> --
> Want to unsubscribe from this list?
> Send a message to cygwin-unsubscribe@sourceware.cygnus.com
> 
> 


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Cygwin participation threshold

[Fergus Henderson]

On 24-Feb-1999, Christopher Faylor <cgf@cygnus.com> wrote:
> On Thu, Feb 25, 1999, Fergus Henderson wrote:
> >Yes, but you can write and distribute proprietry applications or even
> >proprietry kernel modules for Linux without paying anyone a license fee.
> >The same is not true for Cygwin (although it *was* true once, back around
> >version b16, when it was called gnu-win32).
> 
> True, but that is not the point.  I believe this whold thread started
> because I lamented the lack of people contributing directly to cygwin
> development.

You also asked why.  I believe that licensing may be one of the reasons why.
So I don't think my comment is beside the point.  You may disagree with me,
but I think we're talking about the same topic.

> The many contributors to the linux kernel do not do so
> because it is possible to develop proprietary code for linux.

That may not be their direct motivation, but I do think it is a
significant factor.  I think that if it were impossible to develop
proprietry code for Linux, then Linux would have a much smaller user
base, and there would be far fewer contributors to Linux.

> I don't consider companies who create proprietary kernel modules as
> contributing to linux development in any way.

The ability to create proprietry kernel modules is of little importance.
The ability to create proprietry applications is of much greater importance.

> Possibly they help indirectly
> by getting the word out about linux but that is a secondary and, IMO, very
> minor benefit.

I agree that the benefits are indirect and secondary.  However,
I don't think they should be ignored.

In addition to getting the word out, companies which develop proprietry
applications (or kernel modules) often also help

	(1) by using Linux, and in the process sometimes reporting
	    and/or fixing bugs in the kernel and/or the various
	    open-source applications that are part of Linux; sometimes
	    they will even add whole new features which are needed for
	    their proprietry application (or module); and

	(2) by providing software (or drivers) which other people need,
	    and thus encouraging those other people to use Linux,
	    leading to the same benefits as (1).

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "Binaries may die
WWW: < http://www.cs.mu.oz.au/~fjh >  |   but source code lives forever"
PGP: finger fjh@128.250.37.3        |     -- leaked Microsoft memo.

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Cygwin participation threshold

[Christopher Faylor]

On Thu, Feb 25, 1999 at 12:51:48AM +1100, Fergus Henderson wrote:
>On 23-Feb-1999, Christopher Faylor <cgf@cygnus.com> wrote:
>> On Mon, Feb 22, 1999, Carl Zmola wrote:
>> >
>> >The fact that a company is in charge of 
>> >coordinating the efforts has an effect.
>> >
>> >In the past the main reason I didn't even investigate contributing is :
>> >Because of the feeling that contributions are unwanted, and that someone
>> >else is making money of of my work.
>> >
>> >After a little investigation, I found that these wern't valid concerns, but
>> >they are a first line of resistance.  
>> 
>> It is interesting that you felt this way at first.  I wonder if the reason
>> has anything to do with the name "Cygwin" which sounds so similar to "Cygnus".
>> 
>> The reason I am saying this is because hundreds of people have contributed to
>> the linux project and *many* companies make money from linux.
>
>Yes, but you can write and distribute proprietry applications or even
>proprietry kernel modules for Linux without paying anyone a license fee.
>The same is not true for Cygwin (although it *was* true once, back around
>version b16, when it was called gnu-win32).

True, but that is not the point.  I believe this whold thread started
because I lamented the lack of people contributing directly to cygwin
development.  The many contributors to the linux kernel do not do so
because it is possible to develop proprietary code for linux.

I don't consider companies who create proprietary kernel modules as
contributing to linux development in any way.  Possibly they help indirectly
by getting the word out about linux but that is a secondary and, IMO, very
minor benefit.

cf

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Cygwin participation threshold

[Fergus Henderson]

On 23-Feb-1999, Christopher Faylor <cgf@cygnus.com> wrote:
> On Mon, Feb 22, 1999, Carl Zmola wrote:
> >
> >The fact that a company is in charge of 
> >coordinating the efforts has an effect.
> >
> >In the past the main reason I didn't even investigate contributing is :
> >Because of the feeling that contributions are unwanted, and that someone
> >else is making money of of my work.
> >
> >After a little investigation, I found that these wern't valid concerns, but
> >they are a first line of resistance.  
> 
> It is interesting that you felt this way at first.  I wonder if the reason
> has anything to do with the name "Cygwin" which sounds so similar to "Cygnus".
> 
> The reason I am saying this is because hundreds of people have contributed to
> the linux project and *many* companies make money from linux.

Yes, but you can write and distribute proprietry applications or even
proprietry kernel modules for Linux without paying anyone a license fee.
The same is not true for Cygwin (although it *was* true once, back around
version b16, when it was called gnu-win32).

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "Binaries may die
WWW: < http://www.cs.mu.oz.au/~fjh >  |   but source code lives forever"
PGP: finger fjh@128.250.37.3        |     -- leaked Microsoft memo.

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Cygwin participation threshold

[Carl Zmola]

Christopher Faylor <cgf@cygnus.com> wrote:

> On Mon, Feb 22, 1999 at 11:30:59AM +0000, Carl Zmola wrote:
> >
> >In the past the main reason I didn't even investigate contributing is :
> >Because of the feeling that contributions are unwanted, and that someone
> >else is making money of of my work.
> >
> >After a little investigation, I found that these wern't valid concerns, but
> >they are a first line of resistance.  
> 
> It is interesting that you felt this way at first.  I wonder if the reason
> has anything to do with the name "Cygwin" which sounds so similar to "Cygnus".

Quite possibly. Also in the past, if you went to the cygnus web site, you couldn't
get to the 'free' cygwin tools.  That left a bad taste in my mouth.

> The reason I am saying this is because hundreds of people have contributed to
> the linux project and *many* companies make money from linux.

That is quite true.  The name could be part of the problem, but I do know
who cygnus is because of the name.

 

Carl 
zmola@campbellsci.com

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Cygwin participation threshold

[Christopher Faylor]

On Wed, Feb 24, 1999 at 11:35:42AM +0000, Carl Zmola wrote:
>Christopher Faylor <cgf@cygnus.com> wrote:
>
>> On Mon, Feb 22, 1999 at 11:30:59AM +0000, Carl Zmola wrote:
>> >
>> >In the past the main reason I didn't even investigate contributing is :
>> >Because of the feeling that contributions are unwanted, and that someone
>> >else is making money of of my work.
>> >
>> >After a little investigation, I found that these wern't valid concerns, but
>> >they are a first line of resistance.  
>> 
>> It is interesting that you felt this way at first.  I wonder if the reason
>> has anything to do with the name "Cygwin" which sounds so similar to "Cygnus".
>
>Quite possibly. Also in the past, if you went to the cygnus web site, you couldn't
>get to the 'free' cygwin tools.  That left a bad taste in my mouth.

When was this?  There has been a button on the main site for some time.
I can't say for sure, but I believe that if you were having problems
accessing the cygwin page it must have been an oversight by our
webmaster.

>> The reason I am saying this is because hundreds of people have contributed to
>> the linux project and *many* companies make money from linux.
>
>That is quite true.  The name could be part of the problem, but I do know
>who cygnus is because of the name.

Yup.  It's likely many people Cygwin == Cygnus.

cgf

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Cygwin participation threshold

[Carl Zmola]

> 
> When was this?  There has been a button on the main site for some time.
> I can't say for sure, but I believe that if you were having problems
> accessing the cygwin page it must have been an oversight by our
> webmaster.

Oh 2 years maybe? A long time ago.  

> Yup.  It's likely many people Cygwin == Cygnus.

For better or for worse. 
 

Carl 
zmola@campbellsci.com

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Cygwin participation threshold

[Carl Zmola]

> 
> When was this?  There has been a button on the main site for some time.
> I can't say for sure, but I believe that if you were having problems
> accessing the cygwin page it must have been an oversight by our
> webmaster.

Oh 2 years maybe? A long time ago.  

> Yup.  It's likely many people Cygwin == Cygnus.

For better or for worse. 
 

Carl 
zmola@campbellsci.com

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Cygwin participation threshold

[Christopher Faylor]

On Wed, Feb 24, 1999 at 11:35:42AM +0000, Carl Zmola wrote:
>Christopher Faylor <cgf@cygnus.com> wrote:
>
>> On Mon, Feb 22, 1999 at 11:30:59AM +0000, Carl Zmola wrote:
>> >
>> >In the past the main reason I didn't even investigate contributing is :
>> >Because of the feeling that contributions are unwanted, and that someone
>> >else is making money of of my work.
>> >
>> >After a little investigation, I found that these wern't valid concerns, but
>> >they are a first line of resistance.  
>> 
>> It is interesting that you felt this way at first.  I wonder if the reason
>> has anything to do with the name "Cygwin" which sounds so similar to "Cygnus".
>
>Quite possibly. Also in the past, if you went to the cygnus web site, you couldn't
>get to the 'free' cygwin tools.  That left a bad taste in my mouth.

When was this?  There has been a button on the main site for some time.
I can't say for sure, but I believe that if you were having problems
accessing the cygwin page it must have been an oversight by our
webmaster.

>> The reason I am saying this is because hundreds of people have contributed to
>> the linux project and *many* companies make money from linux.
>
>That is quite true.  The name could be part of the problem, but I do know
>who cygnus is because of the name.

Yup.  It's likely many people Cygwin == Cygnus.

cgf

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Cygwin participation threshold

[Carl Zmola]

Christopher Faylor <cgf@cygnus.com> wrote:

> On Mon, Feb 22, 1999 at 11:30:59AM +0000, Carl Zmola wrote:
> >
> >In the past the main reason I didn't even investigate contributing is :
> >Because of the feeling that contributions are unwanted, and that someone
> >else is making money of of my work.
> >
> >After a little investigation, I found that these wern't valid concerns, but
> >they are a first line of resistance.  
> 
> It is interesting that you felt this way at first.  I wonder if the reason
> has anything to do with the name "Cygwin" which sounds so similar to "Cygnus".

Quite possibly. Also in the past, if you went to the cygnus web site, you couldn't
get to the 'free' cygwin tools.  That left a bad taste in my mouth.

> The reason I am saying this is because hundreds of people have contributed to
> the linux project and *many* companies make money from linux.

That is quite true.  The name could be part of the problem, but I do know
who cygnus is because of the name.

 

Carl 
zmola@campbellsci.com

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Cygwin participation threshold

[Christopher Faylor]

On Mon, Feb 22, 1999 at 11:30:59AM +0000, Carl Zmola wrote:
>
>> DJGPP has a much higher threshold (it's much more complicated), but
>> there are far more people contributing to djgpp than to cygwin.  If
>> anyone can figure out *why*, let us know! ;-) I think it's social -
>> djgpp contributors just know that they'll get a friendly reception to
>> their contributions, good or bad, so they aren't as hesitant to send
>> stuff in.
>
>That could be part of it.  The fact that a company is in charge of 
>coordinating the efforts has an effect.
>
>In the past the main reason I didn't even investigate contributing is :
>Because of the feeling that contributions are unwanted, and that someone
>else is making money of of my work.
>
>After a little investigation, I found that these wern't valid concerns, but
>they are a first line of resistance.  

It is interesting that you felt this way at first.  I wonder if the reason
has anything to do with the name "Cygwin" which sounds so similar to "Cygnus".

The reason I am saying this is because hundreds of people have contributed to
the linux project and *many* companies make money from linux.

cgf

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Cygwin participation threshold

[Carl Zmola]

> DJGPP has a much higher threshold (it's much more complicated), but
> there are far more people contributing to djgpp than to cygwin.  If
> anyone can figure out *why*, let us know! ;-) I think it's social -
> djgpp contributors just know that they'll get a friendly reception to
> their contributions, good or bad, so they aren't as hesitant to send
> stuff in.

That could be part of it.  The fact that a company is in charge of 
coordinating the efforts has an effect.

In the past the main reason I didn't even investigate contributing is :
Because of the feeling that contributions are unwanted, and that someone
else is making money of of my work.

After a little investigation, I found that these wern't valid concerns, but
they are a first line of resistance.  

Carl 
zmola@campbellsci.com

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Cygwin participation threshold

[DJ Delorie]

> Hopefully, that's what you wanted - to give people a nice tool,

I think it would be more accurate to replace "give" with "share with".

As a bit of history, Cygnus had a purely business reason to create
cygwin.  Doing so let us host our tools on 95/NT platforms, which
meant more customers (i.e. more money).  AFAIK, releasing cygwin to
the net had two reasons: the first philosophical, in that we like to
share; and the second practical, in that the more people using cygwin
the more paid support contracts we'll get.

>     But when someone wants to fix or add something to cygwin, here
> comes another problem - it's high enough threshold to be able to do
> so. Even higher threshold to make it acceptable for inclusion back.

DJGPP has a much higher threshold (it's much more complicated), but
there are far more people contributing to djgpp than to cygwin.  If
anyone can figure out *why*, let us know! ;-) I think it's social -
djgpp contributors just know that they'll get a friendly reception to
their contributions, good or bad, so they aren't as hesitant to send
stuff in.

> By this I mean whole technology issues - not Cygwin technology, I
> call it GNU technology - configuration/setup methods, coding styles
> (not just mere conventions for identifier naming / block
> indentation, but modularization conventions, from source modules
> thru libs to executables, etc.) And all that are obstacles to
> contributing.

Even so, I'd rather people contribute what they can instead of just
sulking off in a corner and getting nowhere.  We're not going to laugh
at you for bad style (I hope).  More likely, we'll explain how to
change what you've got to work better with what we've got (it's called
"learning").  Cooperation is a two-way street!  If you're willing to
do *anything*, we'll probably meet you half-way.

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re[2]: Cygwin B20 - fseek under gcc fails to reposition on text files

[Paul Sokolovsky]

Hello Christopher,

Christopher Faylor <cgf@cygnus.com> wrote:

[]

CF> Currently, Corinna, Mumit, and a couple of other people are the only
CF> outside contributers to the project.  Everyone else seems to be in
CF> "Cygwin doesn't work the way I think it should when I run program X.
CF> Here's the error message." mode.

    With other opinions expressed in this thread, I'd like to add
following: it's quite understood that most people are in that mode -
they are using cygwin as their tool, something like car, and are not
concerned, or able to, how it's functioning. Hopefully, that's what
you wanted - to give people nice tool, to keep balance with such toys
like msvc, delphi, etc.

    But when someone wants to fix or add something to cygwin, here
comes another problem - it's high enough threshold to be able to do
so. Even higher threshold to make it acceptable for inclusion back.
By this I mean whole technology issues - not Cygwin technology, I call
it GNU technology - configuration/setup methods, coding styles (not
just mere conventions for identifier naming / block indentation, but
modularization conventions, from source modules thru libs to
executables, etc.) And all that are obstacles to contributing. But of
course I don't say that's bad - there must be order and who willing to
contribute should know and accept it, but it requires time, and
potential contributors may not have it, just the same as developers
may not ;-) .

    Ok, I turn down considering problems of open-source
development, this is hardly appropriate place for it.

CF> I'm collecting the error messages and hope to investigate problems but
CF> the reality is that this is a volunteer effort for DJ and me.  Our
CF> real jobs don't offer much time for tracking down net problems.

CF> -chris


Best regards,
 Paul                            mailto:paul-ml@is.lg.ua


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Cygwin B20 - fseek under gcc fails to reposition on text files

[Christopher Faylor]

On Thu, Feb 18, 1999 at 06:38:46PM +0200, Paul Sokolovsky wrote:
>    Bad thing is that issue very minor. People might don't care what
>line-endings text files have, they might don't care that there's
>notepad and bat files. And when their favorite vi chokes on that \r at
>the end (or beginning? ;-) ) of line they might teach him chop it -
>after all, that's not notepad. But they might think that wrapping each
>command piping binary files in shell script setting CYGWIN (having
>spent some nice time trying to understand why their files are
>corrupted and asking maillist why this bug) is too awkward.

Actually, as far as pipes are concerned, they default to binmode
unless overridden by CYGWIN so this should not be an issue.

>   Of course, that far too imaganable picture, just like my previous
>massage has, just like several years ago cygwin itself was only
>imaganable. I don't believe that things enpictured by me will be, or
>even should be, done to cygwin. I just wanted to hyperbolize it,
>showing that changing itself is not an edge alternative, all
>determained by ammount of changes, and there might be the golden mean,
>exactly what you'll do. (That's just because I have a ho that Cygnus
>guys quite conservative - I remember Christopher Faylor's hesitating
>in cygwin-developer whether correcting bug won't break user (or
>customer) code. Maybe you, Corinna, as leading contributor, and DJ, as
>author of alternative approach, and working for Cygnus, have other
>opinions).

I have no idea what, specifically, you are referring to but it is
interesting that you find it "quite conservative" to consider caring
about breaking somebody's code.  You are probably referring to my
soliciting of opinions on the subject of breaking API compatibility
with a new cygwin DLL.  This was obviously a subject which deserved
careful consideration and it was something that I was willing to do.
In fact, it is something that *will* occur in a future release.

Regardless, if you look at the ChangeLog in the last year, you'll find
that I'm the author of a lot of radical changes in Cygwin.

I am not at all opposed to the idea of somebody fixing ftell/fseek
to work as Microsoft has documented them or as DJGPP has currently
implemented things.  I've written a stdio layer myself and I know
that this is not a trivial undertaking, though.  Certainly no
one at Cygnus has the time right now to undertake this.

Currently, Corinna, Mumit, and a couple of other people are the only
outside contributers to the project.  Everyone else seems to be in
"Cygwin doesn't work the way I think it should when I run program X.
Here's the error message." mode.

I'm collecting the error messages and hope to investigate problems but
the reality is that this is a volunteer effort for DJ and me.  Our
real jobs don't offer much time for tracking down net problems.

-chris

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re[2]: Cygwin B20 - fseek under gcc fails to reposition on text files

[Paul Sokolovsky]

Hello Corinna,

Corinna Vinschen <corinna.vinschen@cityweb.de> wrote:

>>     So, for more than twenty years MS maintains myth about "special
>> format" of text files of their systems. It's hardly believable. Since

CV> The best way would be to throw away and ignore any newline with
CV> more than one single character.

    Yes, and bad thing is that people came say, from Unix, and don't knowing
that here text files are special, but constantly getting binary file
corruptions when filtering gifs, piping gzips, etc. may think that way is
right ;-(

CV> But let's get serious.

CV> IMHO, above all text file processing should be done according to the
CV> underlying OS and it's vendor, also if this is wretched.

    Bad thing is that issue very minor. People might don't care what
line-endings text files have, they might don't care that there's
notepad and bat files. And when their favorite vi chokes on that \r at
the end (or beginning? ;-) ) of line they might teach him chop it -
after all, that's not notepad. But they might think that wrapping each
command piping binary files in shell script setting CYGWIN (having
spent some nice time trying to understand why their files are
corrupted and asking maillist why this bug) is too awkward.

   Of course, that far too imaganable picture, just like my previous
massage has, just like several years ago cygwin itself was only
imaganable. I don't believe that things enpictured by me will be, or
even should be, done to cygwin. I just wanted to hyperbolize it,
showing that changing itself is not an edge alternative, all
determained by ammount of changes, and there might be the golden mean,
exactly what you'll do. (That's just because I have a ho that Cygnus
guys quite conservative - I remember Christopher Faylor's hesitating
in cygwin-developer whether correcting bug won't break user (or
customer) code. Maybe you, Corinna, as leading contributor, and DJ, as
author of alternative approach, and working for Cygnus, have other
opinions).

   But there still that idea - there maybe niche that cygwin doesn't
fill - to be more unixish despite be less winnish.

CV> The second choice has the advantage, to be easy to implement.

CV> The third choice should be implemented, if s.o. has nothing important
CV> to do.

CV> Regards,
CV> Corinna

    Thanks for not taking previous text as profanity, that's was just rebellion
humoresqe, just forgot adding trailing disclaimer ;-)


Best regards,
 Paul                            mailto:paul-ml@is.lg.ua


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Cygwin B20 - fseek under gcc fails to reposition on text files

[Corinna Vinschen]

Paul Sokolovsky wrote:
>     So, for more than twenty years MS maintains myth about "special
> format" of text files of their systems. It's hardly believable. Since
> my old XT I quite nicely handled any text files - be they Unix \xa,
> Mac \xd, or "dos" \xd\xa . So there's nothing special to talk about
> "special" format of text files. Most tools available handled any type,
> and conversion between formats was quite feasible. With win32, such
> problems are ceased at all - I don't have no line endings problems, no
> encoding problems, even that unicode seams to be here.

As a matter of fact: Peter's c example, which opens this thread, does
not work with VC++, if the newline is not \r\n. Look into the source
of M$-ftell(), it can't work.

The best way would be to throw away and ignore any newline with
more than one single character.

But let's get serious.

IMHO, above all text file processing should be done according to the
underlying OS and it's vendor, also if this is wretched.

The second choice has the advantage, to be easy to implement.

The third choice should be implemented, if s.o. has nothing important
to do.

Regards,
Corinna


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re[2]: Cygwin B20 - fseek under gcc fails to reposition on text files

[Paul Sokolovsky]

Hello Corinna,

Corinna Vinschen <corinna.vinschen@cityweb.de> wrote:

[]

CV> We have three possible choices:

CV> 1st: We are not performing the same errors as M$. We do our own, so we let
CV>      it as it is.

CV> 2nd: M$-compatible errors, so we let ftell count \n, too. This would result
CV>      in more often correct telling.

CV> 3rd: The full stdio code in newlib has to be changed. The buffer is used
CV>      anyway in binary mode, every call has to use new counting and
CV>      translation methods than the current one.
CV>      Because this has to be done _very_ cautious, it's a long time change.

CV> For the near future, I would prefer the second choice. Other opinions?

    Let me support 3rd way, in rather flamy passages, however.

    So, for more than twenty years MS maintains myth about "special
format" of text files of their systems. It's hardly believable. Since
my old XT I quite nicely handled any text files - be they Unix \xa,
Mac \xd, or "dos" \xd\xa . So there's nothing special to talk about
"special" format of text files. Most tools available handled any type,
and conversion between formats was quite feasible. With win32, such
problems are ceased at all - I don't have no line endings problems, no
encoding problems, even that unicode seams to be here.

   And here we come to most interesting questions - that fact that MS
maintains aforementioned myth is not surprising, but that myth is
carefully maintained by outside crew too! Just listen to those GNUers
telling us that text files here are "special" and they must dirty
workaround that! Just see peoples advocating data stream corruption on
most basic system level!

   But what if stop that play and acknowledge that some guys have done
quite well and it's useless to try to not notice that. \r\n textfiles
should be handled properly where they belong - e.g. in textutils, but
never in core system, leading just to corruption.

   So, what I argue:

1. Text/binary file notion on most basic, POSIX level should be
   abandoned.
2. That has nothing to do with stdio level - since default accessors for
   that level are single-character oriented, it doesn't hurt much
   stuffing single test there.

(Note that this indeed DJ Delorie's idea as of DJGPP lib, pushed further
to exterminating textuality on POSIX level at all)

3. All stuff working with textfiles and using POSIX level either should
   be taught accept any line-endings or reimplented in stdio.

4. Until then, there're fromdos/todos filters.


   And finally, from where all this stuff might be originated - it may
be done whatever wanted, but if, when writing to console we get clobbered
output without carrage returns, it doesn't cost a cent. That's where
myth of win32 speciality breaks down - Win32 console, as any other
console in cooked mode (Linux, say) performs implicit cr after lf,
when there's no explicit.

   Just run following (tested only on Win95/Win95OSR2 to be honest):

--------
#include <windows.h>

char str[]="\nline1\nline2\nline3\n";

void main()
{
  DWORD dummy;
  WriteFile(STD_OUTPUT_HANDLE,str,sizeof(str)-1,&dummy,NULL);
  WriteFile(STD_ERROR_HANDLE,str,sizeof(str)-1,&dummy,NULL);
}
--------


CV> Regards,
CV> Corinna


Best regards,
 Paul                            mailto:paul-ml@is.lg.ua


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Cygwin B20 - fseek under gcc fails to reposition on text files

[Corinna Vinschen]

Christopher Faylor wrote:
> 
> On Tue, Feb 16, 1999 at 07:41:34AM -0800, Earnie Boyd wrote:
> >
> >Here is the "Microsoft VC++ Run-Time Library Reference" quote:
> >
> >For streams opened in text mode, fseek has limited use, because
> >carriage return-linefeed translations can cause fseek to produce
> >unexpected results.  The only fseek operations guaranteed to work on
> >streams opened in text mode are:
> >
> >* Seeking with an offset of 0 relative to any of the origin values.
> >
> >* Seeking from the beginning of the file with an offset value returned
> >from a call to ftell.
> >
> >Also in text mode, CTRL+Z is interpreted as an end-of-file character
> >[...]

This is the _documentation_ of M$. In fact their code doesn't do the right
thing! As the ftell of newlib, it works without special calls of the
underlying OS, only calls to `_lseek()' are performed.  The only difference
between M$ and newlib is, that M$ performs additional counting of \n in
case of text file processing. It's done in the already translated buffer,
so the result is crap, as in newlib. Only their hit count is better.

> >Based on the documentation then I'll have to agree that your programs
> >isn't behaving as the documentation states that it should.  But, which
> >is wrong, fseek or ftell?
> 
> This does sound like a bug.  We'll try to look into this, time permitting.
> 
> If anyone else wants to take a stab at this (Corinna?) I'd be very grateful.

We have three possible choices:

1st: We are not performing the same errors as M$. We do our own, so we let
     it as it is.

2nd: M$-compatible errors, so we let ftell count \n, too. This would result
     in more often correct telling.

3rd: The full stdio code in newlib has to be changed. The buffer is used
     anyway in binary mode, every call has to use new counting and
     translation methods than the current one.
     Because this has to be done _very_ cautious, it's a long time change.

For the near future, I would prefer the second choice. Other opinions?

Regards,
Corinna


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: Cygwin B20 - fseek under gcc fails to reposition on text files

[Christopher Faylor]

On Tue, Feb 16, 1999 at 07:41:34AM -0800, Earnie Boyd wrote:
>
>Ok I appoligize.
>
>Here is the "Microsoft VC++ Run-Time Library Reference" quote:
>
>For streams opened in text mode, fseek has limited use, because
>carriage return-linefeed translations can cause fseek to produce
>unexpected results.  The only fseek operations guaranteed to work on
>streams opened in text mode are:
>
>* Seeking with an offset of 0 relative to any of the origin values.
>
>* Seeking from the beginning of the file with an offset value returned
>from a call to ftell.
>
>Also in text mode, CTRL+Z is interpreted as an end-of-file character
>on input.  In files opened for reading/writing, fopen and all related
>routines check for a CTRL+Z at the end of the file and remove it if
>possible.  This is done because using fseek and ftell to move within
>an file that ends in CTRL+Z may cause fseek to behave improperly near
>the end of the file.
>
>---
>
>Based on the documentation then I'll have to agree that your programs
>isn't behaving as the documentation states that it should.  But, which
>is wrong, fseek or ftell?
>
>Sorry for speaking out of line,

This does sound like a bug.  We'll try to look into this, time permitting.

If anyone else wants to take a stab at this (Corinna?) I'd be very grateful.

-chris

RE: Cygwin B20 - fseek under gcc fails to reposition on text files

[Earnie Boyd]

Ok I appoligize.

Here is the "Microsoft VC++ Run-Time Library Reference" quote:

For streams opened in text mode, fseek has limited use, because
carriage return-linefeed translations can cause fseek to produce
unexpected results.  The only fseek operations guaranteed to work on
streams opened in text mode are:

* Seeking with an offset of 0 relative to any of the origin values.

* Seeking from the beginning of the file with an offset value returned
from a call to ftell.

Also in text mode, CTRL+Z is interpreted as an end-of-file character
on input.  In files opened for reading/writing, fopen and all related
routines check for a CTRL+Z at the end of the file and remove it if
possible.  This is done because using fseek and ftell to move within
an file that ends in CTRL+Z may cause fseek to behave improperly near
the end of the file.

---

Based on the documentation then I'll have to agree that your programs
isn't behaving as the documentation states that it should.  But, which
is wrong, fseek or ftell?

Sorry for speaking out of line,
Earnie.

---Peter Kabal <kabal@ece.mcgill.ca> wrote:
>
> I did.  I quote from Harbison and Steele, Fourth edition, p 353.
> 
> "The following, more limited set of calls is permitted on text streams
> by ISO C:
> 
> fseek (stream, 0L, SEEK_SET)
> fseek (stream, 0L, SEEK_CUR)
> fseek (stream, 0L, SEEK_END)
> fseek (stream, 0L, ftell_pos, SEEK_SET)  at a position returned by a
>     previous call to ftell for stream.
> "
> 
> I <did> read the docs about "text mode processing"!  Your comment was
> unwarranted and warrants an apology.
> 
> > -----Original Message-----
> > From: Earnie Boyd [ mailto:earnie_boyd@yahoo.com ]
> > Sent: February 16, 1999 8:28 AM
> > To: kabal@ece.mcgill.ca
> > Cc: cygwin users
> > Subject: Re: Cygwin B20 - fseek under gcc fails to reposition on
text
> > files
> > 
> > 
> > 
> > You need to read the docs about "text mode processing".  This is
> > exactly the expected behavior.  If you're going to use these
functions
> > then you must process in binary mode.
> > 
> > Regards,
> > Earnie.
> > 
> > ---Peter Kabal <kabal@ECE.McGill.CA> wrote:
> > >
> > > Consider a text file (CR/LF line endings).  Read a line, save the
> > > current position, seek to end-of-file, seek to the saved position,
> > > read a line.  The second read does not return the second line of
> > > the file.
> > > 
> > > A shell script which tests the problem is included below:
> > >
---------------------------------------------------------------------
> > > #!/bin/sh
> > > #
> > > # Test fseek bug
> > > # On Cygwin 20.1, a file is not correctly repositioned after
seeking
> > to the
> > > # end-of-file on a text file (CR/LF line endings).
> > > 
> > > cat > tfrepos.c << EoF
> > > #include <stdio.h>
> > > int main (int argc, char *argv[])
> > > {
> > >   FILE *fp;
> > >   long int pos, size;
> > >   char line[200];
> > >   char *p;
> > > 
> > >   fp = fopen (argv[1], "r");
> > >   p = fgets (line, 200, fp);
> > >   printf (" Line: %s", p);
> > > 
> > >   pos = ftell (fp);
> > >   fseek (fp, 0L, SEEK_END);
> > >   fseek (fp, pos, SEEK_SET);
> > > 
> > >   p = fgets (line, 200, fp);
> > >   printf (" Line: %s", p);
> > > 
> > >   return 0;
> > > }
> > > EoF
> > > 
> > > # Run the test program with the c-program as input
> > > gcc tfrepos.c -o tfrepos
> > > ./tfrepos tfrepos.c
> > > 
> > > # Clean up
> > > rm -f tfrepos tfrepos.c
> > >
---------------------------------------------------------------------
> > > 
> > > Peter Kabal  kabal@ECE.McGill.CA
> > > Dept. Electrical & Computer Eng.
> > > McGill University 
> > > 
> > 
> > _________________________________________________________
> > DO YOU YAHOO!?
> > Get your free @yahoo.com address at http://mail.yahoo.com
> > 
> > 
> 

_________________________________________________________
DO YOU YAHOO!?
Get your free @yahoo.com address at http://mail.yahoo.com