--8TK7rWhZKvee9Ynil6s
Content-Type: multipart/alternative; boundary="=-9JKKUTsQpEG7LFwJd85x"


--	JKKUTsQpEG7LFwJd85x
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Wed, 2007-22-08 at 08:13 +0900, Bertram Scharpf wrote:

> The distinction between "text" and "binary" is the archetype
> misdesign in DOS and Windows. 


And this explains the distinction between opening binary vs. opening
text in UNIX APIs since *LONG* before MS-DOS how?


> It means nothing more than
> that in "text" mode line ends are translated from "\n" to
> "\r\n" what is of no use but to disturb file positions and
> string lengths. The only purpose of this is to detain
> programmers from doing anything in a non-Microsoft way.
> Anywhere else you don't need to care.
> 
> Sorry for the flame but that's the way it is.


It would help if you actually said things the way they were.  This "text
mode" vs. "binary mode" thing is a UNIX "innovation" (one of many which
has plagued the computing world since UNIX's misdesign).  Let me
introduce to you what "the way it is" really is....

Way back in the bad old days, people talked to computers on teletype
machines: combination printer/keyboard.  We didn't have these fancy,
schmancy glass-screened terminals all over the place.  On these
terminals "carriage return" meant "move the printer head to the far
left".  "Line feed" meant "scroll the paper down one line".  These were
completely separate actions requiring completely separate control codes.
("\n" is the "line feed" or "newline".  "\r" is the "carriage return".)

Most systems of the day wrote everything in a single format.  There was
no binary/text distinction.  Each line was ended by a carriage return
and a line feed.  (I still have some of these systems up and running on
my laptop thanks to good old SIMH.)  When you printed these files,
whatever their contents were was run straight to the teletype and
printed out verbatim.  That meant each line ended with "\r\n".

UNIX, of course, being the half-bastard-child of real operating systems
(MULTICS and ITS) that it was, had to do things differently.  To save on
space (!) its creators, in their nigh-infinite wisdom and judgement,
plagued the world with the notion of only using "\n" to terminate text
lines in text files.  (Apparently saving one byte out of every line was
important!  Never mind that OSes on smaller machines than ever ran UNIX
had no problem with that "wasted" carriage return....)  Of course this
meant that you couldn't just copy the bits of a document directly to the
teletype.  Oh, no.  You had to open the file in a special text mode so
the OS would convert things behind the scenes for you, switching every
"\n" into a "\r\n" before sending it off to the teletype.  This was
perceived (incorrectly) as a Great Innovation.

Later, as the UNIX infection set in, "smart" terminals (teletypes and
glass screen) started to, if set appropriately, automatically convert
line feeds into carriage return/line feed combinations.  This was a
feature added to make up for a misfeature in UNIX systems, though, not
something that was really necessary.  (Indeed it breaks the definition
of a line feed according to the ASCII definition thereof.)

MS-DOS arrived on the scene from a different direction.  It came from
the CP/M side of things which was itself heavily influenced by IBM's
operating systems (scaled down, of course, to the teensy CPU that ran
it).  CP/M?  Used the more traditional (at the time) CR/LF combinations
found in pretty much every operating system of the day other than UNIX.
MS-DOS was a hack off of a CP/M clone for the new 8086 processor and, as
such, inherited CP/M's approach to text files (and command line
switches) which itself was inherited from IBM's (and others') various
operating systems.

So the system that had to do it different?  Wasn't Microsoft's.  Nor
even IBM's.  UNIX was the one that had to be different from everybody
else.  And it is UNIX that is to blame for this artificial text/binary
file distinction.

-- 
Michael T. Richter <ttmrichter / gmail.com> (GoogleTalk:
ttmrichter / gmail.com)
Our outrage at China notwithstanding, we should remember that before
1891 the copyrights of foreigners were not protected in the United
States. (Lawrence Lessig)

--	JKKUTsQpEG7LFwJd85x
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
  <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
  <META NAME="GENERATOR" CONTENT="GtkHTML/3.12.1">
</HEAD>
<BODY>
On Wed, 2007-22-08 at 08:13 +0900, Bertram Scharpf wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">The distinction between &quot;text&quot; and &quot;binary&quot; is the archetype</FONT>
<FONT COLOR="#000000">misdesign in DOS and Windows. </FONT>
</PRE>
</BLOCKQUOTE>
<BR>
And this explains the distinction between opening binary vs. opening text in UNIX APIs since *LONG* before MS-DOS how?<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">It means nothing more than</FONT>
<FONT COLOR="#000000">that in &quot;text&quot; mode line ends are translated from &quot;\n&quot; to</FONT>
<FONT COLOR="#000000">&quot;\r\n&quot; what is of no use but to disturb file positions and</FONT>
<FONT COLOR="#000000">string lengths. The only purpose of this is to detain</FONT>
<FONT COLOR="#000000">programmers from doing anything in a non-Microsoft way.</FONT>
<FONT COLOR="#000000">Anywhere else you don't need to care.</FONT>

