At last, this month we finally get round to PKZIP. However, recent 512 converts may be unaware of the capabilities of archiving software in larger systems than the BBC micro, so we'll start with an overall introduction to the topic.
First though, I must deal with a couple of other brief matters.
I won't be renewing Essential Software's PO box this year; it costs over a hundred pounds and really is no longer justified. From September anyone who wants to contact me or Essential Software should write to:
The second point is that for similar reasons, please note that in future all payments should be made payable to me personally. Now back to our main topic.
One of the most onerous tasks in any micro is taking regular and adequate back-ups (hands up if you always have perfect back-ups! Hmm, well you two are untypical).
One reason for poor back-ups is that it's a job which, ideally, is a complete waste of time. More often than not it is of course, which reinforces that attitude. That, I'm sure is one factor, but it must be admitted that for the 512 Acorn didn't do much to make life easy. They didn't for any of their systems for that matter, but at least in the BBC the amount of data isn't usually huge, so simple disc copies do offer an adequate method. Unless you have a winchester, that is!
So far as I know, and the numerous users who've asked me about it, there is no convenient, reliable and efficient method of backing up a winchester in ADFS. Indeed in terms of standard Acorn offerings the situation is the same for the 512. If anyone knows differently I'd be interested to hear about it and pass it on.
I did try BACKUP a very long time ago, but it proved to be consistently useless, just about the only thing about it that was consistent. It doesn't just fail to work, if you try to use it there's no way of guessing how far it will get before it fails and which randomly selected error it will produce this time. I'm not sure whether BACKUP itself or the ADFS is at fault, but I'm not over impressed by ADFS either. The stand-alone version for the model B and B+ is truly dreadful, although I presume the Master's MegaROM versions are rather more reliable.
Happily, in DOS, the situation is much better, and there's quite a number of options. Given that DOS files tend to be so much larger than BBC files it's just as well, but recent PC methods are of no use for the 512.
Most business users of PCs these days employ a tape drive for back-up. These are adequately rapid devices, usually driven by automated software, so that backing up a couple of hundred megabytes or so can be left to run on its own when business is over for the day.
For non-stop operation on network fileservers, with ever falling hardware costs, RAID systems (multiple duplicate hard drives) are now the norm, again normally with tape backup. Even so there's a huge number of individual PC users who still use floppy discs for back-up. For limited amounts of data they're reasonably cost effective and, so long as you keep a duplicate of each back-up disc, they're adequately reliable too. Of course a few years ago everyone used floppies for back-up, so basically successful backup software has been around for some time, is thoroughly developed and highly reliable.
Low-level access to disc hardware isn't needed for backing-up or archiving as it often is in 'clever' disc utilities; standard DOS filing system calls are quite sufficient for most back-up/archiving programs. As a result the majority can be expected to work well in the 512, even on 800K discs. Since even the DOS partition of a 512's winchester looks like a standard drive too, hard disc files can be usually be backed up by the same software.
The main feature of most backup systems is data compression, the purpose of which is simply to cram more data onto the back-up medium than would otherwise fit. If you've used only an 8-bit machine like the BBC micro in the past you won't be familiar with this process – 8-bit machines just aren't up to the job, particularly in terms of speed. Appropriate compression methods require manipulation of units of data varying in size between 8 and 16 bits, not easy in an 8-bit system, plus a lot of large table indexing, something else that 8-bit machines aren't good at.
The prime benefit of data compression is that it can considerably reduce the amount of back-up media, but there are other gains too. For example, if you compress data to say, half its original size, not only do you get twice as much on a disc, but reading or writing a given amount of it is effectively twice as fast. In the 512 either your back-ups are on floppy or you don't have any, so speed is just as important to me as reducing the number discs. Another plus, at least in the software I use, is that the compressed data has numerous integrity checks built in so you can be sure that recovered data is reliable.
Those of you who recently had a copy of PCCE from me will know that it was delayed because I helped David Harper to eliminate a conflict which would affect hard disc users. Unfortunately, the way I discovered the problem was by the total corruption of the FAT on my hard disc (twice in one weekend, Grrrr!).
Some of you probably know the feeling when you see that wonderfully explicit message 'Outside file on channel 57' as you try to boot the 512. In case you've wondered, it means the FAT is directing the ADFS file pointer to somewhere outside the partition (itself an ADFS file) as the 512 tries to load DOS Plus. It's at this point that you reflect on your optimistic approach to backups and vow (once again) to be more disciplined in future. There's nothing else for it, you have to reallocate the DOS partition and recover all (well, nearly all) the disc's previous contents from back-ups.
My partition is 25Mb. but contained only (only? Huh!) about 17Mb of data in at the time. Obviously using simple disc copies, even with 800K discs, this amount of data would require upwards of 25 floppies, the number depending on how big individual items of data might be. In the event, thanks to data compression I was able to recover (most of) the data from a dozen 800K discs.
Of course not all files can be compressed; some are much better candidates than others. Text is usually very compressible, most programs, particularly .EXE files, are less so. Graphics files present a special case – some (e.g. simple bit-maps) are extremely compressible, while others are effectively already compressed by the application that produced them. These could even grow in size if you compressed them again, so compression software should check for this and store such files as they stand.
The extremes of compression performance are fascinating. If anyone is looking for a programming project to while away the coming winter nights I recommend data compression. You might recall that I wrote a compression system a few months ago, but despite the fact that I designed and coded it from 'scratch' I still don't entirely understand how the de-compression works. At its best my program compressed one 33K test file into less than 256 bytes while random samples of text averaged 50 to 75%. At the other end of the scale, much over 5% was good for most EXE files. My routine may not be the best ever written, but such varying results are representative of what to expect from any compression system.
OK, data compression is a good idea, but what program should you use?
PC-Tools, which I've mentioned before, has a back-up system which offers various degrees of compression balanced by a small trade-off against speed, but I must admit I've never tried this feature myself in the 512. I use an old version of PC-Tools, version 5.5, and almost all the system works well, but I doubt this is as true, if at all, for recent versions. For what it's worth I've seen versions 7 and 8 in action, and I don't like the screens as much as earlier versions either. If you try PC-Tools buy an old version. You'll need a hard disc to store the full system though, as it's not really intended for floppy users.
I also know of a couple of 512 users who use Flexi-bak Plus, a very successful U.K. written shareware program for DOS back-up, and users are very happy with it. However, this is another I've never tried myself and I can't advise on versions if recent ones don't suit the 512. What I would say is that from its reputation alone Flexi-bak Plus is well worth a look if you're in the market for a DOS backup system. Since it's shareware the cost of evaluation is minimal.
The system I use for back-up is PKware's PKZIP This is also shareware and is the successor to PKware's earlier system, PKARC, which served the same purpose until ZIP replaced it. There's little doubt that PKware have virtually made the task of archived data compression their own, PKZIP is the standard tool for DOS data compression, as was PKARC before it.
All versions of PKZIP up to and including the latest, 2.04G, are backward compatible, that is to say that they will unzip data from archives produced by all previous versions of PKZIP However, an important point to note is that PKUNZIP will not extract data from PKARC archives – you still need PKXARC for that. You'll still come across ARC files, in some shareware issues for example, but PKXARC usually will be included on the disc in such cases. If not, the only solution is to find and keep a copy of PKXARC yourself, or PAK mentioned below.
There are a few other compression/ archiving systems which offer broadly similar facilities to PKZIP, LHarc is a well known and, by some, preferred example. Others you might try include ARJ which has some unique options and PAK which can handle .ARC and .ZIP files as well as its own .PAK archives. These too are shareware, as indeed are virtually all such tools unless they're part of a larger utility package such as PC-Tools. This is one area where shareware authors 'got in' first and have done such a good job that most commercial software publishers decline to compete.
Obviously the system you choose might be any of the above, but I can only recommend PKZIP based on my own experiences. I've used PKZIP and PKARC before for many years with no problems whatsoever, apart from an occasional faulty disc which of course is nothing to do with the archiving program.
There is one criticism I'd accept of PKZIP (and PKARC too) which is that the command line syntax does tend to become a bit obscure once you leave the simplest operations behind. This complexity is partly a function of the fact that PKZIP has a very extensive range of options, but equally because of performance objectives.
As soon as you run the program you'll realise that PKZIP is all about speed and efficiency above all else, in which it is certainly impressive. Fancy menus and interactive selections are generally counter productive in this context, so rather than offering any sort of dialogue to allow you to select options these must be specified in the command line entry.
As it stands PKZIP can be quite daunting to the new user. In fact despite my unreserved recommendation of the software, I doubt that anyone, including those who wrote it, know how to use all the switches and options it offers without checking again first. All is not lost though. Also in shareware are a number of 'front-ends' and utilities which aim to make PKZIP more friendly and easier to use.
Equally, although I use some of the more complex options for my back-up and recovery procedures I can't remember off-hand what they are, but it doesn't matter. The relevant instructions are in two batch files on each of my backup discs, one called SECURE.BAT, the other RECOVER.BAT. The names may not be very imaginative, but they are easy to remember and they work when I need them when I need them, which is all that matters.
Next month we'll explore some of the options in PKZIP (and UNZIP) so as to allow you to set up a reliable, largely automated back-up and recovery system. The only problem then is keeping that up to date!
Any shareware house will be sure to have PKZIP, so you'll have plenty of time to get hold of a copy if you don't already have it but feel like giving it a try.