May 2009 - Wine-Devel - list.winehq.org

Re: wined3d: {Name of patch here}

by James Mckenzie

Pavel: Just as a hint, can you name your patches to be more descriptive. I am looking for a fix to this problem, and will attempt to test this against DooM to see if the slowness problem I have is fixed. Thank you for contributing to the Wine Project. James McKenzie -----Original Message----- >From: Pavel Prochazka <prochapa(a)inf.upol.cz> >Sent: May 27, 2009 5:40 AM >To: wine-patches(a)winehq.org >Subject: wined3d: > >

May 27, 2009

Re: wined3d:

by Stefan Dösinger

Am Mittwoch, 27. Mai 2009 14:40:20 schrieb Pavel Prochazka: > IWineGDISwapChainImpl_Present repaired when there is only one backbuffer Hmm. Situations where flip is called on a single-buffered surface should be cought in ddraw I think. If I remember correctly, calling flip on a single buffered surface should return an error

May 27, 2009

Re: comctl32/ipaddress: Skip test on Win95 with common controls 4.70 (try2)

by Nikolay Sivov

Paul Vriens wrote: > Nikolay Sivov wrote: >> >> + ok(hwnd != NULL, "Expected window to be created\n"); >> + if (!hwnd) >> + { >> + win_skip("IPAddress control not implemented\n"); >> + return; >> + } >> >> /* check text just after creation */ >> r = GetWindowText(hwnd, ip, sizeof(ip)/sizeof(CHAR)); > > I would either get rid of the ok(hwnd ...) altogether or move it after > the if(). win_skip() means we are ok with a failure on some Windows > boxes so a test failure just before that doesn't make sense. > Agreed. Try 3 should be fine.

May 27, 2009

Re: comctl32/ipaddress: Skip test on Win95 with common controls 4.70 (try2)

by Paul Vriens

Nikolay Sivov wrote: > For version 4.0 we are skipping earlier on initialization. > > Changelog: > - try2: use win_skip() > - Skip test on Win95 with common controls 4.70 > >>From 81645944ef518860de7ddcd1b64fadd11277a915 Mon Sep 17 00:00:00 2001 > From: Nikolay Sivov <bunglehead(a)gmail.com> > Date: Wed, 27 May 2009 15:39:20 +0400 > Subject: Skip test on Win95 with common controls 4.70 > > --- > dlls/comctl32/tests/ipaddress.c | 8 ++++++-- > 1 files changed, 6 insertions(+), 2 deletions(-) > > diff --git a/dlls/comctl32/tests/ipaddress.c b/dlls/comctl32/tests/ipaddress.c > index d04223c..13af687 100644 > --- a/dlls/comctl32/tests/ipaddress.c > +++ b/dlls/comctl32/tests/ipaddress.c > @@ -33,8 +33,6 @@ static HWND create_ipaddress_control (void) > handle = CreateWindowEx(0, WC_IPADDRESS, NULL, > WS_BORDER|WS_VISIBLE, 0, 0, 0, 0, > NULL, NULL, NULL, NULL); > - assert(handle); > - > return handle; > } > > @@ -45,6 +43,12 @@ static void test_get_set_text(void) > INT r; > > hwnd = create_ipaddress_control(); > + ok(hwnd != NULL, "Expected window to be created\n"); > + if (!hwnd) > + { > + win_skip("IPAddress control not implemented\n"); > + return; > + } > > /* check text just after creation */ > r = GetWindowText(hwnd, ip, sizeof(ip)/sizeof(CHAR)); I would either get rid of the ok(hwnd ...) altogether or move it after the if(). win_skip() means we are ok with a failure on some Windows boxes so a test failure just before that doesn't make sense. -- Cheers, Paul.

May 27, 2009

Re: comctl32/ipaddress: Use ok() test instead of assert()

by Nikolay Sivov

Paul Vriens wrote: >> Maybe it's true. But what about two others boxes: >> http://test.winehq.org/data/bf353f180d622cbf8508af7dbc9590e33293a6ab/95_gvg… >> >> http://test.winehq.org/data/bf353f180d622cbf8508af7dbc9590e33293a6ab/95_fg-… >> >> >> Version reported as 4.0, so it's pure Win95 - tests pass on it. >> > Not really, all tests are skipped on these two boxes ;). Oh, sorry. You're right I'll post a win_skip version.

May 27, 2009

Re: comctl32/ipaddress: Use ok() test instead of assert()

by Paul Vriens

Nikolay Sivov wrote: > Paul Vriens wrote: >> Paul Vriens wrote: >>> Nikolay Sivov wrote: >>>> This test fails to create window sometimes on Win95, >>>> let's turn it into general failure. >>>> >>>> Changelog: >>>> - replace assert() with ok() test >>>> >>>>> From b63fc6defb497505ecaab4921449327e875ab252 Mon Sep 17 00:00:00 2001 >>>> From: Nikolay Sivov <bunglehead(a)gmail.com> >>>> Date: Wed, 27 May 2009 14:26:37 +0400 >>>> Subject: Use ok() test instead of assert() >>>> >>>> --- >>>> dlls/comctl32/tests/ipaddress.c | 3 +-- >>>> 1 files changed, 1 insertions(+), 2 deletions(-) >>>> >>>> diff --git a/dlls/comctl32/tests/ipaddress.c >>>> b/dlls/comctl32/tests/ipaddress.c >>>> index d04223c..b8f30e4 100644 >>>> --- a/dlls/comctl32/tests/ipaddress.c >>>> +++ b/dlls/comctl32/tests/ipaddress.c >>>> @@ -33,8 +33,6 @@ static HWND create_ipaddress_control (void) >>>> handle = CreateWindowEx(0, WC_IPADDRESS, NULL, >>>> WS_BORDER|WS_VISIBLE, 0, 0, 0, 0, >>>> NULL, NULL, NULL, NULL); >>>> - assert(handle); >>>> - >>>> return handle; >>>> } >>>> >>>> @@ -45,6 +43,7 @@ static void test_get_set_text(void) >>>> INT r; >>>> >>>> hwnd = create_ipaddress_control(); >>>> + ok(hwnd != NULL, "Expected window to be created\n"); >>>> >>> >>> Shouldn't you insert a return here when hwnd is NULL. The following >>> tests will fail as well I guess. >>> >> Just had a look and it seems that only one box actually has this >> failure. Maybe a win_skip() would be 'better'? >> >> hwnd = create_ipaddress_control(); >> if (!hwnd) >> { >> win_skip(); >> return; >> } >> >> Maybe even printing the last error in that win_skip() ? >> >> Especially as MSDN states: >> >> The IP address control is implemented in version 4.71 and later of >> Comctl32.dll. >> >> And this box has 4.70.0.1146. >> > Maybe it's true. But what about two others boxes: > http://test.winehq.org/data/bf353f180d622cbf8508af7dbc9590e33293a6ab/95_gvg… > > http://test.winehq.org/data/bf353f180d622cbf8508af7dbc9590e33293a6ab/95_fg-… > > > Version reported as 4.0, so it's pure Win95 - tests pass on it. > Not really, all tests are skipped on these two boxes ;). -- Cheers, Paul.

May 27, 2009

Re: comctl32/ipaddress: Use ok() test instead of assert()

by Nikolay Sivov

Paul Vriens wrote: > Paul Vriens wrote: >> Nikolay Sivov wrote: >>> This test fails to create window sometimes on Win95, >>> let's turn it into general failure. >>> >>> Changelog: >>> - replace assert() with ok() test >>> >>>> From b63fc6defb497505ecaab4921449327e875ab252 Mon Sep 17 00:00:00 2001 >>> From: Nikolay Sivov <bunglehead(a)gmail.com> >>> Date: Wed, 27 May 2009 14:26:37 +0400 >>> Subject: Use ok() test instead of assert() >>> >>> --- >>> dlls/comctl32/tests/ipaddress.c | 3 +-- >>> 1 files changed, 1 insertions(+), 2 deletions(-) >>> >>> diff --git a/dlls/comctl32/tests/ipaddress.c >>> b/dlls/comctl32/tests/ipaddress.c >>> index d04223c..b8f30e4 100644 >>> --- a/dlls/comctl32/tests/ipaddress.c >>> +++ b/dlls/comctl32/tests/ipaddress.c >>> @@ -33,8 +33,6 @@ static HWND create_ipaddress_control (void) >>> handle = CreateWindowEx(0, WC_IPADDRESS, NULL, >>> WS_BORDER|WS_VISIBLE, 0, 0, 0, 0, >>> NULL, NULL, NULL, NULL); >>> - assert(handle); >>> - >>> return handle; >>> } >>> >>> @@ -45,6 +43,7 @@ static void test_get_set_text(void) >>> INT r; >>> >>> hwnd = create_ipaddress_control(); >>> + ok(hwnd != NULL, "Expected window to be created\n"); >>> >> >> Shouldn't you insert a return here when hwnd is NULL. The following >> tests will fail as well I guess. >> > Just had a look and it seems that only one box actually has this > failure. Maybe a win_skip() would be 'better'? > > hwnd = create_ipaddress_control(); > if (!hwnd) > { > win_skip(); > return; > } > > Maybe even printing the last error in that win_skip() ? > > Especially as MSDN states: > > The IP address control is implemented in version 4.71 and later of > Comctl32.dll. > > And this box has 4.70.0.1146. > Maybe it's true. But what about two others boxes: http://test.winehq.org/data/bf353f180d622cbf8508af7dbc9590e33293a6ab/95_gvg… http://test.winehq.org/data/bf353f180d622cbf8508af7dbc9590e33293a6ab/95_fg-… Version reported as 4.0, so it's pure Win95 - tests pass on it.

May 27, 2009

Re: [mshtml/tests] Fix 2 test failures on IE8

by Jacek Caban

