Rainer Gerhards Baesweiler, MONTHNAME DAY, t="%'", 19YEAR, t="%d"
Petronellastr. 6
D-5112 Baesweiler
West Germany
Phone (49) 2401-1601




The C Users Journal
Mr. Robert Ward
2120 W. 25th St. Ste. B
Lawrence, KS 66046
U S A



Dear Mr. Ward,

 CUG Cpio Installation Kit 

I'm writing to announce the enhancement of parts of the CUG cpio
installation kit. I've brought some new features to the cpio
archive processing program as well as written two new MS-DOS
driver programs.

First of all, my version of cpio now supports two additional
options, allowing even more system-independent archives. The
usage information has also been improved. The new options are "p"
and "d".

Option p ignores pathnames stored in the archive file. So
whatever pathname was used during creation of the archive is
ignored on output. However, the pathname is displayed in brackets
for convenience. The p option is currently ignored on input.

Option d reflects a change in the internal program philosophy: Up
to now, cugcpio extracted files under all circumstances. If a
file with the same name existed, it was overwritten silently.
Cugcpio now first checks to see if the file exists. If yes, the
user is queried whether or not to overwrite the old one. To
select the former behavior, option d has been added. If d is
specified on the command line, existing files are silently
overwritten. I'd recommend using this option only for extracting
a new version of a program over an old one. Not specifying the
option is much more secure.

There are also two new low-level drivers for MS-DOS included.
They are companions to my high-level sector read and write
utilities. These new drivers fix all (at least I hope) problems
we had with the old int 0x25/0x26 ones. The new drivers don't use
MS-DOS but the BIOS to do their work. They are strictly
restricted to the IBM 360KB (2 sides, 40 track, 9 sectors, 512
bytes) format, because they map an relative sector number to its
absolute address.

No special tricks (like reading in some information from another
disk) are necessary to operate the sector read/write utilities
using the new drivers. I found them working correctly where the
old ones failed.

Although the new drivers completely replace the old ones, you
should retain them for people with generic MS-DOS machines (like
the early Wang PCs). They old drivers work mostly correct on
them, while the new ones totally fail (those machines don't have
an IBM compatible BIOS).

And one last word to the driver theme: Mr. Scott Henion's letter
in the November issue gave me an inspiration. I had to realize
that our system-independent file transfer system has one serious
problem. Most operating systems allow  to access disks directly.
But most of them require some control structures on disk to do
so. So what's our fine system worth? As long as you don't find a
person able (and willing) to build an actual device driver for
the target environment... nothing! And I think we've seen that it
is hard to find these persons. However, I hope there'll be
someone out there able and willing to produce sector read/write
routines using native OS calls. But, after all, we aren't able to
use their potential because we've to build extremely complex
device drivers.

This way the cpio system wont be a success. Unfortunately the
last few month confirm that. There are only drivers for systems
available that could read your disks ever before. I guess not
even a single percent of your orders is shipped in cpio, while 90
percent are shipped in MS-DOS format. Most members don't accept
the new format because they don't see a direct advantage in using
it. For MS-DOS people the easiest way is to use their native
format. Most other machines require less effort to read MS-DOS
disks than cpio ones. Maybe the files are transferred via
asynchronous communication. All because there's no low-level read
sector driver for them available.

In order to become a success, most people have to see advantages
in using the cpio file transfer system. In order to allow this,
we've to have much more sector load utilities for different
environments. In order to get them we've to find people able and
willing to write them. And in order to find them, we've to make
the task of creating such an driver easier.

As far as I've thought about it, the actual problem is how to
enable the usage of the OS's native read/write sector calls. I
imagine this can be achieved by writing some of the OS's basic
disk information tables to the cpio exchange disk. I don't think
that's a Herculean work for you. You stated you're able to
physically write and read every format. Given a master disk of
each OS, you could read the very first sectors usually containing
the OS disk bookkeeping information. Written this sectors to the
beginning of the exchange disk, you can satisfy the OS's need for
that information. However, there's no need for being correct
(except for the disk type). The archive still starts as a single
dump file immediately after the control information. The disk
will never be read using target OS file system calls.

I think this approach is worth to be discussed, although I know
there are many problems to arise. I also think this approach
might introduce a large overhead to your disk distribution.
Nonetheless, there may be some solutions in between. And I
definitely think that the task of building an system independent
file transfer utility is of huge worth for the whole computer
Industrie, not only the C Users' Group. And as such I think we
should extend our activities to build that system.

Enough about that. I've one final request: could you please pass
me one copy of your official cpio installation kit. This enables
me to base my further work in that area on your official system.
As far as I've read, you've build some other loader utility. I
guess I can save you some time if I adapt my low-level drivers to
your high-level program. And I sure want to extend the number of
low-level drivers as soon as I've the necessary opportunities.




With that promise, sincerely yours



R. Gerhards