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

David Kastrup wrote:
> Paul Lutus <nospam / nosite.zzz> writes:
> 
>> ciapecki wrote:
>>
>> / ...
>>
>>> I was that stupid and forgot to open the writable file as binary "wb">> (before I had "w" only)
>> Don't kick yourself too hard, the error lies with Microsoft trying
>> to golf its way out of a thicket of its own making. There never
>> should have been two standard line endings (actually three if you
>> include the Mac), and there never should have been two path
>> delimiters either, both of which cause endless headaches for
>> cross-platform coders.
>>
>> 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).
> Also forward slashes were used in CP/M as option lead-ins (CP/M, not
> having named directories, did not need to use forwards slashes for
> those).
> 
> This legacy is from long before POSIX, in fact, from long before C.
> 

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 have
been important enough to warrant a design wart on the hardware from
then) line-oriented text processing.

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 manipulation
routine handle the difference gracefully.

The blurb about preserving the idiosyncracies as a business strategy is
hilarious. Also patent nonsense and FUD ;)

David Vallner




--------------enig67E9A41E626EF4D29A0C851B
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)

iD8DBQFFdzfGy6MhrS8astoRAp7oAJ9oz0Lz0miO+qfyR6ZmYan9UOcRhQCfbo5X
ER/8szZCgLUcERAh1mwnAucJi
-----END PGP SIGNATURE-----

--------------enig67E9A41E626EF4D29A0C851B--