Fw: RE: Print Driver version recognition
tpot at samba.org
Mon Jul 23 22:58:42 GMT 2001
This was caught by the spam filter.
------- start of forwarded message -------
>From jreilly at hp.com Mon Jul 23 07:33:53 2001
Message-ID: <499DC368E25AD411B3F100902740AD658D9A27 at xrose03.rose.hp.com>
From: "REILLY,JOHN R (HP-Roseville,ex1)" <jreilly at hp.com>
To: "'Vopni, Jim'" <JimV at metrics.com>
Cc: "'samba-technical at samba.org'" <samba-technical at samba.org>
Subject: RE: Print Driver version recognition
Date: Mon, 23 Jul 2001 07:38:38 -0700
> From: Vopni, Jim [mailto:JimV at metrics.com]
> Sent: Mon 23-Jul-01 5:31am
> To: 'REILLY,JOHN R (HP-Roseville,ex1)'
> Subject: Print Driver versioning
> I am attaching a copy of a patch we are using to "fix" the problem we
> having. I was going to submit this for inclusion in the 2_2 and HEAD
> but wanted to check with you first (since you were the original
> this code)
Sorry I didn't respond sooner. I put together a similar patch last
week, but various events at work prevented me from applying it.
It took a bit of searching to find conclusive evidence in MSDN that
the following was true (from MSDN search: "Porting Steps for Printer
To ensure that the driver's correct version is run on the
corresponding version of Windows NT, each print driver must be
marked with a version number in the resource file; for example:
#define VER_FILEVERSION 0,2,0,0
Version 2 drivers runs in kernel mode. The spooler ensures that
the driver is kept separate from the older, non-kernel-mode drivers.
>From XP documentation at http://www.osr.com/ddk/prtinst_4s6f.htm:
This constant should be set to a sequence of four comma-delimited
values. The third and fourth WORDs are used to set the high and low
WORDs, respectively, of the VS_FIXEDFILEINFO structure's
member. The meaning of each of the four WORDs is described in the
First WORD Reserved. This value should be set to 0.
Second WORD Represents the major version of the driver. For
drivers, set this to 0x0003. For kernel-mode drivers,
set this to 0x0002.
Even then, I tested about 12 different drivers from various
What still concerns me is that I found the attached email on the web,
indicates that "minidrivers" do not follow this convention. I have not
had time to investigate this, but the following (also from the URL
Unidrv- and Pscript5-based printer minidrivers, as well as monolithic
printer drivers (drivers developed completely by an IHV), should
use printer driver versioning on Microsoft Windows XP and
The Windows XP and later print spooler uses the versioning
to enable it to select the correct driver files during the
of a new operating system version or service pack, or when a new
Point and Print connection is established.
Printer driver versioning is not supported on Windows 2000 or
previous NT-based operating system versions. In those operating
system versions, the print spooler bases its decision on whether
to replace a particular driver file solely on the file's timestamp.
A newer file is always chosen in preference to an older file,
even though the file with the newer date might have the old feature
set. Because it is so easy to change the date of a file, this
can prevent the spooler from making the correct choice in the
files it chooses.
To ensure that the correct versions of your driver files are
simply add version numbers to those files. You can do this by
making minor modifications to pdrvver.h (which ships with the
DDK), and including that file in your printer driver DLL resource
file. Setting up a monolithic driver, using INF-based installation,
also benefits from driver versioning, because a newer DLL is not
overwritten by an older DLL, even though the older DLL might have
a more recent timestamp.
Indicates the minidriver issue may not be an issue. BUT, the versioning
test that I also added last year is most likely incorrect for NT/2K. I
only test time/date if there is no version info (see
I plan to work on that issue this week. The problem is to unambiguously
determine if a driver is XP compliant (the versions can be trusted), or
NT/2K (you need to use time/date).
> Do you see any problems with using this logic?
I'm not sure if it is safe to trust the case:
case 0: cversion = 0; break; /* Win 9x */
I'd have to do some investigation... MS doc is very spotty on this
sort of thing. It is certainly safe to continue to check for the
architect to be "WIN40" as the 9x/ME test. This is the only real
difference between your patch and mine.
Do you have any hard doc that says this can be trusted?
> Jim Vopni Software Metrics
> jimv at metrics.com 450 Philips St
> (519) 885-2458 x222 Waterloo Ont. N2L 5J2
jreilly at hp.com | jreilly at samba.org 916-785-4532 fax:916-785-8880
iIPS - internet Imaging & Printing Systems, Hewlett-Packard Co.
8000 Foothills Blvd. Roseville, CA 95747-5659 M/S: 5659
Things are much more complicated than they appear.
From: Parx Shearer
Subject: RE: [ntdev] RE: Installing NT4.0 printer minidrivers.
Sent: Thu, 12 Nov 1998 15:18:59 -0600
Originally I had the version information in my printer driver set to
184.108.40.206 for both product and file versions. Attempting to print would
fail, causing the printing application to usually display a message box
similar to "The driver for the specified printer is not installed...". I
noticed that the driver files were being installed to
At Microsoft's suggestion, I changed the version info to be more
"nt-driver-like" using the files common.ver and ntverp.h. The product
version became 4.0.1381.1 and I chose an arbitrary file version of
0.2.0.0 based on the file version of RASDD.DLL. The driver files now
install to \WINNT\system32\spool\drivers\w32x86 and
\WINNT\system32\spool\drivers\w32x86\2. And I no longer get the printing
However, I poked around on my machine looking at the version info of
several HP printer minidrivers and found that their versions were
4.0.1371.1 for both product and file versions. So printer minidrivers
may have no worry about their version info...
mailto:pshearer at dhs.com
> -----Original Message-----
> From: Windows/Steve/Scott On Behalf Of Scott Hill
> Sent: Thursday, November 12, 1998 5:44 AM
> To: 'NTDEV'
> Subject: RE: [ntdev] RE: Installing NT4.0 printer minidrivers.
> On Wednesday, November 11, 1998 9:29 PM, Parx Shearer
> [SMTP:pshearer at dhs.com] wrote:
> > I have been developing a printer driver, but not a minidriver, so I
> > be off the mark here...
> > Where does your driver file(s) get installed? From my experience,
> > version info is heavily tied to install location, and NT is very
> > about file version and product version. Normally, for Intel
> > your file(s) should get copied to system32\spool\drivers\w32x86 AND
> > system32\spool\drivers\w32x86\xxx where xxx relates to the file
> > of the driver. If product version and file version are equal, NT
> > that the driver is a win 3.1 driver, and subsequently chokes on it
> > during a print job (but not during install!).
> Well, I think I've solved the install problem - I was forgetting
> to install RasDD ! DUH !
> But, what do you mean by 'product version' and how does it
> 'choke' during a print job ? Basically it's still not printing
> properly and I thought maybe this is the problem - I need to do some
> more checking to see exactly what's going on and I'll post again when
> I know more, if I don't figure it out myself, that is.
> Scott Hill
> Scott at DDLinks.co.uk
> Software Engineer (and all round nice guy)
> Company homepage : http://www.ddlinks.demon.co.uk
> "The best trick the devil ever pulled was convincing people he didn't
> - Verbal
> "the Internet is here so we can waste time talking about nothing in
> particular when we should be working" - Marcus Hill.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
[ To unsubscribe, send email to ntdev-request at atria.com with body
UNSUBSCRIBE (the subject is ignored). ]
------- end of forwarded message -------
More information about the samba-technical