<FONT COLOR="#000000">Sorry for the flame but that's the way it is.</FONT>
</PRE>
</BLOCKQUOTE>
<BR>
It would help if you actually said things the way they were.&nbsp; This &quot;text mode&quot; vs. &quot;binary mode&quot; thing is a <B>UNIX</B> &quot;innovation&quot; (one of many which has plagued the computing world since UNIX's misdesign).&nbsp; Let me introduce to you what &quot;the way it is&quot; <B>really</B> is....<BR>
<BR>
Way back in the bad old days, people talked to computers on teletype machines: combination printer/keyboard.&nbsp; We didn't have these fancy, schmancy glass-screened terminals all over the place.&nbsp; On these terminals &quot;carriage return&quot; meant &quot;move the printer head to the far left&quot;.&nbsp; &quot;Line feed&quot; meant &quot;scroll the paper down one line&quot;.&nbsp; These were <B>completely separate actions</B> requiring <B>completely separate control codes</B>.&nbsp; (&quot;\n&quot; is the &quot;line feed&quot; or &quot;newline&quot;.&nbsp; &quot;\r&quot; is the &quot;carriage return&quot;.)<BR>
<BR>
Most systems of the day wrote everything in a single format.&nbsp; There was no binary/text distinction.&nbsp; Each line was ended by a carriage return and a line feed.&nbsp; (I still have some of these systems up and runningn my laptop thanks to good old SIMH.)&nbsp; When you printed these files,hatever their contents were was run straight to the teletype and printed out verbatim.&nbsp; That meant each line ended with &quot;\r\n&quot;.<BR>
<BR>
UNIX, of course, being the half-bastard-child of real operating systems (MULTICS and ITS) that it was, had to do things differently.&nbsp; To save on space (!) its creators, in their nigh-infinite wisdom and judgement, plagued the world with the notion of only using &quot;\n&quot; to terminate text lines in text files.&nbsp; (Apparently saving one byte out of every line was important!&nbsp; Never mind that OSes on smaller machines than ever ran UNIX had no problem with that &quot;wasted&quot; carriage return....)&nbsp; Of course this meant that you couldn't just copy the bits of a document directly to the teletype.&nbsp; Oh, no.&nbsp; You had to open the file in a special text mode so the OS would convert things behind the scenes for you, switching every &quot;\n&quot; into a &quot;\r\n&quot; before sending it offo the teletype.&nbsp; This was perceived (incorrectly) as a Great Innovation.<BR>
<BR>
Later, as the UNIX infection set in, &quot;smart&quot; terminals (teletypesnd glass screen) started to, if set appropriately, automatically convert line feeds into carriage return/line feed combinations.&nbsp; This was a feature added to make up for a misfeature in UNIX systems, though, not something that was really necessary.&nbsp; (Indeed it breaks the definition of a line feed according to the ASCII definition thereof.)<BR>
<BR>
MS-DOS arrived on the scene from a different direction.&nbsp; It came from the CP/M side of things which was itself heavily influenced by IBM's operating systems (scaled down, of course, to the teensy CPU that ran it).&nbsp; CP/M?&nbsp; Used the more traditional (at the time) CR/LF combinations found in pretty much every operating system of the day other than UNIX.&nbsp; MS-DOS was a hack off of a CP/M clone for the new 8086 processor and, as such, inherited CP/M's approach to text files (and command line switches) which itself was inherited from IBM's (and others') various operating systems.<BR>
<BR>
So the system that had to do it different?&nbsp; Wasn't Microsoft's.&nbsp; Nor even IBM's.&nbsp; <B>UNIX</B> was the one that had to be different fromverybody else.&nbsp; And it is <B>UNIX</B> that is to blame for this artificial text/binary file distinction.<BR>
<BR>
<TABLE CELLSPACING="0" CELLPADDING="0" WIDTH="100%">
<TR>
<TD>
-- <BR>
<B>Michael T. Richter</B> &lt;ttmrichter / gmail.com&gt; (<B>GoogleTalk:</B> ttmrichter / gmail.com)<BR>
<I>Our outrage at China notwithstanding, we should remember that before 1891 the copyrights of foreigners were not protected in the United States. (Lawrence Lessig)</I>
</TD>
</TR>
</TABLE>
</BODY>
</HTML>

--	JKKUTsQpEG7LFwJd85x--

--8TK7rWhZKvee9Ynil6s
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQBGy3pxLqyWkKVQ54QRApufAJ9jCNvn5W2d4Pp5L8NC/hX8E5coFwCbBPfR
gjf9+XBt7rKp8v5vO17VGkIGY
-----END PGP SIGNATURE-----

--8TK7rWhZKvee9Ynil6s--