Paul Vriens wrote: > Jacek Caban wrote: >> Hi Paul, >> >> Paul Vriens wrote: >>> Changelog >>> Fix 2 test failures on IE8 >>> >> - ok(disp == (void*)0xdeadbeef, "disp=%p\n", disp); >> + ok(disp == (void*)0xdeadbeef || >> + disp == NULL, /* IE8 */ >> >> >> This test does no longer make sense. It would be better to remove it >> and preferably change implementation to match IE8. >> >> >> Thanks, >> Jacek >> >> >> > Hi Jacek, > > Something like the attached? > Yes, it looks good. Thanks, Jacek

May 27, 2009

Re: comctl32/ipaddress: Use ok() test instead of assert()

by Paul Vriens

Paul Vriens wrote: > Nikolay Sivov wrote: >> This test fails to create window sometimes on Win95, >> let's turn it into general failure. >> >> Changelog: >> - replace assert() with ok() test >> >>> From b63fc6defb497505ecaab4921449327e875ab252 Mon Sep 17 00:00:00 2001 >> From: Nikolay Sivov <bunglehead(a)gmail.com> >> Date: Wed, 27 May 2009 14:26:37 +0400 >> Subject: Use ok() test instead of assert() >> >> --- >> dlls/comctl32/tests/ipaddress.c | 3 +-- >> 1 files changed, 1 insertions(+), 2 deletions(-) >> >> diff --git a/dlls/comctl32/tests/ipaddress.c >> b/dlls/comctl32/tests/ipaddress.c >> index d04223c..b8f30e4 100644 >> --- a/dlls/comctl32/tests/ipaddress.c >> +++ b/dlls/comctl32/tests/ipaddress.c >> @@ -33,8 +33,6 @@ static HWND create_ipaddress_control (void) >> handle = CreateWindowEx(0, WC_IPADDRESS, NULL, >> WS_BORDER|WS_VISIBLE, 0, 0, 0, 0, >> NULL, NULL, NULL, NULL); >> - assert(handle); >> - >> return handle; >> } >> >> @@ -45,6 +43,7 @@ static void test_get_set_text(void) >> INT r; >> >> hwnd = create_ipaddress_control(); >> + ok(hwnd != NULL, "Expected window to be created\n"); >> > > Shouldn't you insert a return here when hwnd is NULL. The following > tests will fail as well I guess. > Just had a look and it seems that only one box actually has this failure. Maybe a win_skip() would be 'better'? hwnd = create_ipaddress_control(); if (!hwnd) { win_skip(); return; } Maybe even printing the last error in that win_skip() ? Especially as MSDN states: The IP address control is implemented in version 4.71 and later of Comctl32.dll. And this box has 4.70.0.1146. -- Cheers, Paul.

May 27, 2009

Re: comctl32/ipaddress: Use ok() test instead of assert()

by Nikolay Sivov

Paul Vriens wrote: > Nikolay Sivov wrote: >> This test fails to create window sometimes on Win95, >> let's turn it into general failure. >> >> Changelog: >> - replace assert() with ok() test >> >>> From b63fc6defb497505ecaab4921449327e875ab252 Mon Sep 17 00:00:00 2001 >> From: Nikolay Sivov <bunglehead(a)gmail.com> >> Date: Wed, 27 May 2009 14:26:37 +0400 >> Subject: Use ok() test instead of assert() >> >> --- >> dlls/comctl32/tests/ipaddress.c | 3 +-- >> 1 files changed, 1 insertions(+), 2 deletions(-) >> >> diff --git a/dlls/comctl32/tests/ipaddress.c >> b/dlls/comctl32/tests/ipaddress.c >> index d04223c..b8f30e4 100644 >> --- a/dlls/comctl32/tests/ipaddress.c >> +++ b/dlls/comctl32/tests/ipaddress.c >> @@ -33,8 +33,6 @@ static HWND create_ipaddress_control (void) >> handle = CreateWindowEx(0, WC_IPADDRESS, NULL, >> WS_BORDER|WS_VISIBLE, 0, 0, 0, 0, >> NULL, NULL, NULL, NULL); >> - assert(handle); >> - >> return handle; >> } >> >> @@ -45,6 +43,7 @@ static void test_get_set_text(void) >> INT r; >> >> hwnd = create_ipaddress_control(); >> + ok(hwnd != NULL, "Expected window to be created\n"); >> > > Shouldn't you insert a return here when hwnd is NULL. The following > tests will fail as well I guess. > The reason was to count failures as usual instead of exit a test hardly. I still don't know why it can't be created some times so I think win_skip doesn't mean much till we don't know a cause.

May 27, 2009

Re: comctl32/ipaddress: Use ok() test instead of assert()

by Paul Vriens

Nikolay Sivov wrote: > This test fails to create window sometimes on Win95, > let's turn it into general failure. > > Changelog: > - replace assert() with ok() test > >>From b63fc6defb497505ecaab4921449327e875ab252 Mon Sep 17 00:00:00 2001 > From: Nikolay Sivov <bunglehead(a)gmail.com> > Date: Wed, 27 May 2009 14:26:37 +0400 > Subject: Use ok() test instead of assert() > > --- > dlls/comctl32/tests/ipaddress.c | 3 +-- > 1 files changed, 1 insertions(+), 2 deletions(-) > > diff --git a/dlls/comctl32/tests/ipaddress.c b/dlls/comctl32/tests/ipaddress.c > index d04223c..b8f30e4 100644 > --- a/dlls/comctl32/tests/ipaddress.c > +++ b/dlls/comctl32/tests/ipaddress.c > @@ -33,8 +33,6 @@ static HWND create_ipaddress_control (void) > handle = CreateWindowEx(0, WC_IPADDRESS, NULL, > WS_BORDER|WS_VISIBLE, 0, 0, 0, 0, > NULL, NULL, NULL, NULL); > - assert(handle); > - > return handle; > } > > @@ -45,6 +43,7 @@ static void test_get_set_text(void) > INT r; > > hwnd = create_ipaddress_control(); > + ok(hwnd != NULL, "Expected window to be created\n"); > Shouldn't you insert a return here when hwnd is NULL. The following tests will fail as well I guess. -- Cheers, Paul.

May 27, 2009

Re: DIB Engine : passing all tests

by Chris Howe

2009/5/27 Roderick Colenbrander <thunderbird2k(a)gmail.com> > On Wed, May 27, 2009 at 10:26 AM, Vit Hrachovy <vit.hrachovy(a)sandbox.cz> > wrote: > > would it be possible to craft a wikipage on Wine Wiki, that would > encompass > > * official DIB implementation requirements > > * high level description of Huw's solution > > * description of Your solution incl. proposed integration plan > > > > I have asked Alexandre about it but it wasn't really an option. Even > for Huw writing a full dib engine (if he resumed his current code) > would take five months or so full time. Filling in the 'easy' bits > (which Alexandre considers most of the things done so far) is not that > much work (the easy bits are the software drawing functions). I'm not sure I understand this answer, as all but the first line doesn't seem to relate to the question. Are you saying that you have been told that making the documentation Vit described wasn't an option? -- Chris

May 27, 2009

Re: DIB Engine : passing all tests

by Roderick Colenbrander

On Wed, May 27, 2009 at 10:26 AM, Vit Hrachovy <vit.hrachovy(a)sandbox.cz> wrote: > Massimo Del Fedele wrote: >> >> Btw, sorry all but I begins to be tired of telling same stuffs again and >> again. I made a proposal for something that *could* help the migration to >> final design, a *working* proposal, not just a prototype, and I believe on >> it. >> If that's not what most devels think, for me is ok. >> The engine will be available as a patch for whom needs/likes it, point. > > Hi Max, > would it be possible to craft a wikipage on Wine Wiki, that would encompass > * official DIB implementation requirements > * high level description of Huw's solution > * description of Your solution incl. proposed integration plan > > It would ease the orientation, prevent repeating the same stuff again and > again and it could also serve as a solid base for further discussion about > DIB integration requirements. > > Regards > Hark > > > I have asked Alexandre about it but it wasn't really an option. Even for Huw writing a full dib engine (if he resumed his current code) would take five months or so full time. Filling in the 'easy' bits (which Alexandre considers most of the things done so far) is not that much work (the easy bits are the software drawing functions). Roderick

May 27, 2009

Re: DIB Engine : passing all tests

by Vit Hrachovy

Massimo Del Fedele wrote: > Btw, sorry all but I begins to be tired of telling same stuffs again and > again. I made a proposal for something that *could* help the migration to > final design, a *working* proposal, not just a prototype, and I believe > on it. > If that's not what most devels think, for me is ok. > The engine will be available as a patch for whom needs/likes it, point. Hi Max, would it be possible to craft a wikipage on Wine Wiki, that would encompass * official DIB implementation requirements * high level description of Huw's solution * description of Your solution incl. proposed integration plan It would ease the orientation, prevent repeating the same stuff again and again and it could also serve as a solid base for further discussion about DIB integration requirements. Regards Hark

May 27, 2009

Re: [mshtml/tests] Fix 2 test failures on IE8

by Paul Vriens

Jacek Caban wrote: > Hi Paul, > > Paul Vriens wrote: >> Changelog >> Fix 2 test failures on IE8 >> > - ok(disp == (void*)0xdeadbeef, "disp=%p\n", disp); > + ok(disp == (void*)0xdeadbeef || > + disp == NULL, /* IE8 */ > > > This test does no longer make sense. It would be better to remove it and > preferably change implementation to match IE8. > > > Thanks, > Jacek > > > Hi Jacek, Something like the attached? -- Cheers, Paul. diff --git a/dlls/mshtml/htmlnode.c b/dlls/mshtml/htmlnode.c index 32b0801..720bbfe 100644 --- a/dlls/mshtml/htmlnode.c +++ b/dlls/mshtml/htmlnode.c @@ -157,6 +157,11 @@ static HRESULT WINAPI HTMLDOMChildrenCollection_item(IHTMLDOMChildrenCollection TRACE("(%p)->(%d %p)\n", This, index, ppItem); + if (ppItem) + *ppItem = NULL; + else + return E_POINTER; + nsIDOMNodeList_GetLength(This->nslist, &length); if(index < 0 || index >= length) return E_INVALIDARG; diff --git a/dlls/mshtml/tests/dom.c b/dlls/mshtml/tests/dom.c index aaf1a39..497fc0a 100644 --- a/dlls/mshtml/tests/dom.c +++ b/dlls/mshtml/tests/dom.c @@ -4456,15 +4456,17 @@ static void test_elems(IHTMLDocument2 *doc) IHTMLDOMNode_Release(node); } - disp = (void*)0xdeadbeef; + hres = IHTMLDOMChildrenCollection_item(child_col, length - 1, NULL); + ok(hres == E_POINTER, "item failed: %08x, expected E_POINTER\n", hres); + + hres = IHTMLDOMChildrenCollection_item(child_col, length, NULL); + ok(hres == E_POINTER, "item failed: %08x, expected E_POINTER\n", hres); + hres = IHTMLDOMChildrenCollection_item(child_col, 6000, &disp); ok(hres == E_INVALIDARG, "item failed: %08x, expected E_INVALIDARG\n", hres); - ok(disp == (void*)0xdeadbeef, "disp=%p\n", disp); - disp = (void*)0xdeadbeef; hres = IHTMLDOMChildrenCollection_item(child_col, length, &disp); ok(hres == E_INVALIDARG, "item failed: %08x, expected E_INVALIDARG\n", hres); - ok(disp == (void*)0xdeadbeef, "disp=%p\n", disp); test_child_col_disp(child_col);

May 27, 2009

Re: DIB Engine : passing all tests

by Austin English

On Wed, May 27, 2009 at 2:11 AM, Massimo Del Fedele <max(a)veneto.com> wrote: > Strange enough, as the consensus on Huw's design was great, and it used > a *real* external driver, and *not* an intermediate one as mine. > But I start thinking that the requirements and consensus are very fluid and > moving matters, lately. > > Btw, sorry all but I begins to be tired of telling same stuffs again and > again. I made a proposal for something that *could* help the migration to > final design, a *working* proposal, not just a prototype, and I believe on > it. > If that's not what most devels think, for me is ok. > The engine will be available as a patch for whom needs/likes it, point. Not directed toward you, Massimo, but others: Keep in mind, Massimo has sent patches dozens of times, along with explanations/critiques. Unless you have something *NEW* to add (check the archives), please refrain from commenting since in waste a lot of time. -- -Austin

May 27, 2009

Re: DIB Engine : passing all tests

by Massimo Del Fedele

Ben Klein ha scritto: > > A little while ago I was trying to run an app that uses Win16 DIB.DRV > (I forget which app it was). My research indicated that although > DIB.DRV was an actual driver (similar in architecture to Max's > proposed DIB engine) in Win16 systems, in Windows 95 the functionality > was rolled into GDI. For my app, this means that (in theory) exposing > appropriate, existing DIB functions to my Win16 app in the form of a > virtual DIB.DRV should work. For Max's engine, we're looking at > diverging from Microsoft's modern architecture and switching back to > something that was "good enough" 25 years ago. I begin thinking to not be clear enough in what I write...... 2 Last words: 1) Huw's starting engine *was* a driver's one, and many people told it was the right way. Worse, it forked driver from inside gdi32, which was awful to maintain. 2) My engine insertrs itself between gdi32 and the display driver; I begins to be tired repeating that it's a step through the final design on where DIB are handled fully inside gdi32. The step is, imho, necessary to split DIB handling from DDB without having to rewrite at once half of gdi32 + half of winex11.drv and maybe others. It is *not* the final step, now it wants to be. It's made so to prepare the switching in a painless way, *if* accepted. If not, just prepare to have the sampe problems we had with mshtml switching on each gecko change. In my case that broke a lot of stuffs. > > We all know AJ wants things to be done "the right way" the first time. > I agree with this policy, because it makes for more maintainable code, > less duplication, etc. again, I agree with that. Defining what is "the right way" is still a mysterious matter. Wine's patch acceptance policy specifically > prohibits "hack it until it works, which hack ????? then worry about it later" style > programming, and the consensus of devs seems to be that adding a new > DIB *driver* as an intermediary between GDI32 and hardware drivers is > the wrong way to go about things. > Strange enough, as the consensus on Huw's design was great, and it used a *real* external driver, and *not* an intermediate one as mine. But I start thinking that the requirements and consensus are very fluid and moving matters, lately. Btw, sorry all but I begins to be tired of telling same stuffs again and again. I made a proposal for something that *could* help the migration to final design, a *working* proposal, not just a prototype, and I believe on it. If that's not what most devels think, for me is ok. The engine will be available as a patch for whom needs/likes it, point. Last work about accepting or not hacks: I never proposed such patches. The most "hacky" stuff I sent (and was rejected, with a motivation that could be right) was the addition of page size handling inside wineps.drv. Motivation was that the printer driver shoul be rewritten for cups without lpr usage. I agree. But by now *is* using lpr and *is* lacking support for page size and other stuffs. So I asked myself : it's better to wait up we have the "complete right code", leaving the printer driver missing stuffs, or for the moment extend it while waiting for the right one ? I would have chosen the second solution, but as usual is a matter of taste. Max

May 27, 2009

Re: DIB Engine : passing all tests

by Massimo Del Fedele

Dmitry Timoshkov ha scritto: > "Massimo Del Fedele" <max(a)veneto.com> wrote: > >> The driver loading mechanics is the gdi32 one duplicated in winedib.drv. >> winedib.drv just intercept DIB calls and forward others to *any* other >> driver. Again, in my thoughts that is a "transient" phase, at the end all >> dib processing should go inside gdi32. > > Probably you need to have a look how support for truetype and other > fonts via freetype was added. Although there is an entity called "GDI > font" (with freetype support), still there is such a thing as device > fonts (suported by x11drv, psdrv or any other device driver). Make that > as an analogy: GDI font - DIB, device font - DDB. Adding support for GDI > fonts didn't require introducing any new "font driver", so adding a DIB > engine shouldn't add a new one as well. DIB engine should be a GDI32 pure > internal thing. > I begin to repeat stuffs too often lately. As I already wrote, *I know* and *I agree* that DIB should belong to GDI32. The proposed driver is a working step to that final goal. Point. Max

May 27, 2009

Re: DIB Engine : passing all tests

by Ben Klein

2009/5/27 Dmitry Timoshkov <dmitry(a)codeweavers.com>: > "Massimo Del Fedele" <max(a)veneto.com> wrote: > >> The driver loading mechanics is the gdi32 one duplicated in winedib.drv. >> winedib.drv just intercept DIB calls and forward others to *any* other >> driver. Again, in my thoughts that is a "transient" phase, at the end all >> dib processing should go inside gdi32. > > Probably you need to have a look how support for truetype and other > fonts via freetype was added. Although there is an entity called "GDI > font" (with freetype support), still there is such a thing as device > fonts (suported by x11drv, psdrv or any other device driver). Make that > as an analogy: GDI font - DIB, device font - DDB. Adding support for GDI > fonts didn't require introducing any new "font driver", so adding a DIB > engine shouldn't add a new one as well. DIB engine should be a GDI32 pure > internal thing. >From what I gather, the desired architecture is to integrate DIB engine into GDI32 wherever applicable (so the current DIB-related methods will be reimplemented with a possibly optional DIB engine). This also seems to be in keeping with Max's end-goal architecture - to integrate with GDI32. A little while ago I was trying to run an app that uses Win16 DIB.DRV (I forget which app it was). My research indicated that although DIB.DRV was an actual driver (similar in architecture to Max's proposed DIB engine) in Win16 systems, in Windows 95 the functionality was rolled into GDI. For my app, this means that (in theory) exposing appropriate, existing DIB functions to my Win16 app in the form of a virtual DIB.DRV should work. For Max's engine, we're looking at diverging from Microsoft's modern architecture and switching back to something that was "good enough" 25 years ago. We all know AJ wants things to be done "the right way" the first time. I agree with this policy, because it makes for more maintainable code, less duplication, etc. Wine's patch acceptance policy specifically prohibits "hack it until it works, then worry about it later" style programming, and the consensus of devs seems to be that adding a new DIB *driver* as an intermediary between GDI32 and hardware drivers is the wrong way to go about things.

May 27, 2009

Re: DIB Engine : passing all tests

by Dmitry Timoshkov

"Massimo Del Fedele" <max(a)veneto.com> wrote: > The driver loading mechanics is the gdi32 one duplicated in winedib.drv. > winedib.drv just intercept DIB calls and forward others to *any* other > driver. Again, in my thoughts that is a "transient" phase, at the end all > dib processing should go inside gdi32. Probably you need to have a look how support for truetype and other fonts via freetype was added. Although there is an entity called "GDI font" (with freetype support), still there is such a thing as device fonts (suported by x11drv, psdrv or any other device driver). Make that as an analogy: GDI font - DIB, device font - DDB. Adding support for GDI fonts didn't require introducing any new "font driver", so adding a DIB engine shouldn't add a new one as well. DIB engine should be a GDI32 pure internal thing. -- Dmitry.

May 27, 2009

Re: d3d9/tests: add simple test to show that QualityLevels is not zero, when we call CheckDeviceMultiSampleType with D3DMULTISAMPLE_NONE

by Jeff Zaroyko

On Wed, May 27, 2009 at 7:47 AM, Louis. Lenders <xerox_xerox2000(a)yahoo.co.uk> wrote: > This test shows second bug in > http://www.winehq.org/pipermail/wine-bugs/2009-May/177221.html > > I tested this on my laptop (under windows) with an ATI-card, my desktop > computer (that has nvidia) only runs Linux, so i could not test it on nvidia > under windows, if anyone could do that that would be nice. > No failures on Vista, nv9800, 180.81.

May 26, 2009

Re: [mshtml/tests] Fix 2 test failures on IE8

by Jacek Caban

