Refining Ripsaw’s Design

In my last entry in the Ripsaw article series, I discussed some of the design goals for Ripsaw. In this article I’ll flesh out the design a little more and discuss specific implementation possibilities.

To bring you up to speed, Ripsaw is a log-viewing utility for Windows that I initially wrote about six years ago, but never released widely. I’ve decided to rewrite it and discuss each step of the rewrite here.

Implementing the API

The initial Ripsaw implementation was a monolithic (albeit small) application, but this time I want to separate the log-reading mechanism from the log-viewing UI. There are times when I’d like to use the log-reading capabilities of Ripsaw from JavaScript or PowerShell, and I’d also like to write more than one viewer application around the log reader. There are at least three possible technologies for this API:

  1. C DLL
  2. COM
  3. .NET

Okay, there are a lot more that I could choose from, but for the machines I’m targeting these are the most likely candidates. A DLL exporting C functions would be the simplest to write and would be easy to integrate with most programming languages, but in order to use that sort of API from JavaScript (or similar languages) I’d have to write a COM wrapper. A .NET implementation would be COM-callable, but it would require having .NET installed on the target machine, and sometimes the systems I debug don’t have .NET installed (hard to believe, I know, but true). COM, however, is ubiquitous on Windows, fairly straightforward, can be used from JavaScript with ease, and is easily callable from .NET if I had a reason to do so later on. Therefore, I’ll implement Ripsaw’s non-UI behavior in a COM library.

What About Registration?

I’d still like to be able to run Ripsaw from a USB drive without having to install anything on the machine I’m debugging or examining, which means I’d like to avoid the hassle of having to run regsvr32 on the target machine before I can use Ripsaw. Fortunately, there is registration-free COM, which will let me run a Ripsaw viewer that loads the Ripsaw COM library with the aid of a manifest. This will let me keep a viewer and the Ripsaw library in a directory on my USB drive so I can just plug it in and run the viewer without having to register or install anything.

Supporting Scripting in the Viewer

Since Ripsaw’s log-reading capability will be implemented in COM, I’ll be able to write JavaScript apps that can watch for data from a log file, and these scripts can either parse the data or take actions based on the data. Not only would this be useful apart from a viewer, but it might also be useful inside a viewer. I could define script actions to operate on log lines, highlight them, parse them, etc., while I’m watching a log in the viewer. To take advantage of this I’ll add JavaScript support to the Windows Ripsaw viewer, along with the capability to load pre-defined scripts that act on log data.

Viewer Implementation

In keeping with my requirement for making Ripsaw light and portable, I don’t want to use .NET for the main viewer implementation. I might create a Windows Forms or WPF viewer later on once .NET becomes more widespread on the systems I mainly work on (point-of-sale terminals and servers for grocery stores), or for when I’m debugging in a controlled environment, but for the main console and GUI viewers I’ll use C++ as the development language. COM is still a bit of a pain to use from C++, at least compared to JavaScript or .NET, but it won’t be too bad.

Multiprocessor Support

Fortunately, the newer POS terminals and servers that are being installed today have multi-core processors, and I definitely want to take advantage of that today. I want to architect the core Ripsaw library to take advantage of multiple threads of execution spread across multiple processors or processor cores. I already write multi-threaded, multi-process systems for these machines, and these systems tend to be heavily instrumented, so sometimes I’m watching several different log files at once during a testing or debugging session. I don’t want to slow a system down too much when I start up the viewer, and loading down one core of a multi-core processor with a log viewer would certainly be a bad thing.

Okay, Can We Start Coding Now?

Actually, I already have been doing some prototyping, which helped me decide on the details I’ve described above. Now that I’ve sorted out some of the lower-level requirements, in the next article I’ll start defining the Ripsaw log-reader COM interface.


Leave a Reply

Your email address will not be published.