Comctl32 tests on version 6.0

[Nikolay Sivov]

Running crossbuilt tests for comctl32 showed some failures when version 
6.0 used:

27 - imagelist
25 - rebar
130 - toolbar

(version 6.0 module used through external manifest xml in my test)
Toolbar and rebar failures show different rectangle coordinates (all 
toolbar fails are about -2 shift of y coord).

I've some questions:

0) What way is better to implement this 6.0 module - using WinSxS 
creating another separate version 6 and act like Win, or
    extend existing module (with version checking probably see next 
question)?
1) the main is about imagelist: why are we relying here on internal 
storage format? Tests show that on 6.0 this format's changed.

If the reason is to get the same structure when writing to IStream 
(to be compatible with streams saved on native platform) here's
    another question =>
2) Since wine module should be able to support "all" versions of native 
ones we need to run tests on both versions on Windows.
    Is there any way to do so easily maybe playing with activation contexts?

The reason why I'm interested in that is the implementation of 
interfaces IImageList (followed by IImageList2) and related calls

HIMAGELIST_QueryInterface from comctl32 (6.0)
SHGetImageList from shell32

All this comes from http://bugs.winehq.org/show_bug.cgi?id=15885

Any thoughts are appreciated.

Nikolay

[Reece Dunn]

2009/1/12 Nikolay Sivov :
> Running crossbuilt tests for comctl32 showed some failures when version
> 6.0 used:
>
> 27 - imagelist
> 25 - rebar
> 130 - toolbar
>
> (version 6.0 module used through external manifest xml in my test)
> Toolbar and rebar failures show different rectangle coordinates (all
> toolbar fails are about -2 shift of y coord).
>
> I've some questions:
> - What way is better to implement this 6.0 module - using WinSxS
>
> creating another separate version 6 and act like Win, or
>    extend existing module (with version checking probably see next
> question)?

In general, Wine implements the various DLLs by being version
independent. That is, they are designed to run as any version of
Windows and the corresponding DLLs that are installed.

This is why the current version of Wine implements the themed user32
components in its comctl32.dll, which is really currently <= 6. NOTE:
I haven't checked to see if it supports any manifest files to report
itself as version 6.
> - the main is about imagelist: why are we relying here on internal
>
> storage format? Tests show that on 6.0 this format's changed.

The tests are designed to ensure that Wine is compatible with Windows,
so these tests are ensuring that the data written out in Wine matches
Windows, so it can be used on a Windows client machine.

This will be the same for RPC, GDI+ region, EMF/WMF and other data formats.

NOTE: There are some failures on the Windows 7 beta machines for GDI+
which look like it is supporting version 2 and is indicating that the
region data has changed.
> If the reason is to get the same structure when writing to IStream
> (to be compatible with streams saved on native platform) here's
>    another question =>
> 2) Since wine module should be able to support "all" versions of native
> ones we need to run tests on both versions on Windows.

Correct. Ideally, the tests for comctl32 should be run using version 5
and version 6.

NOTE: This becomes especially more important when wine starts adding
support for Vista and later controls (push button with menu,
hyperlink) and Vista-specific messages.
> Is there any way to do so easily maybe playing with activation contexts?

The only way I know is to build two versions of the test program: one
without a manifest file and one with a manifest file requesting
version 6 of comctl32.

As for implementing the DLLs to report differently, I don't know.

NOTE: Vista has made a large number of the other DLLs register through
WinSxS, so if they implement new functionality/behaviour, the same
issues will apply there.
> The reason why I'm interested in that is the implementation of
> interfaces IImageList (followed by IImageList2) and related calls
>
> HIMAGELIST_QueryInterface from comctl32 (6.0)
> SHGetImageList from shell32
>
> All this comes from http://bugs.winehq.org/show_bug.cgi?id=15885
>
> Any thoughts are appreciated.

I don't have a solution - or at least an easy solution :(.

NOTE: To implement comctl32 like Windows, I suspect that the current
user32 theming should be built in the WinSxS version only. Likewise, I
suspect that the new controls and messages are only implemented in the
v6 version.

- Reece