Subject: Re: Why text=binary mounts
From: [email-masked]

12 Jan 1998 18:25:29 -0800
Message-ID: <[email-masked]>
To: [email-masked]

Tomas Fasth <[email-masked]> writes:
> 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.

It is an unfortunate fact of life now that Microsoft software controls 85%
of the computers in the world.  That's pretty dominant, and unfortunately,
it will likely have a strong hold on that market share for quite some time
to come.  Unix may have had a chance back in the late 80s when there was
a big attempt to unify the Unix market to combat Microsoft, but alas the
effort was doomed to failure by the dark forces of entropy.  Since then, the
world has been being taken over by Microsoft...

If you are writing software that you want to sell to the largest group of
users, you have to address it to Microsoft.  Sure, the remaining 15% of the
market can buy some product, but not all that much, plus that 15% is split
between all of the non-MS world, so only a very small portion is actually
Unix, MacOS, etc.  So, if you want to appeal to the largest user base, you
really have to work in the MS world.  That's a pretty good reason to "prefer"
MS.  Not that it's the nicest environment to write code in, but because it
gives the better return on your programming investment.

> ... 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 guess it is possible...  The MacOS CR delimiter certainly dates back to
the beginnings of AppleDOS on the Apple ][, around 1976 or so, I think.  The
CR LF of DOS comes by way of CP/M, which came from RT-11 (and other DEC PDP-11
OSs), so it came from the late 60s.  Unix actually seems to be the odd-ball
by using LF as the delimiter.  How many times have you gotten into raw mode,
where the return key no longer terminates you input lines?  Using CR as
the delimiter seems most intuitive, since that's actually what you usually
type to terminate a line.  CR LF makes sense because that's actually what
you send to a TTY or CRT terminal to go to the next line.  There were some
chain printers that used to use LF to move to the start of the next line, but
this was hardly common.

BTW, I think that it is Unix-centric to think of CR as \r and LF as \n.  I
always thought that the original intent was that \n would represent whatever
the local newline character was, whether it was LF or something else. I have
never seen this pairing broken, and I'm sure it was wreck havoc on many
programs if it was changed.

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

That is his point, that he is comparing different formats of text encoding
with different formats of image encoding.

While I do think that Gary's view of a text file manipulation library is a
good one, it is not the path that POSIX/ANSI has taken.  I'm actualy not sure
who originally invented the idea of adding "b" to fopen calls to select
binary files (and leave the default as a text mode open), but everybody seems
to have blessed it.

There might be more milage in working up a word processing abstract format,
similar to BFD, but for text processing documents.  Of course, since I have
spent some time using BFD, maybe I will retract this suggestion...

marcus hall
-
For help on using this list (especially unsubscribing), send a message to
"[email-masked]" with one line of text: "help".