--=-l8TK7rWhZKvee9Ynil6s
Content-Type: multipart/alternative; boundary="=-9JKKUTsQpEG7LFwJd85x"
--=-9JKKUTsQpEG7LFwJd85x
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable
The distinction between "text" and "binary" is the archetype
misdesign in DOS and Windows.=20
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.
=20
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.
--=20
Michael T. Richter <
[email protected]> (GoogleTalk:
(e-mail address removed))
Our outrage at China notwithstanding, we should remember that before
1891 the copyrights of foreigners were not protected in the United
States. (Lawrence Lessig)
--=-9JKKUTsQpEG7LFwJd85x
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=3D"Content-Type" CONTENT=3D"text/html; CHARSET=3DUTF-8">
<META NAME=3D"GENERATOR" CONTENT=3D"GtkHTML/3.12.1">
</HEAD>
<BODY>
On Wed, 2007-22-08 at 08:13 +0900, Bertram Scharpf wrote:
<BLOCKQUOTE TYPE=3DCITE>
<PRE>
<FONT COLOR=3D"#000000">The distinction between "text" and "=
binary" is the archetype</FONT>
<FONT COLOR=3D"#000000">misdesign in DOS and Windows. </FONT>
</PRE>
</BLOCKQUOTE>
<BR>
And this explains the distinction between opening binary vs. opening text i=
n UNIX APIs since *LONG* before MS-DOS how?<BR>
<BR>
<BLOCKQUOTE TYPE=3DCITE>
<PRE>
<FONT COLOR=3D"#000000">It means nothing more than</FONT>
<FONT COLOR=3D"#000000">that in "text" mode line ends are transla=
ted from "\n" to</FONT>
<FONT COLOR=3D"#000000">"\r\n" what is of no use but to disturb f=
ile positions and</FONT>
<FONT COLOR=3D"#000000">string lengths. The only purpose of this is to deta=
in</FONT>
<FONT COLOR=3D"#000000">programmers from doing anything in a non-Microsoft =
way.</FONT>
<FONT COLOR=3D"#000000">Anywhere else you don't need to care.</FONT>
</PRE>
</BLOCKQUOTE>
<BR>
It would help if you actually said things the way they were. This &qu=
ot;text mode" vs. "binary mode" thing is a <B>UNIX</B> "=
;innovation" (one of many which has plagued the computing world since =
UNIX's misdesign). Let me introduce to you what "the way it is&q=
uot; <B>really</B> is....<BR>
<BR>
Way back in the bad old days, people talked to computers on teletype machin=
es: combination printer/keyboard. We didn't have these fancy, schmanc=
y glass-screened terminals all over the place. On these terminals &qu=
ot;carriage return" meant "move the printer head to the far left&=
quot;. "Line feed" meant "scroll the paper down one li=
ne". These were <B>completely separate actions</B> requiring <B>=
completely separate control codes</B>. ("\n" is the "l=
ine feed" or "newline". "\r" is the "ca=
rriage return".)<BR>
<BR>
Most systems of the day wrote everything in a single format. There wa=
s no binary/text distinction. Each line was ended by a carriage retur=
n 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".<BR>
<BR>
UNIX, of course, being the half-bastard-child of real operating systems (MU=
LTICS and ITS) that it was, had to do things differently. To save on =
space (!) its creators, in their nigh-infinite wisdom and judgement, plague=
d the world with the notion of only using "\n" to terminate text =
lines in text files. (Apparently saving one byte out of every line wa=
s important! Never mind that OSes on smaller machines than ever ran U=
NIX had no problem with that "wasted" carriage return....) =
Of course this meant that you couldn't just copy the bits of a document dir=
ectly to the teletype. Oh, no. You had to open the file in a sp=
ecial text mode so the OS would convert things behind the scenes for you, s=
witching every "\n" into a "\r\n" before sending it off=
to the teletype. This was perceived (incorrectly) as a Great Innovat=
ion.<BR>
<BR>
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 fe=
ature added to make up for a misfeature in UNIX systems, though, not someth=
ing that was really necessary. (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. It came from =
the CP/M side of things which was itself heavily influenced by IBM's operat=
ing systems (scaled down, of course, to the teensy CPU that ran it). =
CP/M? Used the more traditional (at the time) CR/LF combinations foun=
d in pretty much every operating system of the day other than UNIX. M=
S-DOS was a hack off of a CP/M clone for the new 8086 processor and, as suc=
h, inherited CP/M's approach to text files (and command line switches) whic=
h itself was inherited from IBM's (and others') various operating systems.<=
BR>
<BR>
So the system that had to do it different? Wasn't Microsoft's. =
Nor even IBM's. <B>UNIX</B> was the one that had to be different from=
everybody else. And it is <B>UNIX</B> that is to blame for this arti=
ficial text/binary file distinction.<BR>
<BR>
<TABLE CELLSPACING=3D"0" CELLPADDING=3D"0" WIDTH=3D"100%">
<TR>
<TD>
-- <BR>
<B>Michael T. Richter</B> <<A HREF=3D"mailto:
[email protected]">ttmri=
(e-mail address removed)</A>> (<B>GoogleTalk:</B> (e-mail address removed))<BR>
<I>Our outrage at China notwithstanding, we should remember that before 189=
1 the copyrights of foreigners were not protected in the United States. (La=
wrence Lessig)</I>
</TD>
</TR>
</TABLE>
</BODY>
</HTML>
--=-9JKKUTsQpEG7LFwJd85x--
--=-l8TK7rWhZKvee9Ynil6s
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+XBt7rKp8v5vO17VGkI=
=UQGY
-----END PGP SIGNATURE-----
--=-l8TK7rWhZKvee9Ynil6s--