This section contains information that isn't relevant to most users, but some will find it extremely important and/or useful. Please follow the guidelines and suggestions below. They exist to make life easier for all of us.
There are only two reasons for submitting a bug report. First, if the client tells you you've found a bug and should contact the Authors. Second, if a feature isn't working the way you think it should, or the way it is documented.
There's a new GNATS server for bug tracking. If you think you've found a bug, you should check there first. Please note that it's only for submitting bugs for TABBS 2.16 Pre-Release 1 and later. If it's for a previous version, you should try upgrading to the latest and greatest first. Please go here for more information on the new server.
If for some reason, the above doesn't work for you, follow the directions below on submitting a bug report.
If the client tells you you've found a bug, you should immediately copy all of the information on your screen and in any scroll-back, and send it to one of the authors. See Contacting The Authors. If you don't have a scroll-back buffer, the relevant information is probabably off the screen. Write down what you were doing in as much detail as possible, and then exit the client (if necessary, it may have exited for you). Then run the client again, adding "-version" on the command line. For example, if you normally run the client by typing
run it as
Copy the information displayed to your screen. Send it along with the stuff you wrote down earliet to the authors. See Contacting The Authors.
It's recommended that information for that be sent to TOM, since he gets the menial task of tracking such things down.
If a feature doesn't work the way it's documented, or the way you think it should work, please let us know. Include all information on how the feature does work, and how you think it should work. Contact either Ayourk or TOM with the information. Sometimes things work differently because the documentation is wrong, or confusing. We'll do our best to explain if that's the case. Sometimes, though, it just doesn't work right. Or maybe your idea of how it should work is better, and the client will change as a result.
It is not recommended that you compile the client yourself. Over 90% of users are able to download and install a precompiled binary. We recommend getting a binary directly from this site, to make technical support easier. If a binary is not available for your system you will have to compile one. If you do so, you are strongly encouraged to Contact TOM so the binary can be added to the list of "Unofficial" binaries.
For most operating systems, you can compile the client with the following commands:
That creates the program called tabbs and places in the same directory with the downloaded source archive. It then removes the compiled sources.
Most error messages are warnings and can be safely ignored. However, you should contact TOM with information about your system and the exact warnings you received, so that future versions of the client won't generate those warnings. As long as you see a message about ignoring any previous error messages, everything is OK. If you don't see that message, and did see error or warning messages, you should contact TOM or Ayourk immediately for help.
Because the client is released under the GPL, you have every right to modify the client for your own use, and even distribute the modifications under the terms of the GPL. If you do this, however, neither TOM nor Ayourk will provide you with technical support. This is because your modifications may cause problems that do not exist in the TOM/Ayourk BBS Client, or cause it to behave differently enough to be impossible to support.
If you make modifications to the client, we would ask that you send your modifications to TOM and Ayourk. This is not required, but it is recommended. By sending modifications to TOM and Ayourk, you give us full rights to publish or use them as we see fit. Any modifications which appear in later releases of the TOM/Ayourk BBS Client will grant full acknowledgement and credit to the person who gave them to us. We are very selective about what goes into the client, and not everything sent to us will be used. See the next section for information on how to send us these modifications, known as Patches.
Again, please note that if you make your modifications available to the public, you must comply with all points in the GPL. Failure to comply with the GPL could result in legal action.
The main files of interest if you plan to modify the sources and make them build properly, are Makefile.*, inst, version.c, and version.h. The inst script generates a Makefile based on the contents of Makefile.unix or Makefile.win32, if the system is unix or win32 derived. The script also creates the version.h file. version.h contains most of the system-specific defines, and determines text strings which are used when displaying version information, whether the compiler supports ANSI prototypes, and several features. The original Makefile is moved into Makefile.bak. To restore the original Makefile, run make for the target "distclean". Some customization can be changed by changing the information in this file. Please examine the inst script closely to see what does what.
If you're modifying the sources, you're expected to be a genius C programmer who can figure out the mess. Feel free to ask TOM about it, but don't expect a response.
So, you've changed the client in some way, adding a feature, changing a feature, or fixing a bug. Being the kind soul you are, you want everybody to get this new thing. We strongly recommend making a patch using the following guidelines to TOM and Ayourk. If we add your patch to our sources, we'll tell you. If we don't like the patch, we'll tell you why, and let you know it won't be added to the TOM/Ayourk BBS Client.
Patches should be made in the form of Unified Diff or Context Diff patches. Check your manual pages for the diff command to learn how to make those. TOM doesn't really care, but Ayourk prefers the Unified Diff if it's available.
Since the client was written by a myriad of people over a long time, it's hard to tell what kind of naming scheme was used for functions and variables. Basically, it's completely inconsistent. We reserve the right to rename any functions or variables your patch adds. The client is also written in C, and should compile with any ANSI C compiler. If your code depends on extensions in gcc or any other specific compiler, it will probably be rejected.
All global functions should be prototyped in proto.h. Any new functions should include both K&R and ANSI style prototypes in the function definition.
Patches should be sent to both TOM and Ayourk. See Contacting The Authors.