Subject: Re: Why text=binary mounts
From: [email-masked] (Fergus Henderson)

12 Jan 1998 10:19:12 -0800
Message-ID: <[email-masked]>
References: <[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
To: Tomas Fasth <[email-masked]>
Cc: "[email-masked]" <[email-masked]>,
        "Gary R. Van Sickle" <[email-masked]>

On 12-Jan-1998, Tomas Fasth <[email-masked]> wrote:
> Fergus Henderson wrote:
> > That solution would be fine, if you were designing a new OS.
> > But we're not!  We're trying to be compatible with an existing OS.
> 
> Yes and no. As far as I understand, one of the goals of gnuwin32 is to
> minimize the burden of porting unix tools to windos.  From that
> perspective, gnuwin32 have to provide a unix-like way of computing for
> these tools.

Yes, indeed.  And it does.  The use of text=binary mode mounts does
minimize porting effort.  But it also harms interoperability with DOS
and Windows tools.

> There are a waste of unix text tools that have '\n' hardcoded.
> I'm not saying this is a good thing, it's just how it is today.

Having '\n' hardcoded is not a problem -- the ANSI C standard requires
C implementations to convert "end-of-line", however it is represented
for that implementation, to '\n'.  The problem is slightly more
complicated: (1) missing "b" or O_BINARY flags in fopen() and open()
calls; and also occaisionally (2) assuming that file offsets,
return values from read(), etc. for text files are equal to the
number of characters.

> Further on, I guess we don't want to unnecessarily contaminate
> the stdio with a filthy text/binary i/o paradigm.

Both text and binary modes are necessary (ANSI C requires it), and both
text=binary and text!=binary mode mounts are necessary (to achieve
different aims).  Of course we don't want to _unnecessarily_ introduce
complexity, but in this case the complexity is necessary.  Without it,
there is no way to achieve the differing goals of gnu-win32: ease of
porting, and possibility of full interoperability.

> Therefore, if we want
> to have access to these tools on the windos platform, and have better
> things to do than rewriting existing unix tools, we have to find a way
> to serve these tools with under-the-cover end-of-line translations. The
> question is: HOW?

I think that we already have a design that can solve that problem...

> text=binary/text!=binary is one possible (and existing) solution.

Indeed.

> Another possible solution could be to map file extensions to the
> appropriate mode.

That doesn't work, because no database of file extensions can ever be
complete, because file extensions do not uniquely identify file types,
and because it is often necessary to distinguish between text and binary
mode even for files with no extension.

> And I'm sure we all have our own favorite solution :)

Sure, but unless they are significantly better than the existing solution
of text=binary/text!=binary mode mounts (and I have not heard any such
solutions mentioned), they are just irrelevant distractions.

> Somewhere along the line someone has to decide what the primary task of
> gnuwin32 is. It cannot possibly solve every problem that occur when
> trying to merge two incompatible programming platforms.

No, but the two (contradictory) goals of minimizing porting effort
and achieving full interoperability with native tools are both
important enough that they deserve to be supported.

> I was hoping
> that one primary goal of gnuwin32 would be to compile and run unix tools
> on the windos platform without modifications.

Yes, agreed.  That's why we should support text=binary mode mounts.
But we should also support text!=binary mode mounts, so that those
who are willing to put a bit more porting effort can achieve full
interoperability with native tools.

> We ought to be thankful to Cygnus for their honorable initiative, and to
> all of you contributing to making gnuwin32 even better.

Agreed.

-- 
Fergus Henderson <[email-masked]>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger [email-masked]         |     -- the last words of T. S. Garp.
-
For help on using this list (especially unsubscribing), send a message to
"[email-masked]" with one line of text: "help".