From: David Vallner <david@...>
Date: 2006-12-07T15:46:50+09:00
Subject: Re: replace delimiter in unicode encdoded file

--------------enig28B4F6765313794615769659
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Paul Lutus wrote:
> David Vallner wrote:
>=20
> / ...
>=20
>>>> The reason these variations exist is so someone can say, "my
>>>> software is different, unique, patentable, now you have to pay me
>>>> for it." Even if the differences convey no benefit to the users.
>>> No, the reason is that CP/M had no tty concept, and consequently no
>>> automatic LF->CRLF translation (and CRLF is required on printers).
>=20
> That was the original reason, yes, but it is hard to justify it this fa=
r
> down the road, with what are ostensibly sophisticated operating systems=
,
> unless the idea is to enshrine a handful of bad choices forever.
>=20

Backwards binary compatibility for decades is one of the MS hallmarks.
It's entrenched rather than enshrined - first it was necessary as a
business objective to support and interoperate with arbitrary DOS
software on WinNT. I think -everyone- saw a office worker sit at a text
mode FoxPro app long after Win98 was ubiquitous. Keeping the legacy
behaviour as the default was an easier path for vendors developing new
applications that would work with textual output from older versions
(letting them reuse old code), instead of making them handle differences
gracefully. Interoperability with other operating systems was just
unimportant either as a goal to achieve or to avoid, *nix occupied a
share of the market that wasn't important when the NT architecture came
to be.

>> Hrm, and I also recall once knowing about why the different text /
>> binary file handling was around. Something to do with some DOS
>> programming environment and efficient (by a measure that could only ha=
ve
>> been important enough to warrant a design wart on the hardware from
>> then) line-oriented text processing.
>=20
> I recall the line ending management issue came up because C (and, later=
,
> C++) used Unix line endings internally, therefore they converted any te=
xt
> files on the fly as they were read or written. But, because some files =
were
> binary, not text, it became necessary to tell the file reader/writer
> routines whether or not this behavior was desired.
>=20

Which was hilarious fun with buggy web browsers interpreting compressed
archives as text, thoroughly thrashing them.

>> I don't think there's any distinction between the file modes on the OS=

>> level anymore, but programming language runtimes interpret the absence=

>> of the 'b' flag as "translate newlines" to only have to internally
>> support one convention and avoid having to have every text manipulatio=
n
>> routine handle the difference gracefully.
>=20
> But only on Windows. The presence or absence of the "b" flag has no eff=
ect
> on other platforms, which don't convert line endings. Except possibly t=
he
> Mac -- I don't know how Macintoshes deal with this, IIRC they have \r a=
s a
> line ending.
>=20

I'd expect the Mac side to be worse. IIRC, Mac OS Classic had a CR as a
line ending, and the OS X Classic subsystem apps still have. OS X uses
the (POSIX-specified, I think) LF. Then there's also the PPC -> Intel
switch, so together you should have three combinations of expected line
endings and byte endianness to handle at some level. Someone with more
detailed knowledge about Macsen might know how that's handled.

>> The blurb about preserving the idiosyncracies as a business strategy i=
s
>> hilarious. Also patent nonsense and FUD ;)
>=20
> One can't help thinking this is the real motive behind a lot of this st=
uff.
>=20

Well, my phrasing there was wrong, it was indeed a business strategy.
The motivation however was compatibility; Windows aims to achieve vendor
lock-in by the range of exclusively available software, not using
low-level technical idiosyncracies (unless you count emergent
consequences). This includes both providing attractive tools (like .NET
being installed via Automatic Updates and an essential Vista component -
a brilliant move from Redmond, actually), and reassuring existing
software keeps working (read: potentially making more money to the
vendor without having to be updated).

Davud Vallner


--------------enig28B4F6765313794615769659
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (MingW32)

iD8DBQFFd7jQy6MhrS8astoRAnkMAJ9EHy1GdsfQBdyIDwaIVHioV4B+HQCfc/3t
71JHuAtdgrC3UhWQWVB5STM=
=nl52
-----END PGP SIGNATURE-----

--------------enig28B4F6765313794615769659--