Errors in the Printer Driver when building

Hi Guys!

Good day! I am currently developing a printer driver based on the samples
provided in the WDK. I was able to build and integrate a TIFF library so that
my output will be in TIFF rather than in Bitmap. My problem now is that I am
trying to put a custom property sheet in the printer driver but i am getting
these errors (see error snippet). I have already included the required
headers for the property sheet (see header snippet) but I am still getting
these errors.

I am building the code using the Windows XP checked Build Environment
provided in the WDK.

Any ideas?

Thank you!

********Error snippet***********
errors in directory c:\winddk\3790~1.183\src\print\oemdll\redmapprinter
c:\winddk\3790.1830\src\print\oemdll\redmapprinter\oemui.h(39) : error
C2061: sy
ntax error : identifier 'POEMCUIPPARAM'
c:\winddk\3790.1830\src\print\oemdll\redmapprinter\oemui.h(40) : error
C2061: sy
ntax error : identifier 'IPrintOemDriverUI'
Compiling - enable.cpp for i386
Compiling - generating code... for i386
Building Library -
c:\winddk\3790~1.183\src\print\oemdll\i386\redmapprinter.lib
for i386
LIB : error LNK1181: cannot open input file 'objchk_wxp_x86\i386\devmode.obj'
BUILD: Compile errors: not linking
c:\winddk\3790~1.183\src\print\oemdll\redmapp
rinter directory
BUILD: Done

8 files compiled - 1 Warning - 2 Errors
1 library built - 1 Error

C:\WINDDK\3790~1.183\src\print\oemdll\RedmapPrinter>

******Header Snippet*******
#include <STDDEF.H>
#include <STDLIB.H>
#include <OBJBASE.H>
#include <STDARG.H>
#include <STDIO.H>
#include <WINDEF.H>
#include <WINERROR.H>
#include <WINBASE.H>
#include <WINGDI.H>
#include <WINDDI.H>
#include <WINSPOOL.H>
#include <TCHAR.H>
#include <EXCPT.H>
#include <ASSERT.H>
#include <PRSHT.H>
#include "COMPSTUI.H"
#include <WINDDIUI.H>
#include <PRINTOEM.H>
#include <PRCOMOEM.H>

Earl
Tue Jun 05 02:06:00 CDT 2007

Hi Guys!

In addition to the post above, I discovered that I was running the printer
driver in kernel mode as stated in the 'source' and the interfaces
POEMCUIPPARAM and IPrintOemDriverUI only runs on user mode. The problem is, I
have to run the driver in kernel mode because I am using functions and
interfaces that are only available in kernel mode. Do you guys have any idea
to how can I add a property sheet on this kind of printer driver?

Thank you!

amsh82
Wed Jun 06 01:32:00 CDT 2007

hi earl,
in fact i am doing the same thing can you tell me what is this libreary and
how did you use it, could you please help me
we may help each others

"Earl" wrote:

> Hi Guys!
>
> In addition to the post above, I discovered that I was running the printer
> driver in kernel mode as stated in the 'source' and the interfaces
> POEMCUIPPARAM and IPrintOemDriverUI only runs on user mode. The problem is, I
> have to run the driver in kernel mode because I am using functions and
> interfaces that are only available in kernel mode. Do you guys have any idea
> to how can I add a property sheet on this kind of printer driver?
>
> Thank you!
>

Earl
Tue Jun 12 21:21:00 CDT 2007

Hi amsh82,

I have already discovered the source of this problem in the printer driver.
The problem lies in the driver itself because the driver, in order to print,
should be in the kernel mode. But the property page should be in user mode to
use the libraries of Windows UI. I will try to convert the printer driver to
user mode in the future so that it will run in Vista. But for now, what I did
is I created a new DLL which is in user mode and let the DLL create the
property pages. I then imported this DLL inside my printer driver to access
the values I need from the property pages.

Hope this helps.

"amsh82" wrote:

> hi earl,
> in fact i am doing the same thing can you tell me what is this libreary and
> how did you use it, could you please help me
> we may help each others
>
> "Earl" wrote:
>
> > Hi Guys!
> >
> > In addition to the post above, I discovered that I was running the printer
> > driver in kernel mode as stated in the 'source' and the interfaces
> > POEMCUIPPARAM and IPrintOemDriverUI only runs on user mode. The problem is, I
> > have to run the driver in kernel mode because I am using functions and
> > interfaces that are only available in kernel mode. Do you guys have any idea
> > to how can I add a property sheet on this kind of printer driver?
> >
> > Thank you!
> >

WeDoDrivers
Sun Jul 08 00:14:02 CDT 2007

Command line development is about 10 times slower than developing in Visual
Studio. The thing is that you have to move your project into Visual Studio,
which due to a breakthrough in technology, we have acheived. You can just
order it off of our web site.
-Jordan
----------------------------------
WeDoDrivers.com
"The Printer Driver Experts"
We handle any size printer driver project, large or small.


"Earl" wrote:

