February 2010 - Wine-Devel - list.winehq.org

Re: Several msxmlX modules

by Nikolay Sivov

On 2/2/2010 20:28, Reece Dunn wrote: > On 2 February 2010 16:19, Nikolay Sivov<bunglehead(a)gmail.com> wrote: > >> Hi. >> >> Wine currently has only one module for MSXML parser - msxml3. Since the >> third one v4 and v6 are already out. >> > There is also an msxml 5. This is only available via Office 2003/2007, > and is installed by that. See http://support.microsoft.com/kb/269238 > ["List of Microsoft XML Parser Versions"]. > > >> Judging from file size I don't think native modules reuse some code between >> them, instead it looks like a completely >> independent builds. >> > http://msdn.microsoft.com/en-gb/library/ms753751%28VS.85%29.aspx > ["What's new on msxml"] gives an overview of the features introduced > by the different versions of msxml. > > For example, msxml 4 has a new parser that is enabled by the > setProperty("NewParser", true) call on the MSXML DOMDocument > interface. > If there's no such property in earlier versions there's no reason for app to use it, there's practically can't happen in real world application. But it's of course a proper way. >> What Wine's policy should be about that? Is that really necessary to have >> several modules to >> look like native does (forwarding class creation to msxml3 of course)? >> > You mean if an application calls CoCreateInstance on an msxml 4 > document, it will create an msxml 3 document? > No. I mean does it make sense to even add new modules. A proper way is to forward with registry settings set, so it shouldn't even matter how module's named. > This will break applications that depend on things like the XPath > property introduced in msxml 4, and adding support for that does not > make sense in msxml 3. > > >> The >> other way is a bit misleading - >> having msxml3 that responds to v4 interface creation I mean (and lot of >> application depend on version fourth today). >> > Why? Generally speaking, the later versions of msxml are supersets of > the older versions (i.e. they can be used without modification for the > newer versions, aside from the CLSID used). > Because on windows registry entry for Document4 points to msxml4, not 3 or something else. > >> After that I thought about renaming msxml3 to msxml but I'm not sure that >> won't break some apps. >> >> I'd like to see some opinions on this. >> > The main things to deal with are the areas where the msxml versions > are common to each other, and where the msxml versions are different > (obviously). > > As I see it, there are two main approaches that can be taken: > > 1/ the wined3d model > > That is... create a winexml (that is taken from the current msxml3), > and have msxml3, 4, 5? and 6 that expose the correct COM API and > forward the requests to the winexml version that supports everything > that the msxml versions support. These will also provide appropriate > checking for the setProperty call and any other APIs that are > different. > > 2/ a latest version with wrappers for older versions > > This is similar to the wined3d model, but having msxml6 (or whichever > is the latest version) as the equivalent of wined3d. The older > versions will then be wrappers around the msxml6 API that limit the > functionality accordingly, and implement any functionality dropped in > the newer version. > > This may end up being a cascade, as for example, XDR Schema support > has been dropped in msxml 6, so msxml 3 would need to wrap msxml 4 > (which wraps msxml 6 and supports XDR Schemas). > Both are too complicated. It seems it's enough to have one winexml and almost empty modules for msxmlX with DllGetClassObject forwarded to winexml, and common server registration helpers to place registry data. > With this in mind, it is probably better to go with the wined3d model. > > You will also need decent tests for msxml 4, 5? and 6. The msxml 3 > tests should cover functionality (like the new properties such as > NewParser) to see how it behaves in these situations. > I can place all tests to lower possible msxmlX module (after separation to winexml) to let automated tests run on all boxes. Testing new functionality with earlier interfaces is a next step. > Q: Are you aiming on bug-for-bug compatibility with XSLT and XSD support? > > If so, this might be fairly tricky to cope with. It should in theory > be possible to parameterise these and perform the different quirks > based on these settings. > > The core support (in winexml, or whatever is used) should support the > superset of functionality. That is, it should support the ProhibitDTD > property [http://msdn.microsoft.com/en-gb/library/ms762632%28VS.85%29.aspx] > in msxml 6, and default this to false for earlier versions for > example. > No need to care of differences between version for a start, will be ideally not to check for version at all. And yes, winexml should be superset of course. > - Reece > >

