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

11 Jan 1998 17:47:41 -0800
Message-ID: <[email-masked]>
References: <[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
To: "[email-masked]" <[email-masked]>
Cc: "Gary R. Van Sickle" <[email-masked]>

Gary R. Van Sickle wrote:
> 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.

Gary, I admit 'get a real OS' seldom is a meaningful argument. I just
couldn't refrain myself from using it. One of my weak spots I guess :)

> Microsoft is winning (in fact has already won) because people hear
> 'get a real OS' and immediately turn off.

What's all this talk about win and loose?
I say, the real winner in the long run is the Internet community.
Windows will pass, the Internet will remain. (My very own prediction ;-)

Microsoft Windows dominates as a desktop platform. This does not
necessarily mean that it's a preferred platform in general for program
development. Note that I said 'preferred'. A great majority of the
programmers today have to make their living developing for MS Windows.
But that does not mean that all these programmers are putting their vote
on it as the preferred environment for program development. As an
example, the steady growth of installed Linux and FreeBSD systems says
otherwise.

There is already many fine tools available for MS Windows that tries to
overcome some of the design flaws in that OS. The point is; don't blame
Unix for making it difficult to port Unix tools to such OS'es. Unix is
simply a great platform for program development. I guess that's why so
many great tools for program development comes from Unix. And that's why
this issue is an issue. Programmers stuck with the poorer DOS
environment have recognized that the grass is greener on the Unix side.
They want greener grass too! Give us those tools now, they say. But
wait, why are those tools so stupid when applied on our precious DOS
text files? Fix it, they say.

Your frustration about textual end-of-line differencies can easily be
morphed into a stunning fascination of the fact that the designers of
three major OS each choosed three different combinations out of four
possible when picking a representation of end-of-line character
sequence. I'm talking about Mac ('\r'), Unix ('\n') and DOS ('\r\n'),
where the Mac choice is by far most hostile to the programmer community,
since it seem to have been made most recently. I haven't heard yet of an
OS using ('\n\r'), but it sure is a valid sequence so I wouldn't be
surprised if it has been used somewhere.

I think a reason for why 'get a REAL OS' turns people off is because
people in general don't give a damn whether programmers are in heaven or
hell when trying to do their job.
Also, companies developing propriatary costware never have cared much
about portability. Hell, they even actively oppose portability,
compatibility and interoperability as a marketing tool for competitor
oppression. At least in the past. The big success of the Internet
hopefully have forced those companies to rethink.

> 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'?

Because Unix also means Simple (note that I didn't say easy :-). And a
Unix end-of-line is simply just a single character. And because of the
same reason many DOS programs can't understand Unix end-of-lines, why
should Unix programmers have cared about DOS perculiarities? You can't
think of everything, can you? ;-)

> 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.

Oh, I think I ment 'back to gnuwin32, which this list is about', or
something.
Anyway, a possible one-for-all solution, at least for future
developments, could be a text processing layer over stdio. Too bad this
would not help much when porting existing software, would it?

> 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.

You have a point there. But wishes does not solve problems. Someone has
to come up with a liable solution. Changing stdio behavior is not a
liable solution IMHO. We need more like a holy grail of porting text
processing tool.

> No surprise here.  But please tell me why the UNIX way is the right way.

Note that I didn't really said that. But Unix sure has some qualities
that DOS don't have.
One may have an opinion that Unix desktops sucks. And that's probably
what really is missing in Unix, a standard state-of-the-art graphical
desktop. But desktops are not about OS functionality, it's about
application services, which preferably should be layered on top of OS
services, as X-Windows have proved to work. Microsoft evidently have
very skillful user interface engineers. What they have done on top of
DOS can also be done on top of Unix. A good example of such an efford is
the K desktop environment. Looks very promising indeed.

>  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.

Be real. If text is text, then why can't images just be images? You are
comparing different end-of-line schemes with different formats of image
encoding. I'm sure you can find imaging tools on DOS, Mac and Unix that
do not support each other's formats of encoding.

Never the less, I think most programmers share your frustration.

> I propose that I will write a 'text access library' with the following
> features:

An honorable proposal indeed. I say; have peace in your mind Gary and go
ahead! I for one surely will make use of such a promising set of tools.
You can bet it will be appreciated in the programming community.

Are you sure such a library not already exist somewhere out there? I
could be worth looking before you begin ...

-- 
Tomas Fasth                     mailto:[email-masked]
EuroNetics Operation            http://euronetics.com
Mjärdevi Science Park           Office tel: +46 13 218 181
Teknikringen 1 E                Office fax: +46 13 218 182
58330 Linköping                 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
"[email-masked]" with one line of text: "help".