Communications Programming for Windows

The message server then routes those messages onto any connected viewers (Paul Bunyan's front end desktop application which is used to display the log messages) and to any registered message handlers (any COM server that implements Paul Bunyan's COM interface through which the message server can pass log messages to user-created custom code).

Finally, the message server also saves the log messages in a persistent FIFO queue of configurable size so that any subsequently connecting viewers can download messages that have come in since the time of last connection ­ much like a news group server.

Paul Bunyan Features

Centralized Logging

Log messages spanning threads, processes, languages, machines, and sites all get pulled together for single source viewing ­ no manual merging of application logs, text files, or databases.

Multiple Simultaneous Connections

Multiple viewers can simultaneously download log messages from a single message server or, conversely, a single viewer can be used to download log messages from multiple servers. The same multiplicity is true with message handlers. Multiple message servers can pass messages to a single message handler or, conversely, a single message server can pass messages to multiple message handlers.

Performance

Paul Bunyan is lightning fast and virtually undetectable in even the most performance critical applications. The process of logging a message is completely front-end biased with all backend processing occurring on low priority threads. Message logging rates are on the order of 25,000 messages per second on a Pentium 233. As a comparison, logging the same string on the same machine using the Win32 API function OutputDebugString and the sample application DBMON yielded a rate of about 4,400 messages per second, discounting the time needed to put the messages on the screen. When the drawing is done, the rate drops to about 1,700 messages second, demonstrating the inefficiency of the design. With Paul Bunyan, what happens to the messages after they are logged has little or no impact on the logging application.

Minimal Memory, CPU, and Resource Impact

Paul Bunyan uses internal data compression in memory, on disk, and on the wire and does all of its backend processing on low priority threads. It is extremely resource-efficient and is completely configurable with regard to memory and disk space usage.

Shippable in release builds

Paul Bunyan was designed to be left in release builds of code. It is extremely fast, light, and secure. It also requires no modifications to installation programs as there are no DLLs or other components to ship (if using the C/C++ API) and it is self disabling on machines where Paul Bunyan is not installed. It is highly advantageous to leave the logging code compiled into shipping applications since enabling it then requires nothing more than installing Paul Bunyan.

Support for Numerous Programming Languages and Environments

The native API is C and C++ which can be called from many languages such as Assembly and Pascal. There is also a COM wrapper that can be invoked from automation clients, ASP (Active Server Pages), VB Script, Visual Basic and VBA-supporting applications such as Microsoft's Access, Word, Excel.

Support for Unicode and ANSI Character Sets

The C/C++ API and COM interface both fully support the Unicode character set for internationalization usage. It is supported concurrently with the ANSI version of the API so that an application can simultaneously log Unicode and ANSI data regardless of which way it is compiled.

Rich Contextual Information

Each log message contains fields for message type, timestamps (Source, Local, and GMT), component, context, machine, process, module, file, line number, process id, and thread id.

Powerful Filtering

We support filtering functionality that is very simple to use yet very powerful. Filtering can be used on an inclusive or exclusive basis and can be applied as selectively as desired to any log message field or fields.

Multiple Queries

We also support the concept of queries which are essentially filters with associated display parameters. There may be as many queries as desired for selecting, sorting, and viewing messages in various manners.

Security

Log messages are encrypted immediately upon creation even before they are transmitted to the message server and stay encrypted for the rest of their lives whether on disk or wire. Further, log messages can be locked up programmatically with passwords at the time of creation and subsequently only downloaded and viewed by users providing that password so there is no risk of airing dirty laundry in front of clients or other competing vendors.

Support for Passing Log Messages to Custom Code

Paul Bunyan supports passing log messages to your code through the use of COM. Custom coded COM servers supporting our callback COM interface are referred to as message handlers. Message handlers are typically used for handling events, translating and forwarding messages to event handling applications like Tivoli(TM) or Opalis(TM), logging transactions to databases, creating audit trails, etc.

Lite Edition

Professional Edition

Enterprise Edition