@database FB @node main "Welcome to FB.." @{b}Welcome to FB.. V1.1@{ub} Call it FileBase, FLEBomb, or just F@#king Brilliant - You decide. Copyright (C) Olly Koenders 28-04-1998 A complete filebase alternative for Max's 1.54+ A big thank you to all those that have evaluated/tested and sent feedback regarding the Max's Pro2 only version of FB (1.0) - I'm so pleased with the results that this version is Max's 1.54+ compatible and such will be all subsequent registered releases. @{" INTRODUCTION " link "introduction"} @{" DOWNLOADING " link "downloading"} @{" FEATURES " link "features"} @{" UPLOADING " link "uploading"} @{" INSTALLATION " link "installation"} @{" CREDIT SYSTEM " link "creditsystem"} @{" COMMANDS " link "commands"} @{" SECTION ACCESS " link "sectionaccess"} @{" NEWFILES CHECK " link "newfilescheck"} @{" PROGRAMMING " link "programming"} @{" FILE SECTIONS " link "filesections"} @{" DISCLAIMER " link "disclaimer"} @{" LINKED SECTIONS " link "linkedsections"} @{" THINGS TO DO " link "todo"} @{" CONVERSION " link "conversion"} @{" DISTRIBUTION " link "distribution"} @{" V1.0 BUGS FIXED " link "bugs"} @endnode @node introduction "In the beginning.." @{b}- INTRODUCTION -@{ub} It all began a month ago, a different filebase program was running the filebase for Max's, and I got home from work to do some small coding and other knick-knacks, when the user online in the Amiga Comms area hit a bug in its datafile that eluded me from the beginning, and Amiga Resource Group crashed once more. There goes about 15 minutes of coding and all my faith in that program's ability to run the filebase without supervision - again. I started wondering how many users lost their uploads in the ubiquitous "TMPx" upload directory with lost carriers, and how many others lost their tagged files after losing carrier as well. Also how many sysops pulled out their hair in frustration trying to configure it, and not to mention editing all those Max's menus to accommodate it. Coded in compiled Hisoft BASIC with its quirks and quandries, its unnerving ability to annoy cached processors much of the time, and seeing that the defacto author Glen Martin told me he dropped the project - it was time the Amiga BBS community at large had something else. This is the result of a month's hard work, and it's the most ambitious project I've ever undertaken. Certainly been well worth it though.. @endnode @node features "Got a pen..?" @{b}- FEATURES -@{ub} * The FASTEST file listing ever! Up to 3x that of FLE or 7x DFB.. * Extremely fast case-insensitive string search. * Extremely fast and user optionable newfiles search. * Unlimited file sections/areas - Yes, REALLY! * Unlimited "linked" sections. * Unlimited files per section (well, dependant on available memory and AmigaDOS). * Individual access levels for each section. * Minimum filesize for credit in each section. * Extracts and adds File_Id.Diz's to any archive type optionally specified for each file section. * Adds your own BBS advert to each archive as above. * Ability to view any archive/file contents you specify. * 45 x 12 multiline file descriptions optional for each file section. * Proper word-wrap of "wierd" format Diz's (PeeCee) * User definable upload signatures at users discretion. * Automatically adds AmigaDOS filenote to every file uploaded. * Automatically keeps track of lost carrier uploads and allows the user to resume on next login to the correct file area without losing files! * All main datafiles and configs are plain, editable ASCII! * Rapid marking/unmarking of files to download. * User can tag up to 100 files at a time. * Automatically tracks marked files for download with or without lost carriers/aborts. * Tracks and reports top CPS rates for each baud rate. * Local login file copy of marked files to any specified directory. * Allows logoff after download with 15 second abortable countdown. * Allows download before logoff if tagged files detected. * Allows the options of "free" file sections and "creditless" ones as well. * Truncation of annoying long filenames. * Use Max's for editing ratio's. * Editable ANSI's. * NO MILLENNIUM BUG!! * Hand crafted in highly optimized assembler. * Caches file lists in memory for even faster access and minimal disk activity. * Minimal memory requirements (~37K without cached list) * Is an "all in one" executable - not many little doors. * All ANSI's and archive viewer/packer/unpacker configs already included, all you need are the archivers. * No need to rip out your old filebase completely for a quick look, just use the examples provided. See @{" QUICK PEEK " link "quickpeek"}. * Is fully multinode compliant. * Kickstart 1.3 compatible. * Installation and use is so easy you'll kick me for not releasing it sooner.. Don't panic over understanding all these features, they'll become more familiar soon and many of them are automatic anyway.. @endnode @node installation "Where did I put it..?" @{b}- INSTALLATION -@{ub} Unpack the main archive directly to your "BBS:" path. Reach into the newly created "BBS:FB/" directory and copy/move the main "FB" executable to your main "Doors:" path. Reach into "BBS:FB/0/" and edit the "Sect.cfg" file to suit your average type file section. Make a directory "0" in each of your file sections.. EG: If you have a file section called "DH0:IFF_Pics/" then reach into there and make a "DH0:IFF_Pics/0/" directory. Copy the Sect.cfg file you just edited and put it in each of these "0" directories. Now edit each one of these to conform to the type of file section you'd like it to be. See @{" FILE SECTIONS " link "filesections"} for more info. Also make an ANSI (or a simple text file if you like) describing the section in beautiful ANSI lettering "IFF PICCIES" or whatever you want and that file is called "Sect.ans" and goes in the same "0" directory. In your "Doors:Maindoor.text" file you may put "FB nf" to initiate auto user config for new users to the filebase and later newfiles check will be initiated automatically for established users. Create a directory called "Files:TMP/" and make sure that "Files:" is assigned so that "TMP" can be found! The "Files:" path is also where Max's keeps its "Filepaths.text" file. Now the Max's menus, which have always been a slight pain but still better than most BBS software I think you'll agree..:) Say the key resides in a menu: (P).... IFF Pics ..for the user to select. -------------------------------------------------------------------------- Key: Function: Extra: Lo acc: Hi acc: Filename/Name/Dest/Path: @{b}[@{ub}P @{b}] [@{ub}34 @{b}] [@{ub}0 @{b}] [@{ub}0 @{b}] [@{ub}10000 @{b}] [@{ub}Doors:FB lf dh0:iff_pics/ @{b}] @{ub}-------------------------------------------------------------------------- This will initiate a "listfiles" function from FB and the path MUST ALWAYS have a trailing "/" or ":" - else expect trouble!! Remember the path should be completely lowercase. It's as simple as that :) For more info on the commands available to FB see @{" COMMANDS " link "commands"}. @endnode @node filesections "Wot are they..?" @{b}- FILE SECTIONS -@{ub} Amazing little buggers these, they are where all your files are stored ready for users to up/download to/from. Directories is all they are but the sheer power of these shouldn't be underestimated. Within each file section path ensure there's a directory called "0" and within this directory should be the "Sect.cfg", "Sect.ans" and later when files are added to the section there'll also be a "Sect.lst", and if you like you can grab the "BBS:FB/SectMenu.ans", edit it (don't change the key specifications!!) and place it in the "0" dir as well. So now you can have a different listfiles menu for each section if you like, otherwise FB will use the default in the "BBS:FB/" directory. The flags in the Sect.cfg have various functions, and at all times "Y" means "Yes" to the option, and "-" means No".. Files Free - If "Y", files in this section can be downloaded at no cost to the users credits. Allow Uploads - If "Y", then uploads will be allowed to this section. Unpack ID.DIZ - "Y" sets automatic File_Id.Diz unpacking for the description editor using "BBS:FB/Arcs/UnpackDiz.txt". Creditless UL - If "Y" then all uploads to this section won't be added to users credits. Add BBS Adv. - If "Y" then "BBS:FB/Arcs/AddBBSad.txt" will be accessed to add your BBS advert to the archive. Add FileDiz - "Y" will allow FB to add the users manually typed description to the archive as a File_Id.Diz via "BBS:FB/Arcs/PackDiz.txt". NOTE: Unpack ID.DIZ is a special "mode" function. If "Y", then the upload will be handled as a "normal" upload using all the relevant options above, if "-" then a 45 character description line can be entered only, and all flags above except "Creditless UL" will be ignored, and the file entry will not be added to the "Sect.lst". Therefore nothing will be added to the file/archive except the automatic AmigaDOS filenote. EG: "Upload2Sysop" is best handled using "-" for the Unpack ID.DIZ flag in conjunction with the command "ul". You may use "Y" in conjunction with the "ul" command if it suits you, as it may allow better description of the file for your purposes, and makes it a bit easier to add directly to the correct area later on with a cut, paste and move from CED or your fave text editor. If there's no files in the section then FB will announce to the user that the section is empty and to upload something. If the section IS empty of archives/files then ensure you don't have a "Sect.lst" file in there! Remember the first line of the Sect.cfg will be displayed to the user in different functions, so don't include control codes. It'll also be displayed when the listfiles is active so it'll also be printed wherever you leave the cursor in the SectMenu.ans. @{b}IMPORTANT LATE BREAKING NEWS!!!@{ub} I noticed during a user download that Max's couldn't find a file that was marked for download. This is impossible as FB don't allow tagging of files that don't exist. As it turns out it's Max's way of telling us (not in any documentation found so far) that the string to be passed to the d/l or u/l routine in Max's must be maximum 40 characters. Therefore your paths MUST be maximum 20 - as FB uses 20 character filenames.. EG: "dh0:20characterpath/" ..then the 20 byte filename is appended. It will work fine this way..:) @endnode @node commands "Aww.. DO IT fer f#%k sake..!" @{b}- COMMANDS -@{ub} These are extremely important and MUST be in lowercase, or FB won't recognise them and go straight to the newfiles option: --------------------------------------------------------------------------- "lf" - Initiates FB to allow access to listing of files, uploading, downloading, editing and erasing of marked files. The path MUST be in lowercase if the listfiles routine is to recognise marked files and print them in a different colour! USAGE: "Doors:FB lf (full path)+/" --------------------------------------------------------------------------- "nf" - Initiates the newfiles check for established users and the user config for non-established users. The newfiles check will skip listing of areas with a higher access level than the user. New files will always be "new" for a couple of days. You MUST have the file "BBS:FB/Link/NewFilesPaths.lst" setup correctly. For more info see @{" NEWFILES CHECK " link "newfilescheck"}. USAGE: "Doors:FB nf" --------------------------------------------------------------------------- "lk" - Initiates linked sections using a filename only - no path must be specified as FB searches the "BBS:FB/Link/" directory for the specified filename. See @{" LINKED SECTIONS " link "linkedsections"} for important info. List access control as per access level of the section. USAGE: "Doors:FB lk (filename only)" --------------------------------------------------------------------------- "uc" - Initiates a user config that allows the user to change options pertaining to their newfiles check and upload signature. USAGE: "Doors:FB uc" --------------------------------------------------------------------------- "lo" - Allows the user to logoff from the BBS and is usually located in a logoff menu. This function also warns users if they're leaving marked files behind and allows them to download before they go. USAGE: "Doors:FB lo" --------------------------------------------------------------------------- "ul" - Initiates upload to "special" areas like "Upload2Sysop" or others where you'd prefer users don't have access to the listmenu or be able to download from. Can be used for "All new uploads here!". USAGE: "Doors:FB ul (full path)+/" --------------------------------------------------------------------------- "dl" - Allows download of a single file only without access to the listmenu and other fuctions. Useful for downloading of membership forms and BBS file lists. The "*" is either a "Y" or a "-" indicating if file is a freebie or not. "Y" means free, "-" means not. Must be directly in front of the path specification - no spaces! USAGE: "Doors:FB dl (*full path+filename)" EG: "Doors:FB dl Ybbs:text/Mbrship.txt" --------------------------------------------------------------------------- @endnode @node newfilescheck "..rummage, rummage.." @{b}- NEWFILES CHECK -@{ub} There's a file required for this called "BBS:FB/Link/NewFilesPaths.lst", edit this to reflect the file sections you wish FB to search for new files. Ensure there's a "/" or ":" trailing each full path specification. Each section will be checked for new files depending on the current users access level, if the users access level is lower than a particular section, then the section will be skipped. Ensure the path specifications are in lower case, or previously marked files won't be shown in a different colour. Please note that anytime you do check for new files, a millennium bug can occur in any normal setup that doesn't use 4 characters for the year part of the date. In which case if a user last logged on 010100, and your filebase contains files from say, 010198, then those files even though older than the last logon date, would be shown as new. I have overcome this problem and still use 2 character year strings. But this fix will only work until the year 2010, but by then you shouldn't have any old 1999 dated files, and there'll be a proper version in the works way before then - Depending on what processors we're using in the next few years. @endnode @node linkedsections "..you, an' you.. an' you.." @{b}- LINKED SECTIONS -@{ub} Are handled exactly the same as the newfiles check, but it allows all the normal listing functions associated with string searches, reverse listing, marking and unmarking etc. As the end of each section is listed, the next one will be linked into play. Ensure lowercase path specifications as per the newfiles check. There is one important difference with the "BBS:FB/Link/(filename)" you need to edit, which comprises a section header as the first line of the list. See the example for "BBS:FB/Link/LinkedAmiga". An important note: Ensure that the first path specification is general access - say, BBS related files that are either free or have a sufficiently low access level, like 5 or 0. This is due to the coding of the routine and not a bug. @endnode @node downloading "Greedy sods.. [snif!]" @{b}- DOWNLOADING -@{ub} All marked files for download are written to a file: "BBS:FB/Tags/(User_Name)". They are plain ASCII and have the freefile specification character at the beginning, either a "Y" for free or "-" for not. The user can mark files in any section around the BBS where access is available, and come download time they will be found and subsequently sent regardless of the section the user is in at the time. The user will be asked if they wish to download, and then if they wish to logoff immediately after. If they choose logoff, then a 15 second delay counter will greet them after all their files have been sent, and they may abort the countdown or the logoff. When logged in LOCAL, FB will run the local copy routine and marked files will be copied to the path specified. Ensure a trailing "/" or ":". @endnode @node uploading "..push, shove, strain.." @{b}- UPLOADING -@{ub} The user can upload to any file section that has the allow upload flag in the "Sect.cfg" set to "Y", and if they have a sufficient access level. They will first be prompted with an ANSI if they wish to proceed, and if they respond positive, Max's will begin receive mode. A directory "Files:TMP/(User_Name)" will be created for them and all uploaded files will end up in here. On completion of the upload the File_Id.Diz will be extracted from each file if it exists, if not they are prompted to type a description. If they typed a description themselves then that will be used as a File_Id.Diz for the archive if you have the corresponding flag set in the "Sect.cfg". All adding of AmigaDOS filenotes are fully automatic. If the "Sect.cfg" is set to filenote only then the File_Id.Diz won't be extracted, and they will be promped with a single line entry. The file won't be added to the "Sect.lst", nor will the File_Id.Diz be inserted into the archive. Although if you have the appropriate flag set for the BBS advert it will be added. All filenames will be uppercased and truncated to a maximum of 20 characters EG: VeryLongAndAnnoyingFilename.lha becomes: VNNOYINGFILENAME.LHA If the user loses carrier while sending, the newfiles check from your "Doors:Maindoor.text" file will alert the user with 2 choices, to delete all their uploaded files or continue. If continue is selected then FB will go straight back into receive mode. If the user lost carrier entering descriptions, then FB will go straight into the description editor after alerting the user. All files will end up in the intended file section after successful descriptions are entered. Uploading for the sysop is a simple matter. Just logon and goto the file section you wish to upload to, and then commence upload. Go into the excellent DirectoryOpus or similar, enter the "Files:TMP/" directory, and you'll find a directory created in your name, enter that and copy all the files you wish to upload into there. Once the copy is complete, abort the transfer on Max's side and begin entering the file descriptions. If an archive contains a File_Id.Diz and it can be extracted then it'll be entered for you. Once there aren't any more files in your upload directory you'll return to where you left off and your upload directory will be deleted. @endnode @node creditsystem "Now lemme see, that's 40 hours at 1.50 an hour.." @{b}- CREDIT SYSTEM -@{ub} FB uses the old file ratio system for credits. Yeah, yeah.. I know - "Whinge, whinge, whinge.. not good enough.. they'll amass huge credits an' get all me files.. blah, blah..". I've had enough problems with kilobyte ratios and all sorts of wierd credit systems in the past, none seem to offer good control as they can be misled one way or another. The key to good operation of this is fair ratios to good uploaders, and strict ones to those average PeeCee wankers who like to do nothing but leech. If you see someone trying to upload crap then act on it accordingly and reduce their ratio, don't just sit there and expect it to work all by itself. But considering the type of service you're providing, don't be too damn tight with your files, or they WILL start to rename their downloads and send them back. The tighter you are the tighter they'll be, but you'll always get hard cases and sometimes it's best not to bother doing business with them. There's a small addition to the ratio. If the user uploads to a file section where the minimum credit for a file is 80000 bytes, and the uploaded file is smaller than this, then they won't be credited for that file. This avoids teeny little text files being credited and allows pictures of a decent quality to be "paid for", as large picture files are often better quality than smaller ones, same for utilities etc. Although this isn't failsafe it's somewhat better than just a plain file ratio. Calculate the file credits of a user with this formula: ((Uploads * Ratio) + Ratio) - Downloads = File Credits FB gets all it's information for this from Max's, so it's up to you to set their ratio accordingly. If they seem to be amassing a large number of credits then either you've chosen too high a ratio or they actually deserve them, so don't be too tight with your files, be vigilant. If you wish the user to have unlimited credit, then simply set his ratio in Max's to 0. All settings must be made without FB running at the time as FB gets all the variables early in its execution. @endnode @node sectionaccess "..An' STAY out.. [SLAM!]" @{b}- SECTION ACCESS -@{ub} If a user has a lower access level to the section they enter, then they won't be able to mark, upload or download files. If you wish to disallow access to this section altogether, then set the "Lo acc:" for that section in the Max's menu to the sections' access level. @endnode @node quickpeek "Oh I see! It's all so very clear now.." @{b}- QUICK PEEK -@{ub} If you haven't unpacked the archive, then see @{" INSTALLATION " link "installation"} on how to do this in a quick fashion, but ignore setting up the ENTIRE filebase, as we're only going to show one section. All the required files are setup to do this already but you won't be able to mark or download files as the listed archives aren't physically available. Please do NOT attempt an upload unless you have read the section on @{" UPLOADING " link "uploading"} and @{" INSTALLATION " link "installation"}, and have created a "Files:TMP/" directory! Righto.. Go into Max's and allocate a key in a menu like this: -------------------------------------------------------------------------- Key: Function: Extra: Lo acc: Hi acc: Filename/Name/Dest/Path: @{b}[@{ub}? @{b}] [@{ub}34 @{b}] [@{ub}0 @{b}] [@{ub}0 @{b}] [@{ub}10000 @{b}] [@{ub}Doors:FB lf bbs:fb/ @{b}] @{ub}-------------------------------------------------------------------------- Once complete, and the FB executable has been copied to the "Doors:" path, then login local and press the required key. The first time run you'll be confronted with questions relating to your upload signature and newfiles check, after you have successfully completed this and you're back at your Max's menu, press the key again. Now that you're configured, the main section menu will appear, and you'll be able to list the files in the section, but if you try to mark, FB will display an error message. This can be used for testing of uploads, downloads etc, until you become more familiar with the way it works. I think you'll find that FB is very self-sufficient. By the way, if you do set it up correctly for uploads and actually execute some, then the uploaded archives will end up in the main FB directory. @endnode @node programming "ERROR: Byte contains only 7 bits.." @{b}- PROGRAMMING -@{ub} At this point in time there are no external utils or extra doors to go with this release. That's because I've been busy making sure that all the bugs have been squished and everything works as it should. However, FB would need few if any external "maintenance" utilities as it's very self-supporting, and the use of editable ASCII files where possible helps this fact no end. I would like to see other programmers create some useful doors/utilities for FB, so I'll give you some offsets: --------------------------------------------------------------------------- "BBS:FB/User/(User_Name)" Offs: Size: Description: 0 46 Upload signature, null terminated. 46 2 Kludge fill, null. 48 42 Last upload path, null terminated. If first byte=0, ignore. 90 1 Lost carrier on u/l, 0=descriptions, "C"=while sending. 91 1 Kludge fill, null. 92 4 Date last on. Convert value to DEC number for date$. 96 4 Uploaded bytes, maximum 4.29 Gig. 100 4 Downloaded bytes, maximum 4.29 Gig. 104 1 Upload signature usage, "1"=All the time, "2"=Ask, "3"=Never 105 1 Newfiles check usage, "N"=Never, "Y"=All the time, "A"=Ask --------------------------------------------------------------------------- "BBS:FB/CPS/(BaudRate)" Offs: Size: Description: 0 42 User name, null terminated. 42 4 Download rate, maximum 4.29 Gig. --------------------------------------------------------------------------- "Sect.lst" n = filename string, left justified, padded with spaces. Maximum length 20 characters. # = Spaces, MUST exist! First space of entry at character 21. s = Size text, the "ù" is actually IBM ascii for a "·", 5 characters maximum. u = Date uploaded, "DDMMYY". T = Tab, 4x on each line before next description line. d = Line of description, maximum length 45 characters, terminated with [CR]. nnnnnnnnnnnnnnnnnnnn#sssss#uuuuuu#dddddddddd..->[CR] SCIENCES.LZX 22ù8K 050997 An extract from an ongoing argument about # T T T T dddddddddd..->[CR] the sciences. The whole entry should look like this: SCIENCES.LZX 22ù8K 050997 An extract from an ongoing argument about the sciences. @endnode @node disclaimer "Uhh.. I didn't do it.." @{b}- DISCLAIMER -@{ub} I have spent weeks testing, optimizing and futher testing routines to ensure that no bugs remain. As far as I'm aware there aren't any. So if you lose masses of hard drive datablocks, it wasn't me. Ensure that you use the program as intended and READ the docs, as I have no control over your choice of usage all the way from Australia. I've had FB running on Amiga Resource Group for a 5 weeks now and the only problems obtained so far are more PeeCee wankers, which allow me to test it to the limit - thanks guys..:) @endnode @node todo "..maybe this would help.." @{b}- THINGS TO DO -@{ub} * Integrate a CD ROM spooler. * Give FB the ability to create, archive and send BBS filelistings. * Allow more flexible configuration. * Integrate a function to "move" files+descriptions from one section to another. * Some external utils/doors would be nice. * An upload logfile would be handy too. @endnode @node conversion "Shoot! I needed all that data.." @{b}- CONVERSION -@{ub} For this release of FB (V1.1), I have included a small utility to convert the Sect.lst files from FB 1.0. This is for users/evaluators that wish to see it in full action but don't have Max's Pro2. For those that do wish to register for free updates, and have already re/started a BBS with FB, you *MUST* convert to the 1.54+ format or subsequent versions of FB will not function correctly (does GURU 81000005 sound familiar?). The Sect.lst file will grow in size by exactly 1 byte per dizline. If an entry referenced in this file has only 1 line of description, nothing will be changed on that line, but subsequent dizlines for that entry will have a " " (space) added in front of the 4 tabs (see @{" PROGRAMMING " link "programming"} for entry format). This extra space is to cater for the longer control codes that "normal" BBS programs use (like PeeCee ones) instead of the short CSI codes of the Amiga that Max's Pro2+ caters for. The conversion util for Pro -> 1.54+ is useless to those that are starting a filebase from scratch with FB V1.1. At this time I don't understand too well how the original Max's filebase works, nor even Max's Pro. So I don't have a conversion program handy. I plan to have conversion utils available for the standard Max's and DFB filebases, but unsure of their format as yet - they will be investigated. I DO have a conversion program to convert the old File Lister Express (FLE) to FB, and after some optimizations fixed it to convert a section in about 2 seconds rather than 45! The conversion utility creates ready-made lists for FB from the FLE datafiles. This will allow you to keep your descriptions, and avoid having to type them in all over again and start your filebase from scratch! It saved me re-doing 15,300 files, and the whole conversion from FLE to FB took about 2 hours with bug testing. The converter will be available to registered users only. See the section on @{" DISTRIBUTION " link "distribution"} for details. @endnode @node distribution "Where would you like to be right now..?" @{b}- DISTRIBUTION -@{ub} I had originally intended to distribute FB as freeware, but after all the hard work and testing I decided against this. After all the Max's doors and other utilities I've assembled and distributed to Aminet for free, this one was just too much work to let it go for nothing. Please note that FB isn't crippled. I could have whacked out a chunk of code or two to make it practically unusable, but haven't done so for the sake of Amiga fans. I haven't even placed my name in the program anywhere. I know that shareware doesn't work too well, so I'll just say this: This version of FB can be registered for $15.00 Australian - that's all. It's not much, and translates to about £6.00 UK or $9.75 American. You can send Australian Postal Orders, American Express Money Orders or similar to: Olaf Koenders 4/43 Thomas St. Ringwood, Victoria Australia 3134 If you'd like some time to evaluate it or even just to say hello, e-mail me at: turiya@sub.net.au And last but not least, call our BBS at +61-3-9870-4608 (Land of OZ). If I don't receive any registrations, then this is the last version the public will enjoy. I will continue the improvements and e-mail them free to those that have registered. If I hear reports or find a BBS that's running later versions without registration, I'll not only be extremely disappointed, as this is the kind of thing that lame PeeCee wankers do, but I'll also endeavor to destroy the contents of that hard drive in any manner I see fit. So be warned, I have ways! This version of FB is freely distributable, but you may not sell the program to anyone, unless the money is forwarded to me. In this case do not charge more than a small copying fee plus the registration fee if necessary. Enjoy - Olly. --------------------------------------------------------------------------- #=--:-+--::: :. .::==+oO88888888800000@@0O======= #=---=+-:::: . .:-=++O88808000800@@@@@0++====++ @===-++=:---. ......:-=+oOO8880000000@@@@@0000o=++++ @===+o+=-:::. .-==: ...:-++++++++++OO800000000000@@@0000000+=+++ @==++o+-::::: :==-+oO+-. .-++oOO880888888880000000000000@@000000@@o=+++ @=---+=-:--:: .:::. .-o80000@08OO000000000000000000000000000@@+=+++ @=---+=-:--:. :o800008-....:-=-=o8OOO8880008000000@@@000=++++ @=---++=---: :+O80888o.......-=+o++=--=+O800000000@@@@0O=++++ @+=--o+=-==:: .=oO8OOoo+: ...::---::--++O8000000@@@@@00++++++ @+=-=o=++++== -+O8OOOoo+=. . ..::---=+oO80000000000@@0+++++++ @+==+o==+oo=+- :=oOOOOOOO+=:....:::--=+++oO8000000000000O++++++++ @++=+oo++oo=+-- .:=+O88008O+=:...::--==+oOO800000000@0000O+++++++++ @++++O+++++==-=- :=o8000000O=-::::--=+oOO8800000000080808O+++++++++ @++++O+++=+====+-. . :=oO00088800O+---=++oO8000000000000@@@@@0008OOOo+++ @+=+oO+++=++===++: .. :=oO00000000@08+==+oOO80000000000000@@@@@@@@@0000008 @++oOO+++=oOOOO88+:::-=+O000@@@@@@0000OoooOO88000000000000@@@@@@@@@@@@@@@@@ @Oo+OOoOO88888888O=+==++OO0000@@@0000088OOO888000000000000@@@@@@@@@@@@@@@@@ @OOoO8888888888888++++==+++oO000000000088O8888880000000000@@@@@@@@@@@@@@@@@ @O8888888888888880++++=-===--+oO88080888888888880000000000@@@@@0@@@@@@@@@@@ @8888888888888808@O+==++++=++OO880800008888888888808000080@@@@@00@@@@@@@@@@ @888888888888808808O++++oooO880000000008888888888000008800@@@@@000@0000@000 #8888888888880088080Oo++++oO88888888OOOOOOO8888000088888000@@00000000000000 #88888888888000888008Oo+++++++OOOOOOOOOOO8880800088888880000@00000000000000 #888888888880008888008Oo++++++oOOOOOOOO8O8800008888888800000000000000000000 #8888888888000088880008OoooooOOOOOOOO88888088888888888000000000000000000000 --------------------------------------------------------------------------- @endnode @node bugs "Ooo.. an undocumented feature.." @{b}- V1.0 BUGS FIXED -@{ub} - Memory buffer overrun bug fixed in list caching routine. Engine enhanced and optimized for further speed gain. - Same bug also found in string search routine (wow!) - Engine also enhanced. - Strange bug mentioned by only one user in the upload routine using "ul" in conjunction with Unpack Diz flag - still not experienced by myself or anyone else but investigating! @endnode