how to develop a virtual printer driver?

I am a beginner for developing a virtual printer driver software for Windows in C++… Anybody who knows how to start the development, please reply me with your valuable suggestions… I know basics of C++… I am learning now what is a Virtual printer… So, i think you know my stage in the development procedure…

Some points of interest
-What type of virtual printer do you want to develop? The implementation
depends very much on what you want to achieve.
-It might be easier to implement it in plain c, as the DDK and the
examples are in plain c. Although it is possible to use C++, the
question is, if the scale of the project makes up for the hassle.
-You might want to base you driver on one of the examples from the DDK,
like the Plotter Driver. On the other hand, if you just need a plain
bitmap driver, you might take look at the unidriver.
-There are several open source virtual printer drivers available, which
you could take a look at.
-You might find some interesting information at
http://www.undocprint.org/winspool
-You might get help on the following mailing list
http://www.freelists.org/list/winprndev

/Christoph

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@gmail.com
Sent: Thursday, December 13, 2007 7:09 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] how to develop a virtual printer driver?

I am a beginner for developing a virtual printer driver
software for Windows in C++… Anybody who knows how to
start the development, please reply me with your valuable
suggestions… I know basics of C++… I am learning now what
is a Virtual printer… So, i think you know my stage in the
development procedure…


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 want to develop a virtual printer driver for Windows platform… It captures all kinds of images and text reports or any other application’s reports into a DICOM(A file format for image) image… It is needed for a particular sort… I need it to be developed in C++ as per guidance… I have studied all the basics of Windows platform and device driver developments… TELL ME WHERE I COULD FIND A GOOD MATERIAL(SIMPLE and EASY to UNDERSTAND) for DRIVER DEVELOPMENT in C++…
Thanks for your valuable reply…

> I want to develop a virtual printer driver for Windows

platform… It captures all kinds of images and text reports
or any other application’s reports into a DICOM(A file format
for image) image… It is needed for a particular sort…

Well this sounds like the best would be implement a full printer driver.
You probably need to implement most DDI functions to create the DICOM
data. You could use the plotter example as basis.

I need it to be developed in C++ as per guidance…

Well, then you are pretty much on your own. And need to implement
everything from scratch, as all the examples are in c. I suggest you
reconsider, especially as you are new to printer driver development. The
best way for a new beginner is to base the driver on one of the
examples, as there are lot of pitfalls when you start from scratch.

TELL ME WHERE I COULD FIND A GOOD
MATERIAL(SIMPLE and EASY to UNDERSTAND) for DRIVER
DEVELOPMENT in C++…

There is no simple and easy to understand guide. What you want to do is
a major task, and printer driver development is not very well
documented.

Paul Yao has some courses on printer driver development
http://www.paulyao.com/

Alternatively you might consider building you driver with one of the
commercially available printer driver SDKs, which shields you from much
of the pitfalls

/Christoph

thank you…

Christoph speaks wisely. Kernel driver development today uses WDK version
6000, and it is highly recommended that you use WDF. While WDF has a lot of
C++isms about it, it absolutley is NOT C++. You can use a C++ compiler and
the features of said compiler such as overloading, but your managers are
highly unwise in expecting a neophyte driver developer to produce a viable
device driver using C++ as something other than a more powerful C compiler.

TELL ME WHERE I COULD FIND A GOOD
MATERIAL(SIMPLE and EASY to UNDERSTAND) for DRIVER
DEVELOPMENT in C++…

There isn’t one … not for C++. Period. You have the WDK and this list,
with MANY experienced developers to help you with WDF development though.

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. It also was not
recommended by the majority of this list.


The personal opinion of
Gary G. Little

“Christoph Lindemann” wrote in
message news:xxxxx@ntdev…
> I want to develop a virtual printer driver for Windows
> platform… It captures all kinds of images and text reports
> or any other application’s reports into a DICOM(A file format
> for image) image… It is needed for a particular sort…

Well this sounds like the best would be implement a full printer driver.
You probably need to implement most DDI functions to create the DICOM
data. You could use the plotter example as basis.

> I need it to be developed in C++ as per guidance…

Well, then you are pretty much on your own. And need to implement
everything from scratch, as all the examples are in c. I suggest you
reconsider, especially as you are new to printer driver development. The
best way for a new beginner is to base the driver on one of the
examples, as there are lot of pitfalls when you start from scratch.

> TELL ME WHERE I COULD FIND A GOOD
> MATERIAL(SIMPLE and EASY to UNDERSTAND) for DRIVER
> DEVELOPMENT in C++…

There is no simple and easy to understand guide. What you want to do is
a major task, and printer driver development is not very well
documented.

Paul Yao has some courses on printer driver development
http://www.paulyao.com/

Alternatively you might consider building you driver with one of the
commercially available printer driver SDKs, which shields you from much
of the pitfalls

/Christoph

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