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 1.2.3.4 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);
if(ret != ERROR_CALL_NOT_IMPLEMENTED)
{
/* 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.
Felix
