Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Home NTDEV
Before Posting...
Please check out the Community Guidelines in the Announcements and Administration Category.

More Info on Driver Writing and Debugging


The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.


Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/


how to develop a virtual printer driver?

suresh_techsuresh_tech Member Posts: 34
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...

Comments

  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    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: [email protected]
    > [mailto:[email protected]] On Behalf Of
    > [email protected]
    > 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
    >
  • suresh_techsuresh_tech Member Posts: 34
    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...
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    > 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
  • suresh_techsuresh_tech Member Posts: 34
    thank you...
  • Gary_Little-2Gary_Little-2 Member Posts: 379
    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:[email protected]
    > 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
  • anton_bassovanton_bassov Member MODERATED Posts: 5,187
    >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
  • Gary_Little-2Gary_Little-2 Member Posts: 379
    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:[email protected]
    > >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
    >
  • Maxim_S._ShatskihMaxim_S._Shatskih Member Posts: 10,396
    >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 :-)

    --
    Maxim Shatskih, Windows DDK MVP
    StorageCraft Corporation
    [email protected]
    http://www.storagecraft.com
  • Tim_RobertsTim_Roberts Member - All Emails Posts: 13,646
    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, [email protected]
    Providenza & Boekelheide, Inc.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • anton_bassovanton_bassov Member MODERATED Posts: 5,187
    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
  • Peter_Viscarola_(OSR)Peter_Viscarola_(OSR) Administrator Posts: 8,113
    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 Viscarola
    OSR
    @OSRDrivers

  • anton_bassovanton_bassov Member MODERATED Posts: 5,187
    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
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    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: <[email protected]>
    To: "Windows System Software Devs Interest List" <[email protected]>
    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
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    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: [email protected]
    > [mailto:[email protected]] 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, [email protected]
    > 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
    >
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    +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.
    >
  • Gary_Little-2Gary_Little-2 Member Posts: 379
    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. :)

    --
    The personal opinion of
    Gary G. Little

    wrote in message news:[email protected]
    > 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
    >
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    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. :-)

    Alberto.


    ----- Original Message -----
    From: "Gary G. Little" <[email protected]>
    Newsgroups: ntdev
    To: "Windows System Software Devs Interest List" <[email protected]>
    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. :)
    >
    > --
    > The personal opinion of
    > Gary G. Little
    >
    > <[email protected]> wrote in message news:[email protected]
    >> 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
  • Tim_RobertsTim_Roberts Member - All Emails Posts: 13,646
    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, [email protected]
    Providenza & Boekelheide, Inc.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    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. :)
    >
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    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" <[email protected]>
    To: "Windows System Software Devs Interest List" <[email protected]>
    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, [email protected]
    > 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
  • Rune_MobergRune_Moberg Member Posts: 63
    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)
  • Tim_RobertsTim_Roberts Member - All Emails Posts: 13,646
    On Sat, Dec 29, 2007 at 02:59:02PM -0500, [email protected] 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, [email protected]
    Providenza & Boeklheide, Inc.

    Tim Roberts, [email protected]
    Providenza & Boekelheide, Inc.

  • Rune_MobergRune_Moberg Member Posts: 63
    On Dec 31, 2007 11:34 PM, <[email protected]> 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
  • OSR_Community_UserOSR_Community_User Member Posts: 110,217
    > 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:

    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
  • Rune_MobergRune_Moberg Member Posts: 63
    On Jan 2, 2008 10:32 AM, Christoph Lindemann
    <[email protected]> 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
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Upcoming OSR Seminars
OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead!
Writing WDF Drivers 7 Dec 2020 LIVE ONLINE
Internals & Software Drivers 25 Jan 2021 LIVE ONLINE
Developing Minifilters 8 March 2021 LIVE ONLINE