|
| 1 | + ***************** |
| 2 | + * * |
| 3 | + * The X-Systems * |
| 4 | + * * |
| 5 | + ***************** |
| 6 | + |
| 7 | +Now there are 6 library systems starting with an X in their name and 3 of |
| 8 | +them end in master.library. I think a bit of information is needed to |
| 9 | +know what they are. Note that these systems are shared libraries and thus |
| 10 | +useless without an application program using them. XPK, XFD and XAD have |
| 11 | +some easy application programs included in the distribution, but most |
| 12 | +important are all the other applications using them. |
| 13 | + |
| 14 | +xprxxxxx.library: (XPR = eXternal PRotocol) |
| 15 | + |
| 16 | +First of all there was the idea to implement program independent transfer |
| 17 | +protocols to make different transfer system support a lot better than it |
| 18 | +was this time. The xprxxxxx.libraries were invented. Most of the protocols |
| 19 | +are wellknown from mailbox times (Z-Modem, X-Modem, Y-Modem, Kermit, ...). |
| 20 | +Before the XPR libraries existed, the programs supported the protocols |
| 21 | +directly and most time only some of them and always missing the one you |
| 22 | +needed yourself. XPR made an end to that. You only copy the specific |
| 23 | +library to LIBS: and select it in the terminal program (like Term) and |
| 24 | +know you can use it. The libraries can be developed by different authors |
| 25 | +and totally independent from any terminal program. |
| 26 | +To be able to do so, all the libraries use a standard interface, which |
| 27 | +does not differ in all the libraries. So the terminal programm does |
| 28 | +not need to do anything special, but only call the requiered function |
| 29 | +and the XPR library is doing its work. |
| 30 | + |
| 31 | +xemxxxxx.library: (XEM = eXternal EMulation) |
| 32 | + |
| 33 | +Like the XPR libraries, these libraries can be developed totally independant |
| 34 | +from terminal programs. They present a set of different terminal emulations |
| 35 | +(VT100, VT340, RIP, ...) and are designed a lot like the XPR libraries. |
| 36 | + |
| 37 | +xpkxxxx.library: (XPK = eXternal PacKer) |
| 38 | + |
| 39 | +This system was developed by Urban Dominik M�ller and some other persons |
| 40 | +and is continued by Dirk St�cker. Its main concept is taken from XPR, but it |
| 41 | +is used totally different. It is no longer used with terminal programs, but |
| 42 | +with any program. XPK is a system to pack and unpack data in a standardized |
| 43 | +data format XPKF. XPK consists of one xpkmaster.library, which does all |
| 44 | +the work you need to do to support packing (data handling, file format |
| 45 | +creation, parameter checking, ...) and a lot of sub libraries, which are |
| 46 | +equal to the XPR libraries. They have an standardized interface and are |
| 47 | +stored in LIBS:compressors directory. Normally you call the master library |
| 48 | +when you need to pack or unpack something. You also may use the sub |
| 49 | +libraries directly (like for XPR). The sub libraries all implement |
| 50 | +different packing or encrypting algorithms. In an application program the |
| 51 | +user only needs to select one of the libraries and the program now uses |
| 52 | +that algorithm. |
| 53 | +This allows applications to use up-to-date compression/encryption without |
| 54 | +spending a lot of work implementing these in the program itself. And the |
| 55 | +user is able to select parameters like "low packrate - high speed" or "best |
| 56 | +rate - lower speed" or any other combination he likes. |
| 57 | + |
| 58 | +xfdmaster.library: (XFD = eXternal File Decruncher) |
| 59 | + |
| 60 | +Another system developed by Georg H�rmann. This system allows to decrunch |
| 61 | +any type of crunched Amiga data (executable programs, data files). Unlike |
| 62 | +XPK, which only decrunches its own types, XFD decrunches data of all the |
| 63 | +other packer system developed over the years. XFD cannot crunch data, |
| 64 | +only decrunch. Like XPK it consists of one xfdmaster.library doing all the |
| 65 | +work. Unlike XPK the slaves can no longer be accessed directly, as they are |
| 66 | +no longer libraries. Each slave is either internally in the library or |
| 67 | +an extern file in LIBS:xfd. The extern slaves are normal Amiga executable |
| 68 | +files with a standard interface allowing xfdmaster.library to call their |
| 69 | +functions. These extern files can be developed independend from |
| 70 | +xfdmaster.library by different authors, like it is for the other 4 systems. |
| 71 | +Like for XPK, Dirk St�cker is now the author of the XFD system at least |
| 72 | +until Georg wants back the authorship. |
| 73 | + |
| 74 | +xadmaster.library: (XAD = eXternal Archive Decruncher) |
| 75 | + |
| 76 | +XAD was developed by Dirk St�cker. It is much like XFD system, but it |
| 77 | +dearchives file and disk archives instead of files. The xadmaster.library |
| 78 | +gives application programs a standard interface to extract files from file |
| 79 | +archives (lha, lzx, ...) or unarchive disk archives (dms, zoom, ...). Like |
| 80 | +XFD, the XAD system has library internal clients and extern clients stored |
| 81 | +in LIBS:xad directory. These extern clients are Amiga executable files |
| 82 | +like for XFD, but they have a totally different interface. |
| 83 | + |
| 84 | +xvs.library (XVS = eXternal Virus Scanner) |
| 85 | + |
| 86 | +This library is unlike all the others, as it is not possible to write any |
| 87 | +extra slaves/clients for the library, all virus-scanning routines are |
| 88 | +stored in the library itself and are even protected so they can't be |
| 89 | +altered. If they could, viruses would no doubt alter them. This library is |
| 90 | +the work of Georg H�rmann, who seperated the virus scanning functionality |
| 91 | +out of his VirusZ tool, and made a library that any application could call. |
| 92 | +This way, Amiga users can enjoy many more interfaces to virus-scanning |
| 93 | +functionality -- for example, in web and FTP downloading tools, archive |
| 94 | +extractors, as well as the usual graphical virus scanning applications. |
| 95 | + |
| 96 | +Additional words: |
| 97 | +As XPK and XFD both decrunch data, they are linked a bit. XFD always |
| 98 | +decrunches XPKF files by calling xpkmaster.library. XPK itself asks |
| 99 | +xfdmaster.library, wheather a certain format is known to it and if it is, |
| 100 | +XPK calls XFD to decrunch it. In this way XPK can decrunch some of the |
| 101 | +non-XPK file types using XFD. As XPK needs to know which size the file |
| 102 | +will have after decrunching, before the file is really decrunched, not |
| 103 | +all of XFD's slaves are supported by XPK. Only slaves for crunched data |
| 104 | +files which return uncrunched size on recognition are supported. |
| 105 | + |
| 106 | +Also XAD clients may call XPK or XFD system to decrunch their data. |
| 107 | + |
| 108 | +"Clients" (XAD), "Slaves" (XFD) and "Sub Libraries" (XPK) are different |
| 109 | +words for the same thing: The parts really doing the work. |
| 110 | + |
| 111 | +Dirk St�cker <soft@dstoecker.de> |
| 112 | +Stuart Caie <kyzer@4u.net> |
| 113 | + |
| 114 | +20th November 2002 |
0 commit comments