patth@dasys1.UUCP (Patt Haring) (07/30/87)
----------------------line eater food----------------------------------
In an effort to get an Apple ][ text and binary file exchange going,
and maybe allow us to have a newsgroup: comp.sources.apple; I've
previously posted BLU (Binary Libary Utilities) and am now posting
the documentation for ALU (Apple Library Utilities). After
reading these files we can all discuss the BEST way to go about
exchanging files, after we decide which "standard" to use - then
everyone will have either the BLU or the ALU to pack/unpack the
files.
Here, then, for your further information is the documentation on
ALU:
A)pple
L)ibrary
U)tility
A Users Guide
-------------
copyright (C) 1986, Donald R. Elton
Living Legends Software
1915 Froude St.
San Diego, CA 92107
(619) 222-3722 [ voice ]
(619) 281-7222 [ modem -- login: guest ]
ALU - Apple Library Utility
===============================
The ProDOS version of LU and its UNIX, PC-DOS and MS-DOS equivalents
are based upon the CP/M library utility made popular by RBBS's and RCP/M sys-
tems around the world. These library utility programs are used to maintain
and manipulate a large data file (commonly known as an LBR file) made up of
two or more program/data files.
Library Files
=============
Most library files contain two or more program or data files that are
somehow related to one another. By "packing" these files into one large file
it makes it easier for other computer users to download all of the necessary
modules and information without having to worry about whether they missed out
on a vital portion of your package. Once the LBR file is downloaded it can be
"unpacked" (seperated back into the original files) with another LU utility
and used by the recipient. The following example shows how useful a program
like ALU can be:
ABC.SHEET -----------------\
ABC.GRAPH -----------------\\
ABC.A/R ------------------>> ABC.DATA
ABC.A/P -----------------//
ABC.G/L -----------------/
original files from the resulting LU file
The ABC Company ready to be transmitted
The only requirement is that both the sending and receiving parties have a
libary utility program to pack/unpack the files.
The common denominator of all LBR files is that they have the same
structure, regardless of the operating system used when the LBR file was
created. This version of ALU has ProDOS-specific enhancements that are
compatible with the LU command found in the Extended Command Processor (ECP),
and is upward and downward compatible with the versions of LU used on other
computers and under other operating systems.
Using ALU
=========
Since ALU allows the "packing" of many files into one large file, it
lends itself to manipulating multi-file programs. For example, many programs
may need several utility modules, help files and printer drivers. Rather
than have to search through an entire Data Library for all the files you can
download just the necessary LBR file and "unpack" it. Packed files generated
by ALU use the ProDOS file type LBR ($E0).
Note that this version of ALU does not check the type of library file
before attempting to manipulate it. Use of the LBR file type is optional at
present to avoid confusion with other ProDOS-based programs, although Apple
Computer Inc. has reserved $E0 in the ProDOS FILE_TYPE table as the LBR file
identifier.
LBR files generated by ALU contain one or more ProDOS or alien files
and a simple directory. Whenever an existing library is changed (if an indi-
vidual file has been changed or deleted) the library requires "reorganizing".
More on this later.
ALU operation is quite simple. There are only a few commands, and
each is described in the following sections.
Creating An LBR File
====================
ALU must be run from ProDOS Basic. After starting the program by
typing "-ALU" or "BRUN ALU" the following prompt will be displayed.
ALU:
You should then enter the command string in the following format, or just
press the RETURN key to exit ALU. The syntax for commands given to ALU
follows this pattern.
<library file name> <command> { <optional filenames> }
For example:
MYFILE.LBR U /PRODOS/FILE1 /PRODOS/FILE2 /PRODOS/FILE3
would create an LBR file named MYFILE.LBR containing the three files FILE1,
FILE2 and FILE3 from the disk /PRODOS.
MYFILE.LBR T
would list all the files contained within the LBR file MYFILE.LBR.
ALU Commands
============
All ALU commands are a single letter. Only one command can be entered
at a time.
A Unpack all files from the LBR file. This is the same as the E
(extract) command, followed by all the file names. This is much
easier is all you want to do is remove all the files.
Q Unpack all files in prompted mode.
T List all files contained in the LBR file. Each filename is listed,
along with the size of the file in hexadecimal bytes. If this
library member was added to the LBR file by the ECP version of LU or
this version of ALU then the ProDOS file type will also be
displayed.
L Same as T.
E Extract a file from the LBR file. The file(s) to be extracted are
entered after the LBR file name. Each file will be extracted and
copied to a disk file of the same name. Note that only a copy of
the file is extracted, the original library is unchanged by this
command.
U Update a library. This is also used to create new libraries. File
name(s) are entered after the LBR file name, and each file is added
to the library. Any file of the same name already in the library
will be delted first, otherwise just added. Updating a library
always increases the size of the library as new members are always
appended to the end of the file. Please read about reorganizing,
below.
If the library file does not exist (creating a new one) then the
library will be created with 32 file slots.
D Delete a file. This just marks the file within the library as
"deleted". The library file will not change in size; it does not
remove the data contained by the file. See reorganization, below.
R Reorganizes the library. All free space (from deleted files, or
existing files that were Updated) is freed up, and the LBR file
generally becomes smaller. Should be used after a Delete or Update
command. Creates a temporary file called ECP.LU.....TEMP, therefore
you should not use this file name elsewhere. Note that a lot of
disk space is needed temporarily by this program as it basically
copies all of the active members of the original LBR file into the
temp file above. If the copy is successful then the old file is
deleted and the temporary file is renamed as the new library file.
Reorganizing LBR Files
======================
The structure of an LBR file (as described below) is very simple.
Because of its simplicity, files that are deleted or changed still consume
space within the LBR file. Any LBR file must be "squeezed" whenever the
library is changed.
Deleting a file merely marks the file as "deleted" -- it DOES NOT
remove data contained in the LBR file; therefore, the library must be re-
organized. This results in the creation of a new library, the copying of
all active files to it, and the removal of all deleted or replaced data.
GENERAL RULE: Reorganize after deleting a file or updating an existing file.
LBR File Structure
==================
The LBR file contains a simple directory at the start, followed by
all the data contained in the file. New files are added to the end of the
LBR file. The directory entry for each file points to the data and contains
the length and other ProDOS directory information (if the member was added
with the ECP version of LU or this version of ALU).
Each directory entry is:
00: file status (00 = active, FE = unused, FF = deleted)
01: 11 character filename
PLEASE NOTE that file naming and storage conventions are not the same between
CP/M, MS-DOS, UNIX, and ProDOS. The former three operating systems can have
up to 8 characters in the filename, followed by an optional 3 character arbi-
trary file extension. A CP/M version of ALU (usually called "LU.COM") would
be stored as:
"LU______COM" ( "_" designates a space )
The ALU program will not change this file name format in an existing LBR file
or in LBR files that it reorganizes. If you extract or list the members of
this LBR file the above file name will be displayed as "LUCOM". Some MS-DOS
files may start with digits; for example, "1.BAT". This filename is invalid
under ProDOS, so ALU will append a "P" to the front of the file name in an
attempt to create a valid ProDOS filename ("P1BAT").
12: 16 bit offset to start of data (in 128 byte sectors)
14: 16 bit data length (in 128 byte sectors)
-----------------------------------------------------------------------------
NOTE that the fields that follow are NOT in the standard ALU specification,
but are added to better support Apple ProDOS files. The presence of the
following data should not affect the operation of ALU versions running on
other operating systems.
16: ProDOS Access bits
Upon extraction, all files will be UNLOCKed.
17: ProDOS File type.
18: 16 bit ProDOS auxiliary file type.
20: 16 bit ProDOS date of last modification.
22: 16 bit ProDOS time of last modification.
24: 24 bit ProDOS End of File mark
31: 16 bit value $A2A2 (for Apple 2 of course!)
This tells ALU that the file contains valid ProDOS directory information
in bytes 16-32.
-----------------------------------------------------------------------------
Since the original program was written in BDS C, all file offsets and
lengths are in multiples of 128 bytes (the CP/M "sector size"). ALU multi-
plies these values by 128 before using. All file sizes are rounded up to the
nearest 128 bytes.
The offset is the location of the data for the file, relative to the
start of the LBR file.
The first directory entry is the directory itself. The filename is
always blank, the offset is not used, and the length is the length of the
directory.
Peculiarities
=============
A side effect of the original design: all files are rounded up to the
nearest 128 bytes. This does not matter for most files, but some files -- a
spreadsheet, for example -- will not work unless the size is exactly right.
Files added to the LBR file by ALU will not have this problem since ALU keeps
up with the programs' correct EOF (end of file) position.
If you're using ALU to archive files it's a good idea to use the SQ
utility (under development for ProDOS ECP) to squeeze the files before placing
them in a library file. Squeezing a LBR file can be done, but may not be
reliable. Best to SQ first, then run ALU.
An additional note: due to the methods used by CompuServe to store
files, none of the LBR files in their Data Libraries are squeezed. This seems
to be unique to CIS only, and does not necessarily apply to files on bulletin
board systems.
Further Information
===================
ALU is distributed as a Public Domain program by Living Legends
Software. We strongly encourage our fellow Apple users to spread this
program around to their friends and to other BBS systems so that others can
enjoy the benifits that come from combining numerous files into one large,
easy to handle LBR file.
Questions regarding ALU can be forwarded to us in San Diego, or you
can leave E-mail on:
CompuServe
--
Patt Haring UUCP: ..cmcl2!phri!dasys1!patth
Big Electric Cat Compu$erve: 76566,2510
New York, NY, USA MCI Mail: 306-1255; GEnie: PAT80 spgspros@CLARK-EMH.ARPA (08/01/87)
I did't get the end of the library utilities source could you send anotherto my e-mail.
thanks
jimmyspgspros@CLARK-EMH.ARPA (08/08/87)
could someone E-mail me the program Apple Library Utilities(ALU).
The ProDOS version of Lu.exe
Thanks
Jimmy........