EarthSoft 5 Dumergue Avenue Queenborough Kent ME11 5BJ Hello, I'm Arcane Jill, bringing you more bits and pieces to look at and play with. Once again, I would ask anyone with a modem to upload all my stuff onto as many BBs as possible, and anyone running a PD library to include all my stuff. First, there's an article called "Known Bugs in Devpac 3". This is a tutorial on the life cycle of the common grasshopper, with a forward by Charles Darwin. (Only joking - actually it's about the bugs in Devpac 3). Since this is the assembler which is actually recommended by ACC, I think we should discuss these problems. That's not to say that Devpac 3 isn't the best assembler available - coz it is. Secondly, there's a CLI utility called WhereIs. As its name suggests, this little beast can locate any file. It has some pretty useful features, so check out the docs. (Modem owners please note - even games players could find this program useful!, so do spread it around). Thirdly, there's a proggy called UpdateCat, which can create and maintain a catalogue of your entire floppy disc collection. (WhereIs can examine this catalogue, and hence find a file without your having to stick hundreds of discs in one after another). Unfortunately, I have a small confession to make. UpdateCat is written in ARexx! (In fact, there's a good chance that Mark might refuse to include it because ACC is supposed to be machine code only. If this is the case, write to me with a disc and a SAE). I might get away with it, because UpdateCat enhances the behaviour of WhereIs (which IS written in assembler). The truth of the matter is that I wrote a "temporary" version of UpdateCat in ARexx just to get the idea working, with the intention of writing a more permanent assembler version later, but I just never got round to it. This does unfortunately mean that, for the time being at least, if you don't have ARexx you can't use UpdateCat. Sorry about that. I'll get the assembler version done one day. Fourthly, theres a short little program called ArpWild, which comes complete with source code. This is a proggy for WB2.0+ users who are fed up with having to keep typing #? instead of * when they want a universal wildcard. The ARP wildcards, commonly used under WB1.3, allowed you to use * as a wildcard, but AmigaDOS did not. Under WB2.0, AmigaDOS DOES allow you to use * as a wildcard, but this is not the default. To switch on this facility, you must set a flag, and this is precisely what ArpWild does. Despite its name, ArpWild does NOT require the use of arp.library. Some information for Mark. PowerPacker Patcher is shareware, and Michael Berg asks a $5+ shareware fee. I've sent you the documentation for it. It works in basically the same way as you've suggested, and Examine() is patched so as to supply the correct (uncrunched) file length. I have to confess, I have some reservations about this program, at least in its current form. Michael states in his documentation: "Thirdly, the DOS library patches aren't done according to the textbook (if there is one on this topic!). If you skim through the source, you won't find any calls to SumLibrary(). Its presence or absence seemed to make no difference whatsoever, so I left it out (what does it do, anyway?)." Of course, there IS a textbook on this topic, it's called "The Amiga ROM Kernel Reference Manual: Includes and Autodocs". The entry for SumLibrary() states quite clearly: "This call could periodically be made from some future system-checking task". The upshot of this is that PP is not guaranteed to work on future Amigas, which could periodically guru because the dos.library checksum is wrong. I also have some reservations about ANY program which uses removable patches. Patches are fine as long as they are permanent (at least until system reset) but removable ones have a few problems, and here's why... Suppose that two processes both wish to patch the same library function. Let us imagine that the ORIGINAL library vector jumps to address A. Now, along comes process 1 which patches this vector so that it now jumps to address B. This new routine may call routine A as part of its processing, and it will "remember" the address A so that it can unpatch. Process 2 comes along next, and it too applies a patch. Now the vector points to routine C. This routine may call routine B as part of its processing, and it will "remember" the address B so that it can unpatch. Now things start to go wrong. Process 1 decides to remove its patch. To do this it will repatch a jump to routine A into the vector. Any future calls to this library function will get processed by the original routine A. This means that the unpatch has had a side effect - it has removed BOTH patches in one go. As part of its cleanup, process 1 frees the memory allocated for routine B. The system then uses this memory for something else. We're getting close to guru-time now. Process 2 decides to remove its patch. It doesn't know that process 1 has already messed things up. It substitutes what it THINKS is a jump to routine C with a jump to address B. Of course, this is now a pointer to nowhere. Any future calls to this library function will cause the processor to start executing random data. Crash! So whose fault was the crash? Well, nobody's really. The problem is that there is no established system protocol for setting up removable patches in the Amiga's multitasking environment. The general problem is even more complicated than the above example. (What happens if you patch a disc-based library which then closes and expunges? What happens when that same library re-opens?). What is needed is a protocol which everyone agrees on and sticks to. I've been thinking about this problem for some time, but with no clear cut solution. Send your thoughts to ACC, and we'll see if we can come up with anything. But anyway - back to PowerPacker Patcher. A good program. It does work under WB2.0, even though its docs say it doesn't. It does slow the system down a bit (for instance, Examine() now has to read two disc sectors whereas before it only needed to read one). But I have a confession to make. Being a hard disc user, I seem to have plenty of space to save things, and most of my stuff is uncrunched, so I don't use it.