Hi Paul, Paul Vriens wrote: > Changelog > Fix 2 test failures on IE8 > - ok(disp == (void*)0xdeadbeef, "disp=%p\n", disp); + ok(disp == (void*)0xdeadbeef || + disp == NULL, /* IE8 */ This test does no longer make sense. It would be better to remove it and preferably change implementation to match IE8. Thanks, Jacek

May 26, 2009

Re: PowerPC MacOSX work...

by Detlef Riekenberg

On Mo, 2009-05-25 at 22:06 +0200, Stefan Dösinger wrote: > they won't work because WinPPC uses little endian while MacOS uses big endian. > I am wondering > how that would be possible though, can PPCs switch modes? Yes, a PowerPC can switch endian. -- By by ... Detlef

May 26, 2009

Re: [PATCH 05/10] msi: Add support for importing binary OBJECTS.

by Michael Stefaniuc

Hib Eris wrote: > On Tue, May 26, 2009 at 8:57 PM, Alexandre Julliard <julliard(a)winehq.org> wrote: >> Hib Eris <hib(a)hiberis.nl> writes: >> >>> I have looked at my new code and it does not seem wrong to me, but >>> maybe it is somewhere else. Unfortunately, as I cannot reproduce this >>> failure, I have no idea how to debug it. Does this fail for other >>> people as well? >>> >>> Just a wild guess... could it have something to do with 64-bit vs. >>> 32-bit? I am running on 32-bit. Alexandre, did you run the test on 32 >>> or 64 bit? >> 32-bit of course, nothing works on 64-bit <g> >> >> It's heap corruption, you forgot to allocate space for the terminating >> null in msi_import_stream_filename. And you should probably use strdupW >> instead. > > Ahhh, I see! I will create a new patch. Thanks. > > A question about using strdupW: In my patch I use msi_alloc and > msi_realloc to allocate memory for the returned string and use > msi_free to free it again. > If I would use stdupW to create a string copy instead of msi_alloc, > would it then still be okay to use msi_realloc and msi_free? According > to > http://source.winehq.org/WineAPI/StrDupW.html I should use LocalFree > to free the memory? StrDupW and strdupW aren't the same. > I've seem some more places where msi_free and StdDupW were mixed, so I msi doesn't uses StdDupW but strdupW. > guess it will work. But is it considered good practice? Checkout dlls/msi/msipriv.h. You'll find there the implementation of msi_alloc, msi_free and strdupW. Those are basically wrappers around HeapAlloc/HeapFree. bye michael

May 26, 2009

Re: [PATCH 05/10] msi: Add support for importing binary OBJECTS.

by Hib Eris

Hi Nikolay, Thanks for your reply. Alexandre already pointed me to my mistake, so no need for you anymore to help out. Thanks anyway. Hib > > Hi, Hib. > --- > error: patch failed: dlls/msi/tests/db.c:1966 > error: dlls/msi/tests/db.c: patch does not apply > --- > Post a rebased version please, I'll try it on my box. > > Nikolay S. >

May 26, 2009

Re: [PATCH 05/10] msi: Add support for importing binary OBJECTS.

by Hib Eris

On Tue, May 26, 2009 at 8:57 PM, Alexandre Julliard <julliard(a)winehq.org> wrote: > Hib Eris <hib(a)hiberis.nl> writes: > >> I have looked at my new code and it does not seem wrong to me, but >> maybe it is somewhere else. Unfortunately, as I cannot reproduce this >> failure, I have no idea how to debug it. Does this fail for other >> people as well? >> >> Just a wild guess... could it have something to do with 64-bit vs. >> 32-bit? I am running on 32-bit. Alexandre, did you run the test on 32 >> or 64 bit? > > 32-bit of course, nothing works on 64-bit <g> > > It's heap corruption, you forgot to allocate space for the terminating > null in msi_import_stream_filename. And you should probably use strdupW > instead. Ahhh, I see! I will create a new patch. Thanks. A question about using strdupW: In my patch I use msi_alloc and msi_realloc to allocate memory for the returned string and use msi_free to free it again. If I would use stdupW to create a string copy instead of msi_alloc, would it then still be okay to use msi_realloc and msi_free? According to http://source.winehq.org/WineAPI/StrDupW.html I should use LocalFree to free the memory? I've seem some more places where msi_free and StdDupW were mixed, so I guess it will work. But is it considered good practice? Hib

May 26, 2009

Re: [PATCH 05/10] msi: Add support for importing binary OBJECTS.

by Nikolay Sivov

Hib Eris wrote: > Hi all, > > hmm, I've tested it again with current git, and it still works fine here. > > I have looked at my new code and it does not seem wrong to me, but > maybe it is somewhere else. Unfortunately, as I cannot reproduce this > failure, I have no idea how to debug it. Does this fail for other > people as well? > > Just a wild guess... could it have something to do with 64-bit vs. > 32-bit? I am running on 32-bit. Alexandre, did you run the test on 32 > or 64 bit? > > So, I can only ask for someone to please also try > http://www.winehq.org/pipermail/wine-patches/2009-May/073272.html and > see if it works for him/her. > > > Hib > Hi, Hib. --- error: patch failed: dlls/msi/tests/db.c:1966 error: dlls/msi/tests/db.c: patch does not apply --- Post a rebased version please, I'll try it on my box. Nikolay S.

May 26, 2009

[PATCH 05/10] msi: Add support for importing binary OBJECTS.

by Hib Eris

Hi all, hmm, I've tested it again with current git, and it still works fine here. I have looked at my new code and it does not seem wrong to me, but maybe it is somewhere else. Unfortunately, as I cannot reproduce this failure, I have no idea how to debug it. Does this fail for other people as well? Just a wild guess... could it have something to do with 64-bit vs. 32-bit? I am running on 32-bit. Alexandre, did you run the test on 32 or 64 bit? So, I can only ask for someone to please also try http://www.winehq.org/pipermail/wine-patches/2009-May/073272.html and see if it works for him/her. Hib On Tue, May 26, 2009 at 3:30 PM, Alexandre Julliard <julliard(a)winehq.org> wrote: > Hib Eris <hib(a)hiberis.nl> writes: > >> --- >> dlls/msi/database.c | 63 +++++++++++++++++++++++++++++++++++++++++++++++--- >> dlls/msi/msipriv.h | 3 +- >> dlls/msi/record.c | 2 +- >> dlls/msi/tests/db.c | 12 +++++----- >> 4 files changed, 68 insertions(+), 12 deletions(-) > > This doesn't work here: > > ../../../tools/runtest -q -P wine -M msi.dll -T ../../.. -p msi_test.exe.so db.c && touch db.ok > wine: Unhandled page fault on write access to 0x00000004 at address 0x7bc4460e (thread 0019), starting debugger... > Unhandled exception: page fault on write access to 0x00000004 in 32-bit code (0x7bc4460e). > Register dump: > CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b > EIP:7bc4460e ESP:0032f770 EBP:0032f7e8 EFLAGS:00010202( R- -- I - - - ) > EAX:00000000 EBX:7bc94448 ECX:00110014 EDX:00000000 > ESI:0012dcc8 EDI:0012dc48 > Stack dump: > 0x0032f770: 0032f784 00110014 00000020 0012dd00 > 0x0032f780: 0032f794 4d430002 0032f7bc 0012dc58 > 0x0032f790: 0032f7a4 00110014 00000070 4d430003 > 0x0032f7a0: 00000000 4d430003 00000000 00000000 > 0x0032f7b0: 00000000 00000000 00000000 4d430000 > 0x0032f7c0: 0012dc58 00000070 00000000 00000000 > Backtrace: > =>0 0x7bc4460e HEAP_CreateFreeBlock+0x3be(subheap=0x110014, ptr=0x12dc48, size=128) [/home/julliard/wine/wine/dlls/ntdll/../../include/wine/list.h:98] in ntdll (0x0032f7e8) > 1 0x7bc44847 HEAP_MakeInUseBlockFree+0x57(subheap=0x110014, pArena=<is not available>) [/home/julliard/wine/wine/dlls/ntdll/heap.c:586] in ntdll (0x0032f838) > 2 0x7bc44b3c RtlFreeHeap+0x18c(heap=0x110000, flags=2, ptr=0x12dcc8) [/home/julliard/wine/wine/dlls/ntdll/heap.c:1480] in ntdll (0x0032f898) > 3 0x6081aa8e free_table+0x3e(table=<register EDI not in topmost frame>) [/home/julliard/wine/wine/dlls/msi/msipriv.h:1059] in msi (0x0032f8b8) > 4 0x6081abae free_cached_tables+0x2e(db=<register ESI not in topmost frame>) [/home/julliard/wine/wine/dlls/msi/../../include/wine/list.h:133] in msi (0x0032f8c8) > 5 0x607d3ec2 MSI_CloseDatabase+0x42(arg=0x12b7e8) [/home/julliard/wine/wine/dlls/msi/database.c:66] in msi (0x0032f8e8) > 6 0x607e6b58 msiobj_release+0x48(info=<register ESI not in topmost frame>) [/home/julliard/wine/wine/dlls/msi/handle.c:257] in msi (0x0032f918) > 7 0x607e6ccf MsiCloseHandle+0xbf(handle=<is not available>) [/home/julliard/wine/wine/dlls/msi/handle.c:311] in msi (0x0032f948) > 8 0x6066abda test_binary_import+0x33a() [/home/julliard/wine/wine/dlls/msi/tests/db.c:1991] in msi_test (0x0032fca8) > 9 0x60677d7e func_db+0x264e() [/home/julliard/wine/wine/dlls/msi/tests/db.c:7672] in msi_test (0x0032fde8) > 10 0x60749a80 run_test+0x130(name="db.c") [/home/julliard/wine/wine/dlls/msi/tests/../../../include/wine/test.h:456] in msi_test (0x0032fe28) > 11 0x60749c6f main+0x11f(argc=<register ECX not in topmost frame>, argv=<register ECX not in topmost frame>) [/home/julliard/wine/wine/dlls/msi/tests/../../../include/wine/test.h:505] in msi_test (0x0032fed8) > 12 0x6074a484 __wine_spec_exe_entry+0x84(peb=0x7ffdf000) [/home/julliard/wine/wine/dlls/winecrt0/exe_entry.c:36] in msi_test (0x0032ff08) > 13 0x7b878660 start_process+0x130(arg=(nil)) [/home/julliard/wine/wine/dlls/kernel32/process.c:941] in kernel32 (0x0032ffe8) > 14 0x6002bc07 wine_switch_to_stack+0x17() in libwine.so.1 (0x00000000) > 0x7bc4460e HEAP_CreateFreeBlock+0x3be [/home/julliard/wine/wine/dlls/ntdll/../../include/wine/list.h:98] in ntdll: movl %eax,0x4(%edx) > 98 elem->next->prev = elem->prev; > > > -- > Alexandre Julliard > julliard(a)winehq.org >

May 26, 2009

Re: comctl32:rebar: Don't store an empty string in REBAR_InsertBandT.

by Nikolay Sivov

Sergey Khodych wrote: > Nikolay Sivov пишет: >> Where did you test that it isn't stored? > > The patch fixes a bug when wine allocates an extra space for a band with > an empty string. I replaced NULL by "" in the size test to show the > native realization doesn't change its behavior unlike wine in this case. Ok. All todos for Rebar tests are about colors. You could check it at test.winehq.org. So there's no reason to touch tests that already pass. It looks like you need to add a simple test like that: - add band with empty string and RBBIM_TEXT mask of course; - query band data back with RB_GETBANDINFO and check this lpText field. If it's really NULL (e.g. your buffer didn't change) instead of empty string you should test RB_SETBARINFO for the same case. What you mean saying extra space? Some offset during drawing or what?

May 26, 2009

Re: comctl32:rebar: Don't store an empty string in REBAR_InsertBandT.

by Sergey Khodych

Nikolay Sivov пишет: > Where did you test that it isn't stored? The patch fixes a bug when wine allocates an extra space for a band with an empty string. I replaced NULL by "" in the size test to show the native realization doesn't change its behavior unlike wine in this case.

May 26, 2009

Re: patch wined3d

by Stefan Dösinger

Am Dienstag, 26. Mai 2009 18:13:49 schrieb Pavel Prochazka: Is there any reason why we'd want 32 backbuffer swapchains? The currentl limit comes from d3d9(no more than 3 backbuffers allowed). We can certainly change it, but I doubt that any Windows driver supports that in ddraw. If there is no limit in ddraw(provide a test), we should remove the limit and make it dynamic.

May 26, 2009

Re: patch wined3d

by Henri Verbeet

2009/5/26 Pavel Prochazka <prochapa(a)inf.upol.cz>: > +»······int i=1; > + > +»······/*it moves all backbuffers by 1 to left form id = 1, > +»······the backbuffer swap to frontbuffer and frontbuffer swaps to the end of chain > +»······Something like this: > +»······»·······»·······»·······»·······»·······»·······»·······»·······»·······»·······------------^»··»······· > +»······»·······»·······»·······»·······»·······»·······»·······»·······»·······»·······|»······»·······»·······| > +»······|FrontBuffer| |BackBuffer0|BackBuffer1|Backbuffer2|....|BackbufferN| > +»······ »····»·······»·······»·······»·······»·······»·······»·······»·······»·······»·······»·······»·······»·······»·······^ > +»······»·······|---------------------------------------------------------------| > +»······»·······^ > +»······»·······|---------------------| > + > +»······»·······»·······»·······»·······»·······»·······»·······»·······»·······»······· > +»······*/ > + > +»······for(;i<This->presentParms.BackBufferCount-1;i++)· > +»······{ > +»······»·······hlp1 = (IWineD3DSurfaceImpl *)This->backBuffer[i]; > +»······»·······hlp2 = (IWineD3DSurfaceImpl *)This->backBuffer[i+1]; > +»······»·······hlp1->hDC = hlp2->hDC; > +»······»·······hlp1->dib.DIBsection = hlp2->dib.DIBsection; > +»······»·······hlp1->dib.bitmap_data = hlp2->dib.bitmap_data; > +»······»·······hlp1->resource.allocatedMemory = hlp2->resource.allocatedMemory; > +»······»·······hlp1->dib.client_memory = hlp2->dib.client_memory; > +»······} > + > +»······hlp1 = (IWineD3DSurfaceImpl *)This->backBuffer[i]; > +»······hlp1->hDC = front->hDC; > +»······hlp1 = (IWineD3DSurfaceImpl *)This->backBuffer[i]; > +»······hlp1->dib.DIBsection = front->dib.DIBsection; > +»······hlp1->dib.bitmap_data = front->dib.bitmap_data; > +»······hlp1->resource.allocatedMemory = front->resource.allocatedMemory; > +»······hlp1->dib.client_memory = front->dib.client_memory; > +»······ > +··· Style issues aside, that's not a very efficient way to implement a swapchain.

May 26, 2009

Re: [1/4] comctl32/listview: Basic LVM_GETVIEWRECT tests

by Nikolay Sivov

Paul Vriens wrote: > Nikolay Sivov wrote: >> Changelog: >> - Basic LVM_GETVIEWRECT tests >> >> + todo_wine expect(104, rect.right); >> + expect(0, rect.top); >> + expect(73, rect.bottom); > > The first and last one of these 3 introduces errors on several boxes > (see test.winehq.org) I guess these numbers can't be hardcoded and > need to be calculated somehow? > > Could you have a look? > Yeah. I've already fixed this in my tree. Will replace it with (> 0) cause all I want here is to show that not empty rectangle returned. Calculation is a best way of course but it's a next problem.

May 26, 2009

Re: [1/4] comctl32/listview: Basic LVM_GETVIEWRECT tests

by Paul Vriens

Nikolay Sivov wrote: > Changelog: > - Basic LVM_GETVIEWRECT tests > > + todo_wine expect(104, rect.right); > + expect(0, rect.top); > + expect(73, rect.bottom); The first and last one of these 3 introduces errors on several boxes (see test.winehq.org) I guess these numbers can't be hardcoded and need to be calculated somehow? Could you have a look? -- Cheers, Paul.

May 26, 2009

Re: Problem Running Winetricks

by Austin English

On Tue, May 26, 2009 at 9:26 AM, Michael <info(a)transformationalhealing.com.au> wrote: > Hi, > When I run winetricks, it consistently loops through and creates output > files winetricks.1 , winetricks.2 , etc ... until I break the terminal. > And doesn't do much more. > > Each of these files shows: > > > > How are you running it, exactly? It's apparently making copies of itself.. -- -Austin

May 26, 2009

Problem Running Winetricks

by Michael

Hi, When I run winetricks, it consistently loops through and creates output files winetricks.1 , winetricks.2 , etc ... until I break the terminal. And doesn't do much more. Each of these files shows:

May 26, 2009

Re: [PATCH 05/10] msi: Add support for importing binary OBJECTS.

by Alexandre Julliard

Hib Eris <hib(a)hiberis.nl> writes: > --- > dlls/msi/database.c | 63 +++++++++++++++++++++++++++++++++++++++++++++++--- > dlls/msi/msipriv.h | 3 +- > dlls/msi/record.c | 2 +- > dlls/msi/tests/db.c | 12 +++++----- > 4 files changed, 68 insertions(+), 12 deletions(-) This doesn't work here: ../../../tools/runtest -q -P wine -M msi.dll -T ../../.. -p msi_test.exe.so db.c && touch db.ok wine: Unhandled page fault on write access to 0x00000004 at address 0x7bc4460e (thread 0019), starting debugger... Unhandled exception: page fault on write access to 0x00000004 in 32-bit code (0x7bc4460e). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:7bc4460e ESP:0032f770 EBP:0032f7e8 EFLAGS:00010202( R- -- I - - - ) EAX:00000000 EBX:7bc94448 ECX:00110014 EDX:00000000 ESI:0012dcc8 EDI:0012dc48 Stack dump: 0x0032f770: 0032f784 00110014 00000020 0012dd00 0x0032f780: 0032f794 4d430002 0032f7bc 0012dc58 0x0032f790: 0032f7a4 00110014 00000070 4d430003 0x0032f7a0: 00000000 4d430003 00000000 00000000 0x0032f7b0: 00000000 00000000 00000000 4d430000 0x0032f7c0: 0012dc58 00000070 00000000 00000000 Backtrace: =>0 0x7bc4460e HEAP_CreateFreeBlock+0x3be(subheap=0x110014, ptr=0x12dc48, size=128) [/home/julliard/wine/wine/dlls/ntdll/../../include/wine/list.h:98] in ntdll (0x0032f7e8) 1 0x7bc44847 HEAP_MakeInUseBlockFree+0x57(subheap=0x110014, pArena=<is not available>) [/home/julliard/wine/wine/dlls/ntdll/heap.c:586] in ntdll (0x0032f838) 2 0x7bc44b3c RtlFreeHeap+0x18c(heap=0x110000, flags=2, ptr=0x12dcc8) [/home/julliard/wine/wine/dlls/ntdll/heap.c:1480] in ntdll (0x0032f898) 3 0x6081aa8e free_table+0x3e(table=<register EDI not in topmost frame>) [/home/julliard/wine/wine/dlls/msi/msipriv.h:1059] in msi (0x0032f8b8) 4 0x6081abae free_cached_tables+0x2e(db=<register ESI not in topmost frame>) [/home/julliard/wine/wine/dlls/msi/../../include/wine/list.h:133] in msi (0x0032f8c8) 5 0x607d3ec2 MSI_CloseDatabase+0x42(arg=0x12b7e8) [/home/julliard/wine/wine/dlls/msi/database.c:66] in msi (0x0032f8e8) 6 0x607e6b58 msiobj_release+0x48(info=<register ESI not in topmost frame>) [/home/julliard/wine/wine/dlls/msi/handle.c:257] in msi (0x0032f918) 7 0x607e6ccf MsiCloseHandle+0xbf(handle=<is not available>) [/home/julliard/wine/wine/dlls/msi/handle.c:311] in msi (0x0032f948) 8 0x6066abda test_binary_import+0x33a() [/home/julliard/wine/wine/dlls/msi/tests/db.c:1991] in msi_test (0x0032fca8) 9 0x60677d7e func_db+0x264e() [/home/julliard/wine/wine/dlls/msi/tests/db.c:7672] in msi_test (0x0032fde8) 10 0x60749a80 run_test+0x130(name="db.c") [/home/julliard/wine/wine/dlls/msi/tests/../../../include/wine/test.h:456] in msi_test (0x0032fe28) 11 0x60749c6f main+0x11f(argc=<register ECX not in topmost frame>, argv=<register ECX not in topmost frame>) [/home/julliard/wine/wine/dlls/msi/tests/../../../include/wine/test.h:505] in msi_test (0x0032fed8) 12 0x6074a484 __wine_spec_exe_entry+0x84(peb=0x7ffdf000) [/home/julliard/wine/wine/dlls/winecrt0/exe_entry.c:36] in msi_test (0x0032ff08) 13 0x7b878660 start_process+0x130(arg=(nil)) [/home/julliard/wine/wine/dlls/kernel32/process.c:941] in kernel32 (0x0032ffe8) 14 0x6002bc07 wine_switch_to_stack+0x17() in libwine.so.1 (0x00000000) 0x7bc4460e HEAP_CreateFreeBlock+0x3be [/home/julliard/wine/wine/dlls/ntdll/../../include/wine/list.h:98] in ntdll: movl %eax,0x4(%edx) 98 elem->next->prev = elem->prev; -- Alexandre Julliard julliard(a)winehq.org

May 26, 2009

Re: Mac OS X Joystick problem

by Aric Stewart

Hum, Strange. Those wine tests look just fine. They seem to be implying that it is finding your joystick and able to read its buttons and such. That would lead me to believe that the games would also be able to find it. Could you maybe provide me a +dinput log of you starting up one of these games so I can take a look? -aric Nathan Gray wrote: > On Thu, May 21, 2009 at 10:45 AM, Aric Stewart <aric(a)codeweavers.com> wrote: >> If you are good there then try building the winetests for dinput and run >> them with your joystick plugged in. You should get some status traces about >> your joystick (finding the name and status of the various axes and buttons) > > Ok, I built everything with Mike's build environment (after a bit of > updating URLs and such). From within the build directory I can run > dinput_test.exe and I get output like this (moving the stick and > pushing some buttons): > > [n8gray(a)golux]% wine programs/winetest/dinput_test.exe joystick > joystick.c:616: -- Testing Direct Input Version 0x0700 -- > fixme:dinput:get_osx_device_elements Unhandled type 513 > fixme:dinput:get_osx_device_elements Unhandled type 513 > joystick.c:206: ---- Microsoft SideWinder Precision Pro (USB) ---- > joystick.c:572: > joystick.c:591: X 1976 Y-1061 Z 0 Rx 0 Ry 0 Rz -323 S0-1056 > S1 0 POV0 9000 POV1 -1 POV2 -1 POV3 -1 B 0 0 0 1 1 0 0 1 0 0 > 0 0 > > joystick.c:596: > joystick.c:616: -- Testing Direct Input Version 0x0500 -- > fixme:dinput:get_osx_device_elements Unhandled type 513 > fixme:dinput:get_osx_device_elements Unhandled type 513 > joystick.c:206: ---- Microsoft SideWinder Precision Pro (USB) ---- > joystick.c:572: > joystick.c:591: X 2000 Y-1101 Z 0 Rx 0 Ry 0 Rz -323 S0-1088 > S1 0 POV0 9000 POV1 -1 POV2 -1 POV3 -1 B 0 0 0 1 1 0 0 1 0 0 > 0 0 > > joystick.c:596: > joystick.c:616: -- Testing Direct Input Version 0x0300 -- > joystick: 251 tests executed (0 marked as todo, 0 failures), 0 skipped. > >> If that is working then it may be how the games interact with dinput so it >> become not a mac specific issue. > > However, I still don't get any axes detected in the IL2 demo. During > launch it produces this output: > > DirectX Joystick NOT created: DirectX joystick driver: device not attached > > (Yes, the joystick is attached when I launch it.) > > I also don't get any joysticks listed in the Descent Freespace demo's setup app. > > Is there some other demo you can recommend that works for you? > > Thanks, > -n8 >

May 26, 2009

Re: DIB Engine : passing all tests

by Sergey Novosyolov

On Monday 25 May 2009 15:03:17 Alexandre Julliard wrote: > Writing a DIB engine is not a fill-in-the-blanks exercise. A large part > of the task is precisely to come up with a good design, Does anyone have a mention about what a good design should be? My mention is that DIB driver should not exist at all. All DIB functions should be released inside GDI32 as some functions already released (such as CreateDIBSection, CreateBitmap etc.)

May 26, 2009

Re: /. wants a fork

by Francois Gouget

On Mon, 25 May 2009, Stefan Dösinger wrote: [...] > On that subject, I think Dan Kegel's patchwatcher was a really, really good > idea, and we should revive it. Not only to catch simple problems, but also to > broaden the set of platforms patches are pre-tested before they are > applied(/me thinks about different graphics drivers) Agreed. I think it's one of the projects that has the most potential for helping Wine move faster. As usual it's probably best to start small even if it does not do all we would like at first. Then once the basics are in place, well tested and stable we can broaden the scope and think about the wilder reaches (testing on multiple platforms: FreeBSD and Solaris, automatic conformance test runs on multiple Windows versions, etc). But the first and most important step is to get things in place. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Before you criticize someone, walk a mile in his shoes. That way, if he gets angry, he'll be a mile away - and barefoot.

May 26, 2009

Re: DIB Engine : passing all tests

by Massimo Del Fedele

Alexandre Julliard ha scritto: > > The last time I rejected a simple patch from Massimo, he basically said > that he didn't have time to fix the patch and just dropped it. That > doesn't encourage me to spend more effort on reviewing his more complex > stuff. > Hi again :-) Well, to be precise those were some patches rejected, one with some explanation and others not. Former was about adding page size support to wineps.drv. I haven't dropped it, but you told me that an almost complete rewrite of cups printers handling was foreseen and preferred, so I kept it on my tree. I have really not enough skills nor time to do such a complex job. My patch was just sending the missing page size string to lpr along as printer name, which is by now the only stuff sent. I can understand, of course, that going through lpr is not a very nice way. I'm using the patch for my daily job, it's not dropped. Latters were one testcase (which was meant preparing some gdiplus patches....) which was rejected because "too long" and "with meaningless comments" and a couple of gdiplus functions that were missing (and are still missing) needed by autocad to run with builtin gdiplus, rejected because "contains errors" (possible, but which ?) and were "a pain to review" (hmmmm....). BTW, about comments, I'm sorry but my memory is not perfect and I tend to forget what I did and why after a couple of monthes, so the reason of maybe over-commenting all my code :-) I must say that the must difficult part of writing my engine was to try to figure out what gdi32/winex11 code does, and some comments more woul have been of great help ! Anyways, to finish, I'm coding for fun (ops, I guess I already said that) and I also have a job and a family that takes most of my time. If I don't see the possibility that my patches are accepted in a couple of tentatives, I tend to keep them on my "maybe useful stuffs" tree; otherwise if I see the possibility of having them published I can spend a bit more time on them. Of course a comment like "a pain to review" doesn't push me to work hard on it..... Ciao Max

