Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!philabs!seismo!hao!hplabs!sri-unix!Kenny%his-phoenix-multics.arpa@BRL-VGR.ARPA
From: Kenny%his-phoenix-multics.arpa@BRL-VGR.ARPA
Newsgroups: net.micro.cpm
Subject: Re: CP/M Media Compatibility
Message-ID: <14538@sri-arpa.UUCP>
Date: Mon, 12-Dec-83 10:45:00 EST
Article-I.D.: sri-arpa.14538
Posted: Mon Dec 12 10:45:00 1983
Date-Received: Thu, 15-Dec-83 01:04:42 EST
Lines: 20

From:   Kevin Kenny <Kenny%his-phoenix-multics.arpa@BRL-VGR.ARPA>

In fact, Tony Li's a little conservative about CP/M-MP/M-CCP/M media
exchange.  The XFCB's (extended file control blocks) look like files in
nonexistent user areas (above 16).  In fact, though, they're set up so
that if all you use is date/time stamping and the protection attributes,
you won't actually get in trouble.  The second 16 bytes of the XFCB is
reserved for encrypted password, and will be zero if the file is
unpassworded, meaning that the ``file'' won't look as if it's using any
space on the disc, and CP/M-80 won't get confused.

In short, you can exchange discs freely back and forth between CP/M-80
and the newer systems, *provided* that the files are unpassworded, even
if XFCB's are used.

Some of the public domain programs may get confused by the XFCB's, so be
careful.  I know that SAP and DUU work.  SD reports some garbage
information for the additional directory entries.

/k**2