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++…
> TELL ME WHERE I COULD FIND A GOOD
MATERIAL(SIMPLE and EASY to UNDERSTAND) for DRIVER
DEVELOPMENT in C++…
Repeatedly shouting your request IN CAPITALS is not going to get you the
information any faster, if it exists.
Also, you should wait until the US has woken up, and had a couple of
coffees, for your question to have been read by the widest part of the
mailing list.
Chill,
Tim.
Moving it to another thread will not get you any other answer than what you
have already gotten.
WHAT YOU WANT DOES NOT EXIST!!! KERNEL DRIVER DEVELOPMENT SHOULD BE DONE IN
WDF AND NOT C++. period.
Have you downloaded the WDK? Do you have a subscription to the MSDN?
–
The personal opinion of
Gary G. Little
“Tim Green” wrote in message news:xxxxx@ntdev…
> TELL ME WHERE I COULD FIND A GOOD
> MATERIAL(SIMPLE and EASY to UNDERSTAND) for DRIVER
> DEVELOPMENT in C++…
Repeatedly shouting your request IN CAPITALS is not going to get you the
information any faster, if it exists.
Also, you should wait until the US has woken up, and had a couple of
coffees, for your question to have been read by the widest part of the
mailing list.
Chill,
Tim.
> KERNEL DRIVER DEVELOPMENT SHOULD BE DONE IN WDF AND NOT C++. period.
Well, the OP speaks about *printer* driver, i.e. the type of driver that can be done in the user mode. However, this kind of project still should be done in UMDF, rather than C++, so that the main idea of your post is still perfectly valid…
Anton Bassov
Dudes, calm down- Christmas is coming! 
Printer drivers are USER MODE drivers, and lots of people develop them in C++. BUILD supports C++ exception handling and even (unless we strip it out in the WDK for some reason) ATL (MFC, but only a really old version of it, as well) when you’re building user mode drivers (after all, WDF includes UMDF and that IS C++).
Don’t know of any books [didn’t need one myself, as I was there (I was the original SDET for Win32 printing) when the model was invented], although I’ve heard of one being mentioned (in a phone interview- could have been someone trying to snow me, thinking I’d already been BSing them in making the previous statement- just love considering that kind of possibility).
Start off trying to be a peacemaker, end up being a cynic…
Still, what OP is asking for isn’t really all that outlandish. Besides, while I lost interest fast when the plugin model came along in Win2K [no challenge], IIRC the printing plugins are COM interfaces, and anyone recommending writing one of THOSE in C deserves just a smidgin or two of criticism…
I may be able to offer some old code [written while I was unemployed, and thus relatively free of the usual constraints] for a C++ monolithic driver that generated TIFFs- thing is I don’t think it’s fully functional [had mono working, but color took a while, and I eventually got a job]. If I finish it, it probably runs into moonlighting and other IP constraints- hence the *may*, as in don’t bet your life on that one…
Printer “drivers” have their own model and do not fit into the WDM idea of what a driver is. As such, UMDF is not applicable to write a printer driver. Either you use one of the 2 printer driver “port drivers” (post script or unidriver) or you implement the whole thing on your own.
d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@hotmail.com
Sent: Thursday, December 13, 2007 3:25 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] C++ book to refer for virtual printer development?
KERNEL DRIVER DEVELOPMENT SHOULD BE DONE IN WDF AND NOT C++. period.
Well, the OP speaks about *printer* driver, i.e. the type of driver that can be done in the user mode. However, this kind of project still should be done in UMDF, rather than C++, so that the main idea of your post is still perfectly valid…
Anton Bassov
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
Anton-
>
However, this kind of project still should be done in
UMDF, rather than C++,
<<
(1) Printer drivers are GDI drivers (like the old display driver model, except in user mode)- UMDF would add no value to such a project, and it fact would make it much more difficult to accomplish.
(2) You write UMDF drivers in C++ (I write KMDF drivers in C++ [have a blog post or seven in the works on that topic, actually], but weird is as weird does in my case).
Gary, we’ve been there before. There’s nothing that prevents a good driver -
WDF or WDM - to be written in C++. Maybe we should cool the rethoric down ?
I have worked with DriverWorks and DriverNetworks. I have written drivers in
C++. I know it can be done.
That said, there’s a few things one should be aware, let me list them
briefly, for the sake of all readers!
-
Beware your compiler. Some compilers aren’t very good at generating good
object oriented code. If you can, use a compiler which allows you to build
both driver and application code. -
Check your code. Use that assembly listing option in your compiler.
-
Know your machine code. Know your hardware. It’s your responsibility to
make sure that the code generated by your C++ compiler works on your machine
and fits the vagaries of the Operating System. -
Do not use features that requires calls to the C++ runtime libraries.
They’re not designed to operate on the kernel side. This is the hardest call
of them all, because you must be fully aware, at all times, of what code
your compiler generates. -
Beware recursion! The kernel-side stack is small. Also, flatten your call
structure if you can. -
Encapsulate your OS calls. The interface into the OS calls is
old-fashioned and it doesn’t fit C++ that well, so, watch out. The OS may
also interfere behind the scenes in things you’re not expecting it to get
involved with, so, again, be alert! In C++, it may be a good idea to
encapsulate your OS calls in one or more wrapper classes, so that the rest
of your driver doesn’t need to worry about the vagaries of the OS. That
brings the additional benefit that it becomes easier to port your driver to
a non-Windows OS if you need to, or to quickly replace Windows deprecated
functionality with more modern things, or - if you’re bold enough or needy
enough, or typically both - to replace the Windows implementation with your
own. -
Write to a 64-bit target. Don’t bother with 32-bit, it comes in the wash.
Avoid 32-bit types, specially standard compiler types like “int” or “long”.
One of the standing points about OO is your ability to manage your own type
environment, so, no point delegating it to the compiler. For example, in
OpenGL I’d rather use GLint than int. -
Avoid pointers if you can - use higher level types such as arrays. If you
feel the urge to use pointer arithmetic, encapsulate it in a wrapper class
so that your pointer arithmetic is localized and easy to debug. Learn how to
use references, they’re great help. -
Use Unicode throughout: forget 8-bit character sets. If nothing else,
your colleagues in Asia will be glad you did it. -
Be minimalist: only use a feature if you really need it. Applies to
everything, from inheritance and virtual functions to OS-calls: your duty as
a driver writer is to be as close to the iron and as independent from the OS
as you can. I regard anything that’s doesn’t directly map to a machine
instruction stream I can “see” in my mind through a quick inspection as a
“pay the troll” proposition: I do it, but only when I’m forced to. When in
doubt, roll your own: at least you know what code you’re generating! -
Use the MSVC IDE. It’s a piece of cake to get it to use build.exe to
build your driver, and you get all the source level benefits of using a
modern integrated environment. For example, we have a solution where the
driver is one of our projects, while the other projects are the diverse
user-side applications and libraries that are shipped with the driver: one
environment binds them all, and we added a set of “Build the Driver”, “Build
test app 1”, buttons to the IDE’s build toolbar. I also use the MSVC class
browser a lot, and its find and locate capabilities. -
Write a set of macros and maybe a plugin or two to make Windbg aware of
your key objects, and maybe of your chip’s hardware registers and other
facilities. Even if you don’t want to write a plugin, I find the Windbg
alias facility a great help.
There’s more, but I hope you get the gist.
That said, there’s a lot to gain by using C++, even if you don’t want to use
the more intense OO features of the language: merely using it as a “better
C” already makes your life easier. C++ is great for encapsulating
functionality, for being able to program with higher level objects (for
example, in OpenGL it’s easier to declare a, b and c as 3D vectors with your
own class and to say “a=b+c” than to split it out into three lines of code,
one for each coordinate), for organizing your code, and much more.
C++ is also great to get you thinking at a higher level and avoiding falling
prey to the bit-twiddling syndrome. You know, this isn’t the 60’s or 70’s
any longer! 
Alberto.
----- Original Message -----
From: “Gary G. Little”
Newsgroups: ntdev
To: “Windows System Software Devs Interest List”
Sent: Thursday, December 13, 2007 4:49 PM
Subject: Re:[ntdev] C++ book to refer for virtual printer development?
> Moving it to another thread will not get you any other answer than what
> you have already gotten.
>
> WHAT YOU WANT DOES NOT EXIST!!! KERNEL DRIVER DEVELOPMENT SHOULD BE DONE
> IN WDF AND NOT C++. period.
>
> Have you downloaded the WDK? Do you have a subscription to the MSDN?
>
> –
> The personal opinion of
> Gary G. Little
>
>
> “Tim Green” wrote in message
> news:xxxxx@ntdev…
>> TELL ME WHERE I COULD FIND A GOOD
>> MATERIAL(SIMPLE and EASY to UNDERSTAND) for DRIVER
>> DEVELOPMENT in C++…
>
> Repeatedly shouting your request IN CAPITALS is not going to get you the
> information any faster, if it exists.
>
> Also, you should wait until the US has woken up, and had a couple of
> coffees, for your question to have been read by the widest part of the
> mailing list.
>
> Chill,
> Tim.
>
>
>
> —
> 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,
I’ve written drivers, as well as embedded code in assembly, proprietary
assembly, Pascal, FORTRAN, (a few languages that pre-ceeded C whose names
elude me), C, and yes even C++. Little is ever mentioned about it, but
around 96, VC++ (4.52 I think) had a functional IDE that could be used for
creating a driver development project and supported C++. I used it to write
a C++ driver for an NT 4 system that was used for an in-flight entertainment
system. It worked. The very next driver, after attending Jamie Hanrahans
seminar, I went back to C. My next encounter with C++ was with your
DriverStudio, which I and my fellow developer recommended, and realized was
a big mistake; but I’ve gone into that, in detail, in other threads.
But that was then … this is now. I no longer limit my lables to 8
characters, because this is now, and I no longer have the limitations of a
16 bit assembler, or of the assembler for the firmware that ran the 16 bit
processor. I’ve also dumped binary to paper tape, and watched same tape get
sucked around the spindle of the cooling fan in the bottom of the cabinet.
But again … that was then … this is now, and the fact is that C++ has
been bantered around this list for years with the majority of the membership
in agreement: C++ is not recommended for use in the kernel, and in very rare
instances, a foolish decision for either management or the developer to
make.
I’m glad you are one of the rare ones.
–
The personal opinion of
Gary G. Little
“Alberto Moreira” wrote in message news:xxxxx@ntdev…
> Gary, we’ve been there before. There’s nothing that prevents a good
> driver - WDF or WDM - to be written in C++. Maybe we should cool the
> rethoric down ?
>
> I have worked with DriverWorks and DriverNetworks. I have written drivers
> in C++. I know it can be done.
>
> That said, there’s a few things one should be aware, let me list them
> briefly, for the sake of all readers!
>
> 1. Beware your compiler. Some compilers aren’t very good at generating
> good object oriented code. If you can, use a compiler which allows you to
> build both driver and application code.
>
> 2. Check your code. Use that assembly listing option in your compiler.
>
> 3. Know your machine code. Know your hardware. It’s your responsibility to
> make sure that the code generated by your C++ compiler works on your
> machine and fits the vagaries of the Operating System.
>
> 4. Do not use features that requires calls to the C++ runtime libraries.
> They’re not designed to operate on the kernel side. This is the hardest
> call of them all, because you must be fully aware, at all times, of what
> code your compiler generates.
>
> 5. Beware recursion! The kernel-side stack is small. Also, flatten your
> call structure if you can.
>
> 6. Encapsulate your OS calls. The interface into the OS calls is
> old-fashioned and it doesn’t fit C++ that well, so, watch out. The OS may
> also interfere behind the scenes in things you’re not expecting it to get
> involved with, so, again, be alert! In C++, it may be a good idea to
> encapsulate your OS calls in one or more wrapper classes, so that the rest
> of your driver doesn’t need to worry about the vagaries of the OS. That
> brings the additional benefit that it becomes easier to port your driver
> to a non-Windows OS if you need to, or to quickly replace Windows
> deprecated functionality with more modern things, or - if you’re bold
> enough or needy enough, or typically both - to replace the Windows
> implementation with your own.
>
> 7. Write to a 64-bit target. Don’t bother with 32-bit, it comes in the
> wash. Avoid 32-bit types, specially standard compiler types like “int” or
> “long”. One of the standing points about OO is your ability to manage your
> own type environment, so, no point delegating it to the compiler. For
> example, in OpenGL I’d rather use GLint than int.
>
> 8. Avoid pointers if you can - use higher level types such as arrays. If
> you feel the urge to use pointer arithmetic, encapsulate it in a wrapper
> class so that your pointer arithmetic is localized and easy to debug.
> Learn how to use references, they’re great help.
>
> 9. Use Unicode throughout: forget 8-bit character sets. If nothing else,
> your colleagues in Asia will be glad you did it.
>
> 10. Be minimalist: only use a feature if you really need it. Applies to
> everything, from inheritance and virtual functions to OS-calls: your duty
> as a driver writer is to be as close to the iron and as independent from
> the OS as you can. I regard anything that’s doesn’t directly map to a
> machine instruction stream I can “see” in my mind through a quick
> inspection as a “pay the troll” proposition: I do it, but only when I’m
> forced to. When in doubt, roll your own: at least you know what code
> you’re generating!
>
> 11. Use the MSVC IDE. It’s a piece of cake to get it to use build.exe to
> build your driver, and you get all the source level benefits of using a
> modern integrated environment. For example, we have a solution where the
> driver is one of our projects, while the other projects are the diverse
> user-side applications and libraries that are shipped with the driver: one
> environment binds them all, and we added a set of “Build the Driver”,
> “Build test app 1”, buttons to the IDE’s build toolbar. I also use the
> MSVC class browser a lot, and its find and locate capabilities.
>
> 12. Write a set of macros and maybe a plugin or two to make Windbg aware
> of your key objects, and maybe of your chip’s hardware registers and other
> facilities. Even if you don’t want to write a plugin, I find the Windbg
> alias facility a great help.
>
> There’s more, but I hope you get the gist.
>
> That said, there’s a lot to gain by using C++, even if you don’t want to
> use the more intense OO features of the language: merely using it as a
> “better C” already makes your life easier. C++ is great for encapsulating
> functionality, for being able to program with higher level objects (for
> example, in OpenGL it’s easier to declare a, b and c as 3D vectors with
> your own class and to say “a=b+c” than to split it out into three lines of
> code, one for each coordinate), for organizing your code, and much more.
>
> C++ is also great to get you thinking at a higher level and avoiding
> falling prey to the bit-twiddling syndrome. You know, this isn’t the 60’s
> or 70’s any longer!
>
>
> Alberto.
>
>
>
>
>
> ----- Original Message -----
> From: “Gary G. Little”
> Newsgroups: ntdev
> To: “Windows System Software Devs Interest List”
> Sent: Thursday, December 13, 2007 4:49 PM
> Subject: Re:[ntdev] C++ book to refer for virtual printer development?
>
>
>> Moving it to another thread will not get you any other answer than what
>> you have already gotten.
>>
>> WHAT YOU WANT DOES NOT EXIST!!! KERNEL DRIVER DEVELOPMENT SHOULD BE DONE
>> IN WDF AND NOT C++. period.
>>
>> Have you downloaded the WDK? Do you have a subscription to the MSDN?
>>
>> –
>> The personal opinion of
>> Gary G. Little
>>
>>
>> “Tim Green” wrote in message
>> news:xxxxx@ntdev…
>>> TELL ME WHERE I COULD FIND A GOOD
>>> MATERIAL(SIMPLE and EASY to UNDERSTAND) for DRIVER
>>> DEVELOPMENT in C++…
>>
>> Repeatedly shouting your request IN CAPITALS is not going to get you the
>> information any faster, if it exists.
>>
>> Also, you should wait until the US has woken up, and had a couple of
>> coffees, for your question to have been read by the widest part of the
>> mailing list.
>>
>> Chill,
>> Tim.
>>
>>
>>
>> —
>> 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
>
>
>C++. BUILD supports C++ exception handling and even (unless we strip it out
in
the WDK for some reason) ATL (MFC, but only a really old version of it, as
well)
+1.
I have a COM ATL server with some STL use (std::vector mainly) built using
BUILD.
–
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
Thanks for all your replies… I have decided to develop a USER MODE virtual printer driver in C++… Base for the rest of many functionalities is available in C in WDK. Now i am going to extend it to support my driver… HELP TOPIC: " how to display a dummy printer driver in the print properties sheet of any application ?"… Can you say where i could find some samples or references for finding my answer… Since i am a beginner i dont know much about developing it…
> going to extend it to support my driver… HELP TOPIC: " how
to display a dummy printer driver in the print properties
sheet of any application ?"… Can you say where i could find
some samples or references for finding my answer… Since i
am a beginner i dont know much about developing it…
Well as said before, take a look at the DDK. There you will find both
things:
-Reference information in the DDK documentation
-Samples in the DDK “src\print” folder. Some of it for stuff actually
included with Windows.
And as I also wrote before, there are several Open Source virtual
printer projects available. I would say they are pretty good samples:
complete projects, working and all. (but what do I know).
/Christoph