May 26, 2009

Re: DIB Engine : passing all tests

by Massimo Del Fedele

Alexandre Julliard ha scritto: Hi Alexandre, > > One of the main problems I see is that your design is based on the > premise that there's only one graphics driver, the X11 driver. Well, I guess I expressed myself not completely corrected. My engine do load the winex11 exactly as gdi32 does. That means that in must not be winex11, it can be any driver that gdi32 would have loaded. The loading phase is like this : GDI32 <-- load any driver and gets function pointers for DC and bitmap (ORIGINAL) GDI32 <-- load winedib.drv <-- load any driver (etcetera) (MY WAY) The driver loading mechanics is the gdi32 one duplicated in winedib.drv. winedib.drv just intercept DIB calls and forward others to *any* other driver. Again, in my thoughts that is a "transient" phase, at the end all dib processing should go inside gdi32. That's > clearly not the case, DIBs can be used with any driver (and with > multiple drivers at the same time). This is also why you can't have the > DIB driver decide on when to forward/not forward to the X11 driver, it > should go in the other direction. > > I'm also very skeptical about mirroring DIBs with a DDB. Well, that was just a thought. I think that maintaining a mirrored DDB copy would slow down just a bit drawing operations but would speed up a lot blitting. But it's not a need. But even if you > do this that should be a purely internal x11drv decision, the DIB engine > shouldn't have any notion about this at all. This means you can't expose > DIB->DDB conversion routines, DDBs are entirely up to the graphics > driver. > I was meaning exposing a "stripped-extended" version of GetDIBits and SetDIBits, allowing partial image transfers. Again, that's not a need, it will just avoid code duplication in gdi32 and winex11. That would allow gdi32 to read and write portions of DDB with a call to winex11. Like it is now, you need knowledge of different DIB formats both in winex11 AND in gdi32; having this function would allow to move the "mixed blitting" stuffs almost completely inside gdi32. That's also just a suggestion. In my engine I have a bunch of PutLinexxx and GetLinexxx that do conversion from any format do 32 bit RGBA and vice versa; the functions I spoke about are just extensions of them for handling DDB conversion to/from 32 bit RGBA, and should reside, of course, in winex11. I agree with you that the DDB caching of DIBs should be a winex11 stuff and totally transparent to gdi32. Thanx for answers Max

May 26, 2009

Re: DIB Engine : passing all tests

by Alexandre Julliard

Chris Morgan <chmorgan(a)gmail.com> writes: > Wouldn't a review of the proposed dib engine be useful? One that > included concerns, things that needed to be changed etc? Everyone > involved seems to be asking for leadership and guidance about how to > proceed, wouldn't a thorough review of the proposed design give > direction towards an "acceptable" design? Of course, but a thorough review takes time, lots of time. If you want Huw or myself to invest that kind of time, you have to demonstrate that it's worth it. That was my point about first establishing a track record with simpler stuff. The last time I rejected a simple patch from Massimo, he basically said that he didn't have time to fix the patch and just dropped it. That doesn't encourage me to spend more effort on reviewing his more complex stuff. -- Alexandre Julliard julliard(a)winehq.org

May 26, 2009

Re: DIB Engine : passing all tests

by Alexandre Julliard

