On 12/08/2009 08:03 AM, Paul Vriens wrote:
On 12/07/2009 11:38 PM, Detlef Riekenberg wrote:
On So, 2009-12-06 at 19:28 +0100, Paul Vriens wrote:
Some test failures are shown on boxes with long printernames, for example:
http://test.winehq.org/data/17b7ee13fb55e872902be3156610e583e4cd324b/vista_t...
http://test.winehq.org/data/17b7ee13fb55e872902be3156610e583e4cd324b/win7_15...
And indeed if I create a local printer with a very long name the cutoff is one bigger than what the test is currently doing.
The attached patch fixes that.
I cant find a reason, why Windows is using 2 character for the terminating zero. This looks like an Windows bug. I expect a different behavior on older Windows versions.
The best test would probably to add a printer in the tests
An addprinter-test with a medium sized name is in my tree, but it needs some fixes in our Implementation. I'm testing with AddPrinter in localspl, but the 16Bit separation got a higher priority.
Any thoughts?
Manual creating printers with the specific length (CCHDEVICENAME -2 / -1 / +0 / +1) on older OS and run the tests is easy, but I cant do that before the next weekend.
I will add some printers with names of different length to my test boxes and see what the results are.
Win9x/WinMe won't let me create a printername (manually) with a name > (CCHDEVICENAME - 1)
On NT4/W2K I can create longer names but the dmDeviceName is still nicely cut off at (CCHDEVICENAME - 1) so the tests still succeed.
As of XP when I create a printer with a name greater then (CCHDEVICENAME - 1) it's cut of at 30 for dmDeviceName.
It will change the tests to deal with both. As this is the behavior of XP and later I don't think we can talk about a bug so I won't mark this as broken() for any of them.