NOTE: In order to save menu space I have appended the files SHAREWARE.ANGER! COPYRIGHT.NOTICE PP.HISTORY.DOC To this main PP.Doc file. If you wish to read them (and you should do) Then flick down the file to the end. Mike иииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииии Powerpacker Patcher Version 1.4 Copyright (C) 1991, Michael Berg All Rights Reserved иииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииии INTRODUCTION Ever get tired of having to use PPMore or equivalent to view all those Powerpacked datafiles you have scattered everywhere? Or maybe PPMore doesn't do exactly what you want? Does your favourite ANIM player support Powerpacked anim-files? No? Well, this program should solve all your problems. It makes PowerPacker datafiles act completely as if they were normal files. In fact, with this program up and running, there is not one thing you can do with normal files, which you cannot do with Powerpacker datafiles. Regardless of what programs you are using. иииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииии RUNNING PP Powerpacker Patcher runs from either the Workbench or the CLI. If you use it from CLI, you need not RUN it, because it detaches itself from the current CLI process as soon as it is activated. If you run PP "as is", with no arguments, it will use RAM: for its background file decrunching. You may supply PP with one argument, describing the path it should use instead. You may designate any path (device or directory) you like, but keep in mind that PP will be writing and reading a lot in that path, so, if possible, use a fast device (RAM: or DH0:Temp/DecrunchDir). It is possible for you to specify PP's temporary path from the Workbench, too: Click (down, up) on PP's icon. Then press and hold either SHIFT button, and double-click (2*(down, up)) on the disk or drawer icon to be used for background file decrunching. PP will let you know if you made a mistake during startup. Since V1.3, PP has been told to be suspicious towards certain chances in the DOS. DOS is usually the primary target for link-vira, and with PP running it can be hard for a viruschecker to establish if a virus is active or not. So PP now does its own, very simple, virus checking. Read more about this in the virus section below. Besides the default path, you may give an option to PP, which tells it NOT to do the basic virus checking. The option may be given to PP either as a CLI argument like this: 1> PP DH0:Mydir/decrunchtmp -N or as a "Tooltypes" item in PP's icon, if you use PP from Workbench. The '-n' (Nocheck) is case insensitive and may appear anywhere on the command line. Further, another switch has been provided to activate the virus checking, even if this is actually the default. The switch for this is '-c' (Check). 'Tooltypes' switches look a little different: CLI argument Tooltypes equivalent -------------------------------------------- -c or -C CHECK -n or -N NOCHECK Switches are "permanent". Running PP again with another option won't work. Once Powerpacker Patcher has hooked itself into AmigaDOS, it will display a small banner message to show you that everything went all right. Powerpacker datafiles will begin to "act" as normal files as soon as PP has been activated. Most programs, commercial and PD, will be fooled into thinking that a powerpacked file isn't powerpacked at all. When they attempt to load such a file, PP will interfere and decrunch it before passing the file along to the calling program. иииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииии STOPPING PP Simple! Just re-run PP and the in-memory version will terminate immediately, if possible (see "caveats" below). DOS will be restored to its original state, and Powerpacker datafiles will again appear as ... Powerpacker datafiles! Note: PP silently ignores any arguments (CLI or Workbench) if another PP is already running in memory. иииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииии YOU'LL NEED... No, no ARP or anything like that. I just thought that I should mention that PP no longer needs 'powerpacker.library', like Pre-1.4 versions did. иииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииии MEMORY NOTICE If you use RAM: for background file decrunching then, to decrunch any powerpacked datafile, you'll need an amount of memory equivalent to what the file unpacks to, plus an additional 10k (112k for a file that unpacks to 102k). Older versions of PP would temporarily want more than twice this (one image in memory being written completely out to RAM: and then freed). PP V1.4 uses a highly intelligent "end-to-end fragment" allocation scheme that allows it to free the memory image WHILE the it is being written out to a file in RAM: To keep it simple: With PP 1.4 you can now load and decrunch much larger files than you could using older versions. Of course, all of this only applies when you use a memory-based device like RAM: for background file decrunching. For other types of media, it only means that PP returns the memory it needs (for decrunching) to the system faster than pre-1.4 versions. If PP can't find the memory it needs to unpack a file (or if its temporary path fills up), it will simply return the original (powerpacked) datafile to the calling program. This is potentially a bit dangerous, so in these low-memory situations, you may get some "READ ERROR" messages from whatever programs you are using. DON'T dispare - these messages have no other meaning than to tell you that memory is too low. Close some windows, terminate some programs, delete some files from RAM:, or anything else you can think of. If you get "READ ERROR" messages even if memory is NOT low, then it's time for you to conduct a lengthy session with your favourite disk-editor. Because then the message is for real. ;^) иииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииии SAMPLE APPLICATIONS Well, what is it all good for, then? Here's a small list just to get your juices flowing: o Viewing Powerpacker datafiles (text) Simply use the TYPE command - or bring the text directly into your favourite editor (Memacs, TxEd, CygnusEd, whatever) o Viewing Powerpacker datafiles (pictures) Load powerpacked IFF pictures directly into DPaint (or equivalent) o Icons Yes, that's right. Go ahead and crunch all those icons. Workbench will never know the difference. Remember to retain the names of the icons - DON'T use ".info.pp". Workbench recognizes icons as files with a postfix of ".info". o Include files (header files) Why not go ahead and crunch all your include files for your compiler? (believe me, it's worth it!) o Try to "LIST" a directory containing powerpacked files. Pick one out and remember the size of it. Now "LIST" that particular file. You will see that the size of your file has seemingly grown. Why? The first LIST gives you the actual size of the file. The second one gives you the size of the decrunced file... (this is really a side effect in PP, but quite useful in many situations) o Another side effect. To decrunch a file, simply COPY it from one location to another. The target file will be decrunched. o Much more There is no end to it. ANY kind of datafile may now be crunched, because it will retain its functionality 100% as long as PP is up and running. Script files for AmigaDOS, *.config files for programs that support config'ing, *.doc files for public domain disks, IFF pictures for DPaint, rexx scripts, makefiles, sound samples, printer drivers -- YOU NAME IT! иииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииии THEORY OF OPERATION It's okay to skip this section if you don't care for ugly programming details... It's simple, really. PP juggles with a few DOS library vectors, so that future calls to certain DOS functions are rerouted through PP. When a file-open request arrives, PP looks at the file in question in order to determine the filetype. If it is a special file (e.g. CON: or NIL:) a filehandle from the original DOS Open() function is returned. Otherwise, the file is decrunched to a memory block, which is then flushed into a temporary file on the RAM disk or in whatever directory you supplied PP with when you started it. A pointer to this new file is then returned. PP is, of course, intelligent enough to remove temporary files as these are no longer needed. Otherwise the temporary path would soon get crowded with squillions of useless files. If PP sees that the temporary file has been changed between the Open and the Close call, the file is rewritten over the original file, if possible. The result is, of course, NOT a crunched file. Future attempts to Examine() a powerpacked datafile will return the size of the decrunched file in the FileInfoBlock, and not the size of the Powerpacker datafile itself. Why? Imagine an editor trying to load a text file. It does an Examine() to get at the filesize. Then it allocates just enough memory to hold the file. It then loads the file into that memory area. Well, that just won't work if the filesize it receives from Examine() is about 50% too small. Keep in mind that as soon as an Open() attempt is made, the file is decrunched, and will thus have a completely different filesize! The above is also why some programs may report read errors in low-memory situations. Examine() has told them that the size of the file was, say, 100k, and yet they can read only 50k (if the crunch gain was 50%), which is the size of the crunched file. This is considered to be a read error by some programs. I have made PP as system friendly as possible with respect to memory requirements. The "end-to-end segment" allocation scheme allows PP to free parts of an allocated memory block, namely the parts it has already written to a file. This is achieved by first allocating the entire block of memory, and then, inside a Forbid()/Permit() pair freeing the memory again. The block is then reallocated (using AllocAbs()) in small, consequtive 10k chunks. This gives the caller a pointer to a memory block that he can free in equally sized chunks. I tried Nico's approach, which said that is was okay to do something like this: m = AllocMem(1000 bytes) FreeMem(m,first 16 bytes) m += 16 FreeMem(m,1000-16 (the rest of the block)) But that will cause tremendous problems ("free twice" meditations) in low-memory situations. (Hope Nico is reading this, so he can fix his ppLoadData()! -Nico, read "fragalloc.c" and "myPPLoadData.c") For further details on the techniques involved, please read the sourcecode -- it's included for just that. You will probably notice that the program is all in one piece. I am profoundly against "handlers". This barbaric dissection of programs can make everything much more confusing and your L: directory a heck of a lot more crowded. Techies will argue, that the reason for splitting your code in a startup and a resident (the handler part) module is obvious; this way only relevant code stays in memory and the startup code terminates at once. Well, the startup code part is rarely much more than a few K (often much less), and I myself gladly sacrifice that small an amount of memory, if this means that I don't have to copy two files for every executable I have. Handler code is only for *exceptional* programs, where NO OTHER solution seems acceptable. иииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииии CAVEATS Yep, there are a few of these, too. First of all, you have to remember that PP is a one way street. This means that loading Powerpacker files will work fine, but trying to save them again will result in a non-crunched file. The powerpacker.library sorely lacks a crunch function. (Note: At this point, I'm not considering Nico's new Powerpacker V4.0b library) Secondly, when working with crunched icons (or, for that matter, any other type of crunched file), there is a nominal performance reduction caused by the decruncher. Don't expect crunched icons to pop up at the same rate as they used to, or crunched include-files to get included as fast as they used to. In pre-1.4 versions of PP, this effect could be quite annoying - especially for diskette based, highly fragmented files. V1.4 & later, however, use a much more efficient algorithm. Use of B.A.D. and Addbuffers is still highly recommended, though. Thirdly, when you want PP to terminate, you may get a funny message back, saying that it isn't possible to stop the in-memory PP right now. When you get this message, it is because some other program is currently using internal procedures in PP. Wait until all disk activity has been completed, and then try again. If some faulty program "crashed" before it could close all its files, or if it simply forgot to close them, you may not be able to remove PP at all. Further, if you are using other programs that patches the same DOS vectors as PP, you have to terminate these before PP can be terminated. If, for example, you have started PP and then SnoopDOS, you must terminate SnoopDOS before PP can be removed. PP will work happily with any machine configuration I can think of. It has been tested on an A500 using AmigaDOS 1.2, with .5Mb extra RAM fitted, but has also works happily with AmigaDOS 2.0. Further, it has been tested with programs such as "FragIt", "SnoopDOS", "VirusX" and "VirusChecker". I don't have a MMU, so no Enforcer checks have been made (and I don't think that it is even possible to test PP with Enforcer). иииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииии PP AND VIRUSCHECKERS You do have a viruschecker, right? Well, when you are using PP, it is quite possible that your viruskiller will report that a virus has found its way into memory. Don't be alarmed, this is quite normal. PP works because of library patching, and does in fact look a lot like a virus. PP hogs these four vectors: LVOOpen, LVOClose, LVOExamine, LVOWrite Right now I can't really think of any approach to make PP transparent to viruscheckers. But if at any time PP sees that someone has changed any of the above four vectors, it gets suspicious and displays a small message in a console window. This message only appears once, even if one of the vectors are changed yet again after that point. This behaviour is optional and can be turned off with the NOCHECK/-n flag. If PP says that your machine is under attack by a link-virus, don't you believe it. 99% of the time it is simply a harmless program that needs to patch the same vectors as PP. But, unless you know EXACTLY what is going on, you should rely more on a virus checker than on your own judgement. A link-virus is a very nasty and higly intelligent creature, and it WILL outsmart you in most cases. So be careful. PP is not much of a virus checker, agreed, but it does provide the basics. Future releases may possibly contain much more powerful virus protection mechanisms, so rest easy. Get in touch if you have suggestions on this. иииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииии KNOWN BUGS Erm.. none, as far as I can tell. However, don't try to remove PP's temporary directory while it is still running. If you do, PP will not work any longer (it won't crash your system, though, but it will act just like it does in low-memory situations -- see "READ ERROR" comment above). In pre-1.4 versions, the autodetaching was sloppy. If run from a script (such as your startup-sequence), the EndCli command would refuse to close the CLI window. Moreover, any messages printed by PP would appear after the CLI prompt, and that's just plain ugly. However, 1.4 and later fixes these problems. And now for the funny parts. There is a very strange bug lurking around somewhere in the Workbench. To test this, try the following (you'll need at least one external drive, or a hard drive): o Load Workbench o Start PP o Insert disks in DF0: and DF1: o Start any program from DF1: and keep it running. (Doesn't really matter what program it is, as long as it runs for some time) o Eject the disk in DF1: (Step 4 was to prevent WB from removing the DF1: icon when you remove the disk) o Click ONCE on DF0:'s icon o Press and hold either SHIFT button o Double-click on DF1:'s icon BANG! Workbench crashes (GOMF: "Code likely out of control") and summons the dreaded Guru dude. I discovered this peculiarity by accident, and immediately thought that PP was at fault. After hours of fruitless bug hunting, I decided to run SnoopDOS while performing the procedure outlined above once again. Without PP running, of course. And guess what. Workbench crashed once again. This can only be because of two things: Either, There's a bug in Workbench or There is the same bug in PP and in SnoopDOS There are pros and cons for both of these. If you try the procedure without anything funny running in the background (no PP or SnoopDOS or anything like that), Workbench doesn't crash, and does what you expect it to do. However, the chance that exactly the same bug should exist in two programs (by two different authors) is very slim. And SnoopDOS is considered to be a textbook example of a well-behaved program (PP doesn't do too bad, either ;^) Further, Workbench 2.0 does not exhibit this behaviour, so it is probably the 1.2/1.3 Workbench who's at fault. For now, I'm going to let the problem rest. It IS a borderline case, agreed, but it could potentially cause problems in other situations and other programs. My best guess is that WB is making assumptions about scratch register contents after certain DOS calls. This is a no-no, as you well know. If you have any idea what the heck is going on, don't hesitate to mail me (see address below). иииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииии UNKNOWN BUGS...? I've had reports from people who can't get PP to cooperate with ARexx properly. rexxarplib.library's getfile() has been reported to guru when PP is installed. If you have Professional Page you may also run into some trouble. It is hard for me to fix these kinds of problems, because it may not always be PP who is at fault. Further, I don't even have the software involved (ARexx, ProfPage, etc), so when these "inexplainable" gurus occur, just don't use PP for that particular purpose. At least not until I can find a way to fix things. During version changes, it is quite possible that I "accidently" fix some of the problems, so whenever you receive a new version of PP, try it out with your software again. You never know... 8^) иииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииии REMAKING PP I've enclosed a makefile suitable for Matt Dillons "DMake". Just CD to PP's home directory, and say "DMake". That's really all there is to it. Oh, by the way, remember to set CCOPTS to nothing before issuing the DMake command (the DMakeFile handles parameters for CC on its own). PP will then be remade using large code, large data & 32 bit integers. Large code & data, because other processes will be executing internal procedures in PP, which is virtually impossible using the small memory model. ( Sure it's possible, but I'm lazy! |^) ) иииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииии THANKS GO TO... Well, who other than Nico Franчois. Nico's powerpacker.library, and, for that matter, all the other powerpacker tools, are simply brilliant. Credit where credit is due! иииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииии FUTURE RELEASES Version 1.0 of PP was pretty much a beta release, and 1.1 didn't support all you 2.0 guys & girls. This version (1.4), however, should be free of nasty surprises. There's still a multitude of possibilities for improving PP. Some obvious choises: д More control on PP. Switching PP temporarily on and off while it is running. Possibly through hotkey combinations. д Option to specify multiple paths for file decrunching, such that if one fills up, the next will be used. д Maybe build in a screen blanking facility or PopCLI style hotkeys for starting a new CLI. Will this be useful, or will it merely interfere with the real PopCLI? Let me know. д Improving the virus protection mechanisms д Patching more DOS functions. DeleteFile() is a good one. This would enable to the user to verify the "dangerous" actions of a new program (a small autorequester: "ARE YOU SURE (blabla)"). д More on this: Turning PP into a simple virus protector as well. д Integrating PPLoadSeg and PP, as suggested by Arthur P pers (I am opposed to this proposition, however) д Anything else that YOU would find useful! The overall effect of this program is quite astonishing. I use it all the time. Try it - it is just fantastic to see how *.pp files act as if they were completely normal files! иииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииии SHAREWARE PP is shareware. As you know, this means that I would like a little something if you use it frequently. Something like $5+ (emphasis on the PLUS) will get you the latest two updates of PP, as soon as these are ready (more money probably means faster development...). Please read the file 'Shareware.ANGER' included in the distribution... иииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииии FLAMES If you find anything you (dis)like, mail me. You're gonna have to write to me actually using old-fashioned ink and paper, because I'm not yet in the modem business. If you can't remember how to hold a pen, get one of the tribe elders to show it to you. Anyway, here's my address: Michael Berg Sct. Peders Gade 24A, 2th 8900 Randers DENMARK (I expect to purchase a modem shortly, so be prepared for some real havoc on all those BBS's 8^) ) Have fun! Oh, by the way. I'm no good at drawing icons, and as you may already have seen, the icon for PP looks quite terrible. But how do you represent a program such as PP in a graphical manner? Please feel free to contribute any suggestions for what the icon for PP should look like. If I see something I like (data or merely ideas), I may even use it with future releases of PP. иииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииии __ /// __ /// \\X// AMIGA - There Can Be Only One ппп иииииииииииииииииииииииииииии иииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииии Copyright Notice for Powerpacker Patcher (This notice shall apply to all current and future versions of PP) Copyright This program and the related documentation are copyright. You may not use, copy, modify, or transfer the program or documentation or any copy except as expressly provided in this document. This program and the related documentation may be redistributed to and by public networks or individuals only in whole, and only for a basic fee covering the distribution expences. The PP program and the related documentation must not be distributed as part of any commercial product without a written permission from the author of PP. Special licenses are available for people or organizations that wish to distribute the executable 'PP' program alone, as part of their PD distribution disks. Program Disclaimer & Liability This program is provided "as is" without warranty of any kind, either expressed or implied, including, but not limited to, the implied warranties of merchantability and fitness for a particular purpose. The entire risk as to the results and performance of this program is assumed by you. Should the program prove defective, you alone assume the entire cost of all necessary servicing, repair, or correction. Further, the author of PP neither warrants, guarantees, or makes any representations regarding the use of, or the results of the use of, the program in terms of corrections, accuracy, reliability, currentness, or otherwise; and you rely on the program and results solely at your own risk. The author of PP can in no event be held responsible for any data or information which may be lost or rendered inaccurate by PP, even if the author of PP has been advised of the possibility of such damages. Summary: In a nutshell: Don't change PP. Don't distribute PP for money, and only distribute it in full (program as well as documentation). It's okay to use it, just don't blame me if it does something awful to one or more of your files. Okay? In this document you will find a list of versions and comments to each of these. Below the list you will find a more detailed description of whatever changes there are in the latest version. иииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииии Program history (latest version listed first): 23 DEC 1991 - V1.4. Fixed some minor inconsistencies concearning list manipulation (potential Guru attractors!) Better autodetaching. Now uses Eddy Carrol style res() No more need to press RETURN to terminate the WB banner. Dropped support for encrypted datafiles. Who use it anyway? Made PP a lot more robust. Should cope much better with ackward situations such as a request to terminate PP while another process is still executing internal PP code. Still a few things left to do.. MAJOR ENHANCEMENT: No more need for powerpacker.library! Uses optimized version of Nico's assembly language decrunch routine. MAJOR ENHANCEMENT: More than 80% faster file loading! (uses customized ppLoadData()) Discovered strange bug! Read .DOC file, please! Much better memory management - load & decrunch larger files Simple virus warnings иииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииии 22 AUG 1991 - V1.3. Made PP behave more politely to the OS. It now works with most patcher-type programs, including VirusX. Thanx Ray! иииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииии 18 AUG 1991 - V1.2. Added support for AmigaDOS 2.0 иииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииии 08 AUG 1991 - V1.1. PP now works as an on/off switch. Added more error messages. Added workbench support. More intelligent file loading. Temporary decrunch path now selectable. Made detach-startup optional (through #def's) иииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииии 08 JUL 1991 - V1.0. Initial (beta) release (PP would open a window for you to close when you no longer wanted it to be active. File loading was crude and slow, and PP was only able to use RAM for back- ground file decrunching. Oh, by the way: PP didn't have any error messages either ... ) иииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииии Changes in Powerpacker Patcher Version 1.3 -> 1.4 A. All list manipulation calls (AddHead() & friends) are now sandwiched between Forbid() and Permit() calls. B. Pre-1.4 versions used the Aztec autodetach code. It worked, but had some nasty side effects. For one thing, EndCLI refused to close the window. Secondly, if anything happened during startup, and PP wanted to print something, it would appear after the CLI prompt, which was not a pretty sight. V1.4 uses a C'ified and debugged version of Eddy Carrols res() function. Now PP autodetaches correctly (and when it is good and ready for it!) C. I've had letters from people complaining about this. Now, any Workbench messages displayed by PP will disappear after a few seconds. D. During my work to enhance the overall performance of PP, it soon became clear that encrypted datafiles would be a big problem. So after some consideration, I decided to discontinue the support for encryped datafiles, as of PP v1.4. If anyone out there has some very strong arguments against this, I'm all ears. E. Older versions terminated more or less at once, without any considerations to the fact that other processes could quite possibly still be executing internal PP code. 1.4 should cope much better in such situations. Further, PP now refuses to terminate if some other process has repatched its DOS vectors. F. It turned out that Nico's .fd file for powerpacker.library was incorrect. I simply couldn't get his pp_DecrunchBlock to work! So I removed all references to the library from the program, and implemented Nico's own assembly decrunch routine (v2.0). I made a few optimizations here and there, and PP now decrunches faster than Powerpacker itself. Nothing too radical - I figure it to be about 15% max. G. This is a major one. Older PP's used the in-library ppLoadData(), which was actually a major overkill. I finally pulled myself together and wrote my own ppLoadData(). It is customized to suit the special needs of PP, and so saves a lot of Seek()'ing and file opening/closing. A few basic tests of mine showed that PP v1.4 was about 80% faster than previous versions. With WB2.0 the effect is even more outspoken. H. This bug is possibly a Workbench bug. Please read "PP.DOC" (BUG section) to find a more detailed description of this peculiarity. I. Also a major enhancement. For RAM based decrunch-paths (RAM:, VD0:, RAD:, RRD: & friends), memory requirements are now only 10k more than what a file unpacks to. For a file that unpacks to 100k, PP & RAM: combined require some 110k (peak). Older versions would temporarily require more than 200k to do this. J. PP will now (optionally) report when anybody changes PP's DOS vectors. Not too sophisticated, but it gets the job done. иииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииии CONCLUSION If you have v1.3, throw it away and use v1.4 instead. If you have less than v1.3, you have my condolences. иииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииииии It is not going to be easy, but I have to say this. In all of the history of PP, I have received 47 US$ and 40 DM. Two people from Germany and seven people from the US have contributed this amount, and, quite frankly, that is simply pathetic. You can't begin to comprehend the amount of work I have put into PP, and it really p*s%es me off to see how loosely people are treating the shareware concept. Come on, folks! Is FIVE US $ really too much to ask? For that you get TWO NEW VERSIONS of the program, and I'm even buying the disks, stamps and envelopes?! Even if ALL of the people who has written to me had enclosed a shareware fee, I doubt that it would even pay for the stamps and disks I use when I return new versions of PP. The shareware fee is not supposed to make me rich, it is simply meant to cover the distribution expences I have when a new version of PP is ready to go. So, folks, here it is: Unless a lot more people start sending me some money, I will have to either commercialise PP - or trash the project entirely. And we wouldn't want that to happen, do we?! Grrrrr.....! PS Excuse the bad language. But if that is what it takes to wake you people up, I'll be glad to oblige.