Feb. 2, 2010

Re: Several msxmlX modules

by Reece Dunn

On 2 February 2010 16:19, Nikolay Sivov <bunglehead(a)gmail.com> wrote: > Hi. > > Wine currently has only one module for MSXML parser - msxml3. Since the > third one v4 and v6 are already out. There is also an msxml 5. This is only available via Office 2003/2007, and is installed by that. See http://support.microsoft.com/kb/269238 ["List of Microsoft XML Parser Versions"]. > Judging from file size I don't think native modules reuse some code between > them, instead it looks like a completely > independent builds. http://msdn.microsoft.com/en-gb/library/ms753751%28VS.85%29.aspx ["What's new on msxml"] gives an overview of the features introduced by the different versions of msxml. For example, msxml 4 has a new parser that is enabled by the setProperty("NewParser", true) call on the MSXML DOMDocument interface. > What Wine's policy should be about that? Is that really necessary to have > several modules to > look like native does (forwarding class creation to msxml3 of course)? You mean if an application calls CoCreateInstance on an msxml 4 document, it will create an msxml 3 document? This will break applications that depend on things like the XPath property introduced in msxml 4, and adding support for that does not make sense in msxml 3. > The > other way is a bit misleading - > having msxml3 that responds to v4 interface creation I mean (and lot of > application depend on version fourth today). Why? Generally speaking, the later versions of msxml are supersets of the older versions (i.e. they can be used without modification for the newer versions, aside from the CLSID used). > After that I thought about renaming msxml3 to msxml but I'm not sure that > won't break some apps. > > I'd like to see some opinions on this. The main things to deal with are the areas where the msxml versions are common to each other, and where the msxml versions are different (obviously). As I see it, there are two main approaches that can be taken: 1/ the wined3d model That is... create a winexml (that is taken from the current msxml3), and have msxml3, 4, 5? and 6 that expose the correct COM API and forward the requests to the winexml version that supports everything that the msxml versions support. These will also provide appropriate checking for the setProperty call and any other APIs that are different. 2/ a latest version with wrappers for older versions This is similar to the wined3d model, but having msxml6 (or whichever is the latest version) as the equivalent of wined3d. The older versions will then be wrappers around the msxml6 API that limit the functionality accordingly, and implement any functionality dropped in the newer version. This may end up being a cascade, as for example, XDR Schema support has been dropped in msxml 6, so msxml 3 would need to wrap msxml 4 (which wraps msxml 6 and supports XDR Schemas). With this in mind, it is probably better to go with the wined3d model. You will also need decent tests for msxml 4, 5? and 6. The msxml 3 tests should cover functionality (like the new properties such as NewParser) to see how it behaves in these situations. Q: Are you aiming on bug-for-bug compatibility with XSLT and XSD support? If so, this might be fairly tricky to cope with. It should in theory be possible to parameterise these and perform the different quirks based on these settings. The core support (in winexml, or whatever is used) should support the superset of functionality. That is, it should support the ProhibitDTD property [http://msdn.microsoft.com/en-gb/library/ms762632%28VS.85%29.aspx] in msxml 6, and default this to false for earlier versions for example. - Reece

Feb. 2, 2010

Re: [1/3] gdiplus: Implement GdipSetImageAttributesGamma.

by Vincent Povirk