> Hi Guys!
>
> Good day! I am currently developing a printer driver based on the samples
> provided in the WDK. I was able to build and integrate a TIFF library so that
> my output will be in TIFF rather than in Bitmap. My problem now is that I am
> trying to put a custom property sheet in the printer driver but i am getting
> these errors (see error snippet). I have already included the required
> headers for the property sheet (see header snippet) but I am still getting
> these errors.
>
> I am building the code using the Windows XP checked Build Environment
> provided in the WDK.
>
> Any ideas?
>
> Thank you!
>
> ********Error snippet***********
> errors in directory c:\winddk\3790~1.183\src\print\oemdll\redmapprinter
> c:\winddk\3790.1830\src\print\oemdll\redmapprinter\oemui.h(39) : error
> C2061: sy
> ntax error : identifier 'POEMCUIPPARAM'
> c:\winddk\3790.1830\src\print\oemdll\redmapprinter\oemui.h(40) : error
> C2061: sy
> ntax error : identifier 'IPrintOemDriverUI'
> Compiling - enable.cpp for i386
> Compiling - generating code... for i386
> Building Library -
> c:\winddk\3790~1.183\src\print\oemdll\i386\redmapprinter.lib
> for i386
> LIB : error LNK1181: cannot open input file 'objchk_wxp_x86\i386\devmode.obj'
> BUILD: Compile errors: not linking
> c:\winddk\3790~1.183\src\print\oemdll\redmapp
> rinter directory
> BUILD: Done
>
> 8 files compiled - 1 Warning - 2 Errors
> 1 library built - 1 Error
>
> C:\WINDDK\3790~1.183\src\print\oemdll\RedmapPrinter>
>
> ******Header Snippet*******
> #include <STDDEF.H>
> #include <STDLIB.H>
> #include <OBJBASE.H>
> #include <STDARG.H>
> #include <STDIO.H>
> #include <WINDEF.H>
> #include <WINERROR.H>
> #include <WINBASE.H>
> #include <WINGDI.H>
> #include <WINDDI.H>
> #include <WINSPOOL.H>
> #include <TCHAR.H>
> #include <EXCPT.H>
> #include <ASSERT.H>
> #include <PRSHT.H>
> #include "COMPSTUI.H"
> #include <WINDDIUI.H>
> #include <PRINTOEM.H>
> #include <PRCOMOEM.H>

Maxim
Sun Jul 08 02:53:15 CDT 2007

> Command line development is about 10 times slower than developing in Visual
> Studio.

In what???? what is the difference between pressing the Build toolbar button
via mouse or UpArrow+Enter to repeat the BUILD command?

VS provides _nothing_ useful except a good (yes, really good) text editor and
the average debugger (worse then WinDbg). All other VS's tricks are mainly for
MS to present themselves and for newbies.

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

WeDoDrivers
Sun Jul 08 04:06:04 CDT 2007

Maxim,
To each his own. I used to work at Microsoft, so I know the drill there.
I am really just trying to help people.
I have been developing in C since 1985 and my opinion that is that
developing in Visual Studio (when properly set up) is the fastest way.
Microsoft recommends about 6 months to develop a printer driver. The same
printer driver I can do in about 2 weeks in Visual Studio. I noticed a
drastic increase since we switched.
Otherwise, why did they bother making Visual Studio?
Are you basically saying that Visual Studio is a waste of time?
I'm just trying to save people time and money. I would not mislead them and
say the command line is just as good. That's just flat out doing them a
diservice.
A lot of companies cannot afford the luxury of building from the command
line. I have worked around the world with hundreds of programmers and that's
just the reality of the situation.
That's the single biggest time consumer I have seen. That's one way that We
Do Drivers is trying to help programmers in other companies. We don't hold
anything back, unlike most of our competitors.
-Jordan

----------------------------------
WeDoDrivers.com
"The Printer Driver Experts"
We handle any size printer driver project, large or small.


"Maxim S. Shatskih" wrote:

> > Command line development is about 10 times slower than developing in Visual
> > Studio.
>
> In what???? what is the difference between pressing the Build toolbar button
> via mouse or UpArrow+Enter to repeat the BUILD command?
>
> VS provides _nothing_ useful except a good (yes, really good) text editor and
> the average debugger (worse then WinDbg). All other VS's tricks are mainly for
> MS to present themselves and for newbies.
>
> --
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> maxim@storagecraft.com
> http://www.storagecraft.com
>
>

Maxim
Sun Jul 08 11:38:21 CDT 2007

> Microsoft recommends about 6 months to develop a printer driver. The same
> printer driver I can do in about 2 weeks in Visual Studio.

I will wait for fellow MVPs to comment this :-)

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

Carey
Wed Aug 22 14:33:50 CDT 2007

"Maxim S. Shatskih" <maxim@storagecraft.com> wrote:

>> Microsoft recommends about 6 months to develop a printer driver. The same
>> printer driver I can do in about 2 weeks in Visual Studio.
>
>I will wait for fellow MVPs to comment this :-)

Not an MVP, and this is an old thread, but this demands comment.

Like anything, time to develop a print driver depends mainly on 1)
complexity of the driver, and 2) the programmer's level of experience with
print drivers.

There's a fairly steep learning curve with print drivers, and the
documentation is anything but robust, complete, and accurate. Just
discovering which statements in the doc are completely false is a slow,
painful experience. So level of experience is a huge factor. And you
can't even begin to compare the complexity of, say, a simple Unidriver and
a full monolithic driver. Apples and oranges.

It's utterly absurd to suggest that *any* IDE could reduce development
time by over 90%. No matter how slick it is, no IDE is going to help you
develop a full monolithic driver in two weeks. Not even close.

--
Carey Gregory
Windows Print Drivers & Components