Massimo Del Fedele <max(a)veneto.com> writes: > About point 4, which, I guess, is the most important for you, the next step would be > to make a winex11-2.drv on which DIB processing would be stripped away, and with > added DDB buffering of DIBs and mixed blit operations. > That driver could be connected to (and tested with) winedib.drv, always as an option > in registry/environment. > Once ready and stable enough it should be made permanently enabled and remaining part of > winedib.drv could be merged inside gdi32; that could also be made stepwise. > Of course this design would mean some duplication of code in gdi32 and winex11.drv, at least > if we don't want to change something in driver function tables.... which would be the > best solution if it's not imposed by Microsoft behaviour (I didn't check that one, nor > I think to do it for the moment). > A simple GetLine() * PutLine() that do translation between 32 bit RGBA <--> DDB inside > winex11.drv and callable by gdi32 would of course avoid all code duplication needed for > mixed blitting, keeping needed speed. That addition would be trivial. > > I think my design has some advantages and some disadvantages to other ones, but it's > superior to the "double pointer approach" taken before, for reasons already explained. > The main "disadvantage", maybe the only one, is to have for some time 2 different > drivers in wine..... but OTOH it allows deep testing without breaking anything. One of the main problems I see is that your design is based on the premise that there's only one graphics driver, the X11 driver. That's clearly not the case, DIBs can be used with any driver (and with multiple drivers at the same time). This is also why you can't have the DIB driver decide on when to forward/not forward to the X11 driver, it should go in the other direction. I'm also very skeptical about mirroring DIBs with a DDB. But even if you do this that should be a purely internal x11drv decision, the DIB engine shouldn't have any notion about this at all. This means you can't expose DIB->DDB conversion routines, DDBs are entirely up to the graphics driver. -- Alexandre Julliard julliard(a)winehq.org

May 26, 2009

Re: comctl32:rebar: Don't store an empty string in REBAR_InsertBandT.

by Nikolay Sivov

Sergey Khodych wrote: > From a2bf101f7ede3937373b7b8f9e2a8ea032b7790d Mon Sep 17 00:00:00 2001 > From: Sergey Khodych <khodych(a)gmail.com> > Date: Mon, 25 May 2009 02:21:39 +0300 > Subject: comctl32:rebar: Don't store an empty string in REBAR_InsertBandT. > > --- > dlls/comctl32/rebar.c | 12 ++++++++---- > dlls/comctl32/tests/rebar.c | 2 +- > 2 files changed, 9 insertions(+), 5 deletions(-) Where did you test that it isn't stored?

May 26, 2009

Re: PowerPC MacOSX work...

by mghughes＠embarqmail.com

Download link did not work... Would have been good to look at/try/experiment with, but not what I am looking/aiming for. On May 25, 2009, at 03:52 PM, Gert van den Berg wrote: > Just a random question: Any chance that PowerPC Windows apps might > work on a PPC Wine build? > > A PowerPC port of Windows NT (3.51 and 4 according to Wikipedia) > briefly existed.... Don't know if any apps more than those bundled > with Windows existed. (Here's one: http://www.jmcgowan.com/ppc.html ) > > Gert >

May 26, 2009

Re: /. wants a fork

by Jerome Leclanche

2009/5/26 James McKenzie <jjmckenzie51(a)earthlink.net>: > And lastly, I think there is a site at repo.cz that has all of the > unaccepted Wine code somewhere, that we all could look at and fix. > > James McKenzie > All of it, definitely not. Only some of it (unless there IS one I'm not aware of). It would be nice to have a repository of fixes that are still in queue/have been rejected. Some patches do indeed just disappear without any reason given, and the author never bothers to fix what could be just a minor inconvenience in it. Seen years old patches all of a sudden being fixed and resent in order to fix an application that would have been running long before then. It would probably be maintenance hell, though. Maybe patchwatcher could help? -- Adys

May 26, 2009

Re: /. wants a fork

by James McKenzie

Nicklas Börjesson wrote: >> Not sure, but I see the second time around was a success for him. >> > > Let's not look to hard. > He (or her) does have the right to having an opinion and going out of one's way finding out and posting here would only appear vindictive and fuel interest. > > 1. I don't feel like creating a /. account just to reply. 2. AJ has keep several bad patches from being applied to Wine since I've been here. Without this, we would have a project that supports a couple of programs real well and others would be complete garbage.. 3. There should be a code style and submission guidance document. Something that explains coding style (four spaces vice tabs) and comment style ('c' style vice C++/VC++/Java). It would also be nice to have a statement that a patch has to affect one and only one area or bug. Oh, fixes CANNOT break existing running programs, just to get your favorite running, if you want them accepted. Now with that being said, getting the DIB engine into Wine may take a lot of shoehorning and for AJ to look over all of the code and accept/reject it with good notes and reasons. "You can do better" is not, in my book, a good reason. "Your code is not up to our standards" is with a side comment of "look at what is accepted and what is peer-rejected before resubmission". Of course, AJ does take on projects that a coder just cannot make work within the standards. And this is a good thing. Sadly, Electroshock decided that he would take his toys and go play in another sandbox. And lastly, I think there is a site at repo.cz that has all of the unaccepted Wine code somewhere, that we all could look at and fix. James McKenzie

May 26, 2009

Re: Regression in "ntdll: Free old memory"

by Ben Klein

2009/5/26 Niklas Hambüchen <nh2(a)deditus.de>: > There is something wrong with commit > 13a33b73c349530b17347d3ec6a1f5bb268cc917 (ntdll: Free old memory block > when reallocating to a large block.). > > Having this this patch applied (as it is in wine-1.1.22), some > applications show a strange behavior, for example Guild Wars does not > start up (it keeps "repairing" on and on). > > git revert 13a33b73c349530b17347d3ec6a1f5bb268cc917 does the trick, but > most probably this is not the solution. > > > The regression test was: > > 13a33b73c349530b17347d3ec6a1f5bb268cc917 is first bad commit > commit 13a33b73c349530b17347d3ec6a1f5bb268cc917 > Author: Alexandre Julliard <julliard(a)winehq.org> > Date: Sat May 16 11:33:06 2009 +0200 > > ntdll: Free old memory block when reallocating to a large block. > > :040000 040000 e210ab3f16dee6da3a6b6b34d375737b103d5951 > 25abcf5a437d9a494593e654553dd2797066f616 M dlls If you haven't done so already, please report this on bugs.winehq.org

May 26, 2009

Re: DIB Engine : passing all tests

by Chris Morgan

On Mon, May 25, 2009 at 9:32 PM, Chris Morgan <chmorgan(a)gmail.com> wrote: > On Mon, May 25, 2009 at 10:49 AM, Alexandre Julliard > <julliard(a)winehq.org> wrote: >> Zachary Goldberg <zgold(a)bluesata.com> writes: >> >>> On Mon, May 25, 2009 at 7:03 AM, Alexandre Julliard <julliard(a)winehq.org> wrote: >>>> >>>> Writing a DIB engine is not a fill-in-the-blanks exercise. A large part >>>> of the task is precisely to come up with a good design, validate it with >>>> a prototype, >>> >>> Would you, Alexandre, say we are at this point? I.e. that Massimo's >>> design is probably an alright prototype but he just hasn't convinced >>> you/Huw yet and hasn't yet "anticipated common objections" etc.? >> >> Well, the prototype doesn't show much evidence of a good design. Maybe >> Massimo has one in mind, but he hasn't explained it so far. >> >> -- >> Alexandre Julliard >> julliard(a)winehq.org >> > > Wouldn't a review of the proposed dib engine be useful? One that > included concerns, things that needed to be changed etc? Everyone > involved seems to be asking for leadership and guidance about how to > proceed, wouldn't a thorough review of the proposed design give > direction towards an "acceptable" design? > > Chris > If it wasn't clear, I was suggesting that AJ and/or Huw would do this review since they have knowledge of the issue and an opinion of how it should be done :-) Chris

May 26, 2009

Re: DIB Engine : passing all tests

by Chris Morgan

On Mon, May 25, 2009 at 10:49 AM, Alexandre Julliard <julliard(a)winehq.org> wrote: > Zachary Goldberg <zgold(a)bluesata.com> writes: > >> On Mon, May 25, 2009 at 7:03 AM, Alexandre Julliard <julliard(a)winehq.org> wrote: >>> >>> Writing a DIB engine is not a fill-in-the-blanks exercise. A large part >>> of the task is precisely to come up with a good design, validate it with >>> a prototype, >> >> Would you, Alexandre, say we are at this point? I.e. that Massimo's >> design is probably an alright prototype but he just hasn't convinced >> you/Huw yet and hasn't yet "anticipated common objections" etc.? > > Well, the prototype doesn't show much evidence of a good design. Maybe > Massimo has one in mind, but he hasn't explained it so far. > > -- > Alexandre Julliard > julliard(a)winehq.org > Wouldn't a review of the proposed dib engine be useful? One that included concerns, things that needed to be changed etc? Everyone involved seems to be asking for leadership and guidance about how to proceed, wouldn't a thorough review of the proposed design give direction towards an "acceptable" design? Chris

May 26, 2009

Re: PowerPC MacOSX work...

by Michael G Hughes

Yes and no... I'll state that PPC processors have instructions to deal with endianness like: lhbrx/sthbrx Load/Store half word (16-bits) byte reversed indexed lwbrx/stwbrx Load/Store word (32-bit) byte reversed indexed Michael On Mon, 25 May 2009 16:06:03 -0400, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > If I remember and understand the Darwine site correctly, no, they won't > work > because WinPPC uses little endian while MacOS uses big endian. I am > wondering > how that would be possible though, can PPCs switch modes? > -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

May 26, 2009

Re: Does wine handle virtual midi ports correct on OSX?

by James McKenzie

Emmanuel Maillard wrote: > Does notes play well when playing ? > Correct duration, correct tempo or other kind of timing issue ? > > Have you see fixme about MOD_MIDIPORT in log ? Emmanuel: Pardon my barging into this conversation, but music does not play correctly with Doom. Not the CD Music, but the background music. I get no error messages in the log file either about MOD_MIDIPORT. MacOSX 10.5.7 James McKenzie

May 26, 2009

Re: /. wants a fork

by Ben Klein

2009/5/25 Remco <remco47(a)gmail.com>: > Oh great, now there is poison on slashdot: > > http://tech.slashdot.org/article.pl?sid=09/05/24/2044239 > > Let's not fork, shall we? >From this post: "The latest attempt of Massimo Del Fedel satisfied all requirements set previously for the long standing bug 421, and his optional engine seems to work fine by all Wine quality standards." The issue is that it doesn't match Wine's quality standards (for architecture). This Elektroschock guy is hilarious. What post did he use to demonstrate "the dissatisfaction of core developers with the arbitrary project governance"? http://www.winehq.org/pipermail/wine-devel/2009-May/075844.html Chris responding to Max responding to me. Who here is the "core developer"? Chris doesn't appear in the WhosWho page on the wiki, nor can I find his name in git log --author. That only leaves Max, who's best work continues to remain floating on bug page #421 without being committed. For what it's worth, I agree with Chris. Someone needs to document how the DIB engine architecture *should* work, and then Massimo and <insert next guy to pick up DIB engine should Max lose interest> will know how to proceed. I believe we're closer than we've ever been to having a fully-working DIB engine, and I'd love to see real effort made towards getting it upstream.

May 25, 2009

Re: /. wants a fork

by King InuYasha

2009/5/25 Nicklas Börjesson <Nicklas.Borjesson(a)ws.se> > > Not sure, but I see the second time around was a success for him. > > Let's not look to hard. > He (or her) does have the right to having an opinion and going out of one's > way finding out and posting here would only appear vindictive and fuel > interest. > > //Nicklas > > > I don't post on here very often, I don't even hang out in #winehq(-social) very often either, so my opinion may not be considered too important, but by just looking at the efforts of the Wine Project to address the DIB engine over the years, I feel disheartened by the lack of real progress. There have been patches regarding the DIB engine that goes all the way back to 2002 with TransGaming! But the implementations are always stonewalled and left to die over arbitrary architectural reasons. I say arbitrary because I don't have a clue what the spec is for this supposed architecture that the DIB engine is supposed to follow. Eventually, Bug #421 may just be like one of those 10-year-old bugs that live in the GNOME and Mozilla bugzillas, that are just left there because people don't care enough anymore to do anything about it. While it is true that the DIB engine isn't the One True Solution regarding compatibility with many Windows applications, it helps a lot with graphics-intensive ones. At this rate, the DIB engine will be reassigned to the 1.4.0 milestone because nobody will accept any implementation. And nobody say, "Patches welcome!" or "Patches accepted!" because there is proof to the contrary. The fact people say that is also a problem. A vast majority of people are not technically inclined to the level of being able to produce such things. Even people that subscribe to mailing lists like I do, are not capable of contributing like that. And really, code IS NOT the most valuable form of contribution for any project. If anything, it is of the LEAST value. Documentation, advice, testing, support people, moderators, infrastructure management, all these are MUCH more valuable than code or money. Now, this problem is not limited to the Wine Project. This problem is all over the open source world. It bugs me a lot when I get rebuffed because I'm not a programmer. Granted, most people that ask are whiny and demanding, and they get on people's nerves. But, people are generally happier with an explanation in a cordial manner. Being mean or sarcastic about it, or even asking for something they can't give is not a good way to go about it. But, I digress. The Wine Project is making great strides, and with the work the ReactOS Project is doing alongside them, the work is a lot more momentous than just a compatibility API/ABI layer for UNIX and Unix-like systems.

May 25, 2009

Re: Does wine handle virtual midi ports correct on OSX?

by Steve Schow

it seems like what happens is that i select an IAC or virtual midi port from some windows host inside Wine and everything looks ok, but no events are sent. Nothing. But sometimes it works and sometimes it doesn't. Once it is working it works fine. Sometimes I have started it up and it was not working, then I forgot that i had set it up and 5-10 minutes later suddenly it would start sending the data across. Seems like somehow the windows host was not flushing the buffer or something. I had this problem with Reaper and the latest version of Reaper seems to be working ok, so maybe this was a Reaper problem, not wine. I didn't see that fixme you mentioned. Where can I find that? I'm actually using CrossOverGames for this, I was never able to get Wine to work with JackOSX. On May 25, 2009, at 11:47 AM, Emmanuel Maillard wrote: > Does notes play well when playing ? > Correct duration, correct tempo or other kind of timing issue ? > > Have you see fixme about MOD_MIDIPORT in log ? > > Emmanuel > > Le 25 mai 09 à 17:59, Steve Schow a écrit : > >>

May 25, 2009

Re: DIB Engine : passing all tests

by James McKenzie

Paul Vriens wrote: > Massimo Del Fedele wrote: >> The engine has still some known bugs (known by me :-) ) which are not >> spotter >> by wine testsuite, mostly related to coordinate spaces in xxxBlt >> functions. > > Are they not spotted because the tests don't cover these? If so, would > you be able/willing to add some tests to the test suite? > Paul: Max knows about the problems and the tests. He just does not have the time right now to fix the problems and write the tests. He has hinted and asked others to help him. I have no knowledge of the DIB engine nor its processes, but I'd be willing to give it a go on the Mac, but I don't have any programs that appear to use the functions. James McKenzie

May 25, 2009

Re: DIB Engine : passing all tests

by Massimo Del Fedele

Alexandre Julliard ha scritto: > > Well, the prototype doesn't show much evidence of a good design. Maybe > Massimo has one in mind, but he hasn't explained it so far. > Well, I still think that the "goodness" of a design is a matter of taste. My design is *a* design, started because of a personal need and evoluted by *my* personal taste, which was the only way I had without proper roadmap. Btw, I thought to have explained enough the reasons of the choosen design, but I may be wrong.... so I'll put again here the pursued goals : 1) Something usable. That means something that don't work "just for a couple of apps" but that work in general at least as current driver do. This goal il about 90% to be reached, imho. It'll be 100% in a couple of monthes, if my job will let me enough spare time. 2) Something optional. There's no point, imo, to make a driver that breaks even just one app without the ability to fall back to original gdi32/winex11. Goal 100% reached. 3) Provide a working engine that allow in deep testing of speed difference. We know that *some* apps do benefit of it (again, autocad speed gain on TT fonts is something like 50x - 100x), but I've seen that recent thoughts were those of a limited speed gain.... Well, I think that many important apps could benefit of it. Goal 80% reached, as mixed blitting is something slower than original driver. No simple way to make it as fast without touching winex11.drv. 4) "prepare the road" to a definitive migration to what I think should be the "right final design", so DIBs handled by gdi32 double buffered by DDB inside winex11.drv; mixed blitting done inside winex11. I think that one would be the only viable way if we want blitting speed *and* DIB drawing speed. My driver is doing the needed separation of 2 processes. Once completed, moving them into gdi32/winex11.drv should be quite easy and could be done stepwise. 5) for fun. Ops, that one should be the n. 1 :-) About point 4, which, I guess, is the most important for you, the next step would be to make a winex11-2.drv on which DIB processing would be stripped away, and with added DDB buffering of DIBs and mixed blit operations. That driver could be connected to (and tested with) winedib.drv, always as an option in registry/environment. Once ready and stable enough it should be made permanently enabled and remaining part of winedib.drv could be merged inside gdi32; that could also be made stepwise. Of course this design would mean some duplication of code in gdi32 and winex11.drv, at least if we don't want to change something in driver function tables.... which would be the best solution if it's not imposed by Microsoft behaviour (I didn't check that one, nor I think to do it for the moment). A simple GetLine() * PutLine() that do translation between 32 bit RGBA <--> DDB inside winex11.drv and callable by gdi32 would of course avoid all code duplication needed for mixed blitting, keeping needed speed. That addition would be trivial. I think my design has some advantages and some disadvantages to other ones, but it's superior to the "double pointer approach" taken before, for reasons already explained. The main "disadvantage", maybe the only one, is to have for some time 2 different drivers in wine..... but OTOH it allows deep testing without breaking anything. I hope I explained enough about it. Technical details are in (maybe too abundants...) code comments. Ciao Max

May 25, 2009

Regression in "ntdll: Free old memory"

by Niklas Hambüchen

There is something wrong with commit 13a33b73c349530b17347d3ec6a1f5bb268cc917 (ntdll: Free old memory block when reallocating to a large block.). Having this this patch applied (as it is in wine-1.1.22), some applications show a strange behavior, for example Guild Wars does not start up (it keeps "repairing" on and on). git revert 13a33b73c349530b17347d3ec6a1f5bb268cc917 does the trick, but most probably this is not the solution. The regression test was: 13a33b73c349530b17347d3ec6a1f5bb268cc917 is first bad commit commit 13a33b73c349530b17347d3ec6a1f5bb268cc917 Author: Alexandre Julliard <julliard(a)winehq.org> Date: Sat May 16 11:33:06 2009 +0200 ntdll: Free old memory block when reallocating to a large block. :040000 040000 e210ab3f16dee6da3a6b6b34d375737b103d5951 25abcf5a437d9a494593e654553dd2797066f616 M dlls Thank you!

May 25, 2009

RE: /. wants a fork

by Nicklas Börjesson

> Not sure, but I see the second time around was a success for him. Let's not look to hard. He (or her) does have the right to having an opinion and going out of one's way finding out and posting here would only appear vindictive and fuel interest. //Nicklas

May 25, 2009

Re: /. wants a fork

by Jeremy White

> Not sure, but I see the second time around was a success for him.. > > First attempt on the subject : > http://slashdot.org/firehose.pl?op=view&id=4193755 > <http://slashdot.org/firehose.pl?op=view&id=4193755> Ah. I see; he apparently believes that CrossOver has a DIB Engine and we've been holding out all these years. That's why he decided we were evil. /me goes to review Huw's commits to find the one where he snuck a DIB Engine into CrossOver without my knowing it <grin>. Cheers, Jeremy

May 25, 2009

Re: /. wants a fork

by Tom Wickline

On Mon, May 25, 2009 at 9:47 AM, Henri Verbeet <hverbeet(a)gmail.com> wrote: > 2009/5/25 Remco <remco47(a)gmail.com>: > > Oh great, now there is poison on slashdot: > > > > http://tech.slashdot.org/article.pl?sid=09/05/24/2044239 > > > > Let's not fork, shall we? > > > Out of pure curiosity, does anyone know if this "Elektroschock" guy > has a real name? > Not sure, but I see the second time around was a success for him.. First attempt on the subject : http://slashdot.org/firehose.pl?op=view&id=4193755 Tom -- http://www.wine-reviews.net/ http://bordeauxgroup.com/

May 25, 2009

Re: wine on MacOS 10.5.7: 3/4 success

by Steven Edwards

Hi, On Mon, May 25, 2009 at 7:19 AM, <Joerg-Cyril.Hoehle(a)t-systems.com> wrote: > What keys in Wine do you mean precisely? My Mac has subpixel rendering > disabled on my LCD, but it uses shades of grey (hinting or anti-aliasing?) for most fonts. > Neither Terminal.app use hinting, nor winecfg: plain black&white. > I don't have any particular registry key set in Linux. See bug 10342 for more information. Your freetype needs to be compiled with #define FT_CONFIG_OPTION_SUBPIXEL_RENDERING I did not bother to check with the existing FreeType in the latest Xorg or Xcode or where ever it is, under OS X, I just assumed its not enabled and I rolled my own for other reasons anyway. To enable SubPixel support you need to change the value for HCU\Control Panel\Desktop\FontSmoothing from 0 to 1(I think) or 2. Setting the option to 1 seems to change the algorithm used, I think that's using Gray Scale hinting, there is a lot of traffic on the bug so I might have just missed where it clarifies. Setting the option to 2 (to me at least) looks best. http://steven-edwards.kicks-ass.org/~sedwards/Safari-vs-Wine-without-Subpix… http://steven-edwards.kicks-ass.org/~sedwards/Safari-vs-Wine-with-Subpixel.… -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

May 25, 2009

Re: PowerPC MacOSX work...

by Stefan Dösinger

Am Montag, 25. Mai 2009 20:33:28 schrieb mghughes(a)embarqmail.com: > No No No People... Please read the messages before replying. I did, but they were not clear to me. To be honest, I am still not sure what you want to achieve. > For the record... I am not looking to run another full out emulation. > The best example of what I have in mind is what Apple did when they > moved their processor base from 68K to PPC. And I am wondering if the > same could be done for Wine. By the looks of things some of the > framework to make that happen are already there in the form of thunk > code... Apple used what they called trampolines iirc. Do you mean running the Windows app in an emulator, Wine on the native CPU and inserting trampolines or something else that switches in and out of the emulator whenever there's a call from the app to Wine code, or from Wine code back to the app? Something like that exists - the Win16 support that switches the x86 CPU in 16 bit or 32 bit mode whenever the control is passed between Wine and the app. It would probably be comparably easy to adopt this for Win16 on PPC. There are a number of issues that make this much, much harder on Win32 vs PPC. 1) COM interfaces. They pass around function pointers, and there is no DLL entry point for a COM method. You'd have to write a thunk DLL for each DLL that uses COM objects. You'll need a glue DLL that has some PPC code that knows how to convert parameters and call into the emulator. And you'll need glue x86 code that knows how to break out of the emulator and call the PPC side of the glue DLL. 2) Wine vs App call. If I understand things correctly, Wine never calls a Win16 entry point in Wine. There are many cases where a Wine DLL calls another Wine dll. E.g. WineD3D calls gdi32 and opengl32. You'll have to find a way to figure out where a call came from, and more important, figure out where a call is going to if you're calling a callback function. 3) API explosion: Back in the Win 3.1 day the Win16 API has been pretty compact. Nowadays there are hundreds of DLLs that have hundreds to thousands of functions or COM methods. So running Win32 apps in an emulator on a PPC-native Wine is most likely possible from a technical point of view, but it is a very complex job. In terms of final usability the needed effort is probably spent more efficiently by improving the emulator, just run Wine in the emulator and thunk the comparably small Linux syscall interface(qemu already does that). The advantages of Wine-level thunks is that the theoretical best performance is better. This is probably true especially with D3D rendering. E.g. instead of converting a A8R8G8B8 texture from big endian to little endian one might just replace the pixelformat with B8G8R8A8. A setup like that could also allow us to run 32 bit apps on Wine64, and end the "you guys need a proper ABI" whine from distro maintainers. It's an open source project, so everybody is free to take the code and give it a try :-)

May 25, 2009

Re: Icon Refresh News (and a question)

by Joel Holdsworth

> Looks great, hope you get your code clean and soon can send patches. > Why the buttons on the right top of the open-dialog are empty? Answer: Hack n' slash. I have no reproduction of the mechanism for checking which images *should* be alpha blended, and which should not - the code assumes all icons should, and so in the case of 16-bit icons the alpha channel is fixed at constant 0, and so will these icons are drawn with 0% opacity! This is one of many things that need to be finished in my work, but the proof-of-concept is there. Joel

May 25, 2009

Re: PowerPC MacOSX work...

by Stefan Dösinger

Am Montag, 25. Mai 2009 21:52:53 schrieb Gert van den Berg: > On Mon, May 25, 2009 at 13:44, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > > The main trouble is that Windows apps are x86, so in order to run > > anything but builtin notepad you'll need a CPU emulator. In that case, > > just compile wine as x86 binary and run it in the emulator as well. > > Just a random question: Any chance that PowerPC Windows apps might > work on a PPC Wine build? If I remember and understand the Darwine site correctly, no, they won't work because WinPPC uses little endian while MacOS uses big endian. I am wondering how that would be possible though, can PPCs switch modes?

May 25, 2009

Re: /. wants a fork

by Zachary Goldberg

On Mon, May 25, 2009 at 1:24 PM, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > Am Montag, 25. Mai 2009 15:47:30 schrieb Henri Verbeet: >> 2009/5/25 Remco <remco47(a)gmail.com>: >> > Oh great, now there is poison on slashdot: >> > >> > http://tech.slashdot.org/article.pl?sid=09/05/24/2044239 >> > >> > Let's not fork, shall we? >> >> Out of pure curiosity, does anyone know if this "Elektroschock" guy >> has a real name? > He posted similar slashdot stories in the past: > http://developers.slashdot.org/developers/07/10/08/0344231.shtml > >> Personally I don't see a lot of "dissatisfaction of core developers >> with the arbitrary project governance", but I guess it's been a while >> since we had a "real" Governance thread. > I guess we had one on Sept. 27 or 28 2008. I guess the next one is not yet > scheduled, but will be somewhen in the fall I guess. > > On that subject, I think Dan Kegel's patchwatcher was a really, really good > idea, and we should revive it. Not only to catch simple problems, but also to > broaden the set of platforms patches are pre-tested before they are > applied(/me thinks about different graphics drivers) > Patchwatcher is coming back. Look for something from me in the next couple weeks either on wine-devel or in WWN.

May 25, 2009

Re: PowerPC MacOSX work...

by Gert van den Berg

On Mon, May 25, 2009 at 13:44, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > The main trouble is that Windows apps are x86, so in order to run anything but > builtin notepad you'll need a CPU emulator. In that case, just compile wine > as x86 binary and run it in the emulator as well. > Just a random question: Any chance that PowerPC Windows apps might work on a PPC Wine build? A PowerPC port of Windows NT (3.51 and 4 according to Wikipedia) briefly existed.... Don't know if any apps more than those bundled with Windows existed. (Here's one: http://www.jmcgowan.com/ppc.html ) Gert

May 25, 2009

Re: winhlp32: Avoid duplicate assignment in WINHELP_GetWindowInfo(). (RESEND)

by Eric Pouech

Gerald Pfeifer a écrit : > Originally sent ten days ago; looks obvious to me? > > Gerald > > ChangeLog: > Avoid duplicate assignment in WINHELP_GetWindowInfo(). > > diff --git a/programs/winhlp32/winhelp.c b/programs/winhlp32/winhelp.c > index 7f74d8b..d1980e5 100644 > --- a/programs/winhlp32/winhelp.c > +++ b/programs/winhlp32/winhelp.c > @@ -278,7 +278,7 @@ HLPFILE_WINDOWINFO* WINHELP_GetWindowInfo(HLPFILE* hlpfile, LPCSTR name) > mwi.origin.x = mwi.origin.y = mwi.size.cx = mwi.size.cy = CW_USEDEFAULT; > mwi.style = SW_SHOW; > mwi.win_style = WS_OVERLAPPEDWINDOW; > - mwi.sr_color = mwi.sr_color = 0xFFFFFF; > + mwi.sr_color = 0xFFFFFF; > } > return &mwi; > } > > > > > fix is wrong the second should be nr_color instead of sr_color (hence the "double" assignment) A+ -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)

May 25, 2009

Re: Bugzilla: I dont stay logged in

by Kai Blin

On Monday 25 May 2009 14:22:34 André Hentschel wrote: > Hi, > If i log in with both Checkboxes selected, i can do exactly one thing, and > then i am logged out again. For example: if i am on a bug and log in, i > can write a comment and got logged out. if i log in and select "add an > attachment" i can fill the form, but the next step doesnt work correct > because i got logged out. can someone fix it please? I had that as well. Unchecking the "restrict to this IP address" seems to have fixed it for me. Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton.

May 25, 2009

Re: failure to recognize "early 2009" Mac Mini nVidia 9400 OpenGL version string

by Stefan Dösinger

Am Montag, 25. Mai 2009 12:18:55 schrieb Joerg-Cyril.Hoehle(a)t-systems.com: > Before I submit a patch to have wine recognize either space or "-" as > separator, I'd like to query the list whether it actually makes sense > to return major = 1, minor = 5, i.e. Apple numbers to a MS-Windows program? No, it doesn't, and I don't think we're doing anything useful right now with the parsed driver version. We only use the parsed OpenGL version, which is the same format everywhere. Once upon a time we passed that version to the windows game, but as you said, this doesn't make sense. So these days we have a (PCI_VEN/PCI_DEV)->driver version mapping where we hardcode the latest known Windows driver version(that table needs an update). I think the other idea to keep the driver version passing was to be able to work around known bugs, but currently there aren't and driver version dependent workarounds, and I don't know if there ever will be(we dislike hacks to workaround bugs). So feel free to kill the whole driver version parsing.

May 25, 2009

Re: Does wine handle virtual midi ports correct on OSX?

by Steve Schow

it seems like what happens is that i select an IAC or virtual midi port from some windows host inside Wine and everything looks ok, but no events are sent. Nothing. But sometimes it works and sometimes it doesn't. Once it is working it works fine. Sometimes I have started it up and it was not working, then I forgot that i had set it up and 5-10 minutes later suddenly it would start sending the data across. Seems like somehow the windows host was not flushing the buffer or something. I had this problem with Reaper and the latest version of Reaper seems to be working ok, so maybe this was a Reaper problem, not wine. I didn't see that fixme you mentioned. Where can I find that? I'm actually using CrossOverGames for this, I was never able to get Wine to work with JackOSX. Emmanuel Maillard-3 wrote: > > Does notes play well when playing ? > Correct duration, correct tempo or other kind of timing issue ? > > Have you see fixme about MOD_MIDIPORT in log ? > > Emmanuel > > Le 25 mai 09 à 17:59, Steve Schow a écrit : > >> >> Thanks for responding. I'm just sending midi notes around, no sysex. >> Sometimes the ports work and sometimes they don't. I may be finding >> that >> the problem is more related to Reaper bugs, I'm not sure yet. Seems >> like it >> will not work and then sometimes after a few minutes, it will >> suddenly start >> working. Seems possibly related to flushing, but I'm not sure. >> >> I'm not a wine developer, so I will just note your comments about >> MIDIClientCreate and keep testing from my end. >> >> >> >> >> Emmanuel Maillard-3 wrote: >>> >>> Hi, >>> >>> Sorry for the late answer. >>> The MIDI driver is very rudimentary : (by memory) it doesn't handle >>> SysEx, doesn't handle notification from MIDIServer, >>> and poorly tested : just testing by reading few MIDI files, and few >>> In/ >>> Out tests with 2 virtuals application. >>> >>> I think you first need is to add MIDINotifyProc, in MIDIClientCreate >>> to track your MIDI setup changes. >>> >>> Cheers >>> Emmanuel >>> >>> Le 7 mai 09 à 06:20, Dewdman42 a écrit : >>> >>>> >>>> Does anyone know if Darwine can be fixed to handle virtual midi >>>> ports >>>> correctly? They work very sporadically right now. It seems to be >>>> related >>>> to getting the ports flushed or initialized or something. When >>>> there is a >>>> virtual midi port present (under OSX), Wine seems to see it and >>>> lists it as >>>> an available midi port, but I have not been able to consistently get >>>> that >>>> port to function correctly. Sometimes it does and sometimes it >>>> doesn't and >>>> it seems to related to switching it on and off in some fashion makes >>>> it >>>> work, though I can't seem to find a pattern that will work >>>> consistently. >>>> >>>> All I can figure is that somehow Wine is not handling midi ports in >>>> a way >>>> that is compatible with OSX virtual midi ports. >>>> >>>> Anyone have any experience or knowledge in this area? >>>> >>>> Thanks >>>> -- >>>> View this message in context: >>>> http://www.nabble.com/Does-wine-handle-virtual-midi-ports-correct-on-OSX--t… >>>> Sent from the Wine - Devel mailing list archive at Nabble.com. >>>> >>>> >>>> >>> >>> >>> >>> >>> >> >> -- >> View this message in context: >> http://www.nabble.com/Does-wine-handle-virtual-midi-ports-correct-on-OSX--t… >> Sent from the Wine - Devel mailing list archive at Nabble.com. >> >> >> > > > > > -- View this message in context: http://www.nabble.com/Does-wine-handle-virtual-midi-ports-correct-on-OSX--t… Sent from the Wine - Devel mailing list archive at Nabble.com.

May 25, 2009

Re: PowerPC MacOSX work...

by Austin English

On 5/25/09, Roderick Colenbrander <thunderbird2k(a)gmail.com> wrote: > He might be wanting to use winelib and that should work. People used > it in the past. I tried it around December, and a lot of things were broken/missing. I filed several bugs: http://bugs.winehq.org/show_bug.cgi?id=16694 http://bugs.winehq.org/show_bug.cgi?id=16695 http://bugs.winehq.org/show_bug.cgi?id=16736 http://bugs.winehq.org/show_bug.cgi?id=16742 http://bugs.winehq.org/show_bug.cgi?id=16744 http://bugs.winehq.org/show_bug.cgi?id=16747 http://bugs.winehq.org/show_bug.cgi?id=16746 http://bugs.winehq.org/show_bug.cgi?id=16749 http://bugs.winehq.org/show_bug.cgi?id=16750 http://bugs.winehq.org/show_bug.cgi?id=16751 http://bugs.winehq.org/show_bug.cgi?id=16752 http://bugs.winehq.org/show_bug.cgi?id=16861 16695 is the deadly one, breaking everything, including notepad. I've got a patch in there for it, not sure if it's right, however. Of course, keep in mind all that stuff is 6 months old, but should give you a starting point. -- -Austin

May 25, 2009

Re: Does wine handle virtual midi ports correct on OSX?

by Emmanuel Maillard

Does notes play well when playing ? Correct duration, correct tempo or other kind of timing issue ? Have you see fixme about MOD_MIDIPORT in log ? Emmanuel Le 25 mai 09 à 17:59, Steve Schow a écrit : > > Thanks for responding. I'm just sending midi notes around, no sysex. > Sometimes the ports work and sometimes they don't. I may be finding > that > the problem is more related to Reaper bugs, I'm not sure yet. Seems > like it > will not work and then sometimes after a few minutes, it will > suddenly start > working. Seems possibly related to flushing, but I'm not sure. > > I'm not a wine developer, so I will just note your comments about > MIDIClientCreate and keep testing from my end. > > > > > Emmanuel Maillard-3 wrote: >> >> Hi, >> >> Sorry for the late answer. >> The MIDI driver is very rudimentary : (by memory) it doesn't handle >> SysEx, doesn't handle notification from MIDIServer, >> and poorly tested : just testing by reading few MIDI files, and few >> In/ >> Out tests with 2 virtuals application. >> >> I think you first need is to add MIDINotifyProc, in MIDIClientCreate >> to track your MIDI setup changes. >> >> Cheers >> Emmanuel >> >> Le 7 mai 09 à 06:20, Dewdman42 a écrit : >> >>> >>> Does anyone know if Darwine can be fixed to handle virtual midi >>> ports >>> correctly? They work very sporadically right now. It seems to be >>> related >>> to getting the ports flushed or initialized or something. When >>> there is a >>> virtual midi port present (under OSX), Wine seems to see it and >>> lists it as >>> an available midi port, but I have not been able to consistently get >>> that >>> port to function correctly. Sometimes it does and sometimes it >>> doesn't and >>> it seems to related to switching it on and off in some fashion makes >>> it >>> work, though I can't seem to find a pattern that will work >>> consistently. >>> >>> All I can figure is that somehow Wine is not handling midi ports in >>> a way >>> that is compatible with OSX virtual midi ports. >>> >>> Anyone have any experience or knowledge in this area? >>> >>> Thanks >>> -- >>> View this message in context: >>> http://www.nabble.com/Does-wine-handle-virtual-midi-ports-correct-on-OSX--t… >>> Sent from the Wine - Devel mailing list archive at Nabble.com. >>> >>> >>> >> >> >> >> >> > > -- > View this message in context: http://www.nabble.com/Does-wine-handle-virtual-midi-ports-correct-on-OSX--t… > Sent from the Wine - Devel mailing list archive at Nabble.com. > > >

May 25, 2009

Re: failure to recognize "early 2009" Mac Mini nVidia 9400 OpenGL version string

by Roderick Colenbrander

On Mon, May 25, 2009 at 12:18 PM, <Joerg-Cyril.Hoehle(a)t-systems.com> wrote: > Hi, > > as of wine-1.1.21, wine does not recognize the "early 2009" Mac Mini > OpenGL version string from nVidia: > err:d3d_caps:IWineD3DImpl_FillGLCaps Invalid nVidia version string: "2.0 NVIDIA-1.5.44" > > The string probably originates from XQuartz' X11.2.3.3.2. The wine > source code expects a space after NVIDIA. On Linux, the numbers are > much higher, e.g. "2.1.2 NVIDIA 173.14.09" or "2.1.0 NVIDIA 97.55" -- 2 samples from Google. > > Before I submit a patch to have wine recognize either space or "-" as > separator, I'd like to query the list whether it actually makes sense > to return major = 1, minor = 5, i.e. Apple numbers to a MS-Windows program? > > Or should I not care about the useage and just parse the string (i.e. submit patch)? > > Thanks, > Jörg Höhle > > > The version string parsing isn't that important. The version number we return isn't based on this anymore. We use a lookup table in case of nvidia. Roderick

May 25, 2009

Re: PowerPC MacOSX work...

by mghughes＠embarqmail.com

No No No People... Please read the messages before replying. I know the difference betweeen my 6502, 6800, Z80, 68k, x86, 7400. I know Wine is focused on running MSWindows based software on x86 processors. I also know there exists PowerPC code in the wine project because people were interested in bridging the gap to running x86 code via emulation... For the record... I am not looking to run another full out emulation. The best example of what I have in mind is what Apple did when they moved their processor base from 68K to PPC. And I am wondering if the same could be done for Wine. By the looks of things some of the framework to make that happen are already there in the form of thunk code... Apple used what they called trampolines iirc. I am not sure that WineLib is what I am looking to use as the wine script & loader seems to achieve much of what I am already looking to do. My understanding is that Wine has run on PowerPC at some time via native and Qemu/Qemu-user. Since the Darwine (PowerPC work) project went dormant, I have not been able to find much of the information I am looking for... What was the last known Wine/Darwine version known to work on PowerPC? I some had thoughts of getting that version and progressing forward to see what and where things break. Am I mistaken that the connection between wine/server appears to be broken? My previous statements in my first message still apply. Michael

May 25, 2009

Re: /. wants a fork

by Stefan Dösinger

Am Montag, 25. Mai 2009 15:47:30 schrieb Henri Verbeet: > 2009/5/25 Remco <remco47(a)gmail.com>: > > Oh great, now there is poison on slashdot: > > > > http://tech.slashdot.org/article.pl?sid=09/05/24/2044239 > > > > Let's not fork, shall we? > > Out of pure curiosity, does anyone know if this "Elektroschock" guy > has a real name? He posted similar slashdot stories in the past: http://developers.slashdot.org/developers/07/10/08/0344231.shtml > Personally I don't see a lot of "dissatisfaction of core developers > with the arbitrary project governance", but I guess it's been a while > since we had a "real" Governance thread. I guess we had one on Sept. 27 or 28 2008. I guess the next one is not yet scheduled, but will be somewhen in the fall I guess. On that subject, I think Dan Kegel's patchwatcher was a really, really good idea, and we should revive it. Not only to catch simple problems, but also to broaden the set of platforms patches are pre-tested before they are applied(/me thinks about different graphics drivers)

May 25, 2009

Re: /. wants a fork

by Chris Howe

2009/5/25 Remco <remco47(a)gmail.com> > Oh great, now there is poison on slashdot: > > http://tech.slashdot.org/article.pl?sid=09/05/24/2044239 > > Let's not fork, shall we? > > Remco > > > Well, this is awkward. For the record: I didn't intend to ambush anyone on here with my frustrations, and I certainly wouldn't have chosen to publicise them via Slashdot. Such is the nature of public discourse, eh. I don't think forking's the answer (and I'm certainly not putting myself forward for that!) That said, there's only so long that the issues of a proper DIB engine can go unadressed, and I mean, it hasn't been addressed for some time, despite the efforts of several people, latterly Massimo, to provide at least proof of concept solutions. All that's really been agreed upon is that what's there now can't be tweaked over time to become the "right solution", but at the same time, it can't be replaced wholesale as that might cause regression. This would seem to be a logical impasse, and that's why it needs a decision made, I think. No one developer is going to be able to come out and write the roadmap for it, because it needs broad input from a lot of people, not just Alexandre. But certainly, as a starting point, if it's so trivial to reject something on the grounds that the architecture is WRONG it suggests that there is a solution out there that's RIGHT, it just needs to be documented. My intention was not to whine, (except that it's heartbreaking to see good code go to waste over and over again) nor was it my aim to throw stones, but to try and stimulate the required discussion. If this list isn't the place for that, then perhaps a section of the Wiki? Even just a timetable for when it might be discussed? (As in, by release x.x.x, the roadmap needs to have been agreed upon). -- Chris

May 25, 2009

Re: Bugzilla: I dont stay logged in

by Mike Kaplinskiy

2009/5/25 André Hentschel <nerv(a)dawncrow.de>: > Hi, > If i log in with both Checkboxes selected, i can do exactly one thing, and > then i am logged out again. > For example: if i am on a bug and log in, i can write a comment and got > logged out. > if i log in and select "add an attachment" i can fill the > form, but the next step doesnt work correct because i got logged out. > can someone fix it please? > > > I had this problem. I think the recent bugzilla config changes mess with your browser. Just clear all the cookies from bugs.winehq.org . Mike.

May 25, 2009

Re: Does wine handle virtual midi ports correct on OSX?

by Steve Schow

Thanks for responding. I'm just sending midi notes around, no sysex. Sometimes the ports work and sometimes they don't. I may be finding that the problem is more related to Reaper bugs, I'm not sure yet. Seems like it will not work and then sometimes after a few minutes, it will suddenly start working. Seems possibly related to flushing, but I'm not sure. I'm not a wine developer, so I will just note your comments about MIDIClientCreate and keep testing from my end. Emmanuel Maillard-3 wrote: > > Hi, > > Sorry for the late answer. > The MIDI driver is very rudimentary : (by memory) it doesn't handle > SysEx, doesn't handle notification from MIDIServer, > and poorly tested : just testing by reading few MIDI files, and few In/ > Out tests with 2 virtuals application. > > I think you first need is to add MIDINotifyProc, in MIDIClientCreate > to track your MIDI setup changes. > > Cheers > Emmanuel > > Le 7 mai 09 à 06:20, Dewdman42 a écrit : > >> >> Does anyone know if Darwine can be fixed to handle virtual midi ports >> correctly? They work very sporadically right now. It seems to be >> related >> to getting the ports flushed or initialized or something. When >> there is a >> virtual midi port present (under OSX), Wine seems to see it and >> lists it as >> an available midi port, but I have not been able to consistently get >> that >> port to function correctly. Sometimes it does and sometimes it >> doesn't and >> it seems to related to switching it on and off in some fashion makes >> it >> work, though I can't seem to find a pattern that will work >> consistently. >> >> All I can figure is that somehow Wine is not handling midi ports in >> a way >> that is compatible with OSX virtual midi ports. >> >> Anyone have any experience or knowledge in this area? >> >> Thanks >> -- >> View this message in context: >> http://www.nabble.com/Does-wine-handle-virtual-midi-ports-correct-on-OSX--t… >> Sent from the Wine - Devel mailing list archive at Nabble.com. >> >> >> > > > > > -- View this message in context: http://www.nabble.com/Does-wine-handle-virtual-midi-ports-correct-on-OSX--t… Sent from the Wine - Devel mailing list archive at Nabble.com.

May 25, 2009

Re: DIB Engine : passing all tests

by Alexandre Julliard

Zachary Goldberg <zgold(a)bluesata.com> writes: > On Mon, May 25, 2009 at 7:03 AM, Alexandre Julliard <julliard(a)winehq.org> wrote: >> >> Writing a DIB engine is not a fill-in-the-blanks exercise. A large part >> of the task is precisely to come up with a good design, validate it with >> a prototype, > > Would you, Alexandre, say we are at this point? I.e. that Massimo's > design is probably an alright prototype but he just hasn't convinced > you/Huw yet and hasn't yet "anticipated common objections" etc.? Well, the prototype doesn't show much evidence of a good design. Maybe Massimo has one in mind, but he hasn't explained it so far. -- Alexandre Julliard julliard(a)winehq.org

May 25, 2009

Re: Icon Refresh News (and a question)

by André Hentschel

Joel Holdsworth schrieb: > > Does anyone have any thoughts or comments? > > Thanks > Joel > Looks great, hope you get your code clean and soon can send patches. Why the buttons on the right top of the open-dialog are empty?

May 25, 2009

Re: /. wants a fork

by Tommy

Hello, I'd like to ask why you can't include this engine until someone does it the "right" way? If it doesn't do anything until user will manually trigger it, it shouldn't do any harm. If it can't be possible, I can provide a script to automatically download WINE from git, apply DIB engine patches and compile, so maybe someone could post it on WINE website for really DIB-engine-curious users. 2009/5/25 Henri Verbeet <hverbeet(a)gmail.com>: > 2009/5/25 Remco <remco47(a)gmail.com>: >> Oh great, now there is poison on slashdot: >> >> http://tech.slashdot.org/article.pl?sid=09/05/24/2044239 >> >> Let's not fork, shall we? >> > Out of pure curiosity, does anyone know if this "Elektroschock" guy > has a real name? > Personally I don't see a lot of "dissatisfaction of core developers > with the arbitrary project governance", but I guess it's been a while > since we had a "real" Governance thread. > > >

May 25, 2009

Re: DIB Engine : passing all tests

by Zachary Goldberg

On Mon, May 25, 2009 at 7:03 AM, Alexandre Julliard <julliard(a)winehq.org> wrote: > > Writing a DIB engine is not a fill-in-the-blanks exercise. A large part > of the task is precisely to come up with a good design, validate it with > a prototype, Would you, Alexandre, say we are at this point? I.e. that Massimo's design is probably an alright prototype but he just hasn't convinced you/Huw yet and hasn't yet "anticipated common objections" etc.?

May 25, 2009

Icon Refresh News (and a question)

by Joel Holdsworth

Hi All, I've been working away little by little at my icons work, and I'm beginning to make a little progress: http://www.airwebreathe.org.uk/alpha-tango-icons.png The screenshot montage shows my work on getting HICONs and HIMAGELISTs to support the alpha channel, combined with a refreshed icon set from Tango. Right now, a lot of the changes I've made are rather bodged, but I'm encouraged because at least here we see a proof of principle. To get this to work, I've basically had to go through fixing places where the alpha channel is incorrectly stripped or ignored. All of them are relatively easily fixed, except the ones in the stretch blt functions. StretchBlt, StretchDIBits et al. seem to have a fast path and a slow path. The fast path is active when no stretching or translation should occur. The slow path performs all other cases, but my tests show that only the fast path preserves the alpha channel. The reason must be that the stretch is performed in X - but this is a problem, because I don't know if it's possible for X to preserve alpha. Does anyone know? My demo has replaced the offending StretchBlts with BitBlts, which works fine, unless the icon has to be rescaled. Does anyone have any thoughts or comments? Thanks Joel

May 25, 2009