On Tue, Feb 2, 2010 at 2:14 AM, Paul Vriens <paul.vriens.wine(a)gmail.com> wrote: > On 01/31/2010 02:03 AM, Vincent Povirk wrote: >> >> + stat = GdipBitmapGetPixel(bitmap2, 0, 0,&color); >> + expect(Ok, stat); >> + todo_wine expect(0xff20ffff, color); > > Hi Vincent, > > This one introduces a test failure on what appears to be mostly VMware > boxes. Not all VMware boxes show this failure btw and I did see the same > failure on a real WinMe box. > > Would a color_match (like we use in several other tests) be more appropriate > or maybe a broken()? color_match would make sense. I find it odd, though, that gamma adjustment would change 255 (100% brightness) to 254 (less than 100% brightness). I may be missing something.

Feb. 2, 2010

Several msxmlX modules

by Nikolay Sivov

Hi. Wine currently has only one module for MSXML parser - msxml3. Since the third one v4 and v6 are already out. Judging from file size I don't think native modules reuse some code between them, instead it looks like a completely independent builds. What Wine's policy should be about that? Is that really necessary to have several modules to look like native does (forwarding class creation to msxml3 of course)? The other way is a bit misleading - having msxml3 that responds to v4 interface creation I mean (and lot of application depend on version fourth today). After that I thought about renaming msxml3 to msxml but I'm not sure that won't break some apps. I'd like to see some opinions on this.

Feb. 2, 2010

Re: [PATCH 1/5] qedit: Mostly stubbed out implementation of SampleGrabber filter

by Paul Chitescu

On Tuesday 02 February 2010 03:30:20 pm Nikolay Sivov wrote: > On 2/2/2010 16:21, Paul Chitescu wrote: > > Changelog: > > qedit: Mostly stubbed out implementation of SampleGrabber filter > > > > Until the last patch component is applied most application will crash as they > > rarely check for errors. > > > > > + if (IsEqualIID(riid,&IID_IUnknown) || > > + IsEqualIID(riid,&IID_IPersist) || > > + IsEqualIID(riid,&IID_IMediaFilter) || > > + IsEqualIID(riid,&IID_IBaseFilter)) { > > + InterlockedIncrement(&This->refCount); > > + *ppvObject =&(This->IBaseFilter_Vtbl); > > + return S_OK; > > + } > > > You should use ISampleGrabber_AddRef() here on success to keep increment > call in one place. > It's a common practice as far as i can see in Wine code. It's not a global practice though, code in qcap and qedit use InterlockedIncrement() in QueryInterface - probably to avoid having two TRACE lines in output just like I did.

Feb. 2, 2010

Re: [PATCH 1/5] qedit: Mostly stubbed out implementation of SampleGrabber filter

by Nikolay Sivov

On 2/2/2010 16:21, Paul Chitescu wrote: > Changelog: > qedit: Mostly stubbed out implementation of SampleGrabber filter > > Until the last patch component is applied most application will crash as they > rarely check for errors. > > + if (IsEqualIID(riid,&IID_IUnknown) || > + IsEqualIID(riid,&IID_IPersist) || > + IsEqualIID(riid,&IID_IMediaFilter) || > + IsEqualIID(riid,&IID_IBaseFilter)) { > + InterlockedIncrement(&This->refCount); > + *ppvObject =&(This->IBaseFilter_Vtbl); > + return S_OK; > + } > You should use ISampleGrabber_AddRef() here on success to keep increment call in one place. It's a common practice as far as i can see in Wine code.

Feb. 2, 2010

user32: A window is after a call to SetParent invisible when hwnd and newParent is equal (bug 21497)

by Bernhard Übelacker

