how to develop a virtual printer driver?

>As to a C++ development environment: what few their were no longer exsit that I am aware.

The last one available was DriverStudio by Compuware and they stopped developing
it and no longer support it.

What about Jungo framework? Is it still around?

Anton Bassov

Anton,

I’ve heard about, but know little of, Jungo … other than what some of us
here have stated, and much of that is not very pleasant. My experience with
C++ and Compuware came after I had written many drivers. Deciding to use
DriverStudio was the biggest mistake we made in that project, considering
that to get the driver to not fail verifier, I had to fix their power
management fubar.

Mark still has his C++ stuff on Hollistech, but … the same song still
holds true; KERNEL development is best done in C using KMDF, and I know
printer development has USER mode components where C++ is accecptable. It is
a major guffaw for a new driver developer, unless he/she/it is a VERY VERY
rare bird, to attempt, or be forced into their first Windows kernel
development using C++.


The personal opinion of
Gary G. Little

wrote in message news:xxxxx@ntdev…
> >As to a C++ development environment: what few their were no longer exsit
> >that I am aware.
>> The last one available was DriverStudio by Compuware and they stopped
>> developing
>> it and no longer support it.
>
> What about Jungo framework? Is it still around?
>
> Anton Bassov
>

>platform and device driver developments… TELL ME WHERE I COULD FIND A

GOOD MATERIAL(SIMPLE and EASY to UNDERSTAND) for DRIVER
DEVELOPMENT in C++…

First get the knowledge of driver writing in C, then add C++ if you want :slight_smile:


Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

Gary G. Little wrote:

Mark still has his C++ stuff on Hollistech, but … the same song still
holds true; KERNEL development is best done in C using KMDF, …

The personal opinion of
Gary G. Little

I just want to make sure that people who read the first sentence also
read your signature, because it is critically important.

ALL of my drivers are in C++: legacy, WDM, AVstream, BDA, KMDF. Most
of them use classes; a few do not. More than half of my work is in
AVStream, and in that world C++ is the rule rather than the exception.

It’s true that there are parts of the stove that are too hot to touch
without getting hurt, but that’s true both with a C stove and a C++ stove.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Gary,

It is a major guffaw for a new driver developer, unless he/she/it is a VERY VERY
rare bird, to attempt, or be forced into their first Windows kernel development using C++.

…unless his/her boss/client is an idiot. Let’s face it - arguments like " It has to be done in C++ because we do all development in a Jungo framework. This is our company’s position" are not that uncommon, are they??? Therefore, a developer may be just not in a position to make a choice of tools that he/she believes are appropriate…

Anton Bassov

In the name of all that is holy (and in the holiday season) can we PLEASE not devolve this question, which was legitimate but naive, into one of the interminable “C versus C++” or “dangers of C++” or “I’m smarter than you” debates? PLEASE?

If we insist on debating programing languages and the appropriateness thereof, I’m going to insist we debate the merits of doing driver development in C#.

WhatEVER!

Peter
OSR

Peter,

I’m going to insist we debate the merits of doing driver development in C#.

Taking into consideration the current trends in driver development, i.e. insulating driver writers from all “gory details” by various means ranging from “recommending” KMDF, minifilters,etc ( for the time being only “recommending” but I can easily foresee times when it becomes compulsory) to literally locking out “improperly-written” drivers by the PatchGuard and offering a possibility to write certain types of drivers in the user mode, I am afraid this is exactly the kind of thing that will be discussed on this forum in not-so-distant future, at least when it comes to some certain types of drivers ( and drivers that are not among these “certain types” will be only provided either by MSFT or by those on the list of MSFT-approved vendors)…

Anton Bassov

Peter,

This thing has two sides. You must also demand that posters refrain from
attacking such things as writing drivers in C++, accessing the hardware
directly, not using Microsoft-recommended techniques, and so on. Some of us
are senior enough to be able to choose which techniques we use in our own
drivers, and we are all entitled to an opinion.

So, I am sorry, but I will reserve myself the prerogative of answering
whenever some poster comes with a gratuitous attack on a driver writing
technique that I have successfully used over my several years of experience!

Alberto.

----- Original Message -----
From:
To: “Windows System Software Devs Interest List”
Sent: Saturday, December 15, 2007 4:20 AM
Subject: RE:[ntdev] how to develop a virtual printer driver?

> In the name of all that is holy (and in the holiday season) can we PLEASE
> not devolve this question, which was legitimate but naive, into one of the
> interminable “C versus C++” or “dangers of C++” or “I’m smarter than you”
> debates? PLEASE?
>
> If we insist on debating programing languages and the appropriateness
> thereof, I’m going to insist we debate the merits of doing driver
> development in C#.
>
> WhatEVER!
>
> Peter
> OSR
>
> —
> 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 think you all are missing the point.

