🚀 go-pugleaf

In article <8595@tekgvs.LABS.TEK.COM>, toma@tekgvs.LABS.TEK.COM (Tom Almy) writes:
> In article <valley.661107643@gsbsun> valley@uchicago (Doug Dougherty) writes:
> >The whole "ASCII file/^Z = EOF" thing is a bug, in my view.
> >All copying should be in binary mode.  Editors should not append ^Zs
> >to files.  Foo on the Norton Editor!
> 
> Not a bug, but a compatibility feature. MS/DOS was designed to be somewhat
> compatible with CP/M so that all the CP/M applications could be easily ported.
> In CP/M, files were always a multiple of 128 bytes so end of file was 
> indicated by filling the end of the 128 byte sector with ^Z's.
> 
> But this was years ago. There is no excuse for editors to append ^Z's now.
> In fact there is no excuse for any program not ported from CP/M (which is
> just about everything) to append ^Z's.

Not quite true - I think this is still arguable.

There is still software out there that gets quite upset (infinite
loops, or choking in various strange ways) if the ^Z padding is
missing at the end of the file.

There's no doubt that this software is seriously broken (the ^Z
should be optional on input, certainly not required), but it's out 
there and in use;  much of it is old and not supported by the
manufacturer any more (often the manufaturer _isn't_ any more,
simply because of the turnover in the PC business).  Unfortunately
some people still _rely_ on this software, and don't really feel
they have a good alternative (conversion costs/new product costs/
etc).

Even apart from software ported from CP/M, quite a bit of software
for DOS 1.0 had this problem (it wasn't convenient to write a short
block at the end of the file using the FCB's).

Unfortunately if you are writing a commercial product you have to
deal with this problem - and _anything_ you choose to do will have
compatibility issues with _something_.

Whoever thought up the nickname MessyDos had the right idea :-).

						Bruce C. Wright