winspool.drv: Conformance-Tests

Felix Nawothnig felix.nawothnig at
Thu Aug 18 07:50:56 CDT 2005

Detlef Riekenberg wrote:
> I wrote a Commandline-Program for testing the Printing-API and found
> many misterious behaviour.
> While rewriting the conformance-tests for winspool.drv, how should we
> handle this bugs / features ?

There are several types of undocumented behaviour:

a) The documentation is plain wrong and applications will most likely 
depend on the documented behaviour (often hard to tell - an example 
would be a function which is supposed to return the needed buffer size 
but misbehaves under some conditions):

     In this case test for the documented behaviour, comment it out using
     #if 0 and add a note that foobar32.dll Version does not work
     as documented.

b) The documentation is plain wrong and it's likely that applications 
using the API will rely on the undocumented behaviour (for example if 
MSDN got the argument order wrong):

     In this case test for the undocumented behaviour and add a comment
     telling that this is undocumented.

c) The documentation is wrong, misleading or incomplete and although 
applications should not rely on the undocumented behaviour you found one 
which does (for example if a function reports failure instead of 
segfaulting when it retrieves a bad pointer):

     In this case test for the undocumented behaviour and add a comment
     telling which application depends on this undocumented behaviour.

Any other undocumented behaviour should not be tested for at all.

Disclaimer: These are my personal guidelines, so treat them as such. :-)

> Example for GetPrinterDriverDirectory (W/A):
> Win98se and WinME do not check the requested level

Just check this on NT then, but avoid using GetVersion() - I'd suggest 
to do something like:

ret = GetPrinterDriverDirectoryW(foo);
     /* Here you can test stuff which fails on 9x/ME */
else trace("GetPrinterDriverDirectoryW not implemented, skipping tests\n");

/* ... and here the stuff which successeds on both 9x/ME and NT */

> I marked that as todo("windows").
> Is this ok?

No. Until there are other third-party win32 implementations using the 
WRT (Reactos?) we use just todo_wine, nothing else.

> Another Example for GetPrinterDriverDirectory and Enum*:
> On w2k, the the returned "number of bytes required" in the ANSI-Version
> is the same as in the Unicode-Version.

I'd handle this like a).

We probably want our implementation to work as documented (since this is 
most likely what apps will depend on) but we can't test it since it 
would fail on Windows - so we comment out the test.

> For GetPrinterDriverDirectory, the rest from the unicode-version of the
> result is visible in the second part of the buffer. 
> (I Think, w2k fill the buffer with the unicode-version and convert
> in-place to ANSI. Should we do the same ?)

I'm not sure what you mean here...

If the function works as documented but fills the rest of the passed 
buffer with undefined stuff (it NUL terminates the first part, right?) 
we shouldn't test for it unless we find an app which depends on it.


More information about the wine-devel mailing list