Paul Bunyan is a locked application that runs for a fixed number of days as a trial application unless purchased and subsequently unlocked with a license key. If the trial period expires without purchase, Paul Bunyan will operate in Basic Edition mode with a reduced feature set. As such, you are welcome to download and/or distribute the installer, PBnn-nn-nn.exe, as you wish. This section does not pertain so much to the distribution of the installer itself but more to issues and requirements regarding the shipping and installation of Paul Bunyan with your application be it the API files by themselves or Paul Bunyan in entirety.
Note: if you wish to copy the API files around internally within your own organization you are free to do so. Often times applications are compiled for release on a particular machine simply for purposes of build integrity. Diamond Sierra realizes this and endorses this action.
Redistributing the API files with your application
The API files PBLog.exe and PBCOM.dll are distributable because while they are in essence just API interface files like PB.h and PB*.lib they differ in that they cannot be statically linked and so must accompany the user’s application when installed. We do require as part of the license agreement, however, that PBLog.exe and PBCOM.dll be installed in the directory returned from the Win32 API call GetSystemDirectory (typically System32) and that these files be reference counted as shared DLLs. This is because other installation applications will need to be able to find these files in order to determine whether the existing file is of newer or later version than the one tentatively being installed. If these files are not in a standard location then other installation applications, ours as well as anyone else’s, will not be able to find them and will subsequently install whatever version of file they have, with possibly detrimental effects. Additionally, when uninstalling, these files should be removed only when the reference count goes to zero. Note that this requirement only applies to installation applications written for third party usage - if the user subsequently chooses to move these files elsewhere after the installation is finished then the choice and consequences are of course their own.
Distributing and/or installing Paul Bunyan
Paul Bunyan may be installed in a number of ways that ultimately result in the ability to download log messages from a customer’s computer. The user may have already installed a copy or purchased another vendor’s software that installed it. Conversely, the user may choose not to install Paul Bunyan and prefer to wait until there is a need and then install it at that time and try to recreate the problem. A vendor can ship Paul Bunyan’s installer, PBnn-nn-nn.exe, with their application or download it from the web site at install time or simply advise the user that they themselves may download and install Paul Bunyan at any time they choose. If the vendor chooses to install Paul Bunyan as a sub-task of their own installation process then this may be easily done in the foreground or silently in the background and with command line options governing message server configuration parameters and optional components to be installed. Note that due to the licensing protection algorithms used by Paul Bunyan it will be necessary to use the installer rather than trying to install the components directly from within your own installation application.
Message logging in release builds
Publicly logged messages are available to any connecting viewers and are not in any way separated or filtered by vendor, i.e. all public log messages are available to everyone. It is because of this that we advise vendors to leave at least some useful portion of their logging publicly enabled in release builds. If everyone is logging their aspect of a given event then the odds are much higher that the collective sum of that information will lead to a solution. This means end users get problems resolved faster and more accurately which in turn cuts down on everyone’s tech support costs. It also means that bugs and other anomalies are more likely to be reported when they are first encountered rather than when they first break something and cost a user a lot of time and good will.