none
Converting REG_BINARY into a string value

    Question

  • Hi,

    I am trying to convert the DRIVERVERSION REG_BINARY key located in HKLM\SYSTEM\CurrentControlSet\Control\Print\Environments\Windows NT x86\Drivers\Version-3\xxxx into a readable string using PowerShell.

    Any thoughts to how i can achieve this?

    Thanks,

    Scott

    Monday, February 20, 2012 12:35 PM

Answers

  • Hi jv,

    Take a careful look at my post. I am examining a DLL file on my system called BROHLA7A.DLL. As I mentioned, the GetVersionInfo method returns a FileVersionInfo object, and the FileVersionInfo object has a FileVersion property. In this specific case, the FileVersion property returns "1.08", but this is different from what the CIM_DataFile's Version property returns. As I said, I don't know the reason (yet) for the discrepancy. Everything else (Windows Explorer, CIM_DataFile object's Version property, FileSystemObject object's GetFileVersion method, GetFileVersionInfo API, etc.) reports the file's version as 0.3.0.0, not 1.08. As I said, you can get the correct file version by putting the parts together yourself (FileMajorPart, FileMinorPart, etc.).

    Bill


     

    Yes I know.  That is why I used the method I used.  It returns the correct version for a driver.  This seems to only affect drivers.  The file version is correct.  WMI and other utilities report the driver layer version and in a funny way. 

    This reports 0.3.0.0  If you have a 2.0 driver it will report 0.2.0.0 I believe.

    Look at the folder where the drivers are stored.  They are <path to architecture>\3\driver.

    The parent folder is '2' for layer or version 2 drivers.

    I think the DDK has an explanation of this but I so not remember the exact details. 

    I just went and checked this on Windows WS2008R2 in both the x32 and x64 folders.  All true driver files (not helper or resource) exhibit this in the GUI and in WMI.  Fileinfo.VersionInfo shows the correct value for both fields and if we use an executable inspector the header of the DLL is also correct.

    This is a similar issue with using the registry to extract version.  The utilities uses the drive layer version entry and do not use the FileVersion entry which is also wrong at times. The File Version should be 4 16 bit values (8 bytes, With the four elements of version.  Some installers set this incorrectly.  The driver installer should never set this because the system sets it when it installs the driver.  I always thought that it was being set when the driver was started but apparently it is only set when the driver is installed.

    Remember also that these drivers are not system device drivers.  They are user mode drivers that are used to render a document before sending it to the spooler.  They are the GDI device layer that a program uses to format a document.  This is then sent to the spooler either locally or remotely and the spooler then uses this to call the physical device driver that transfers the rendered and translated output to the printer.  This is what allows us to send output to almost any type of device and have it appear pretty much the same on each device.  An HP color laser printer will print a page almost exactly the same as a Toshiba InkJet color printer because the device context controls how the image is rendered and allows the vendor to supply a GDI layer that supports their printer.


    ¯\_(ツ)_/¯

    • Marked as answer by bodum1 Friday, March 09, 2012 9:49 AM
    Wednesday, February 22, 2012 6:58 PM
  • Is there a way to read the files in the script to look for a version number?

    That is what I posted before:

    $driver=gwmi win32_printerdriver -filter 'name like "%HP Inkjet 2100x%"'
    ((get-item $driver.DriverPath).VersionInfo).ProductVersion

    This will display the product version as a string.


    ¯\_(ツ)_/¯

    • Marked as answer by bodum1 Friday, March 09, 2012 9:47 AM
    Tuesday, February 21, 2012 2:00 PM

All replies

  • This displays the value stored in DriverVersion:


    (get-itemproperty "HKLM:\SYSTEM\CurrentControlSet\Control\Print\Environments\Windows NT x86\Drivers\Version-3\..." "DriverVersion").Driverversion


    Monday, February 20, 2012 1:04 PM
    Moderator
  • @JBrasser:  Your code insert doesn't render properly.  All I can see is a horizontal scroll bar.  What does it look like from your side?

    Maybe try re-posting it?  I can't see it at all.


    Grant Ward, a.k.a. Bigteddy

    What's new in Powershell 3.0 (Technet Wiki)

    Monday, February 20, 2012 2:42 PM
  • Copy the whole message and paste it into another application, like Notepad and it will render correctly as text ...

    This displays the value stored in DriverVersion:

    (get-itemproperty "HKLM:\SYSTEM\CurrentControlSet\Control\Print\Environments\Windows NT x86\Drivers\Version-3\..." "DriverVersion").Driverversion

    (Is anyone else annoyed by the recent change in the UI here?)


    Tom Lavedas


    Monday, February 20, 2012 2:48 PM
    Moderator
  • Sorry I did see the scrollbar but I was able to see the code as well. Here is what I posted:

    (get-itemproperty "HKLM:\SYSTEM\CurrentControlSet\Control\Print\Environments\Windows NT x86\Drivers\Version-3\..." "DriverVersion").Driverversion

    To satisfy the complete request by the original posted this piece of code would convert the value to a string as well:

    (get-itemproperty "HKLM:\SYSTEM\CurrentControlSet\Control\Print\Environments\Windows NT x86\Drivers\Version-3\..." "DriverVersion").Driverversion | foreach-object {[string]$tempstring += $_}

    Monday, February 20, 2012 2:48 PM
    Moderator
  • Copy the whole message and paste it into another application, like Notepad and it will render correctly as text ...

    (Is anyone else annoyed by the recent change in the UI here?)


    Tom Lavedas


    Just a bit.  I'm fighting with Brent Serbus and Ed Price over this exact issue.  See the following thread:

    http://social.technet.microsoft.com/Forums/en-US/reportabug/thread/9a3344f9-9e14-459a-9349-77466f7bc823

    Grant Ward, a.k.a. Bigteddy

    What's new in Powershell 3.0 (Technet Wiki)

    Monday, February 20, 2012 2:52 PM
  • (Is anyone elese annoyed by the recent change in the UI here?)


    Tom Lavedas

    Yes, for sure. Some of it here.

    http://social.msdn.microsoft.com/Forums/en-US/reportabug/threads

    If you remove "technet" from URL or just replace it with "msdn" it will help. (at least temporarily)

     

     

     


    Regards, Dave Patrick ....
    Microsoft Certified Professional
    Microsoft MVP [Windows]

    Monday, February 20, 2012 2:52 PM
  • Now i am trying to get this running against a remote server. Ideas?

    Thanks for the input thus far

    Monday, February 20, 2012 2:54 PM
  • There is several ways you can make this work either by launching this powershell script remotely, the easiest perhaps is by running 

    invoke-command -ComputerName computer1 -scriptblock {(get-itemproperty "HKLM:\SYSTEM\CurrentControlSet\Control\Print\Environments\Windows NT x86\Drivers\Version-3\..." "DriverVersion").Driverversion}

    This only works if the computer you are targetting has Powershell 2.0 installed. 

    And yes the forum is bugging out a lot here as well, submit buttons not appearing. Code blocks refusing to be created. Cut and pasting posts in and out the forum just to get it to work. I am not a happy poster either...

    Monday, February 20, 2012 3:48 PM
    Moderator
  • This is against a W2K3 server without powershell installed.
    Monday, February 20, 2012 4:47 PM
  • I am trying to convert the DRIVERVERSION REG_BINARY key located in HKLM\SYSTEM\CurrentControlSet\Control\Print\Environments\Windows NT x86\Drivers\Version-3\xxxx into a readable string using PowerShell.

    Hi,

    What is the purpose/goal?

    Bill

    Monday, February 20, 2012 4:57 PM
    Moderator
  • I would like to write a script that interogates a Windows 2003 server for the installed print driver versions (located in the key above). The issue i am having is the key is a binary value, so i would like to have a means to convert it into a reader friendly string.

    Thanks

    Monday, February 20, 2012 5:05 PM
  • This is against a W2K3 server without powershell installed.

    This will get the name and version of all  remote pronter drivers using WMI. No remote PowerShell is needed.

    gwmi win32_printerdriver|select name,version -computer $computer


    ¯\_(ツ)_/¯



    • Proposed as answer by Bigteddy Monday, February 20, 2012 5:22 PM
    • Unproposed as answer by bodum1 Monday, February 20, 2012 5:27 PM
    • Edited by jrv Monday, February 20, 2012 5:58 PM
    Monday, February 20, 2012 5:10 PM
  • You could also use this vbscript which you can run either remotely or locally on the 2003 server:

    const HKEY_LOCAL_MACHINE = &H80000002 
    strKeyPath = "SYSTEM\CurrentControlSet\Control\Print\Environments\Windows NT x86\Drivers\Version-3\xxxx"
    strValueName = "DRIVERVERSION"
    strComputer = "."
    dim iValues(3)
    Set oReg=GetObject( _
       "winmgmts:{impersonationLevel=impersonate}!\\" & _ 
        strComputer & "\root\default:StdRegProv")
    oReg.GetBinaryValue HKEY_LOCAL_MACHINE,strKeyPath,_
        strValueName,iValues
    For i = lBound(iValues) to uBound(iValues)
    Wscript.Echo iValues(i)
    Next


    Monday, February 20, 2012 5:28 PM
    Moderator
  • Unfortunately the version number through WMI is not the version number marked in the registry. All values through WMI show as 3 (which i believe is the driver type)
    Monday, February 20, 2012 5:28 PM
  • Unfortunately the version number through WMI is not the version number marked in the registry. All values through WMI show as 3 (which i believe is the driver type)

    I get the same result with jv's code, but I thought it was just my machine, because all my drivers are virtual printers.

    Grant Ward, a.k.a. Bigteddy

    What's new in Powershell 3.0 (Technet Wiki)

    Monday, February 20, 2012 5:35 PM
  • You can modify the following code to query the value of a remote registry key:

    $srv = 'grant-pc'
    $key = "SOFTWARE\Microsoft\Windows\CurrentVersion"
    $type = [Microsoft.Win32.RegistryHive]::LocalMachine
    $regKey = [Microsoft.Win32.RegistryKey]::OpenRemoteBaseKey($type, $Srv)
    $reg = $regKey.OpenSubKey($key)
    $reg.GetValue('ProgramFilesDir')


    Grant Ward, a.k.a. Bigteddy

    What's new in Powershell 3.0 (Technet Wiki)



    • Edited by Bigteddy Monday, February 20, 2012 5:44 PM
    Monday, February 20, 2012 5:41 PM
  • You can modify the following code to query the value of a remote registry key:

    $srv = 'grant-pc'
    $key = "SOFTWARE\Microsoft\Windows\CurrentVersion"
    $type = [Microsoft.Win32.RegistryHive]::LocalMachine
    $regKey = [Microsoft.Win32.RegistryKey]::OpenRemoteBaseKey($type, $Srv)
    $reg = $regKey.OpenSubKey($key)
    $reg.GetValue('ProgramFilesDir')


    Grant Ward, a.k.a. Bigteddy

    What's new in Powershell 3.0 (Technet Wiki)



    Cleaner I like it. I would just add this to the end so the value ends up on a single line:

    $regkey.GetValue('DRIVERVERSION') |  foreach-object {[string]$tempstring += $_,""}
    $tempstring

    Monday, February 20, 2012 5:48 PM
    Moderator
  • OK - Nearly there, however i need a way to covert it now?

    PS C:\Windows\system32> $reg.GetValue('DRIVERVERSION')
    119
    15
    206
    14
    2
    0
    5
    0

    Monday, February 20, 2012 6:03 PM
  • The WMI mehod is the only method guaranteed to return the printer driver verison.  The registry does not contain the driver verion for all drivers.  WMI uses a system API to query the driver fot its 'runing' version.

    The following can bemodifed to add a remote computer name.

    gwmi win32_printerdriver|select name,version

    (gwmi win32_printerdriver -filter 'name like "%PDFCreator%"').Version

    Both return strings but the second may need you t extract the string in the remainder of your code.

    I ran through the registry on a large print spooler. Only half of teh drivers actulay produced a legitimate value for the version number .  Many registry versions were set to all zeros.


    ¯\_(ツ)_/¯

    Monday, February 20, 2012 6:05 PM
  • OK - Nearly there, however i need a way to covert it now?

    PS C:\Windows\system32> $reg.GetValue('DRIVERVERSION')
    119
    15
    206
    14
    2
    0
    5
    0


    How do you need to convert it?  Are those figures correct?  Does each one represent a printer?

    Grant Ward, a.k.a. Bigteddy

    What's new in Powershell 3.0 (Technet Wiki)

    Monday, February 20, 2012 6:12 PM
  • OK - Nearly there, however i need a way to covert it now?

    PS C:\Windows\system32> $reg.GetValue('DRIVERVERSION')
    119
    15
    206
    14
    2
    0
    5
    0

    What would you like to convert it to?
    Monday, February 20, 2012 6:18 PM
    Moderator
  • OK - Nearly there, however i need a way to covert it now?

    PS C:\Windows\system32> $reg.GetValue('DRIVERVERSION')
    119
    15
    206
    14
    2
    0
    5
    0


    How do you need to convert it?  Are those figures correct?  Does each one represent a printer?

    Grant Ward, a.k.a. Bigteddy

    What's new in Powershell 3.0 (Technet Wiki)

    Look at the keys.  It is binary.  It is also not necessarily the driver verion you are interested in.

    Only the driver API can return the correct version.  The binary is an arry of versions for the different driver layers.

    The WMI that I posted earlier uses the driver API to get the decoded and correct version information directly.


    ¯\_(ツ)_/¯

    Monday, February 20, 2012 7:00 PM
  • Unfortunately the version number through WMI is not the version number marked in the registry. All values through WMI show as 3 (which i believe is the driver type)

    That is correct.  The driver is version 3 for this kind of driver.

    If you want the file version the WMI also gas the file which you can query for the version.

    $driver=gwmi win32_printerdriver -filter 'name like "%HP Inkjet 2100x%"'
    ((get-item $driver.DriverPath).VersionINfo).ProductVersion

    There are also numerous other files that make up what is referred to as a driver.  In this case we have

    gwmi win32_printerdriver -filter 'name like "%PDFCreator%"'|
         select datafile,DependentFiles,DriverPath,HelpFile| fl

    FOr locally attached printers the driver is a completely diferent thing and is a driver as apposed to being a user mode driver which is really just a formatter.


    ¯\_(ツ)_/¯

    Monday, February 20, 2012 7:17 PM
  • Is there a way to read the files in the script to look for a version number?
    Tuesday, February 21, 2012 1:25 PM
  • Yes there is:

    gwmi win32_printerdriver | foreach-object {get-item $_.driverpath | select *}

    This will list all the properties of all the print drivers loaded. You can filter out the information you require using the select statement.

    Tuesday, February 21, 2012 1:38 PM
    Moderator
  • Is there a way to read the files in the script to look for a version number?

    That is what I posted before:

    $driver=gwmi win32_printerdriver -filter 'name like "%HP Inkjet 2100x%"'
    ((get-item $driver.DriverPath).VersionInfo).ProductVersion

    This will display the product version as a string.


    ¯\_(ツ)_/¯

    • Marked as answer by bodum1 Friday, March 09, 2012 9:47 AM
    Tuesday, February 21, 2012 2:00 PM
  • Hi,

    This is interesting. The FileVersionInfo class (returned by the [System.Diagnostics.FileVersionInfo]::GetVersionInfo method, which is the same thing that the PowerShell VersionInfo ScriptProperty is returning) returns incorrect results for me in some cases. The CIM_DataFile class Version property is correct and shows what Explorer shows. Example:

    PS C:\> $driverPath = (get-wmiobject Win32_PrinterDriver -filter "Name LIKE 'Brother HL%'").DriverPath
    PS C:\> $driverPath
    C:\Windows\system32\spool\DRIVERS\x64\3\BROHLA7A.DLL
    PS C:\> $fileInfo = get-item $driverPath
    PS C:\> $fileInfo.VersionInfo.FileVersion
    1.08
    PS C:\> ([WMI] "\\.\root\CIMV2:CIM_DataFile.Name='$driverPath'").Version
    0.3.0.0
    

    I don't know the details behind the discrepancy, but you can work around it by building the string yourself:

    PS C:\> $verInfo = $fileInfo.VersionInfo
    PS C:\> "{0}.{1}.{2}.{3}" -f $verInfo.FileMajorPart, $verInfo.FileMinorPart, $verInfo.FileBuildPart, $verInfo.FilePrivatePart
    0.3.0.0
    

    HTH,

    Bill

    Tuesday, February 21, 2012 5:04 PM
    Moderator
  • An interesting bit in regards to what AbqBill reported, I have compared the output Powershellv2/WMI are giving me on two different machines, XP and Server2008R2 to compare the results. Here is what I got from the XP machine:

    PS > ([WMI] "\\.\root\CIMV2:CIM_DataFile.Name='$driverpath'").Version
    6.1.7600.20630 (win7_ldr.100128-1505)
    PS > $verinfo.fileversion
    6.1.7600.20630 (win7_ldr.100128-1505)
    PS > "{0}.{1}.{2}.{3}" -f $verinfo.filemajorpart,$verinfo.fileminorpart,$verinfo.filebuildpart,$verinfo.fileprivatepart
    0.3.7600.20630

    Which matches when I click the file properties, partially at least. This is the file viewed from an XP workstation:

    And this is the same file but viewed from a Server 2008 R2 machine:

    PS > ([WMI] "\\.\root\cimv2:cim_datafile.name='$driverpath'").version
    0.3.7600.20630
    PS > $fileinfo.versioninfo.fileversion
    6.1.7600.20630 (win7_ldr.100128-1505)
    PS > "{0}.{1}.{2}.{3}" -f $verinfo.filemajorpart,$verinfo.fileminorpart,$verinfo.filebuildpart,$verinfo.fileprivatepart
    0.3.7600.20630


    So kernel version seems to be a part in this, so does anyone know why this behaviour is occuring?

    Wednesday, February 22, 2012 7:25 AM
    Moderator
  • Two different operating Systems and two differnt files.  YOu cannot compare these two in any way.

    As I pointed out above obbly this is correct for waht you are lookin for>
    $fileinfo.versioninfo.fileversion

    The other numbers relatre to teh system driver layer and not to the driver file version.


    ¯\_(ツ)_/¯

    Wednesday, February 22, 2012 10:50 AM
  • Two different operating systems, the same file. The point is that $fileinfo.versioninfo.fileversion is not giving the same results as the WMI query and not the same result as viewing the file properties using the GUI.

    What I did was tested AbqBill's statement using the same file, the same methods on two different O/S systems and by doing so confirmed what he was experiencing.

    Wednesday, February 22, 2012 11:23 AM
    Moderator
  • Two different operating systems, the same file. The point is that $fileinfo.versioninfo.fileversion is not giving the same results as the WMI query and not the same result as viewing the file properties using the GUI.

    Two different operating systems two different files.

    Each OS produces slightly differeing views of the file due to changes in the OS.

    Be sure you are pointing at two 32 bit versions or two 64 bit versins.

    There are two differnt bits at play here.  They don't read-out as you expect.

    The fileversion of the file object is what you are looking for.  In the case of patches you may have to also compare timestamps. See the Microsoft literature for more information about how file versions are tracked.


    ¯\_(ツ)_/¯

    Wednesday, February 22, 2012 11:31 AM
  • I literally copied the file from the XP machine to the Server 2008 machine and then targetted that file with the commands I listed in my examples above. What I noticed was that the 


    ([WMI] "\\.\root\cimv2:cim_datafile.name='$driverpath'").version


    Matches what is shown in the GUI, $fileinfo.versioninfo.fileversion comes up with a different version number.


    In Server 2008R2 GUI/WMI shows:


    $fileinfo.versioninfo.filemajorpart,$fileinfo.versioninfo.fileminorpart,$fileinfo.versioninfo.filebuildpart,$fileinfo.versioninfo.verinfo.fileprivatepart


    $fileinfo.versioninfo.fileversion gives:


    $fileinfo.versioninfo.productmajorpath,$fileinfo.versioninfo.productminorpath,$fileinfo.versioninfo.filebuildpart,$fileinfo.versioninfo.verinfo.fileprivatepart,<text string>


    This is an actual difference and I am just curious as to why. If you have links to any Microsoft documentation describing this subject I would be glad to read up on it.


    Wednesday, February 22, 2012 11:55 AM
    Moderator
  • Ther eis product version and file version.

    The GUI gets its information by querying the file directly in other ways I believe.  The FieInfo is usually correct in all circumstances.

    When support asks for version they always want to look at the fileversion info.  The date and file version are most important.  The date helps to nail teh exact patch level including custom patches.

    It is not a perfect world yet.


    ¯\_(ツ)_/¯

    Wednesday, February 22, 2012 12:01 PM
  • Hi jv,

    Take a careful look at my post. I am examining a DLL file on my system called BROHLA7A.DLL. As I mentioned, the GetVersionInfo method returns a FileVersionInfo object, and the FileVersionInfo object has a FileVersion property. In this specific case, the FileVersion property returns "1.08", but this is different from what the CIM_DataFile's Version property returns. As I said, I don't know the reason (yet) for the discrepancy. Everything else (Windows Explorer, CIM_DataFile object's Version property, FileSystemObject object's GetFileVersion method, GetFileVersionInfo API, etc.) reports the file's version as 0.3.0.0, not 1.08. As I said, you can get the correct file version by putting the parts together yourself (FileMajorPart, FileMinorPart, etc.).

    Bill

    Wednesday, February 22, 2012 3:51 PM
    Moderator
  • Hi jv,

    Take a careful look at my post. I am examining a DLL file on my system called BROHLA7A.DLL. As I mentioned, the GetVersionInfo method returns a FileVersionInfo object, and the FileVersionInfo object has a FileVersion property. In this specific case, the FileVersion property returns "1.08", but this is different from what the CIM_DataFile's Version property returns. As I said, I don't know the reason (yet) for the discrepancy. Everything else (Windows Explorer, CIM_DataFile object's Version property, FileSystemObject object's GetFileVersion method, GetFileVersionInfo API, etc.) reports the file's version as 0.3.0.0, not 1.08. As I said, you can get the correct file version by putting the parts together yourself (FileMajorPart, FileMinorPart, etc.).

    Bill


    Yes I know.  That is why I used the method I used.  It returns the correct verion for a driver.  This seems to only affect drivers.  The file version is correct.  WMI and other utilities report teh driver layer version and in a funny way. 

    This reports 0.3.0.0  If you have a 2.0 driver it will report 0.2.0.0 I believe.

    Look at teh folder where the drivers are stored.  They are <path to architecture>\3\driver.

    The parent folder is '2' for layer or version 2 drivers.

    I think the DDK has an explanation of this but I so not remember the exact details.


    ¯\_(ツ)_/¯

    Wednesday, February 22, 2012 6:36 PM
  • Hi jv,

    Take a careful look at my post. I am examining a DLL file on my system called BROHLA7A.DLL. As I mentioned, the GetVersionInfo method returns a FileVersionInfo object, and the FileVersionInfo object has a FileVersion property. In this specific case, the FileVersion property returns "1.08", but this is different from what the CIM_DataFile's Version property returns. As I said, I don't know the reason (yet) for the discrepancy. Everything else (Windows Explorer, CIM_DataFile object's Version property, FileSystemObject object's GetFileVersion method, GetFileVersionInfo API, etc.) reports the file's version as 0.3.0.0, not 1.08. As I said, you can get the correct file version by putting the parts together yourself (FileMajorPart, FileMinorPart, etc.).

    Bill


     

    Yes I know.  That is why I used the method I used.  It returns the correct version for a driver.  This seems to only affect drivers.  The file version is correct.  WMI and other utilities report the driver layer version and in a funny way. 

    This reports 0.3.0.0  If you have a 2.0 driver it will report 0.2.0.0 I believe.

    Look at the folder where the drivers are stored.  They are <path to architecture>\3\driver.

    The parent folder is '2' for layer or version 2 drivers.

    I think the DDK has an explanation of this but I so not remember the exact details. 

    I just went and checked this on Windows WS2008R2 in both the x32 and x64 folders.  All true driver files (not helper or resource) exhibit this in the GUI and in WMI.  Fileinfo.VersionInfo shows the correct value for both fields and if we use an executable inspector the header of the DLL is also correct.

    This is a similar issue with using the registry to extract version.  The utilities uses the drive layer version entry and do not use the FileVersion entry which is also wrong at times. The File Version should be 4 16 bit values (8 bytes, With the four elements of version.  Some installers set this incorrectly.  The driver installer should never set this because the system sets it when it installs the driver.  I always thought that it was being set when the driver was started but apparently it is only set when the driver is installed.

    Remember also that these drivers are not system device drivers.  They are user mode drivers that are used to render a document before sending it to the spooler.  They are the GDI device layer that a program uses to format a document.  This is then sent to the spooler either locally or remotely and the spooler then uses this to call the physical device driver that transfers the rendered and translated output to the printer.  This is what allows us to send output to almost any type of device and have it appear pretty much the same on each device.  An HP color laser printer will print a page almost exactly the same as a Toshiba InkJet color printer because the device context controls how the image is rendered and allows the vendor to supply a GDI layer that supports their printer.


    ¯\_(ツ)_/¯

    • Marked as answer by bodum1 Friday, March 09, 2012 9:49 AM
    Wednesday, February 22, 2012 6:58 PM
  • Hi,

    Thanks for the explanation; I wasn't aware of this driver versioning convention.

    Bill

    Wednesday, February 22, 2012 9:27 PM
    Moderator
  • Hi,

    Thanks for the explanation; I wasn't aware of this driver versioning convention.

    Bill

    If you really need the details I recommend looking through the DDK.  It has been some time and I can't say I remember allof the details perfectly.  I do know that driver versions have alweays been a headache and the file object does it best.


    ¯\_(ツ)_/¯

    Wednesday, February 22, 2012 10:00 PM
  • Bodum1,

    If your question has been answered, please mark the reply (or replies) above that answered your question.


    Richard Mueller - MVP Directory Services

    Friday, March 09, 2012 1:16 AM
    Moderator