ARev32 – Emulating Port Based Printing


When Revelation Software announced the development of ARev32 many years ago, we must confess that we were not overly enthusiastic about the news. After all, it was hard enough trying to convince our long-term Advanced Revelation (aka AREV) clients to finally upgrade their systems to OpenInsight. ARev32 seemed to be just another way for businesses to remain standing still with their legacy systems. Of course, all that changed when many of our accounts began to face the dilemma of upgrading their workstations beyond Windows XP. Yes, a full conversion to OpenInsight would still be ideal, but we had to admit that some businesses simply do not have the budget for a project of this scope. Faced with the prospect of losing the client for a cheap off-the-shelf product, we quickly discovered the value of ARev32. Suffice to say we have become converts and great admirers of this product. It is truly remarkable how well it preserves the AREV look, feel, and functionality. There are a few differences, of course, but these are typically the result of the underlying technology required to implement ARev32 as an emulated environment. Fortunately, most of these are easy to work around.

A common problem we often face is with printing. In and of itself printing in ARev32 works rather well – in many ways it handles standard reports better than AREV. This is due to the improved print management that DirectPrint – a Windows-based API – offers compared to the old DOS-based print jobs. No longer does our code have to employ various tricks to tell the print queue that the job is complete. Furthermore, ARev32 can access printers that AREV (DOS) could never support without third-party assistance, such as those connected via USB ports.

The real problem with ARev32 printing is, in a sense, the consequence of its advantages: the lack of being able to print to a port. As many will recall, when setting up the printer environment within AREV, each printer can be associated with a specific port or output device (typically LPT1, LPT2, or LPT3):


These port assignments were often more important than the printer type. If the report itself used only straight text and common control characters (e.g., Char(12)), then the printer type was immaterial. The port made sure that the output went to the correct printer. This made it easy for several workstations to have one or more local printers attached and printers could be different makes and models. Effectively, AREV was agnostic of the printer itself. Even if custom formatting was required, most laser printers supported HP PCL and most dotmatrix printers supported popular control codes such as Epson ESC/P. All that really mattered was whether the printers were compatible.

Hence, many reports were written with hard-coded calls to SETPRINTER x, where x was the number of the printer that a particular report should always be routed to. This made workflow efficient and predictable. This all changed with ARev32. Gone is the ability to conveniently assign a port. Rather, printers are now identified by their resource name in Windows:



This is due to a constraint within the DirectPrint API itself. Although it allows print jobs with ESC sequences to pass through unmodified, it still requires a Windows printer to be referenced. At first blush this might not seem like a big deal. Simply make the substitutions from the old printer ports to the new printer names and call it a day. However, as explained above, users can have different printers. This means the names of the printers would also be different. Even users with the same make and model would at times have slight variations in the names thus making it impossible to settle on one name for all users.

The astute reader and experienced AREV developer might well ask why different environments would not help to resolve the problem. Thus, simply create a unique environment for each user and assign the appropriate printer name to the relevant printer. Then all the hard-coded SETPRINTER values will continue to work. Well, yes, this could work. However, we also have better things to do than update every user profile with a custom environment, visit (or remote connect) to potentially dozens of workstations, and associate each printer with the Windows printer(s) for that machine. Furthermore, maintaining changes in printers and users would also become cumbersome.

Our solution ended up being almost too obvious and simple. Instead of worrying about installing specific printers for each model connected to each machine, we simply installed Generic / Text Only printers and assigned them to the appropriate ports. Then we began renaming these printers so they had purpose. Thus, instead of Generic / Text Only we would name them Checks, Invoices, or Labels. If we wanted to be more generic then we would use names like Laser, Dotmatrix, or Labels. In one environment we actually just named the printers as LPT1, LPT2, and LPT3. This worked out very well since we could continue to use the original AREV configuration as is:


Two final comments should be made about this. First, our solution still requires a bit of work to implement since it is unlikely these Generic / Text Only printer drivers are pre-installed. Fortunately, for our larger installations, we were able to work with the onsite IT support and have these printers deployed via a group policy change. So this meant all workstations were updated automatically after a restart. Second, we also discovered that using Generic / Text Only printer drivers appears to resolve a recent problem we have discovered with ARev32 printing in Windows 8 environments. Using manufacturer’s printer drivers simply do not work, even though they worked fine in prior versions of Windows. We aren’t sure if this is a universal issue, but we were pleased to see that our Generic / Text Only solution helped us to avoid this problem.

Leave a Reply