[prev in list] [next in list] [prev in thread] [next in thread]
List: cifs-protocol
Subject: Re: [cifs-protocol] [REG: 110021555999716 ] Spoolss questions
From: Obaid Farooqi <obaidf () microsoft ! com>
Date: 2010-04-05 16:21:59
Message-ID: C76EE6B9CA401246BD8228089E50BC023A2E2431 () TK5EX14MBXC123 ! redmond ! corp ! microsoft ! com
[Download RAW message or body]
Hi Matthieu:
Please let me know if it answers your question.
Regards,
Obaid Farooqi
Sr. Support Escalation Engineer | Microsoft
-----Original Message-----
From: Obaid Farooqi
Sent: Friday, March 26, 2010 10:21 AM
To: Matthieu Patou
Cc: pfif@tridgell.net; cifs-protocol@samba.org; MSSolve Case Email
Subject: RE: [REG: 110021555999716 ] Spoolss questions
Hi Matthieu:
We have finished our investigation regarding your question on how to query the \
features offered by a printer driver. There is no API available to query printer \
features remotely. To query the features of a printer, the driver must be installed \
locally.
The PrintCapabilities architecture is the only way to get all of the features and \
options supported by a printer. After the driver is installed, to query the full \
print capabilities for a printer, you should use the PTGetPrintCapabilities \
(http://msdn.microsoft.com/en-us/library/dd162881.aspx) method. That will return the \
print capabilities in the XML format specified in the Print Schema \
(http://www.microsoft.com/whdc/xps/printschema.mspx) . You can also use the \
PTConvertDevModeToPrintTicket (http://msdn.microsoft.com/en-us/library/dd162879.aspx) \
function to instruct a printer driver to convert a DEVMODE into an XML print ticket \
whose format is also specified in the Print Schema. You can also use the slightly \
simpler DeviceCapabilities (http://msdn.microsoft.com/en-us/library/dd183552.aspx) \
method to get lists of bin names, resolutions, paper sizes, etc., which may make the \
feature option pairs more human-readable.
Please let me know if it answers your question. If it does, I'll consider this issue \
resolved.
Regards,
Obaid Farooqi
Sr. Support Escalation Engineer | Microsoft
-----Original Message-----
From: Matthieu Patou [mailto:mat+Informatique.Samba@matws.net]
Sent: Saturday, February 27, 2010 3:52 AM
To: Obaid Farooqi
Cc: pfif@tridgell.net; cifs-protocol@samba.org; MSSolve Case Email
Subject: Re: [REG: 110021555999716 ] Spoolss questions
On 27/02/2010 04:16, Obaid Farooqi wrote:
> Hi Metthieu:
> We have finished our investigation on your first question. I'll update you as soon \
> as I have answers for your remaining questions. Please see below for the answer. I \
> have arranged it in Question/Answer format for clarity.
> Question:
> Page 372 it is stated that:
> "FeatureOptionPairs (variable): Must be a concatenation of an even number of \
> zero-terminated ASCII strings, terminated by an additional zero character. Each \
> pair of two consecutive strings specifies a print schema feature and the currently \
> selected option."
> Which options should be included in this field ?
> What is the signification of the options, for instance the dump of the Generic / \
> Text only driver give the following array:
> options: ARRAY(10)
> [0] : 'InputBin'
> [1] : 'Option1'
> [2] : 'RESDLL'
> [3] : 'UniresDLL'
> [4] : 'Resolution'
> [5] : 'Option1'
> [6] : 'PaperSize'
> [7] : 'LETTER'
> [8] : 'Orientation'
> [9] : 'PORTRAIT'
>
> For PaperSize and Orientation it's quite obvious but for InputBin
> RESDLL or Resolution it's already not
>
> Answer:
> Windows behavior<88> of MS-RPRN will be modified in a future version of the \
> document. The changes are detailed below. I am also attaching a PDF version that \
> contains full<88> with modifications highlighted with strikethrough and color.
> First paragraph of<88> Section 2.2.2.1.4
> --------------------------------------------------
>
> Current verbiage: This is the JTEXP structure, which contains the
> _DEVMODE dmDriverExtraData defined by Windows to hold print ticket
> selection information
>
> Future verbiage: This is the JTEXP structure, which contains the
> _DEVMODE dmDriverExtraData defined by Windows to hold feature
> selection information
>
> Definition of FeatureOptionPairs (variable)
> ---------------------------------------------------
> Current Verbiage: Must be a concatenation of an even number of zero-terminated \
> ASCII strings, terminated by an additional zero character. Each pair of two \
> consecutive strings specifies a print schema feature and the currently selected \
> option.
> Future verbiage: Must be a concatenation of an even number of zero-terminated ASCII \
> strings, terminated by an additional zero character. Each pair of two consecutive \
> strings specifies a vendor-defined feature and the currently selected option for \
> that feature. Each printer driver provides its own list of features and possible \
> option values for each feature.
> Please let me know if it answers your question. If yes, I'll consider this issue \
> resolved.
So far it seems, is there a standard api to get the list of printer feature ?
Matthieu.
>
> Regards,
> Obaid Farooqi
> Sr. Support Escalation Engineer | Microsoft
>
> -----Original Message-----
> From: Matthieu Patou [mailto:mat+Informatique.Samba@matws.net]
> Sent: Sunday, February 14, 2010 3:26 PM
> To: Interoperability Documentation Help; pfif@tridgell.net;
> cifs-protocol@samba.org
> Subject: Spoolss questions
>
> Hello Dochelp Team,
>
> I've got a few questions regarding the MS-RPRN documentation, here they are:
>
> 1) Page 372 it is stated that :
> "FeatureOptionPairs (variable): Must be a concatenation of an even number of \
> zero-terminated ASCII strings, terminated by an additional zero character. Each \
> pair of two consecutive strings specifies a print schema feature and the currently \
> selected option."
> Which options should be included in this field ?
> What is the signification of the options, for instance the dump of the Generic / \
> Text only driver give the following array:
> options: ARRAY(10)
> [0] : 'InputBin'
> [1] : 'Option1'
> [2] : 'RESDLL'
> [3] : 'UniresDLL'
> [4] : 'Resolution'
> [5] : 'Option1'
> [6] : 'PaperSize'
> [7] : 'LETTER'
> [8] : 'Orientation'
> [9] : 'PORTRAIT'
>
> For PaperSize and Orientation it's quite obvious but for InputBin
> RESDLL or Resolution it's already not
>
> 2) I have the impression that the definition of the JTEXP structure defined page \
> 372 is not complete. Because here is a dump of the whole extra data field:
> 00000000 44 49 4e 55 22 00 b0 00 ec 02 00 00 ba 91 73 ca
> > DINU".........s.|
> 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > ................|
> 00000020 00 00 00 00 00 00 00 00 00 00 00 00 05 00 00 00
> > ................|
> 00000030 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > ................|
> 00000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > ................|
> *
> 00000230 01 00 00 00 00 00 00 00 00 00 00 00 b0 00 00 00
> > ................|
> 00000240 53 4d 54 4a 00 00 00 00 10 00 a0 00 47 00 65 00
> > SMTJ........G.e.|
> 00000250 6e 00 65 00 72 00 69 00 63 00 20 00 2f 00 20 00 |n.e.r.i.c.
> ./. .|
> 00000260 54 00 65 00 78 00 74 00 20 00 4f 00 6e 00 6c 00 |T.e.x.t.
> .O.n.l.|
> 00000270 79 00 00 00 49 6e 70 75 74 42 69 6e 00 4f 70 74
> > y...InputBin.Opt|
> 00000280 69 6f 6e 31 00 52 45 53 44 4c 4c 00 55 6e 69 72
> > ion1.RESDLL.Unir|
> 00000290 65 73 44 4c 4c 00 52 65 73 6f 6c 75 74 69 6f 6e
> > esDLL.Resolution|
> 000002a0 00 4f 70 74 69 6f 6e 31 00 50 61 70 65 72 53 69
> > .Option1.PaperSi|
> 000002b0 7a 65 00 4c 45 54 54 45 52 00 4f 72 69 65 6e 74
> > ze.LETTER.Orient|
> 000002c0 61 74 69 6f 6e 00 50 4f 52 54 52 41 49 54 00 00
> > ation.PORTRAIT..|
> 000002d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> > ................|
> 000002e0 00 00 00 00 00 00 00 00 00 00 00 00 |............|
> 000002ec
>
> As the feature options pair is a null terminated array of null terminated string it \
> seems to me that the end of the array is at 2cF and it leaves 28 bytes not used. Am \
> I wrong ?
> 3) Page 372 it is stated that:
> "dwOptions: The value of this field must be the number of entries in the aOptions \
> array that are initialized.
> aOptions: This field is an array that is 512 bytes in length and contains user \
> interface selections. Unused fields should be initialized to zero. The meaning of \
> the entries differs for each supported printer model. Upon receipt, the checksum of \
> this array is computed and compared to dwChecksum32. The array is used only if the \
> checksums match. "
>
> A ndrdump of this part gives:
> usedoptions : 0x00000005 (5)
> options: ARRAY(128)
> options : 0x00000002 (2)
> options : 0x00000000 (0)
> options : 0x00000000 (0)
> options : 0x00000000 (0)
> options : 0x00000000 (0)
> options : 0x00000000 (0)
> options : 0x00000000 (0)
> options : 0x00000000 (0)
> options : 0x00000000 (0)
> options : 0x00000000 (0)
> options : 0x00000000 (0)
> options : 0x00000000 (0)
> options : 0x00000000 (0)
> options : 0x00000000 (0)
> options : 0x00000000 (0)
> options : 0x00000000 (0)
> options : 0x00000000 (0)
> options : 0x00000000 (0)
> options : 0x00000000 (0)
> options : 0x00000000 (0)
> options : 0x00000000 (0)
>
> where usedoptions is dwOptions and options is aOptions.
>
> The questions are: what is the meaning of an initialized entry in the aOptions \
> array, because according to the dump we should have 5 initialized entries and we \
> have only 1 with a non null value, and what is the signification of the value of \
> the entry, is there a special meaning for each entry (ie. entry #1 is for the paper \
> size, entry #2 is for the duplex capability) Also which checksum function is used \
> how to compute it ? on which data ?
> 4) About level 101 of getprinterdriver We have currently a problem
> when replying correctly to level 101 request in getprinterdriver as
> the client is not downloading the drivers from the server, I made a
> test with a windows XP acting as a print server and in this case the
> client (also XP) is downloading the driver (see capture
> http://www.matws.net/mat/misc/xpserver_genericprinter) after the getprinterdriver \
> response. In capture http://www.matws.net/mat/misc/s3server_genericprinter we can \
> see that around packet 619, instead of requesting the drivers from the server (as \
> it was the case for xp) the client is requesting forms. Do you have an explanation \
> for this ? what is needed as an answer from the server to trigger the driver \
> download ?
>
> Regards.
> Matthieu.
>
>
_______________________________________________
cifs-protocol mailing list
cifs-protocol@cifs.org
https://lists.samba.org/mailman/listinfo/cifs-protocol
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic