October 2007 - Wine-Devel - list.winehq.org

Misplaced Property Sheet buttons

by Peter Åstrand

I'm debugging a problem where the standard buttons on a property sheet are misplaced. The application is Magna Cura. The screenshot http://www.cendio.com/~astrand/wine/62-tab-size/unpatched.png demonstrates the problem: The buttons are only partially visible. It turns out that the parent window for the Buttons changes size several times. The height is: 228 95 466 436 450 The PROPSHEET_AdjustButtons function, however, is only called in WM_INITDIALOG, so the buttons are positioned based on the height 466, and never repositioned. What's the proper fix for this? I've tried this patch: --- propsheet.c (revision 13243) +++ propsheet.c (arbetskopia) @@ -3828,6 +3828,13 @@ return TRUE; } + case WM_WINDOWPOSCHANGED: + { + PropSheetInfo* psInfo = (PropSheetInfo*) lParam; + PROPSHEET_AdjustButtons(hwnd, psInfo); + return FALSE; + } + default: return FALSE; } This solves the position problem, but instead the Help button disappears. See screenshot http://www.cendio.com/~astrand/wine/62-tab-size/patched.png. Any ideas? Best regards, --- Peter Åstrand ThinLinc Chief Developer Cendio AB http://www.cendio.se Wallenbergs gata 4 583 30 Linköping Phone: +46-13-21 46 00 ThinLinc User Group 2007 Höstkonferens --- 15-16 november, Linköping. Program och anmälan: http://www.thinlincusergroup.se/aktiviteter

Oct. 26, 2007

Re: Lots of 'make test' failures on Windows

by Robert Shearman

Jakob Eriksson wrote: > Alexandre Julliard wrote: > >> If we require tests to pass on all Windows versions before getting >> committed it will drastically reduce the number of tests accepted, >> with little benefit. In most cases tests fail on some Windows boxes >> because they are too strict in the behavior they expect, and that's >> not a problem for us. >> >> > > Except that the tests clutter up the reports. We should have at least one > dedicated, declared sane, Windows installation that we regard as most > important. When you _start_ expecting tests to fail is when you > _stop_ paying attention to tests. > > (That Codeweavers do not have such an installation yet, is beoynd me. Or > if you do, please make it automatically submit its findings to > test.winehq.org!) We do. I've got a machine that regularly runs the test on Windows 2003 on real hardware: http://test.winehq.org/data/200710241000/2003_rshearman/report However, the tests are run by a service rather than manually by me to reduce the effort needed. This results in some tests failing when they perhaps shouldn't. This also doesn't help the Direct3D developers since D3D is disabled by default on Windows 2003, so we also need a real Windows XP box to run the tests regularly. -- Rob Shearman

Oct. 26, 2007

Re: my first patch

by Vijay Kiran Kamuju

This looks good, I am not an expert in that area. Send this patch to wine-patches(a)winehq.org Cheers, VJ On 10/26/07, viny <vincent.hardy.be(a)gmail.com> wrote: > Can someone tell me if this patch is correct for submitting to wine-patches. > I have generated this patch with "git format-patch -o out origin" > > (related bug : http://bugs.winehq.org/show_bug.cgi?id=9805) > > From c5eab13b67e6f24b3518dd77840f260dc101520e Mon Sep 17 00:00:00 2001 > From: Vincent Hardy <vincent.hardy.be(a)gmail.com> > Date: Fri, 26 Oct 2007 13:37:39 +0200 > Subject: [PATCH] Add TypeLib version for W2K, WXP, and Vista > > --- > dlls/oleaut32/typelib16.c | 9 +++++++++ > 1 files changed, 9 insertions(+), 0 deletions(-) > > diff --git a/dlls/oleaut32/typelib16.c b/dlls/oleaut32/typelib16.c > index a010f7d..31bbf93 100644 > --- a/dlls/oleaut32/typelib16.c > +++ b/dlls/oleaut32/typelib16.c > @@ -153,6 +153,9 @@ HRESULT WINAPI LoadTypeLib16( > *| OLE 2.1 NT 1993-95 ?? ??? > *| OLE 2.3.1 W95 23 700 > *| OLE2 4.0 NT4SP6 1993-98 40 4277 > + *| OLE 2.1 W2K 2000 10 3029 > + *| OLE 2.1 WXP 2002 10 3029 > + *| OLE 2.1 Vista 2007 10 3029 > */ > DWORD WINAPI OaBuildVersion16(void) > { > @@ -171,6 +174,12 @@ DWORD WINAPI OaBuildVersion16(void) > return MAKELONG(3024, 10); /* W98 SE */ > case 0x00000004: /* NT4 */ > return MAKELONG(4277, 40); /* NT4 SP6 */ > + case 0x00000005: /* W2K */ > + return MAKELONG(3029, 10); /* W2K SP4 */ > + case 0x00000105: /* WXP */ > + return MAKELONG(3029, 10); /* WXP SP2 */ > + case 0x00000006: /* Vista */ > + return MAKELONG(3029, 10); /* Vista */ > default: > FIXME("Version value not known yet. Please investigate it!\n"); > return 0; > -- > 1.5.2.5 > > > > >

Oct. 26, 2007

Re: ddraw:d3d tests failing consistently

by Stefan Dösinger

Am Freitag, 26. Oktober 2007 15:42:18 schrieb Jakob Eriksson: > Agree 100%. Windows on vmware is still Windows. No, I do not agree with that. Using that logic, Windows on Parallels would still be Windows. However, Parallels uses WineD3D as their Direct3D driver. Is Windows on Parallels still Windows then, from a d3d point of view? How about Intel chips then? Many games do not work on those because they depend on nvidia / ati specific things. I once used wined3d on windows to get a game like that running on an intel chip. ATI and Nvidia have defined their own Direct3D as a de-facto standard. Their behavior is sometimes in conflict with the reference rasterizer, and games depend on that.

Oct. 26, 2007

Re: Improving http://tests.winehq.org/data/

by Jakob Eriksson

Francois Gouget wrote: > On Fri, 26 Oct 2007, Robert Shearman wrote: > [...] > >> Win9x's rpcrt4 is quite buggy and I don't think it's worth the trouble >> of diagnosing what is happening and trying to work around it, both with >> the crash and the test failures. >> > > Then rpcrt4_test should detect this and skip the server test. Otherwise > it will show up as failed in the results and this will get reported > again and again. > Yes, can somebody please do that? It would also be an excellent precedent when similar problems occur with other tests. regards, Jakob

Oct. 26, 2007

Re: ddraw:d3d tests failing consistently

by Jakob Eriksson

Francois Gouget wrote: > acceleration that they added in 6.0. So the relevant tests should be > easy to skip, either by detecting lack of any 3D support or in the worst > case by detecting the name of the graphics /sound card. > Agree 100%. Windows on vmware is still Windows. // Jakob

Oct. 26, 2007

my first patch

by viny

Can someone tell me if this patch is correct for submitting to wine-patches. I have generated this patch with "git format-patch -o out origin" (related bug : http://bugs.winehq.org/show_bug.cgi?id=9805) >From c5eab13b67e6f24b3518dd77840f260dc101520e Mon Sep 17 00:00:00 2001 From: Vincent Hardy <vincent.hardy.be(a)gmail.com> Date: Fri, 26 Oct 2007 13:37:39 +0200 Subject: [PATCH] Add TypeLib version for W2K, WXP, and Vista --- dlls/oleaut32/typelib16.c | 9 +++++++++ 1 files changed, 9 insertions(+), 0 deletions(-) diff --git a/dlls/oleaut32/typelib16.c b/dlls/oleaut32/typelib16.c index a010f7d..31bbf93 100644 --- a/dlls/oleaut32/typelib16.c +++ b/dlls/oleaut32/typelib16.c @@ -153,6 +153,9 @@ HRESULT WINAPI LoadTypeLib16( *| OLE 2.1 NT 1993-95 ?? ??? *| OLE 2.3.1 W95 23 700 *| OLE2 4.0 NT4SP6 1993-98 40 4277 + *| OLE 2.1 W2K 2000 10 3029 + *| OLE 2.1 WXP 2002 10 3029 + *| OLE 2.1 Vista 2007 10 3029 */ DWORD WINAPI OaBuildVersion16(void) { @@ -171,6 +174,12 @@ DWORD WINAPI OaBuildVersion16(void) return MAKELONG(3024, 10); /* W98 SE */ case 0x00000004: /* NT4 */ return MAKELONG(4277, 40); /* NT4 SP6 */ + case 0x00000005: /* W2K */ + return MAKELONG(3029, 10); /* W2K SP4 */ + case 0x00000105: /* WXP */ + return MAKELONG(3029, 10); /* WXP SP2 */ + case 0x00000006: /* Vista */ + return MAKELONG(3029, 10); /* Vista */ default: FIXME("Version value not known yet. Please investigate it!\n"); return 0; -- 1.5.2.5

Oct. 26, 2007

Re: Anything wrong with my patch from 16.10. aboutw32x86andwin40creation?

by Markus Gömmel

> You could do it in GetPrinterDriverDirectory. ??? And if a Windows application simply queries systemdir and adds spool\drivers\w32x86 to copy printer driver files into it (ok, bad design, but I've seen a lot of that stuff in the past), it will still fail... And a native Windows system also comes with these both directories by default... So I think my patch is closer to the real... Anyway thanks for your time Markus

Oct. 26, 2007

Re: [1/5] (resend) WineD3D: Enable the draw buffers extension only when used

by Stefan Dösinger

Please ignore this patch. I just saw that macos advertises 4 draw buffers, but only one was used inside wined3d because we weren't using fbo offscreen rendering. Now macos supports the extension, 4 draw buffers but still complains... oh well > Am Freitag, 26. Oktober 2007 12:45:57 schrieb Stefan Dösinger: > > In a last discussion with Henri on IRC I fixed a concern he had about the > > old patch(dropped extension check). As for the general concern about > > driver issue fixups, we didn't come to a final conclusion and decided to > > ask Alexandre for his opinion. Just to sum up the pros/cons: > > > > -) Makes the code more complex to work around another's issues > > -) Will most likely never be removed should the driver be fixed > > > > +) Compiling the shader without warnings makes real issues more visible > > and important > > +) Avoids confusing mac users and developers with the false warnings > > +) MacOS Tiger Driver will propably never get fixed > > Use the attached patch instead, it follows a suggestion by Chris and is > less intrusive.

Oct. 26, 2007

Re: Lots of 'make test' failures on Windows

by Jakob Eriksson

Alexandre Julliard wrote: > If we require tests to pass on all Windows versions before getting > committed it will drastically reduce the number of tests accepted, > with little benefit. In most cases tests fail on some Windows boxes > because they are too strict in the behavior they expect, and that's > not a problem for us. > Except that the tests clutter up the reports. We should have at least one dedicated, declared sane, Windows installation that we regard as most important. When you _start_ expecting tests to fail is when you _stop_ paying attention to tests. (That Codeweavers do not have such an installation yet, is beoynd me. Or if you do, please make it automatically submit its findings to test.winehq.org!) > The only cases that we should really worry about are tests that fail > the same way on all Windows versions, because it shows that the test > is expecting the wrong thing. > Cleaning up these tests to not expect the wrong thing should lead to a deeper understanding of desired behaviour of Wine. regards, Jakob

Oct. 26, 2007