Re: /. wants a fork

by Daniel Devine

On Monday 25 May 2009 23:12:57 Remco wrote: > Oh great, now there is poison on slashdot: > > http://tech.slashdot.org/article.pl?sid=09/05/24/2044239 > > Let's not fork, shall we? > > Remco I saw the article. Anybody who thinks a fork is a good idea is quite frankly an idiot. However they are free to have their own GIT repo and play in their own corner. At the end of the day anybody is able to write a patch and share it with whomever they like - it might even be extremely popular but that is no reason to spoil the main code base. Patching and compiling really is child's play - there is even automated scripts for Ubuntu so even your grandmother can do it. Stop whining and improve your code/design and try asking around for some help. On the subject of the DIB engine I think that the parties involved need to just cool down, remember that they are on the same team and calmly and rationally work out the (full!) requirements. I am not very well known to this list (but I hang in #winehq and -social quite a bit) so I'm not sure if I am right to submit my thoughts. Take whatever I have said wrong with a grain of salt. I love the Wine project and I hope to become a productive contributor eventually. Also take Slashdot with pinch... I mean BAG of salt.

May 25, 2009

Re: /. wants a fork

by Henri Verbeet

2009/5/25 Remco <remco47(a)gmail.com>: > Oh great, now there is poison on slashdot: > > http://tech.slashdot.org/article.pl?sid=09/05/24/2044239 > > Let's not fork, shall we? > Out of pure curiosity, does anyone know if this "Elektroschock" guy has a real name? Personally I don't see a lot of "dissatisfaction of core developers with the arbitrary project governance", but I guess it's been a while since we had a "real" Governance thread.

May 25, 2009

/. wants a fork

by Remco

Oh great, now there is poison on slashdot: http://tech.slashdot.org/article.pl?sid=09/05/24/2044239 Let's not fork, shall we? Remco

May 25, 2009

Re: PowerPC MacOSX work...

by Roderick Colenbrander

He might be wanting to use winelib and that should work. People used it in the past. Roderick On Mon, May 25, 2009 at 1:44 PM, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > Am Montag, 25. Mai 2009 00:49:55 schrieb Michael G Hughes: >> I have managed to get Wine compiling on a PowerMac G4, MacOSX 10.3.9, a >> while back... >> >> What I know so far... It does not work... Who'd a thunk it? >> >> Just trying to run winecfg gives me: >> >> fixme:seh:RTLCaptureContext not implimented on PowerPC >> fixme:seh:call_stack_handlers not implemented on PowerPC >> wine: Unhandled alignment at address 0x44010788 (thread 000d), starting >> debugger... >> err:process:__wine_kernel_init boot event wait timed out > The main trouble is that Windows apps are x86, so in order to run anything but > builtin notepad you'll need a CPU emulator. In that case, just compile wine > as x86 binary and run it in the emulator as well. > > > >

May 25, 2009

Bugzilla: I dont stay logged in

by André Hentschel

Hi, If i log in with both Checkboxes selected, i can do exactly one thing, and then i am logged out again. For example: if i am on a bug and log in, i can write a comment and got logged out. if i log in and select "add an attachment" i can fill the form, but the next step doesnt work correct because i got logged out. can someone fix it please?

May 25, 2009

Re: PowerPC MacOSX work...

by Stefan Dösinger

Am Montag, 25. Mai 2009 00:49:55 schrieb Michael G Hughes: > I have managed to get Wine compiling on a PowerMac G4, MacOSX 10.3.9, a > while back... > > What I know so far... It does not work... Who'd a thunk it? > > Just trying to run winecfg gives me: > > fixme:seh:RTLCaptureContext not implimented on PowerPC > fixme:seh:call_stack_handlers not implemented on PowerPC > wine: Unhandled alignment at address 0x44010788 (thread 000d), starting > debugger... > err:process:__wine_kernel_init boot event wait timed out The main trouble is that Windows apps are x86, so in order to run anything but builtin notepad you'll need a CPU emulator. In that case, just compile wine as x86 binary and run it in the emulator as well.

May 25, 2009

Re: Does wine handle virtual midi ports correct on OSX?

by Emmanuel Maillard

Hi, Sorry for the late answer. The MIDI driver is very rudimentary : (by memory) it doesn't handle SysEx, doesn't handle notification from MIDIServer, and poorly tested : just testing by reading few MIDI files, and few In/ Out tests with 2 virtuals application. I think you first need is to add MIDINotifyProc, in MIDIClientCreate to track your MIDI setup changes. Cheers Emmanuel Le 7 mai 09 à 06:20, Dewdman42 a écrit : > > Does anyone know if Darwine can be fixed to handle virtual midi ports > correctly? They work very sporadically right now. It seems to be > related > to getting the ports flushed or initialized or something. When > there is a > virtual midi port present (under OSX), Wine seems to see it and > lists it as > an available midi port, but I have not been able to consistently get > that > port to function correctly. Sometimes it does and sometimes it > doesn't and > it seems to related to switching it on and off in some fashion makes > it > work, though I can't seem to find a pattern that will work > consistently. > > All I can figure is that somehow Wine is not handling midi ports in > a way > that is compatible with OSX virtual midi ports. > > Anyone have any experience or knowledge in this area? > > Thanks > -- > View this message in context: http://www.nabble.com/Does-wine-handle-virtual-midi-ports-correct-on-OSX--t… > Sent from the Wine - Devel mailing list archive at Nabble.com. > > >

May 25, 2009

Re: wine on MacOS 10.5.7: 3/4 success

by Joerg-Cyril.Hoehle＠t-systems.com

Steven Edwards wrote: >There is a reason you may want to roll your own freetype. I don't >believe the freetype that ships with even the latest Xorg dpkg >contains support for the patented bytecode stuff or subpixel rendering >enabled. I could be wrong about needing to do it (perhaps I have an >old version floating around), but I rolled my own freetype with it >enabled and enabled the proper keys in Wine and can hardly see a >difference in Safari or Wine iexplore rendering winehq.org Very interesting. Indeed I forgot to mention that fonts do not look good in regular wine GUI windows using my native compile and XQuartz' FreeType. Putting two wine desktops side by side on the Mac display, a) ssh -X to a linux box (i.e. wine running on Linux, X display on the Mac) b) Mac native shows the disaster, solely running winecfg: - The Linux fonts in winecfg look sharp (1 pixel wide), while e.g. the Mac's 'W' looks bulky. Both the Tahoma sample text and the regular system text are affected. - Text needs more horizontal room (is this lack of grid-fitting?), so e.g. the copyright text in winecfg overflows into the "registered owner" input box area as it needs one more line of text to display the same words. OTOH, Mike Kronenberg's 1.1.20 winecfg looks as good as the Linux one. What keys in Wine do you mean precisely? My Mac has subpixel rendering disabled on my LCD, but it uses shades of grey (hinting or anti-aliasing?) for most fonts. Neither Terminal.app use hinting, nor winecfg: plain black&white. I don't have any particular registry key set in Linux. Regards, Jörg Höhle

May 25, 2009

Re: DIB Engine : passing all tests

by Alexandre Julliard

Jan de Mooij <jandemooij(a)gmail.com> writes: > On Sun, May 24, 2009 at 12:04 PM, Chris Howe <mrmessiah(a)gmail.com> wrote: >> 2009/5/24 Massimo Del Fedele <max(a)veneto.com> >> >> Sorry to sound like a stuck record but the Wine website still lists >> "write a DIB engine" as a requirement, and every time someone >> does, the patches dissapear down a hole because they're "not >> right". Someone document what "would be right", or take "write >> a DIB engine" off the list. I'd love to have a go at documenting it >> myself, but I don't have the time to reverse engineer it from a >> few years' worth of rejected solutions. >> > Agreed. I would be willing to invest some time this summer in a DIB > engine but it's impossible because of this. A wiki page describing the > "right design" and what is needed in which component would be a great > start. Maybe a goal for next WineConf? Writing a DIB engine is not a fill-in-the-blanks exercise. A large part of the task is precisely to come up with a good design, validate it with a prototype, and then convince people (especially Huw and myself) that your design is good, that you know what you are doing, that you have anticipated the common objections and have good answers for them, that you are willing to make requested changes, that you have good test cases, etc. Showing that it more or less works on a couple of apps, or that it passes the (very few) existing gdi32 tests, is of course necessary, but by no means enough. If you want to tackle this, it will also help to have a good track record in getting simpler patches in first. Once all of this is done and the proper design is in place in the tree, then there might be a number of fill-in-the-blanks tasks to implement the less common graphics calls that would probably be stubbed out in the first version. But we are nowhere near that point yet. -- Alexandre Julliard julliard(a)winehq.org

May 25, 2009

Re: DIB Engine : passing all tests

by Paul Vriens

Massimo Del Fedele wrote: > The engine has still some known bugs (known by me :-) ) which are not > spotter > by wine testsuite, mostly related to coordinate spaces in xxxBlt functions. Are they not spotted because the tests don't cover these? If so, would you be able/willing to add some tests to the test suite? -- Cheers, Paul.

May 25, 2009

failure to recognize "early 2009" Mac Mini nVidia 9400 OpenGL version string

by Joerg-Cyril.Hoehle＠t-systems.com

Hi, as of wine-1.1.21, wine does not recognize the "early 2009" Mac Mini OpenGL version string from nVidia: err:d3d_caps:IWineD3DImpl_FillGLCaps Invalid nVidia version string: "2.0 NVIDIA-1.5.44" The string probably originates from XQuartz' X11.2.3.3.2. The wine source code expects a space after NVIDIA. On Linux, the numbers are much higher, e.g. "2.1.2 NVIDIA 173.14.09" or "2.1.0 NVIDIA 97.55" -- 2 samples from Google. Before I submit a patch to have wine recognize either space or "-" as separator, I'd like to query the list whether it actually makes sense to return major = 1, minor = 5, i.e. Apple numbers to a MS-Windows program? Or should I not care about the useage and just parse the string (i.e. submit patch)? Thanks, Jörg Höhle

May 25, 2009

Re: DXTn textures in D3DX9

by Stefan Dösinger

Am Sonntag, 24. Mai 2009 21:11:27 schrieb Mike Kaplinskiy: > I believe mesa looks for libtxc_dxtn @ > http://homepage.hispeed.ch/~rscheidegger/dri_experimental/s3tc_index.html > and then enables full s3tc support. The library itself is tiny and in > (ugly) C, so that is already good news. But as stated on the website, > you cannot use the code due to legality. Maybe there would be a way to > do on-demand loading as with mesa and output a warn/fixme if the > library is not found? It seems like the approach would be similar to > the way the font bytecode interpreter was handled (turn on if > available). Wine did that a while ago, prior to my ddraw rewrite. However, from testing it seems that the S3TC decompression of that lib did not work properly(Gothic 2 showed bad textures), and the compression code according to that site is ugly. So my 2c is that we need a better library than this libtxc_dxtn stuff. Maybe we can get a C wrapper around the nvidia texture tools lib in place. The nvidia texture tools also have command line utilities - maybe that works. Note that I don't think we can ship nvidia texture tools, but we can load the lib dynamically and enable / disable. Maybe we should require the Win32 version, not the Linux version, and handle it similarily to gecko.

May 25, 2009

Re: DIB Engine : passing all tests

by Jan de Mooij

On Sun, May 24, 2009 at 12:04 PM, Chris Howe <mrmessiah(a)gmail.com> wrote: > 2009/5/24 Massimo Del Fedele <max(a)veneto.com> > > Sorry to sound like a stuck record but the Wine website still lists > "write a DIB engine" as a requirement, and every time someone > does, the patches dissapear down a hole because they're "not > right". Someone document what "would be right", or take "write > a DIB engine" off the list. I'd love to have a go at documenting it > myself, but I don't have the time to reverse engineer it from a > few years' worth of rejected solutions. > Agreed. I would be willing to invest some time this summer in a DIB engine but it's impossible because of this. A wiki page describing the "right design" and what is needed in which component would be a great start. Maybe a goal for next WineConf? I understand people are working on other important issues and that's much appreciated, but it's frustrating that so much valuable time has been spent on this (discussions and code) for years and see all attempts hit the same brick wall.

May 25, 2009

Re: DIB Engine : passing all tests

by Massimo Del Fedele

Steven Edwards ha scritto: > On Sun, May 24, 2009 at 10:19 PM, James McKenzie > <jjmckenzie51(a)earthlink.net> wrote: >> That's ugly. Did you attempt to type in something in the Document area? > > I've disabled all my Quartz hacks, the only thing sort of non-standard > I have is my custom FreeType with patented engine enabled and support > for SubPixel rendering turned on. Now that I think about it, that > could be a problem. I'll try another round of testing with that > disabled next. > > Yes, it is MUCH faster rendering and scrolling and the like but there > are minor glitches with the font placement in the document area. > Notice how the word support and deployment overlap with the dib engine > and how the lines alternate color? The speed difference for editing is > like night and day. The header and footers for the document body > containing images renders fine. Installers such as ie6setup and msxml3 > embedded images don't render properly, I'll try to upload images for > that as well in the morning. Bugzilla seems to be running quite slow > so I can't upload the images there. Comparison screenshots for Word > are here > > http://steven-edwards.kicks-ass.org/~sedwards/Wine_1.1.22_Word2007_NO_DibEn… > http://steven-edwards.kicks-ass.org/~sedwards/Wine_1.1.22_Word2007_With_Dib… > > Since this is not likely to get merged in anytime soon, lets move the > rest of the OS X related discussions back to the bug when bugzilla > decides to stop munching on the pesticide. I'll try to file more > detailed reports as time permits. > > Max this is wonderful progress, please keep up the good work! > > Thanks He Steven, Thank you for testing and for your words :-) The engine has still some known bugs (known by me :-) ) which are not spotter by wine testsuite, mostly related to coordinate spaces in xxxBlt functions. There is also a small stuff in AlphaBlend() with DDB as source, which is still not implemented, but should be trivial too. Another stuff that needs to be "fixed" is font handling; by now is not complete even if it's mostly functional: it does not kerning (you can see it easily on some apps, autocad too) and font sizes sometimes are wrong. All these stuffs should be trivial to fix, but I have really few time on these days, so it will take some time. Ciao Max

May 25, 2009

Re: DIB Engine : passing all tests

by Steven Edwards

On Sun, May 24, 2009 at 10:19 PM, James McKenzie <jjmckenzie51(a)earthlink.net> wrote: > That's ugly. Did you attempt to type in something in the Document area? I've disabled all my Quartz hacks, the only thing sort of non-standard I have is my custom FreeType with patented engine enabled and support for SubPixel rendering turned on. Now that I think about it, that could be a problem. I'll try another round of testing with that disabled next. Yes, it is MUCH faster rendering and scrolling and the like but there are minor glitches with the font placement in the document area. Notice how the word support and deployment overlap with the dib engine and how the lines alternate color? The speed difference for editing is like night and day. The header and footers for the document body containing images renders fine. Installers such as ie6setup and msxml3 embedded images don't render properly, I'll try to upload images for that as well in the morning. Bugzilla seems to be running quite slow so I can't upload the images there. Comparison screenshots for Word are here http://steven-edwards.kicks-ass.org/~sedwards/Wine_1.1.22_Word2007_NO_DibEn… http://steven-edwards.kicks-ass.org/~sedwards/Wine_1.1.22_Word2007_With_Dib… Since this is not likely to get merged in anytime soon, lets move the rest of the OS X related discussions back to the bug when bugzilla decides to stop munching on the pesticide. I'll try to file more detailed reports as time permits. Max this is wonderful progress, please keep up the good work! Thanks -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

May 25, 2009