| These days, the utility of choice
is CONVERT.(5) It runs in the GEOS environment as
an application. It converts GEOS files into SEQuential
files by changing the pointers so that the directory
entry points to the file header, the file points
to the index block, the index block points to the
first record, first record to the second record,
etc. The time/date/structure data from the directory
gets written to the file and the file type gets
changed to sEQ. When converting a SEQuential file
back to GEOS, time/date/structure data gets written
to the directory entry, the files gets it's pointers
changed back to what they should be, and the original
file type is restored. Since CONVERT doesn't actually
create a whole new file, it operates very fast. |
ARC and SDA
Don't start thinking that CONVERT is the last
word. While it does what it is supposed to do,
there is a problem with the files it creates that
will sometimes cause difficulties. The glitch
is in the way some telecommunications software
handles SEQuential files. Usually executable code
is stored in PRoGram files using bytes that are
eight bits long. SEQuential files are typically
used for text files. Since only seven of the eight
bits in a byte are needed to represent the entire
ASCII character set, the eighth bit sometimes
gets altered. If you transmit executable code
in a SEQutential file and your software assumes
that it is text and does something funny to the
eighth bit, the receiver gets a mutilated file.
The solution is to change the SEQuential file
into a PRoGram file for it's trip over the phone
lines, then change it back to SEQutential on the
receiving end. Although this is a trivial operation,
it is one more step. Using ARC can make it worth
your while in more ways than one.(6)
ARC is short for ARChiver. It does some very
nice things other than change SEQ files to PRG.
ARC can combine multiple files into a single file.
Say you have 3 files - an application, a data
file, and a documentation file. ARC will read
those files and output a single file which contains
the three original files. ARC also compresses
the output file. With some files I've ARCed, the
output file was only half the size of the input
file. A real benefit of using ARC is that you'll
spend less time uploading files. And you'll also
spend less time downloading files that other people
have ARCed. A recent development in the ARC world
is the Self-Dissolving ARChive, or SDA. It creates
an ARC file that doesn't require ARC to dissolve.
Just LOAD and RUN any file with .SDA at the end
of it's file name, and the original files get
written back to disk in their original form. How
nice!
SUMMARY
One of the tradeoffs of user-friendly systems
is usually added complexity at some level. With
GEOS, that complexity shows up in the file structure.
Until a user-friendly GEOS terminal program is
available to handle user-nasty files, we'll have
to rely on good utilities and a little knowledge
of how things work.
I would like to include your GEOS hints &
tips and bug reports in future columns. If you
have any brief GEOS tricks or bugs that you've
discovered, please send them to me.
Randy Winchester
P.O. Box 426074
Cambridge, MA 02142
In exchange for material submitted on disk, I'll
return a disk of public domain GEOS software. |
1. I use the
public domain DISK PATCH V2.0 by Kevin Pickell,
L. Phillips and J. May.
2. SEQ->Text Scrap. Versions 1.0 - 1.3 are
freely available to the public. Versions 2.0 and
higher are a commercial product.
3. Recommended terminal software: 64 mode - the
public domain CBTERM by CHRISDOS. 128 mode - ULTRATERM,
shareware by Steve Boerner.
4. SECTORS->DATA, DATA->SECTORS, public
domain. A related utility SECTORDUMP, creates
a formatted file suitable for printing.
5. CONVERT by T Bone 22. Version 1.4 is current.
Freely available to the public.
6. ARC is available for both 64 and 128 modes.
It is a shareware program by Chris Smeets. |
A
simple solution I devised was to write a short
program that would convert disk blocks to BASIC
DATA statements.(4) Searching through the disk,
I made notes to include the blocks containing
the directory entry (which would also include
the time, date, and structure data, and the pointer
to the file header), the file header, the program,
and if a VLIR file, the index and all of the records.
I then fed this data to the utility to produce
the DATA statements. The resulting DATA statements
were then appended to a companion program that
would write everything back where it should be
on another disk. This approach produced a file
which could safely be uploaded and downloaded
as a BASIC program and reproduce a complicated
GEOS file on the receiving end. The disadvantages
were that the process wasn't automatic enough,
and that DATA statements can require more than
twice as much storage as raw disk blocks.
