From: tiberius AT braemarinc DOT com (Gary R. Van Sickle) Subject: RE: Why text=binary mounts 10 Jan 1998 05:51:15 -0800 Message-ID: <01BD1D0C.8604DA80.tiberius.cygnus.gnu-win32@braemarinc.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: "gnu-win32 AT cygnus DOT com" Let me start by saying this: It looks to me we agree almost 100%. But let me address the 'almost': >> What's wrong with this solution: Do it the Unix way. A file is a file is a file. Textual end-of-line is not a business of the i/o subsystem. In Unix the character sequence for end-of-line ('\n' == 012 == 0x10 == 0b00001100) is nothing more exciting than a mutual agreement between tools that want to share text information. How simple! I agree. Let's do away with the "b" and the "t" entirely. All files opened by fopen are binary - what you put in is what you get out. >> Maybe you're only interested in some groovy tools to filter your poor DOS text files? My advice: get native ports of those tools. There is no port? Sad, but you might have to live with that. If you can't, do the port yourself or switch to a REAL OS (hint: ends with nix :-) I don't want to start yet another religious war, but the 'get a real OS' refrain sounds a lot like the same refrain we used to hear from the Mac users. And the Apple II users. And the C64 users. And the Amiga users. (NOTE: I am not comparing UNIX to any of these systems). Microsoft is winning (in fact has already won) because people hear 'get a real OS' and immediately turn off. People love the underdog, and 'get a real OS' just helps the underdog image, regardless of the fact that Microsoft is in no real way an underdog. Furthermore if UNIX is a 'real' OS, why can't the UNIX tools accomodate more than one text file format, including my 'poor DOS text files'? PaintShop Pro can manipulate probably 50 different image file formats, from PCX for God's sake to PNG, and the user hardly knows the difference. >> So, a text processing library is the exactly right place for fixes of os design flaws and differencies such as the use of end-of-line sequence taking twice as much space as necessary. Voila! We're back to where we started. GnuWin32. What did I miss here? GnuWin32 does not include any sort of text proces sing library as far as I know. It deals with the problem by putting in a layer *between* the fopen stuff and the OS calls AFAIK, when the solution I think you are proposing is a layer *over* the fopen stuff. >> Please, please, please. Do what you like, but do NOT try to break the Unix way of computing in the GnuWin32 distribution. If you do, then what's the point the whole project? I am in no way thinking of breaking the 'UNIX way of computing'! I just don't see why a compiler/make util/etc. shouldn't be able to take any text file you throw at it, regardless of which operating system it is running on. >> It may come as a surprise for you that the DOS way is not the right way. No surprise here. But please tell me why the UNIX way is the right way. And while we're at it, is JPG the right way, or is PNG the right way? To people, text is text. Why should it not be the same for a 300MHz Pentium II. Or your SparcStation. Or the Mac. To badly paraphrase somebody, "The only requirement for evil to succeed is for good people to do nothing." So, gosh darn it, I'm going to try to do something. I propose that I will write a 'text access library' with the following features: 1. Written in portable ANSI C (no K&R compilers need apply) 2. Provides all the fscanf, fprintf, etc. (i.e. line reading and writing) functionality for text-containing files only 3. Provides some extended, cool features TBD 4. Reads and writes at least UNIX & DOS, maybe HTML, etc. formats later 5. Operates kind of in this wise: Opens any supported format and they behave the same (i.e. 'read line', 'read next char', all retrieve the same text regardless of format), writes I obviously don't want to do this if nobody will use it, so would/could something like this get included in the GNU distribution? Would somebody commit to porting the GNU tools to use it? Could we get people to actually start to deprecate the use of the stdio text-file processing facilities and use this library? Gary R. Van Sickle (tiberius AT braemarinc DOT com) Electrical Design Engineer Braemar Inc. 11481 Rupp Dr. Burnsville, MN 55337 (612) 890-5135 Ext. 144 Fax: (612) 882-6550 -----Original Message----- From: Tomas Fasth [SMTP:tomas DOT fasth AT twinspot DOT net] Sent: Friday, January 09, 1998 1:50 PM To: gnu-win32 AT cygnus DOT com Cc: Gary R. Van Sickle Subject: Re: Why text=binary mounts Gary R. Van Sickle wrote: > > This whole UNIX/DOS/text/binary situation drives me nuts. Why can't this > problem be solved once and for all by everybody for all time? We are > talking about one '\r', for crissake. What's wrong with this solution: Gary, Your solution is wrong because it promotes an out-dated file system concept originated from digital stoneage operating systems. Back then fopen("t") ment character (byte) oriented i/o, while fopen("b") ment block oriented i/o. Back then the choice had an effect on i/o performance. Now? Heck, modern i/o subsystems are _so_ much more efficient and clever. Also, memory (good for i/o buffering among other things) are now-a-days so much more cheap and virtual. What's wrong with this solution: Do it the Unix way. A file is a file is a file. Textual end-of-line is not a business of the i/o subsystem. In Unix the character sequence for end-of-line ('\n' == 012 == 0x10 == 0b00001100) is nothing more exciting than a mutual agreement between tools that want to share text information. How simple! Ultimately, as a programmer you might want to use a library to share commonly used text processing. As a bonus the details of certain strange text processing characteristics (like what sequence of characters to represent end-of-line) can be hidden from the programmer. Good! So, a text processing library is the exactly right place for fixes of os design flaws and differencies such as the use of end-of-line sequence taking twice as much space as necessary. Voila! We're back to where we started. GnuWin32. Please, please, please. Do what you like, but do NOT try to break the Unix way of computing in the GnuWin32 distribution. If you do, then what's the point the whole project? Maybe you're only interested in some groovy tools to filter your poor DOS text files? My advice: get native ports of those tools. There is no port? Sad, but you might have to live with that. If you can't, do the port yourself or switch to a REAL OS (hint: ends with nix :-) > Let me address one sure-to-come-up complaint right now: the notion that it > would be too much work to 'fix' all the existing code. How much time and > effort is wasted on 'working around' the current situation? Certainly more > time than it would take to search-and-replace "w" with "wt", etc. Oh no. Not in this universe. For reasons too many to list. It may come as a surprise for you that the DOS way is not the right way. Life can be cruel sometimes... -- Tomas Fasth mailto:tomas DOT fasth AT euronetics DOT com EuroNetics Operation http://euronetics.com Mjardevi Science Park Office tel: +46 13 218 181 Teknikringen 1 E Office fax: +46 13 218 182 58330 Linkoping Mobile tel: +46 708 870 957 Sweden Mobile fax: +46 708 870 258 - 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".