views:

267

answers:

2

I need to intercept LPT output traffic. After a couple of hours of research, I've come to understand that the only way to do this is by writing a kernel-mode driver, more precisely a "filter driver"...?

I've downloaded the WDK, but the terminology and vast number of driver types is a little overwhelming.

I'm basically trying to understand what kind of driver I should be writing; my target environment is Windows XP SP2 and 3 only.

Some background info, if it matters: I have a bunch of legacy DOS apps that print to LPT1. I'd like to be able to capture this output and redirect this data (after GDI calls) to a modern USB (network) printer. Fortunately, the latter part of the problem's easy.

I'm hoping someone could point me in the right direction. TIA.

A: 

I have a feeling you could alternatively use Detours to sniff and log traffic. I had a friend once do some very shifty things with moving things from a COM port to somewhere else using it.

I don't know for sure, but it might be easier than writing a driver from scratch.

Tom Ritter
Thanks for your answer. I think detouring CreateFile/WriteFile and friends would work, but I have a feeling that this won't work for a 16-bit app.
A: 

The sysinternals.com guys wrote an application called Portmon which would let you see what was going to serial and parallel ports.

It's a few years old (11/2006 was the last update), but it should let you log what you need at least to do some of the research.

If the applications are just DOS-based, then you should be able to write a TSR program that loads before the other program and hooks the print interrupt call, and redirect it to where you want.

You might have to brush up on your 386 assembler :)

lavinio