From: fjh AT cs DOT mu DOT OZ DOT AU (Fergus Henderson) Subject: Re: Why text=binary mounts 12 Jan 1998 10:19:12 -0800 Message-ID: <19980112234505.22444.cygnus.gnu-win32@murlibobo.cs.mu.OZ.AU> References: <01BD1C69 DOT BBA294A0 DOT tiberius AT braemarinc DOT com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii To: Tomas Fasth Cc: "gnu-win32 AT cygnus DOT com" , "Gary R. Van Sickle" On 12-Jan-1998, Tomas Fasth 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 | "I have always known that the pursuit WWW: | of excellence is a lethal habit" PGP: finger fjh AT 128 DOT 250 DOT 37 DOT 3 | -- the last words of T. S. Garp. - For help on using this list (especially unsubscribing), send a message to "gnu-win32-request AT cygnus DOT com" with one line of text: "help".