From: utzoo!decvax!ucbvax!info-cpm
Newsgroups: fa.info-cpm
Title: CPM
Article-I.D.: ucbvax.255
Posted: Tue Dec  7 16:37:59 1982
Received: Wed Dec  8 05:11:44 1982

>From vortex!lauren@Lbl-Unix  Tue Dec  7 16:31:19 1982
To: ELIOT@Mit-Dms
Cc: INFO-CPM@BRL
Via:  Lbl-Unix; 7 Dec 82 5:15-EST
Via:  Brl; 7 Dec 82 6:25-EST
Via:  Brl-Bmd; 7 Dec 82 6:48-EST

Eliot,

Certainly I don't take offense at your message, but I don't think you've
been reading my messages very carefully.

I never said that CP/M Plus wouldn't work for disk I/O!  What I said is that
any programs that try to be "smart", thinking that they know exactly
WHERE the BDOS, BIOS, disk deblocking, etc. are, will probably stop
working.  Remember that D.R. has claimed "functional compatibility" 
with 2.2, not total compatibility.  My own interpretation of "functional"
is that if you use BDOS and BIOS calls exclusively, the program will
probably work, though I have some doubts about programs that use the BIOS
to do their own "fancy" disk handling.  

Obviously, programs like DU, directory managers, and similar utilities
will also probably be vulnerable to some degree to changes in CP/M.
One other point -- if the disk blocking/deblocking is moved to the BDOS,
then obviously the portion of the BDOS that contains the blocking/deblocking
code can no longer be overlayed by most user programs.  If you have a fancy
bank-switched system you might not care, but on most systems, all of these
changes are going to cost, somewhere!

--Lauren--

P.S.  I got a call a couple of days ago from a 3.0 Beta test site who
was making a MARC query.  He basically said something like, "by the way,
they do I/O redirection all wrong..."  He didn't have time to elaborate,
but it didn't give me a very good feeling.  By the way, BYTE published
their box on MARC, but managed to print a totally erroneous phone number
for Vortex.  Sigh .

--LW--