First of all, the question was about printer driver development, so all
the stuff about WDM, KMDF… does not apply. Actually there is no kernel
mode stuff involved at all (unless you have to support < NT4 SP6). So
using C++, COM, MFC, whatever… is quiet possible, and I have done so
successfully myself.

BUT:

The OP wanted “easy and simple” samples and documentation for writing
virtual printer drivers in C++, as a beginner with no printer driver
knowledge.

And as the samples in the DDK are in C (unless you are writing for the
unidrv), I do not think it is a good idea for a beginner to jump into
printer driver development, both in C++ and starting from scratch. And
not being able to base his works on the DDK samples does not make it
simpler to avoid the pitfalls and undocumented spooler “features”

/Christoph

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Tim Roberts
Sent: Friday, December 14, 2007 11:09 PM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] how to develop a virtual printer driver?

Gary G. Little wrote:
> Mark still has his C++ stuff on Hollistech, but … the same song
> still holds true; KERNEL development is best done in C
using KMDF, …
> –
> The personal opinion of
> Gary G. Little

I just want to make sure that people who read the first
sentence also read your signature, because it is critically important.

ALL of my drivers are in C++: legacy, WDM, AVstream, BDA,
KMDF. Most of them use classes; a few do not. More than
half of my work is in AVStream, and in that world C++ is the
rule rather than the exception.

It’s true that there are parts of the stove that are too hot
to touch without getting hurt, but that’s true both with a C
stove and a C++ stove.


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

+1

I don’t design using a large framework like DriverWorks, because I think
it results in something kind of unnatural, a little more complicated and
definitely obfuscated, but I use a lot of classes, inheritance, et. c.
I think the part about using KMDF is best, without some context and
constraints, is just silly.

mm

Tim Roberts wrote:

Gary G. Little wrote:
> Mark still has his C++ stuff on Hollistech, but … the same song still
> holds true; KERNEL development is best done in C using KMDF, …
> –
> The personal opinion of
> Gary G. Little

I just want to make sure that people who read the first sentence also
read your signature, because it is critically important.

ALL of my drivers are in C++: legacy, WDM, AVstream, BDA, KMDF. Most
of them use classes; a few do not. More than half of my work is in
AVStream, and in that world C++ is the rule rather than the exception.

It’s true that there are parts of the stove that are too hot to touch
without getting hurt, but that’s true both with a C stove and a C++ stove.

Oh my goo’ness, Peter, I remember a table at the second driver developer
conference where C# was in deed discussed for drivers, and the Microsoft was
leading the charge. :slight_smile:


The personal opinion of
Gary G. Little

wrote in message news:xxxxx@ntdev…
> In the name of all that is holy (and in the holiday season) can we PLEASE
> not devolve this question, which was legitimate but naive, into one of the
> interminable “C versus C++” or “dangers of C++” or “I’m smarter than you”
> debates? PLEASE?
>
> If we insist on debating programing languages and the appropriateness
> thereof, I’m going to insist we debate the merits of doing driver
> development in C#.
>
> WhatEVER!
>
> Peter
> OSR
>

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!

If I do it fast enough, that individual will have a great chance of being
hired by Microsoft to implement it on their next driver development kit. :slight_smile:

Alberto.

----- Original Message -----
From: “Gary G. Little”
Newsgroups: ntdev
To: “Windows System Software Devs Interest List”
Sent: Tuesday, December 18, 2007 9:20 AM
Subject: Re:[ntdev] how to develop a virtual printer driver?

> Oh my goo’ness, Peter, I remember a table at the second driver developer
> conference where C# was in deed discussed for drivers, and the Microsoft
> was leading the charge. :slight_smile:
>
> –
> The personal opinion of
> Gary G. Little
>
> wrote in message news:xxxxx@ntdev…
>> In the name of all that is holy (and in the holiday season) can we PLEASE
>> not devolve this question, which was legitimate but naive, into one of
>> the interminable “C versus C++” or “dangers of C++” or “I’m smarter than
>> you” debates? PLEASE?
>>
>> If we insist on debating programing languages and the appropriateness
>> thereof, I’m going to insist we debate the merits of doing driver
>> development in C#.
>>
>> WhatEVER!
>>
>> Peter
>> OSR
>>
>
>
>
> —
> 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

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.

I almost posted to ask whether this has ever been discussed/threatened,
because it seemed like the sort of thing that might come up. Actually,
I was thinking .NET, but same idea.

mm

Gary G. Little wrote:

Oh my goo’ness, Peter, I remember a table at the second driver developer
conference where C# was in deed discussed for drivers, and the Microsoft was
leading the charge. :slight_smile:

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 :slight_smile: )

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. :wink:

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 :slight_smile: )

Then the same answers apply :wink:

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:

  1. 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.

  2. 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