mrr@amanpt1.zone1.com (Mark Rinfret) (10/31/88)
Since MRBackup V2.4 has finally "hit the streets", I thought I'd drop a
line to let you know what's going on. First off, there is a shortcoming
in V2.4 which has always existed and which I intend to fix very soon.
Directories are not saved/restored with original creation dates and comments.
V2.5 will fix this. Other coming attractions:
Support for overlays - MRBackup has gotten a little too large. The initial
overlay strategy calls for separate Backup, Restore and Utilities segments.
Separate decompression filter/flag - Users have expressed a desire to suppress
decompression of certain files during a restore. I will address this by
adding yet another filter file and a menu flag "Decompress Files" to be
used during Restore operations.
Up to 16 bit compress/decompress, user-selectable (depends on available
memory).
ARPification - This may turn some users off, but I won't be providing an
option here. I think ARP has proved its survivability. If I can get it
to work with 1.3 AmigaDOS, I'm going to go with it (iff I can get 1.3!).
Going back to 4 colors - MRBackup currently uses a custom screen with 8
colors. It's a waste of memory. Though I will be reducing the number of
colors (default = workbench colors), I will add color support to the user
preferences (COLOR0..COLOR3 = <R> <G> <B>). Who knows? I might even add
a palette.
Tum-da-da-daaa! I'm going to add an AREXX port. This will allow users to
do neat things like timed backups, cycled device selection, hands-free
operation. I hope. I've just started learning all the ins and outs of
AREXX (got it last week) and it's really snazzy! Of course, to take advantage
of this feature, you have to go out and buy AREXX. I know, that sounds
wierd - get a $50 add-on to a $0 backup program :-). Fortunately, AREXX
stands on its own as an outstanding product and also integrates with a
number of commercially available products. Each week sees more support by
commercial developers. That's exciting!
One of these days, I want to switch from the slow AmigaDOS backup format
to a faster track-oriented approach. I just don't know how I want to do it.
I could maintain Amiga compatibility by using a "canned" disk format,
allocating one huge file to the entire disk, then using track-at-a-time
I/O. The file would probably be in a modified "tar" or "cpio" format,
perhaps "zoo" if I can get enough info (jbwaters - are you listening?).
The other alternative is to write a disk which is foreign to AmigaDOS. I
really don't want to do that. Got any suggestions?
Release of full source code - As you're probably aware, I put a price tag
on the source a while back. My motivation wasn't monetary gain. I just
wanted to discourage "collectors" (haha! - like me!) who get anything that's
free. I don't have time for it (Fred - how DO you do it?!?!) Not only that,
but I've always wanted the luxury of time to groom the source before the
world got to see what crummy code a busy hacker can create. I know what
constitutes good coding practice, I just don't always exercise those
practices on my part-time endeavors. Anywho, I'm currently working on an
"embedded documentation extractor" using AREXX and DME (thanks for the
feature, Kim - and of course, the editor, Matt!). As soon as I get one
small bug fixed, I'm going to make the time. Though many of you are
probably using Matt's "suplib", you may find a few useful goodies in the
collection (some mine, some from others) that I've compiled into a library.
For those of you who wonder if MRBackup is the only thing I do - NO IT IS
NOT! Unfortunately, it's the only thing I've done (other than the little
MRPrint program posted recently) that's mostly original and complete enough
to post to Usenet. I spend entirely too much time collecting "useful-
someday" gems from Usenet (even more time now, thanks to Bob Page's
splendid efforts) and in the customization of that software to meet my needs.
I'm also working in the background on an Amiga-based TIFF/IFF support
package, though progress on that is abysmally slow. I also have about
two years invested in a discrete event/continuous simulator which has its
origins in SAINT (Systems Analysis of Integrated Networks of Tasks). If it
ever sees the light of day, it'll be a pretty nifty product. On top of
all this, there's the job (exciting but demanding - unfortunately not
related to the Amiga ) and the family (3rd grandkid on the way and I'm not
40 yet!) and our church (did a 10 mile CWS/CROP walk for the hungry
yesterday - yeah, I'm proud of it!).
I hope this doesn't sound like whining. I really wish I could offer more
and participate in some of the interesting discussions being bandied about
in this group. Unfortunately, I'm one who likes to think about the issues
before responding. By the time I've thought about it, either someone else
has responded for me or the issue has changed (or I've forgotten what I
was thinking about) :-). I'm especially excited about interprocess
communciations and "open architecture" software. The Amiga shines above all
others in this regard - if its display could match the Mac-II's, I could get
people at work to listen to me. Oh yeah - we NEED resources ( the
kind Matt's been talking about), resource tracking and standardization of
user-interface thingies. I know - be patient, they're coming. Don't worry,
be happy (I love it!).
I'm a rather conservative poster and tend to "listen" a lot and "talk" a
little. I'm not likely to engage in frequent one or two line responses to
ongoing discussions, though I thoroughly enjoy reading the dialogue that
goes on here and in .tech (most of it, anyway :-). Thanks to all of you
who have shared your ideas/software with me. Thank you, C-A and associates,
for your very constructive participation. Mmmm...I feel warm all over.
Now I can go crawl back under my rock for another month or so :-).
Sincerely,
Mark Rinfret
--
< Mark R. Rinfret, mrr@amanpt1.ZONE1.COM | ...rayssd!galaxia!amanpt1!mrr >
< HyperView Systems Corp. Home: 401-846-7639 >
< 28 Jacome Way Work: 401-849-9390 x301 >
< Middletown, RI 02840 Hypermedia R Us! >