July 2005 Archives
One of the first decisions I had to make on this project is which driver type to write, a question which isn’t quite as simple as it might seem. There is a long history behind the Microsoft DDK and driver styles which dates back to early versions of Windows. Each new version of Windows brings new questions about whether the driver is 16, 32 or even 64 bit, is the driver in the kernel or out and finally what framework will I build it on.
After a bit of research the decisions become a bit clearer. The product the driver is going to become part of only runs on Windows NT type systems, ie NT, 2000, XP and 2003 server and we have no intention of supporting the 95/98 series which has been obsolete in business for at least 5 years now.
The first choice is whether to use the Microsoft universal driver model, this is a set of standard driver dll’s which come with Windows and support PCL and PostScript type printers out of the box. As a driver writer all you need to do is write the configuration information on what features your printer has and how to select them in the print file. This is a nice easy model which gives you quick results but has a couple of problems for what I need to do. The PCL output is really quite unlike PDF so there is no way I could bend it to do what I needed, PostScript is a little better but to support it I would need a full blown PostScript interpreter which is what Adobe Distiller has, a project far too large to produce on my own. The alternative to this is to write a full blown printer driver which is what I am doing.
This gives me flexibility to do pretty much what I want in the driver, the only weakness I can see so far is I can’t support encapsulated PostScript which is probably not a huge issue.
The final decision is whether the driver is going to run in user mode or kernel mode. To give you a little background to this printer drivers used to run in user mode in NT 3.51 which is the safer place for them to be, a crash in the driver won’t result in a blue screen. When NT 4 was one of the main features was an increase in performance over 3.51, to achieve this some of the drivers were moved into the kernel and so to support NT 4 I have to write a kernel mode driver. In Windows 2000 I have a choice of kernel and user mode and finally in Longhorn the choice is gone and its user mode all the way.
Debugging a kernel mode driver seems like a pretty painful process and as the long term trend is towards user mode I have decided to abandon NT 4 support and stick with a user mode driver. If I look through my web logs it seems there aren’t many NT4 clients being used and by the time the project is released I don’t think this is going to have a commercial impact.
I have just started a new programming project which involves writing a Windows printer driver for creating PDF files. This is a new type of project for me so my first thought was to search Google for information and resources on using the Windows DDK. Usually you can find lots of resources about just about any programming subject through Google but I found very little about the DDK and even less regarding printer drivers. After finding so little information online I thought it would be useful to blog about my experiences, hopefully making life a little easier for anyone else working on a similar project.
There are two reasons I started this project which will become a standard module of the main product of my software Print Distributor. The first is I have been finding a substantial number of my customers are using my software to create PDF files in conjunction with Adobe Acrobat Distiller. Making this work is far from trivial, it involves configuring my software to print to file using a PostScript driver then setting up Distiller with watched folders to convert that file to a PDF or calling Distiller with some command line options. Wanting to avoid customers having to configure options like the dialog above I decided it would be much better if the PDF creation was handled right in my software taking away the need to install Acrobat at all.
The second problem I have is customers who need to modify their output after they have printed. There are lots of reasons they might want to do this from selecting different paper trays for copies through to water-marking the final print. At the moment Print Distributor doesn’t have an option for this because we pick up the print job after it has been rendered by the printer driver, this means we can’t really modify the file because we can’t hope to understand every different format of prn file being used. By using a restricted set of PDF functions it should be reasonably easy to use PDF as an interim format as jobs pass through Print Distributor.
