|
GEOS files are a new type of construction - much
different than other types of files that existed prior to
GEOS. Special handling is required to prepare GEOS files
before shipping them off along the phone lines. The tools to
prepare GEOS files are well developed, making file transfers
highly reliable.
One of the first things I tried to do with GEOS was to
write some utilities that would work with it. I finally
settled on a project - read a standard SEQuential text file
and output a GEOS Text Scrap. Then I would be able to take
files I created with SpeedScript, convert them to Text
Scraps, then paste them into geoWrite or geoPaint documents.
I had a lot of good information on SEQuential files, but no
information on Text Scraps. Examining GEOS disks with a disk
editing utility revealed a lot of information about GEOS
files.(1)
|
|
|
The directory entry for a GEOS file has more data than
a standard file entry. The GEOS entry has been expanded
to provide room for time, date, and file structure data,
and a pointer to a block called the file header. The file
header contains, among other things, the file's icon that
you see while using the deskTop.
So, after a week or so of hacking, I had a program
ready.(2) I wanted to upload this program to a local BBS,
but before I tried, I was already aware I had some
problems to solve first.
GEOS File Structure
Before GEOS, uploading and downloading a file was a
clearly defined process. You got the telecommunications
software ready on the sending and receiving ends.(3) You
told the receiving end to expect a file named "OLDFILE"
and you ready your software to start sending "OLDFILE."
Commodore DOS finds "OLDFILE" in the directory
and sends the file.
|
|
|
Normal
Commodore DOS files are linked sequentially - each block
following another.
|
|
|
|
Take a look at the simplified diagram of the structure
of a GEOS VLIR file. VLIR stands for Variable Length
Indexed Record. It consists of multiple segments, called
records, which can be of any length. One block is called
an index. The index is a table of pointers to the
records. There is also the info block and the time/date
data following the directory entry. The only part of this
file Commodore DOS is able to locate from the directory
entry is the index block. If you use the same
telecommunications software to send this file, you're in
for a big disappointment. It'll only transmit one block,
the index block.
|
|
|
GEOS CONVERT
 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.
|
|
|
|
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.
|