(Resent, my first mail has not appeared on the list?) Hello, in SetParent the window (hwnd) get hidden by ShowWindow( hwnd, SW_HIDE ), then a call to wineserver is done and then the window is made visible again. If this call to wineserver fails the window stays invisible. This patch at least avoids this when hwnd and newParent is equal. (If there are other cases this call could fail the window stays invisble.) It could be observed in http://bugs.winehq.org/show_bug.cgi?id=21497 I want to ask for some comments what to change or if it could be sent to wine-patches as it is? Kind regards Bernhard --- dlls/user32/tests/win.c | 6 ++++++ dlls/user32/win.c | 4 ++-- 2 files changed, 8 insertions(+), 2 deletions(-) diff --git a/dlls/user32/tests/win.c b/dlls/user32/tests/win.c index 6fb6ce0..82caccb 100644 --- a/dlls/user32/tests/win.c +++ b/dlls/user32/tests/win.c @@ -445,6 +445,12 @@ static void test_parent_owner(void) ret = SetParent( test, child ); ok( ret == desktop, "SetParent return value %p expected %p\n", ret, desktop ); check_parents( test, child, child, 0, 0, hwndMain, test ); + + ShowWindow( test, SW_SHOW ); + ret = SetParent( test, test ); + ok( ret == NULL, "SetParent return value %p expected %p\n", ret, NULL ); + ok( GetWindowLongA( test, GWL_STYLE ) & WS_VISIBLE, "window is not visible after SetParent\n" ); + check_parents( test, child, child, 0, 0, hwndMain, test ); DestroyWindow( test ); /* owned popup */ diff --git a/dlls/user32/win.c b/dlls/user32/win.c index acf70a3..8308ba8 100644 --- a/dlls/user32/win.c +++ b/dlls/user32/win.c @@ -2690,8 +2690,8 @@ HWND WINAPI SetParent( HWND hwnd, HWND parent ) return 0; } - /* Some applications try to set a child as a parent */ - if (IsChild(hwnd, parent)) + /* Some applications try to set a child as a parent or itself */ + if (IsChild(hwnd, parent) || hwnd == parent) { SetLastError( ERROR_INVALID_PARAMETER ); return 0; -- 1.6.5

Feb. 2, 2010

Re: ws2_32: Fix parameter validation order in getpeername.

by Alexandre Julliard

Andrew Nguyen <arethusa26(a)gmail.com> writes: > Invalid pointers appear to be handled by getpeername in all versions > of Windows, so adding an exception handler seems to be justified. It's only justified if there is a real app that passes a bad pointer that is not the result of some other Wine bug. Please provide more details. -- Alexandre Julliard julliard(a)winehq.org

Feb. 2, 2010

Qemu using the appdb code for their OS support list.

by Paul Vriens

Hi, Just saw this: http://www.claunia.com/qemu/ -- Cheers, Paul.

Feb. 2, 2010

Re: [PATCH 4/5] d3drm: Add some tests

by Paul Vriens

On 02/01/2010 10:10 PM, Christian Costa wrote: > Paul Vriens a écrit : >> >> On 02/01/2010 08:56 AM, Stefan Dösinger wrote: >>> On Monday 01 February 2010 08:18:42 Christian Costa wrote: >>>> +void Test(void) >>>> +{ >>>> ... >>>> Test(); >>> I think the function name Test() won't be too helpful once more tests >>> are >>> added. You can also make it static, unless you plan to call it from >>> another .c >>> file. >>> >>> >> >> +#define D3DRM_GET_PROC(func) \ >> + p ## func = (void*)GetProcAddress(d3drm_handle, #func); \ >> + if(!p ## func) { \ >> + trace("GetProcAddress(%s) failed\n", #func); \ >> >> A win_skip() would probably be better here. >> >> + FreeLibrary(d3drm_handle); \ >> + return FALSE; \ >> + } >> + >> +static BOOL InitFunctionPtrs(void) >> +{ >> + d3drm_handle = LoadLibraryA("d3drm.dll"); >> + >> + if(!d3drm_handle) >> + { >> + skip("Could not load d3drm.dll\n"); >> >> And here as well. >> > Well. It comes from vector.c. I never use win_skip so far but I can take > a look at it. Thanks. > > While you are at it. This patch introduces a test failure on NT4: http://test.winehq.org/data/tests/d3drm:d3drm.html Could you have a look? -- Cheers, Paul.

Feb. 2, 2010