I accept that there may be situations out there where a driver’s cpu usage
may turn into a performance liability, but I personally never seen it
happen. I bet if someone wrote a universal driver that implemented an IL
interpreter - don’t even need to compile - performance would be acceptable
for the great majority of the cases.
Alberto.
----- Original Message -----
From: “Tim Roberts”
To: “Windows System Software Devs Interest List”
Sent: Wednesday, December 19, 2007 1:18 PM
Subject: Re: [ntdev] how to develop a virtual printer driver?
> Alberto Moreira wrote:
>> Not to add fuel to the fire, but all it takes is a kernel-side IL
>> interpreter, and if you’re compulsive enough, a simple-minded JIT
>> compiler. One of these days I’ll get one of my best students to tackle
>> it as a Masters Degree thesis!
>
> .NET code is always JIT compiled. It is never interpreted. It would
> not be hard at all to do this, and for many classes of drivers it would
> work just fine. People I trust tell me that the performance of the
> JITted code is nearly as good as native code.
>
> The big challenge would be defining an appropriate subset of the CLR and
> rewriting it to be kernel-safe. .NET is useless without the CLR.
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
I am facing similar challenges as the original poster. (sans the C++ requirement 
)
I want to get at the EMF generated by winspool.drv. AFAICT, I should be able to read the EMF as a graphical format and later convert it to bmp or tiff at my leisure.
What stops me is that I see several companies selling metafile printer drivers for thousand of dollars. One company charges 3500 USD for their driver that is compatible with Terminal Server. And they of course want a similar sum of money for the 64-bit version… Another company “merely” wants ten grand for “all” driver versions (32-bit/64-bit XP/2003/Vista) followed by an annual maintenance fee of about a thousand dollars.
So something isn’t right here. Either this is much harder than some of the resources I’ve found indicates or…
I’ve also found “RedMon” and GhostScript which could solve my problem adequately, but RedMon is still 32-bit only and the GNU license scares my boss (our lawyer says our whole application might have to be GNUified if we bundle RedMon).
So I started reading the WDK (what, it isn’t called the DDK anymore?) docs and looked at some of the samples… I’m tempted to go in all-guns blazing, but feel the need for a sanity check with you guys first… What am I missing?
If I do make my own printer driver, do I still have to make my own port monitor to control where the output is sent? (I don’t really want to let the user mess with the settings… The output is for my app only and the user can export it from there)
On Sat, Dec 29, 2007 at 02:59:02PM -0500, xxxxx@gmail.com wrote:
I want to get at the EMF generated by winspool.drv. AFAICT, I should
be able to read the EMF as a graphical format and later convert it to
bmp or tiff at my leisure.
What stops me is that I see several companies selling metafile printer
drivers for thousand of dollars. One company charges 3500 USD for their
driver that is compatible with Terminal Server. And they of course want a
similar sum of money for the 64-bit version… Another company “merely”
wants ten grand for “all” driver versions (32-bit/64-bit XP/2003/Vista)
followed by an annual maintenance fee of about a thousand dollars.
So something isn’t right here. Either this is much harder than some of
the resources I’ve found indicates or…
It’s a problem of supply and demand. If you spend a man-year developing
a product (say US$150,000) and you know you will be selling 1,000 copies
a year, you can charge $100 and make up your investment pretty quickly.
However, the total market for EMF printer drivers is probably in the
dozens, not the thousands. To make up a $150,000 investment when your
projected total sales are less than 100, you have to charge $2,000 a
copy for it to make business sense.
If I do make my own printer driver, do I still have to make my own
port monitor to control where the output is sent? (I don’t really want
to let the user mess with the settings… The output is for my app only
and the user can export it from there)
If this is only for your own application, then why are you messing with a
printer driver at all? Can’t you just change the way you produce your
output?
Tim Roberts, xxxxx@probo.com
Providenza & Boeklheide, Inc.
On Dec 31, 2007 11:34 PM, wrote:
> If this is only for your own application, then why are you messing with a
> printer driver at all? Can’t you just change the way you produce your
> output?
It’s not my own output I’m interested in. 
I want the output of third-party applications.
Our input usually consists of scanned documents. We would like to
archive a photographic image of any document, regardless of which
application produced it… This will not be the main source of input,
but a very-nice-to-have addition.
And our application is shelfware. We do not dictate/control the setup
of our users.
My guesstimate is that a EMF virtual printer driver is closer to one
man-week rather than a man-year… Am I way off?
However, I have asked my boss to revisit the GNU license terms, and
I’m thinking of using “RedMon”
(http://pages.cs.wisc.edu/~ghost/redmon/) combined with GhostScript to
accomplish the same thing. The only drawback is that “RedMon” (a
redirection printer monitor) is still 32-bit only. The other drawback
is that Artifex claim ownership of GhostScript and asserts their own
license for commerical usage (http://artifex.com/indexlicense.htm).
(I apologize for the information overload towards the end there,
basically I would much appreciate if someone could give some hints of
the bigger pitfalls I face and which components are required. E.g. Do
I still need a port monitor if I write my own printer driver? I see no
reason why at this point)
TIA.
–
Rune
> I am facing similar challenges as the original poster. (sans
the C++ requirement )
Then the same answers apply
I want to get at the EMF generated by winspool.drv. AFAICT, I
should be able to read the EMF as a graphical format and
later convert it to bmp or tiff at my leisure.
If you only need bitmap data, stuff gets easier, then you should be able
to do this by implementing a unidrv plugin (I think, never done that).
If you really need the EMF/vector data, it is a lot more messy! Here
there are 2 ways:
-
snatch the EMF spoolfile from the spooler. The spoolfile format is
undocumented and the included EMF makes use of some extra undocumented
records, it also changes between windows versions and some service
packs. Lots of other stuff you need to workaround. If you need terminal
services, clustering, sharing support, there are even more challenges.
Most EMF drivers are implemented this way, and read the EMF data in a
custom print processor. The print driver parts are mostly just dummies.
-
build your own EMF engine, and convert the DDI calls back to GDI/EMF.
This is the “cleanest” way of implementing it, and you should not have
any problems with stuff like terminal services or 3rd party print
applications. But I think the conversion of DDI back to GDI/EMF is a big
task to develop.
I know of at least 1 product using this method.
What stops me is that I see several companies selling
metafile printer drivers for thousand of dollars. One company
charges 3500 USD for their driver that is compatible with
Terminal Server. And they of course want a similar sum of
money for the 64-bit version… Another company “merely”
wants ten grand for “all” driver versions (32-bit/64-bit
XP/2003/Vista) followed by an annual maintenance fee of about
a thousand dollars.
So something isn’t right here. Either this is much harder
than some of the resources I’ve found indicates or…
Depending on what the rates are in your area, I think it is probably
cheaper to license an existing driver, then to develop a driver by your
self with all the pitfalls to cover.
/Christoph
On Jan 2, 2008 10:32 AM, Christoph Lindemann
wrote:
> If you only need bitmap data, stuff gets easier, then you should be able
> to do this by implementing a unidrv plugin (I think, never done that).
Your words prompted me to look again:
“Unidrv Bitmap Plugin Sample”
It doesn’t support landscape and it says very large bmps are produced
for 24-bpp multipage print jobs…
But I’ll give it a whirl. Hopefully there will be a way to modify it
to split the .bmps or change graphical format. (and proper landscape
support)
Thx for the input Christoph.
I’ve also read up on XPS. The WDK comes with full XPS printer source.
(Vista only AFAICT)
–
Rune