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

Re: ntdll/tests: Mark return value of RtlUnicodeStringToInteger("", 16) as broken for nt4.

by Alexandre Julliard

Paul Vriens <paul.vriens.wine(a)gmail.com> writes: > I don't think this is correct. This test has always succeeded until > March 9th. There haven't been any changes to the test in that period, > but I remember an upgrade of winehq in that weekend. > > In other words, there is more to it. Testing a simple cross compiled > version of this test doesn't yield an error on NT4. My feeling is that it's returning uninitialized data, so the results depend on the stack layout that the compiler is using. There's probably no sense in checking for a specific value, just consider this case broken no matter what it returns. -- Alexandre Julliard julliard(a)winehq.org

May 19, 2009

Re: gdiplus: implement GdipTransformPoints

by Alexandre Julliard

Vincent Povirk <madewokherd+8cd9(a)gmail.com> writes: > It's odd, but it seems like the simplest way to write this. > > I've tried what I think was your suggestion, and that's attached. I > don't think it's an improvement. You should short-circuit the src_space == dst_space case, that would simplify things a lot. Then you can probably have two switch statements, one to do src_space -> Page and then Page -> dst_space. -- Alexandre Julliard julliard(a)winehq.org

May 19, 2009

Re: [PATCH] winhttp: avoid NULL ptr dereference (Coverity 927)

by Paul Vriens

Marcus Meissner wrote: > Hi, > > Not sure if we need to set these values in all error paths, > but definitely not in the NULL lpwhr. (lpwhdr?) > > Ciao, Marcus > --- > dlls/wininet/http.c | 4 +++- > 1 files changed, 3 insertions(+), 1 deletions(-) > > diff --git a/dlls/wininet/http.c b/dlls/wininet/http.c > index 212ff9f..53c3743 100644 > --- a/dlls/wininet/http.c > +++ b/dlls/wininet/http.c > @@ -3831,8 +3831,9 @@ static BOOL HTTP_OpenConnection(LPWININETHTTPREQW lpwhr) > > TRACE("-->\n"); > > + if (!lpwhr) goto lend2; > > - if (NULL == lpwhr || lpwhr->hdr.htype != WH_HHTTPREQ) > + if (lpwhr->hdr.htype != WH_HHTTPREQ) > { > INTERNET_SetLastError(ERROR_INVALID_PARAMETER); > goto lend; > @@ -3894,6 +3895,7 @@ lend: > lpwhr->read_pos = lpwhr->read_size = 0; > lpwhr->read_chunked = FALSE; > > +lend2: > TRACE("%d <--\n", bSuccess); > return bSuccess; > } Hi Marcus, After AJ's remark you marked this Coverity one as "lpwhr can not be NULL". Should we thus delete the "NULL == lpwhr" altogether? -- Cheers, Paul.

May 19, 2009

Re: ntdll/tests: Mark return value of RtlUnicodeStringToInteger("", 16) as broken for nt4.

by Paul Vriens

Huw Davies wrote: > --- > dlls/ntdll/tests/rtlstr.c | 3 ++- > 1 files changed, 2 insertions(+), 1 deletions(-) > > > ------------------------------------------------------------------------ > > Hi, I don't think this is correct. This test has always succeeded until March 9th. There haven't been any changes to the test in that period, but I remember an upgrade of winehq in that weekend. In other words, there is more to it. Testing a simple cross compiled version of this test doesn't yield an error on NT4. -- Cheers, Paul.

May 19, 2009

Re: [PATCH 2/2] ole32/tests: Add tests to show the WdtpInterfacePointer marshal data looks like the result of CoMarshalInterface.

by Paul Vriens

Paul Vriens wrote: > Huw Davies wrote: >> --- >> dlls/ole32/tests/usrmarshal.c | 38 >> +++++++++++++++++++++----------------- >> 1 files changed, 21 insertions(+), 17 deletions(-) >> >> >> ------------------------------------------------------------------------ >> >> > Hi Huw, > > Could you have a look at the test results are test.winehq.org> This > patch and the other one against usrmarshall.c introduced some test > failures on several platforms. > Thanks for looking into this, Huw. -- Cheers, Paul.

May 19, 2009

Re: [PATCH 8/8] urlmon: Added binding with MIME filter tests.

by Alexandre Julliard

Jacek Caban <jacek(a)codeweavers.com> writes: > --- > dlls/urlmon/tests/url.c | 782 > ++++++++++++++++++++++++++++++++++++++--------- > 1 files changed, 636 insertions(+), 146 deletions(-) This is failing here: ../../../tools/runtest -q -P wine -M urlmon.dll -T ../../.. -p urlmon_test.exe.so url.c && touch url.ok url.c:2939: Test failed: mon should be destroyed here url.c:2940: Test failed: bctx should be destroyed here make: *** [url.ok] Error 2 -- Alexandre Julliard julliard(a)winehq.org

May 19, 2009

Re: Gecko installation broken?

by Stefan Dösinger

Am Montag, 18. Mai 2009 22:46:59 schrieb Lei Zhang: > It didn't think so either, so I even double checked. Upon further > investigation, it seems the problem is simply the gecko cab download > is failing. Either one of the Sourceforge servers is down/flaky, or > source.winehq.org is taking too long to do the redirect and wininet > doesn't handle that well. That might explain why the HL2 test ran successfully yesterday, but not the TF2 test(which does the same Gecko setup). Today both failed again. On the other hand, it seems that the download succeeds - the progress bar runs to the end, and the dialog box says "installing" for about a second.

May 19, 2009

Re: [Article] WINE and the importance of application compatibility

by Kai Blin

On Tuesday 19 May 2009 01:45:14 Scott Ritchie wrote: > I don't think we'll get much traction with this unless we can reasonably > tell them they only need to test the stable Wine release. But 1.0 is > pretty old these days, so they probably won't bother. > > I'll add it to my list of evangelism to do after Wine 1.2 hits. And > also not-so-subtly suggest this is another reason Wine 1.2 needs to > happen sooner ;) There's two sides to this, though. From an ISV perspective, there's something as "release too often". I've heard fom many distros that they're not too happy about Samba doing a minor version bump twice a year these days. Of course I guess a Wine stable release once a year is reasonable, assuming we try really hard to not regress between stable releases. That depends on being able to test a lot of applications, though. 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 19, 2009

Re: [wintrust/tests] Add some basic CryptCATOpen tests

by Paul Vriens

Detlef Riekenberg wrote: > On Mo, 2009-05-18 at 16:07 +0200, Paul Vriens wrote: >> + hcat = pCryptCATOpen(emptyW, 0, 0, 0, 0); >> + todo_wine >> + { >> + ok(hcat != NULL && hcat != INVALID_HANDLE_VALUE, "Expected a >> correct handle\n"); >> + ok(GetLastError() == ERROR_SUCCESS, >> + "Expected ERROR_SUCCESS, got %08x\n", GetLastError()); >> + } > > MSDN documents INVALID_HANDLE_VALUE on failure. > When NULL is valid result, then a comment about the MSDN error would be > nice. NULL is not supposed to be valid it was just to show that hcat changed. I guess just checking for INVALID_HANDLE_VALUE will do. > > Did you have an application, that need ERROR_SUCCESS? > The result of GetLastError() should only be tested, when the function > failed, > or when GetLastError is documented to be valid on success. Well, I actually don't know. Our implementation is wrong so this one is hard to check. I will remove it from the test. -- Cheers, Paul.

May 19, 2009

Re: [Article] WINE and the importance of application compatibility

by Ben Klein

2009/5/19 Austin English <austinenglish(a)gmail.com>: > On Mon, May 18, 2009 at 3:48 PM, David Gerard <dgerard(a)gmail.com> wrote: >> 1. Find apps that work pretty much perfectly in Wine. >> 2. Ask them to declare Wine officially supported. >> 3. Add them to http://wiki.winehq.org/AppsThatSupportWine >> 4. Use 3. to add more to 2. > > You forgot: > 5. ???? > 6. Profit! Off-topic, but that only works with 3-stage plans, thus: 1. Find apps that work pretty much perfectly in Wine 2. ? 3. Profit! "Time to go to work, work on Wine, work on opensource today! We won't stop until we've got opensource, yum yum yummy yum yay!" Back on topic, do we really take such strongly biased blog crap from zdnet seriously? The author has done little to no research: "Which brings us to today. Linux desktops have reached a point of maturity, polish and sophistication which rivals that found in Windows 2000. Yes, it's not as integrated as XP nor as glittering as Mac OS X. But it's Good Enough™. What Linux cannot offer to most potential users, that critical attribute which presently holds Linux back from much broader adoption on the desktop, is that magical ingredient which Windows offered to DOS users; being able to all your important applications within the new environment." ^^ missing a word here ("being able to all your important applications"). Note that MacOSX also fails to bring this functionality, but it's not being hammered like Linux is. I've recently seen the OpenSUSE 11.1 installer in action and, although Debian is still my preferred distro, I am very impressed. It's all pretty and snazzy, and YAST has come a long way since I first tried SUSE. Maybe this is just because Novell bought it, but it's certainly way beyond the "Windows 2000" level he's claiming. "Wine is still a work-in-progress and a pain to configure. It therefore pays to purchase a nicely-packaged form of this open source technology from one of two vendors: for business apps, CrossOver Office from Codeweavers, and for gamers, WineX from Transgaming, Cost is maybe $50, but it will make installing and managing all those Windows apps under Linux a snap." For a start, *Cedega* is a subscription service ... "How to make the vineyard bloom? There are four major industry players (IBM, Sun, Red Hat and Novell) who have a vested interest in desktop Linux's success, and therefore much to gain by cultivating the open source developer community which produces Wine. At the moment Wine is growing organically; slow and steady. With some well directed nutrient booster, say in the form of $10 million apiece, Wine will be running 99% of all those thousands of Windows apps within a year." This makes me LOL. Somehow I don't think money is the problem. First comment too, only way to go forward is for someone to buy Codeweavers (and potentially taint Crossover/Wine for the purposes of getting things to work).

May 19, 2009

Re: [Article] WINE and the importance of application compatibility

by Scott Ritchie

David Gerard wrote: > 2009/5/18 Brian Vincent <brian.vincent(a)gmail.com>: > >> Which leads me to my $.02: I wonder if there's a sweet spot for Wine >> adoption somewhere in the middle-tier of the software application popularity >> contest. For instance, rather than going after Photoshop or Photoshop >> Elements (which is still a noble goal), what about approaching Paintshop Pro >> about their Photo x2 product. Or, what about approaching the ISV that >> created Home Depot's freeware CD for laying out your home design? >> Specifically, I think there's a lot of proprietary applications without a >> good alternative (think more of the Home Depot or Sysco's "Rio", etc ). I >> think there's $$$ to be made for someone who can QA apps with Wine, fix >> minor issues, package Wine alongside the app, and finally deliver the >> product to an ISV. I don't think this is something the Wine community >> itself would be interested in, but I suspect there's someone in the Wine >> community who's capable of pulling it off. I think there's a lot of angles >> to the idea that could work. > > > 1. Find apps that work pretty much perfectly in Wine. > 2. Ask them to declare Wine officially supported. > 3. Add them to http://wiki.winehq.org/AppsThatSupportWine > 4. Use 3. to add more to 2. > > I don't think we'll get much traction with this unless we can reasonably tell them they only need to test the stable Wine release. But 1.0 is pretty old these days, so they probably won't bother. I'll add it to my list of evangelism to do after Wine 1.2 hits. And also not-so-subtly suggest this is another reason Wine 1.2 needs to happen sooner ;) Thanks, Scott Ritchie

May 18, 2009

Re: gdiplus: implement GdipTransformPoints

by Nikolay Sivov

Vincent Povirk wrote: > It's odd, but it seems like the simplest way to write this. > > I've tried what I think was your suggestion, and that's attached. I > don't think it's an improvement. > > Vincent Povirk > > Could be a single switch maybe. Don't know, looks better for me. Comparisons were really ugly here - a strict comparison should be used instead if you don't like switches. Anyway it's just my thoughts.

May 18, 2009

Re: gdiplus: implement GdipTransformPoints

by Vincent Povirk

It's odd, but it seems like the simplest way to write this. I've tried what I think was your suggestion, and that's attached. I don't think it's an improvement. Vincent Povirk On Mon, May 18, 2009 at 5:17 PM, Nikolay Sivov <bunglehead(a)gmail.com> wrote: > Vincent Povirk wrote: > > From 1de9b2291bf9a5617ca1e3b0cba5f1260889c259 Mon Sep 17 00:00:00 2001 > From: Vincent Povirk <vincent(a)codeweavers.com> > Date: Mon, 23 Mar 2009 16:34:12 -0500 > Subject: [PATCH] gdiplus: implement GdipTransformPoints > > > It's a strange way to check enumeration with integer comparison, isn't it? > And not clear in this particular case. > >> + if (stat == Ok) >> + { >> + unitscale = convert_unit(graphics->hdc, graphics->unit); >> + >> + if(graphics->unit != UnitDisplay) >> + unitscale *= graphics->scale; >> + >> + if (src_space <= CoordinateSpaceWorld && dst_space >= >> CoordinateSpacePage) >> + GdipMultiplyMatrix(matrix, graphics->worldtrans, >> MatrixOrderAppend); >> + if (src_space <= CoordinateSpacePage && dst_space >= >> CoordinateSpaceDevice) >> + GdipScaleMatrix(matrix, unitscale, unitscale, >> MatrixOrderAppend); >> + >> + if (dst_space <= CoordinateSpacePage && src_space >= >> CoordinateSpaceDevice) >> + GdipScaleMatrix(matrix, 1.0/unitscale, 1.0/unitscale, >> MatrixOrderAppend); >> + if (dst_space <= CoordinateSpaceWorld && src_space >= >> CoordinateSpacePage) >> + { >> + GpMatrix *inverted_transform; >> + stat = GdipCloneMatrix(graphics->worldtrans, >> &inverted_transform); >> + if (stat == Ok) >> + { >> + GdipInvertMatrix(inverted_transform); >> + GdipMultiplyMatrix(matrix, inverted_transform, >> MatrixOrderAppend); >> + GdipDeleteMatrix(inverted_transform); >> + } >> + > > Maybe it's better to use 'switch' for source coords with falling and ifs > inside cases for destination. > > <= CoordinateSpaceWorld is just CoordinateSpaceWorld >>= CoordinateSpaceDevice - is CoordinateSpaceDevice. > > > >

May 18, 2009

Re: gdiplus: implement GdipTransformPoints

by Nikolay Sivov

Vincent Povirk wrote: >From 1de9b2291bf9a5617ca1e3b0cba5f1260889c259 Mon Sep 17 00:00:00 2001 From: Vincent Povirk <vincent(a)codeweavers.com> Date: Mon, 23 Mar 2009 16:34:12 -0500 Subject: [PATCH] gdiplus: implement GdipTransformPoints It's a strange way to check enumeration with integer comparison, isn't it? And not clear in this particular case. > + if (stat == Ok) > + { > + unitscale = convert_unit(graphics->hdc, graphics->unit); > + > + if(graphics->unit != UnitDisplay) > + unitscale *= graphics->scale; > + > + if (src_space <= CoordinateSpaceWorld && dst_space >= CoordinateSpacePage) > + GdipMultiplyMatrix(matrix, graphics->worldtrans, MatrixOrderAppend); > + if (src_space <= CoordinateSpacePage && dst_space >= CoordinateSpaceDevice) > + GdipScaleMatrix(matrix, unitscale, unitscale, MatrixOrderAppend); > + > + if (dst_space <= CoordinateSpacePage && src_space >= CoordinateSpaceDevice) > + GdipScaleMatrix(matrix, 1.0/unitscale, 1.0/unitscale, MatrixOrderAppend); > + if (dst_space <= CoordinateSpaceWorld && src_space >= CoordinateSpacePage) > + { > + GpMatrix *inverted_transform; > + stat = GdipCloneMatrix(graphics->worldtrans, &inverted_transform); > + if (stat == Ok) > + { > + GdipInvertMatrix(inverted_transform); > + GdipMultiplyMatrix(matrix, inverted_transform, MatrixOrderAppend); > + GdipDeleteMatrix(inverted_transform); > + } > + Maybe it's better to use 'switch' for source coords with falling and ifs inside cases for destination. <= CoordinateSpaceWorld is just CoordinateSpaceWorld >= CoordinateSpaceDevice - is CoordinateSpaceDevice.

May 18, 2009

Re: [wintrust/tests] Add some basic CryptCATOpen tests

by Detlef Riekenberg

On Mo, 2009-05-18 at 16:07 +0200, Paul Vriens wrote: > + hcat = pCryptCATOpen(emptyW, 0, 0, 0, 0); > + todo_wine > + { > + ok(hcat != NULL && hcat != INVALID_HANDLE_VALUE, "Expected a > correct handle\n"); > + ok(GetLastError() == ERROR_SUCCESS, > + "Expected ERROR_SUCCESS, got %08x\n", GetLastError()); > + } MSDN documents INVALID_HANDLE_VALUE on failure. When NULL is valid result, then a comment about the MSDN error would be nice. Did you have an application, that need ERROR_SUCCESS? The result of GetLastError() should only be tested, when the function failed, or when GetLastError is documented to be valid on success. -- By by ... Detlef

May 18, 2009

Re: [Article] WINE and the importance of application compatibility

by Austin English

On Mon, May 18, 2009 at 3:48 PM, David Gerard <dgerard(a)gmail.com> wrote: > 1. Find apps that work pretty much perfectly in Wine. > 2. Ask them to declare Wine officially supported. > 3. Add them to http://wiki.winehq.org/AppsThatSupportWine > 4. Use 3. to add more to 2. You forgot: 5. ???? 6. Profit! :-) -- -Austin

May 18, 2009

Re: [Article] WINE and the importance of application compatibility

by David Gerard

2009/5/18 Brian Vincent <brian.vincent(a)gmail.com>: > Which leads me to my $.02: I wonder if there's a sweet spot for Wine > adoption somewhere in the middle-tier of the software application popularity > contest. For instance, rather than going after Photoshop or Photoshop > Elements (which is still a noble goal), what about approaching Paintshop Pro > about their Photo x2 product. Or, what about approaching the ISV that > created Home Depot's freeware CD for laying out your home design? > Specifically, I think there's a lot of proprietary applications without a > good alternative (think more of the Home Depot or Sysco's "Rio", etc ). I > think there's $$$ to be made for someone who can QA apps with Wine, fix > minor issues, package Wine alongside the app, and finally deliver the > product to an ISV. I don't think this is something the Wine community > itself would be interested in, but I suspect there's someone in the Wine > community who's capable of pulling it off. I think there's a lot of angles > to the idea that could work. 1. Find apps that work pretty much perfectly in Wine. 2. Ask them to declare Wine officially supported. 3. Add them to http://wiki.winehq.org/AppsThatSupportWine 4. Use 3. to add more to 2. - d.

May 18, 2009

Re: Gecko installation broken?

by Lei Zhang

On Mon, May 18, 2009 at 12:29 PM, Nikolay Sivov <bunglehead(a)gmail.com> wrote: > Lei Zhang wrote: >> >> On Mon, May 18, 2009 at 11:20 AM, Lei Zhang <thestig(a)google.com> wrote: >> >>> >>> On Mon, May 18, 2009 at 10:57 AM, Stefan Dösinger >>> <stefandoesinger(a)gmx.at> wrote: >>> >>>> >>>> Hi, >>>> Is my setup broken, or does the gecko installation fail? In a new wine >>>> prefix, >>>> when I open builtin iexplore, I get the installation dialog. The >>>> download >>>> runs successfully, but after installation iexplore still says that HTML >>>> rendering is currently disabled. When I run iexplore again, I again see >>>> the >>>> Wine Gecko installer dialog box. >>>> >>>> My hacky nightly game tests ran into this problem. The last successfull >>>> Team >>>> Fotress 2 test run is from May 14, 2009. After that my Gecko setup >>>> script >>>> failed and did not even try to start up Steam. >>>> >>> >>> Same problem here. Grr. Time for a regression test. >>> >>> >> >> Regression test says: >> >> commit 24d6c88d16c46f00d99fd8529196590aca88b0f4 >> Author: Nikolay Sivov <bunglehead(a)gmail.com> >> Date: Wed May 13 23:23:57 2009 +0400 >> >> comctl32/tab: Fix TabCtrl_* macros. >> >> Will file bug after lunch. >> >> > > Only Oleview and Taskmanager use these macros in Wine tree. So can't be a > cause I suppose. > It didn't think so either, so I even double checked. Upon further investigation, it seems the problem is simply the gecko cab download is failing. Either one of the Sourceforge servers is down/flaky, or source.winehq.org is taking too long to do the redirect and wininet doesn't handle that well.

May 18, 2009

Re: [Article] WINE and the importance of application compatibility

by Brian Vincent

On Sun, May 17, 2009 at 6:55 PM, Steven Edwards <winehacker(a)gmail.com>wrote: > doubt it. The situation I face with my day job, is that we can't even > get support for certain applications in VMware. As soon as we say "we > have a virtualized cluster" they balk. And we are talking about > situations where we are spending millions of dollars on our software > and are going to be supporting it in house. With that sort of > reaction, it leads me to think we are never going to make major > inroads except for the end users at home or the people buying Linux > netbooks. Kind of a tangent.. but I've thought for a long time Google did something really right with Picasa: they packaged a canned version of Wine alongside a canned version of their app. These days, hard drives space is cheap and no one notices an extra 20MB of Wine libraries with a set up program. Which leads me to my $.02: I wonder if there's a sweet spot for Wine adoption somewhere in the middle-tier of the software application popularity contest. For instance, rather than going after Photoshop or Photoshop Elements (which is still a noble goal), what about approaching Paintshop Pro about their Photo x2 product. Or, what about approaching the ISV that created Home Depot's freeware CD for laying out your home design? Specifically, I think there's a lot of proprietary applications without a good alternative (think more of the Home Depot or Sysco's "Rio", etc ). I think there's $$$ to be made for someone who can QA apps with Wine, fix minor issues, package Wine alongside the app, and finally deliver the product to an ISV. I don't think this is something the Wine community itself would be interested in, but I suspect there's someone in the Wine community who's capable of pulling it off. I think there's a lot of angles to the idea that could work. -Brian

May 18, 2009

Re: winspool.drv: implement semi-stub of EnumJobsW

by Detlef Riekenberg

On Mo, 2009-05-18 at 19:30 +0400, Vitaly Perov wrote: > --- > dlls/winspool.drv/info.c | 36 +++++++++++++++++++++++++++++++++++- > 1 files changed, 35 insertions(+), 1 deletions(-) The correct location for an implementation is localspl.dll For which Application did you changed the stub? The important thing to decide first, what Wine is allowed to return: a) Informations from Wine and from Host-OS b) Informations from Wine only (will be empty most of the time) The current code is using "b", but your Patch added: c) Informations from the Host-OS only which is not correct. I'm fine to migrate from "b" to "a". Thanks for working on printing. -- By by ... Detlef

May 18, 2009

Re: Gecko installation broken?

by Nikolay Sivov

Lei Zhang wrote: > On Mon, May 18, 2009 at 11:20 AM, Lei Zhang <thestig(a)google.com> wrote: > >> On Mon, May 18, 2009 at 10:57 AM, Stefan Dösinger >> <stefandoesinger(a)gmx.at> wrote: >> >>> Hi, >>> Is my setup broken, or does the gecko installation fail? In a new wine prefix, >>> when I open builtin iexplore, I get the installation dialog. The download >>> runs successfully, but after installation iexplore still says that HTML >>> rendering is currently disabled. When I run iexplore again, I again see the >>> Wine Gecko installer dialog box. >>> >>> My hacky nightly game tests ran into this problem. The last successfull Team >>> Fotress 2 test run is from May 14, 2009. After that my Gecko setup script >>> failed and did not even try to start up Steam. >>> >> Same problem here. Grr. Time for a regression test. >> >> > > Regression test says: > > commit 24d6c88d16c46f00d99fd8529196590aca88b0f4 > Author: Nikolay Sivov <bunglehead(a)gmail.com> > Date: Wed May 13 23:23:57 2009 +0400 > > comctl32/tab: Fix TabCtrl_* macros. > > Will file bug after lunch. > > Only Oleview and Taskmanager use these macros in Wine tree. So can't be a cause I suppose.

May 18, 2009

Re: Gecko installation broken?

by Lei Zhang

On Mon, May 18, 2009 at 11:20 AM, Lei Zhang <thestig(a)google.com> wrote: > On Mon, May 18, 2009 at 10:57 AM, Stefan Dösinger > <stefandoesinger(a)gmx.at> wrote: >> Hi, >> Is my setup broken, or does the gecko installation fail? In a new wine prefix, >> when I open builtin iexplore, I get the installation dialog. The download >> runs successfully, but after installation iexplore still says that HTML >> rendering is currently disabled. When I run iexplore again, I again see the >> Wine Gecko installer dialog box. >> >> My hacky nightly game tests ran into this problem. The last successfull Team >> Fotress 2 test run is from May 14, 2009. After that my Gecko setup script >> failed and did not even try to start up Steam. > > Same problem here. Grr. Time for a regression test. > Regression test says: commit 24d6c88d16c46f00d99fd8529196590aca88b0f4 Author: Nikolay Sivov <bunglehead(a)gmail.com> Date: Wed May 13 23:23:57 2009 +0400 comctl32/tab: Fix TabCtrl_* macros. Will file bug after lunch.

May 18, 2009

Re: Gecko installation broken?

by Lei Zhang

On Mon, May 18, 2009 at 10:57 AM, Stefan Dösinger <stefandoesinger(a)gmx.at> wrote: > Hi, > Is my setup broken, or does the gecko installation fail? In a new wine prefix, > when I open builtin iexplore, I get the installation dialog. The download > runs successfully, but after installation iexplore still says that HTML > rendering is currently disabled. When I run iexplore again, I again see the > Wine Gecko installer dialog box. > > My hacky nightly game tests ran into this problem. The last successfull Team > Fotress 2 test run is from May 14, 2009. After that my Gecko setup script > failed and did not even try to start up Steam. Same problem here. Grr. Time for a regression test.

May 18, 2009

Gecko installation broken?

by Stefan Dösinger

Hi, Is my setup broken, or does the gecko installation fail? In a new wine prefix, when I open builtin iexplore, I get the installation dialog. The download runs successfully, but after installation iexplore still says that HTML rendering is currently disabled. When I run iexplore again, I again see the Wine Gecko installer dialog box. My hacky nightly game tests ran into this problem. The last successfull Team Fotress 2 test run is from May 14, 2009. After that my Gecko setup script failed and did not even try to start up Steam. Cheers, Stefan

May 18, 2009

Re: [2/3] d3dx9: Add utility functions for loading files and resources into memory

by Stefan Dösinger

Am Montag, 18. Mai 2009 17:44:17 schrieb Tony Wasserka: > +HRESULT LoadFileIntoMemoryA(LPCSTR filename, LPVOID *buffer, DWORD *length) Do you need this function? Woudn't it be better to wrap A->W at the API level and have all internal functions W only? > + handle = CreateFileW(filename, GENERIC_READ, FILE_SHARE_READ, 0, OPEN_EXISTING, 0, 0); > + if(handle == INVALID_HANDLE_VALUE) return D3DERR_INVALIDCALL; > + > + *length = GetFileSize(handle, NULL); >+ if(*length == INVALID_FILE_SIZE) return D3DERR_INVALIDCALL; > + > + *buffer = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, *length); Is there a particular reason not to use mmap, or whatever the Windows equivalent is?

May 18, 2009

Re: [PATCH 2/2] ole32/tests: Add tests to show the WdtpInterfacePointer marshal data looks like the result of CoMarshalInterface.

by Paul Vriens

Huw Davies wrote: > --- > dlls/ole32/tests/usrmarshal.c | 38 +++++++++++++++++++++----------------- > 1 files changed, 21 insertions(+), 17 deletions(-) > > > ------------------------------------------------------------------------ > > Hi Huw, Could you have a look at the test results are test.winehq.org> This patch and the other one against usrmarshall.c introduced some test failures on several platforms. -- Cheers, Paul.

May 18, 2009

Re: [shell32] Improve the Dutch 'about' message box

by Reece Dunn

2009/5/18 Francois Gouget <fgouget(a)free.fr>: > On Mon, 18 May 2009, Reece Dunn wrote: > [...] >> I was thinking of some sort of auto-layout logic, using bounding box >> calculations and metric information fed from Windows guidelines. The >> idea here is to give a consistent layout and make it easier to add new >> controls. >> >> I am aware that this is very complex, and I don't yet know how to >> transform the flat layout to a hierarchical layout that contains the >> box information necessary to do the reflow calculations. > > If we go that route, we should probably start from a bounding box-based > description of the dialogs, and then generate both the English and the > localized dialogs. > > For instance the glade format seems to be bounding-box based. It also > probably already has tools to handle localization. So we could probably > start from a English glade file describing a dialog, generate localized > versions of that file, and then, for each language, pass the dialog > through our bounding-box calculator to convert that to coordinates and > generate the corresponding rc files. Yes. That would be a better way for storing the information. The advantage of choosing something like the Glade format is that we could then take advantage of the editors for the format, so the Wine developers can edit the dialogs visually. A similar thing for the menus. The question here (which applies to any direction that is taken) is whether the format that is chosen can represent all the information in the RC file. The first step would be getting the RC <==> Box format conversion working reliably. Then adding the translation on top of that using the PO/gettext framework. - Reece

May 18, 2009

Re: DIB Engine - Mostly fixed against test suite

by Michael Karcher

Am Montag, den 18.05.2009, 13:41 +0200 schrieb Massimo Del Fedele: > > Be careful with such statements. Look at bug 6519 for example. > Yep, I've seen the bug :-) > Anyways, most failures are fixed by now, also for monochrome bitmaps. > Did you test it on bug's 6519 app ? No, I don't really care. I just fixed that bug and your statement: "Color on monochrome bitmap is seldomly used anyway" sounded an alarming bell in my head. This mail was just a warning to not disregard the issue and no specific problem report. Regards, Michael Karcher

May 18, 2009

Re: [4/4]msctf: starting implementation of ITfContext::RequestEditSession and ITextStoreACPSink::OnLockGranted

by Alexandre Julliard

Aric Stewart <aric(a)codeweavers.com> writes: > --- > dlls/msctf/context.c | 68 > ++++++++++++++++++++++++++++++++++-- > dlls/msctf/tests/inputprocessor.c | 29 +++++++++++----- > include/textstor.idl | 2 + > 3 files changed, 86 insertions(+), 13 deletions(-) It doesn't work here: ../../../tools/runtest -q -P wine -M msctf.dll -T ../../.. -p msctf_test.exe.so inputprocessor.c && touch inputprocessor.ok inputprocessor.c:155: Test succeeded inside todo block: GetStatus called too many times make[2]: *** [inputprocessor.ok] Error 1 -- Alexandre Julliard julliard(a)winehq.org

May 18, 2009

Re: DIB Engine - Mostly fixed against test suite

by Massimo Del Fedele

Michael Karcher ha scritto: > Am Sonntag, den 17.05.2009, 17:35 +0200 schrieb Massimo Del Fedele: >> 1) Some color on monochrome bitmaps.... here I guess nobody knows how to do it right. I fixed some todo wine (most) but have 2 failures which wine does right. >> Seldom used anyways, and happens only on weird palettes. I guess not ever Microsoft knows what they did on this respect :-) > Be careful with such statements. Look at bug 6519 for example. > > Regards, > Michael Karcher > > > ------------------------------------------------------------------------ > > Yep, I've seen the bug :-) Anyways, most failures are fixed by now, also for monochrome bitmaps. Did you test it on bug's 6519 app ? Ciao Max

May 18, 2009

Re: DIB Engine - Mostly fixed against test suite

by Massimo Del Fedele

Austin English ha scritto: > On Sun, May 17, 2009 at 10:35 AM, Massimo Del Fedele <max(a)veneto.com> wrote: >> Austin, could you please retest it against test suite ? > > I've ran it, but it doesn't appear to be showing up on > test.winehq.org. I'll investigate why when I get a bit more time. > > P.S., there's now a crash in user32/cursoricon. > Crash "fixed" on latest post. The fix is partial, as it depends on getting the right color table of a DIB from inside GetDIBits. That can't be done using GetDIBColorTable() as it requires the DIB to be selected into a DC, which is exactly the opposite requirement og GetDIBits. I guess I have to resort to a list of DIB <---> physical bitmaps to do it reliably, as windows doesn't bring any reliable other way to do it. Concluding : crash fixed but a couple of failures in tests/bitmap.c in addition to remaining 4. Total, 6, which is not bad :-) Ciao Max

May 18, 2009

Re: [PATCH] winhttp: avoid NULL ptr dereference (Coverity 927)

by Alexandre Julliard

Marcus Meissner <marcus(a)jet.franken.de> writes: > Not sure if we need to set these values in all error paths, > but definitely not in the NULL lpwhr. (lpwhdr?) There's no reason to have NULL checks in internal functions. -- Alexandre Julliard julliard(a)winehq.org

May 18, 2009

Re: [shell32] Improve the Dutch 'about' message box

by Francois Gouget

On Mon, 18 May 2009, Reece Dunn wrote: [...] > I was thinking of some sort of auto-layout logic, using bounding box > calculations and metric information fed from Windows guidelines. The > idea here is to give a consistent layout and make it easier to add new > controls. > > I am aware that this is very complex, and I don't yet know how to > transform the flat layout to a hierarchical layout that contains the > box information necessary to do the reflow calculations. If we go that route, we should probably start from a bounding box-based description of the dialogs, and then generate both the English and the localized dialogs. For instance the glade format seems to be bounding-box based. It also probably already has tools to handle localization. So we could probably start from a English glade file describing a dialog, generate localized versions of that file, and then, for each language, pass the dialog through our bounding-box calculator to convert that to coordinates and generate the corresponding rc files. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ 1 + e ^ ( i * pi ) = 0

May 18, 2009

Re: [shell32] Improve the Dutch 'about' message box

by Reece Dunn

2009/5/16 Francois Gouget <fgouget(a)free.fr>: > On Tue, 12 May 2009, Reece Dunn wrote: > [...] >> What I would like to do is get an automated (or semi-automated) tool, >> ideally with a GUI interface to it. That would ultimately put the >> designer in charge. Hopefully, this would also mean that you have a >> base resource file that produces the English resources and generate >> the others using the standard po files - thus making it easier to >> translate. > > Yes, handling the translation of Wine's resource files would be really > nice. It would let us leverage a lot of the po tools, especially the > website based ones. This would make it much easier for users to > contribute to the translations (right now it's pretty intimidating). I'm > not sure how to handle the widget layout though. I was thinking of some sort of auto-layout logic, using bounding box calculations and metric information fed from Windows guidelines. The idea here is to give a consistent layout and make it easier to add new controls. I am aware that this is very complex, and I don't yet know how to transform the flat layout to a hierarchical layout that contains the box information necessary to do the reflow calculations. > But I have just stumbled on this pair of tools from the > translate-toolkit packag (on Debian) that seem to be made just for this > purpose: > > * po2rc > convert Gettext PO localization files to Windows Resource (.rc) files > http://translate.sourceforge.net/wiki/toolkit/rc2po > > * rc2po > convert .rc files to Gettext PO localization files > http://translate.sourceforge.net/wiki/toolkit/rc2po > > > I don't have time to play with them but with luck someone else does. > Getting it going with Wine would be really great. Nor do I, and others are probably better qualified than me to answer. - Reece

May 18, 2009

Re: News on Wine 1.1.21/MacOSX/XQuartz 2.3.3

by Mike Kronenberg

Hi, It's not about being willing to, but plain lack of time. I follow this list closely and work as time permits. After half a year, it's been four weeks now that I am able again to build and test on a regular base again. There are other components on OS X that need some love, like the winehelper.app into which I'm looking atm. License and renaming is definitely on the list. I thought to revamp the package, once the winehelper is replaced to not double the work. As already mentioned, I build the dependencies and store them inside the apple .app package, which allows for drag'n'drop installation and removal. Having the dependencies as frameworks would be even better, as there is a lot of trouble with PATHS, especially if multiple environments are on the system, like fink and macports. But if the name-change is the most pressing issue, I will gladly do that for you. Mike Kronenberg On 18.05.2009, at 06:56, Dmitry Timoshkov wrote: > "James McKenzie" <jjmckenzie51(a)earthlink.net> wrote: > >> Austin: >> Contact Mike Kronenberg or Zach Drayer and see what they currently >> have. > > IMHO since they haven't even bothered so far to change the license > from > GPL to LGPL to match Wine, and clarify what exactly is so much > different > in their builds so that they insist on different naming (Darwine vs. > Wine), > they shouldn't be even considered as partners to the Wine project. > > If we could have our own Wine builds for Intel Macs, that would > finally > help to avoid this confusion Darwine adds, and remove it from our Wiki > altogether (since it's apparently where the users coming to them > from). > > -- > Dmitry. > >

May 18, 2009

Re: [shell32] Improve the Dutch 'about' message box

by Michael Stefaniuc

Mikołaj Zalewski wrote: > >> Yes, handling the translation of Wine's resource files would be really >> nice. It would let us leverage a lot of the po tools, especially the >> website based ones. This would make it much easier for users to >> contribute to the translations (right now it's pretty intimidating). >> I'm not sure how to handle the widget layout though. >> > I also think I would be better to use po files (without them, our > translations get out-of-sync - e.g. in start a new /Unix switch was > intruduced, but only 7 out of 16 languages has it in the help message. > For the users of the other 9 languages, we are providing an incorrect > help message. This is adding a new line to an existing message, so wrc > --verify-translation won't notice it). > I was thinking about the widget layout that may need to be different in > a translation and I think this can be solved by adding a possibility to > add some transformations of controls relative to the English ones. > Something like: > > msgid "transform.dialog.133" > msgstr "" > "control 12 resize by (10, 10)" > "control 13 move by (10, 10)" > > Making the transformations relative should make updating such resources > not very common (and in most cases there will be even no need for this). > There may still be cases when it looks ugly if e.g. one adds a new > button to the English dialog while the localized ones are enlarged and > takes a place where the new button is added, but we could be solved by > adding to msgid e.g. a hash of the English resource with localizable > stirngs removed, so that the translation will be fuzzy after a merge. > I could try to look into po2rc and rc2po if they work and can be They work, sort of. I tried them out (though not the latest version) and run into a problem where the MENUs where ignored. That is a known problem with complex MENUs according to the description of the tools on their web page. > augmented with such a functionality, but I'm not sure if I will have > time soon. bye michael

May 18, 2009

Re: News on Wine 1.1.21/MacOSX/XQuartz 2.3.3

by Dmitry Timoshkov

"James McKenzie" <jjmckenzie51(a)earthlink.net> wrote: > Austin: > > Contact Mike Kronenberg or Zach Drayer and see what they currently > have. IMHO since they haven't even bothered so far to change the license from GPL to LGPL to match Wine, and clarify what exactly is so much different in their builds so that they insist on different naming (Darwine vs. Wine), they shouldn't be even considered as partners to the Wine project. If we could have our own Wine builds for Intel Macs, that would finally help to avoid this confusion Darwine adds, and remove it from our Wiki altogether (since it's apparently where the users coming to them from). -- Dmitry.

May 18, 2009

Re: [Article] WINE and the importance of application compatibility

by Steven Edwards

On Sun, May 17, 2009 at 9:53 PM, James McKenzie <jjmckenzie51(a)earthlink.net> wrote: > Many companies don't trust Open Source. They just don't have the assets > to do a proper code sweep and to see that we do not want to swipe their > secrets, but give them something better. Of course, we all know the > outcome of the Windows versus OS/2 wars: Windows won and the best > product went home (it is still available by the way.) Its not even Open Source though, I mean that's another strike but the VMware example shows, any sort of legacy solution, virtualized or otherwise is a major show stopper. Hell, I have enough trouble with vendors and JVM versions. Try getting support for an application running under BEAs JVM verses Sun and the vendor balks. Wine problem is a chicken and egg problem. Most won't support Wine and so most won't run Wine. The vendors won't support it because most won't run Wine. And the cycle of life repeats. That compounded with the fact that as Linux gets better, there is no need for Wine as the vendor will just target apps directly. Facing both of these situations I've started to believe Wine won't ever become much more than it is. It's going to be hit or miss even if it installs, its always going to be playing catch up. That's not a bad thing, a niche market is fine as everything has its place. The wine project just needs to be a bit more flexible as far as integration goes. I think for a long time we've tried to be too generic, distro agnostic, etc. For Wine to get more adoption we need to do a better on that end. Scott and others have been working a lot to solve this problem with the associations, XDG stuff, etc. We need a lot more work on the OS X side and that will help us tremendously due to the size of the market. OK I'm done ranting. 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 18, 2009

Re: [Article] WINE and the importance of application compatibility

by James McKenzie

Steven Edwards wrote: > On Sun, May 17, 2009 at 8:09 PM, Dan Kegel <dank(a)kegel.com> wrote: > >> Sure would be nice if we could convince the DoD they needed >> a second source for Windows :-) >> > > Maybe a big customer like the DoD would help but I am starting to > doubt it. The situation I face with my day job, is that we can't even > get support for certain applications in VMware. As soon as we say "we > have a virtualized cluster" they balk. And we are talking about > situations where we are spending millions of dollars on our software > and are going to be supporting it in house. With that sort of > reaction, it leads me to think we are never going to make major > inroads except for the end users at home or the people buying Linux > netbooks. > Stephen: Many companies don't trust Open Source. They just don't have the assets to do a proper code sweep and to see that we do not want to swipe their secrets, but give them something better. Of course, we all know the outcome of the Windows versus OS/2 wars: Windows won and the best product went home (it is still available by the way.) James McKenzie

May 18, 2009

Re: News on Wine 1.1.21/MacOSX/XQuartz 2.3.3

by Austin English

On Sun, May 17, 2009 at 6:43 PM, James McKenzie <jjmckenzie51(a)earthlink.net> wrote: > Austin English wrote: >> On Sun, May 17, 2009 at 6:49 AM, Steven Edwards >> <sedwards(a)bordeauxgroup.com> wrote: >> >>> On Sat, May 16, 2009 at 11:23 PM, James McKenzie >>> <jjmckenzie51(a)earthlink.net> wrote: >>> >>>> BTW, the version of Wine for Mac that I used for testing was built using >>>> Mike Kronenberg's Build Environment 1.1.5. >>>> >>> I tested this last night myself and am running winetest now. I still >>> get a few d3d texture failures but that could be because my mini's a >>> POS with the Intel GMA card. I'm interested in seeing other results so >>> if you get a chance could you (or anyone else lurking with OS X) do a >>> winetest run? >>> >> >> Ideally, against a more recent wine version. >> >> Shameless plug: >> I've got a script to do it, but no one that I know of is testing it on >> OS X. If someone could test it, I'll add any needed fixes: >> http://winezeug.googlecode.com/svn/trunk/build_script/daily.sh >> >> > Austin: > > Contact Mike Kronenberg or Zach Drayer and see what they currently > have. I know that Mike's builds add all of the necessary libraries to > the Application Object. That keeps the system clean and allows for > 'Drag and Drop' installation/removal of Wine for MacOSX. Your script > seems to be clean as well, but has no MacOSX functionality added to it. > Would be nice if it were there. It's not really made to install all the needed dependencies (there is install-wine-deps.sh for that). The Mac platform is so different in many ways that it's a bit hard to do. Does the user want to use fink/macports? Or install each from source? Do we install to /usr/local/bin? Or to a custom directory elsewhere? It's a big mess... There is an OS X code path in place, but it is untested. -- -Austin

May 18, 2009

Re: DIB Engine - Mostly fixed against test suite

by Austin English

On Sun, May 17, 2009 at 10:35 AM, Massimo Del Fedele <max(a)veneto.com> wrote: > Austin, could you please retest it against test suite ? I've ran it, but it doesn't appear to be showing up on test.winehq.org. I'll investigate why when I get a bit more time. P.S., there's now a crash in user32/cursoricon. -- -Austin

May 18, 2009

Re: [Article] WINE and the importance of application compatibility

by Steven Edwards

On Sun, May 17, 2009 at 8:09 PM, Dan Kegel <dank(a)kegel.com> wrote: > Sure would be nice if we could convince the DoD they needed > a second source for Windows :-) Maybe a big customer like the DoD would help but I am starting to doubt it. The situation I face with my day job, is that we can't even get support for certain applications in VMware. As soon as we say "we have a virtualized cluster" they balk. And we are talking about situations where we are spending millions of dollars on our software and are going to be supporting it in house. With that sort of reaction, it leads me to think we are never going to make major inroads except for the end users at home or the people buying Linux netbooks. 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 18, 2009

re: [Article] WINE and the importance of application compatibility

by Dan Kegel

James McKensie wrote: > WE need to get to the point where most of the common business type > applications will run in Wine without a bunch of twiddling and fixes. Well, yes. That was one of my goals during my big Wine push ( http://www.winehq.org/pipermail/wine-devel/2008-February/062550.html ), and I think we made a lot of progress. Still lots to do, as you know. Sure would be nice if we could convince the DoD they needed a second source for Windows :-) - Dan

May 18, 2009

Re: [Article] WINE and the importance of application compatibility

by James McKenzie

Scott Ritchie wrote: > nn wrote: >> >> >> WINE and the importance of application compatibility >> >> http://community.zdnet.co.uk/blog/0,1000000567,10012751o-2000630136b,00.htm >> >> >> > > It's a good article, though it's sad to see a mention of "WineX" as a > serious alternative to Wine. WineX was obsolete years ago (and the > consensus about its successor Cedega on the various web forums seems > to be that it's often substantially behind Crossover Games). > The article stated that most of it was a few years old. > Codeweavers, you need to do a better job letting people know Crossover > Games exists. > WE need to get to the point where most of the common business type applications will run in Wine without a bunch of twiddling and fixes. The average "Joe" user will not put up with this. I've been on this mantra for a long time. Build a better mousetrap built on an OS that is more robust and market it correctly and you will have the world at your fingertips. Witness the comparision between Windows and OS/2. OS/2 was technically superior but had problems running most of the current software. It 'died' and Windows lived on. The same could be said about Linux/Wine at its current state. I need Wine to run a few Windows applications, one of which will not be made for either Linux or Mac. Thus, I have to have Windows compatibility or Windows itself. I don't feel like 'polluting' my system, so I need API compatibilty. Wine delivers this for me. The problem is that I need another Windows program to run. I'm going to work on it and report bugs as they occur. I may also start running Winetest to see what works and what does not. Hopefully, with the recent release of XQuartz 2.3.3, most of the problems have gone away. James McKenzie > Thanks, > Scott Ritchie > > >

May 17, 2009

Re: News on Wine 1.1.21/MacOSX/XQuartz 2.3.3

by James McKenzie

Austin English wrote: > On Sun, May 17, 2009 at 6:49 AM, Steven Edwards > <sedwards(a)bordeauxgroup.com> wrote: > >> On Sat, May 16, 2009 at 11:23 PM, James McKenzie >> <jjmckenzie51(a)earthlink.net> wrote: >> >>> BTW, the version of Wine for Mac that I used for testing was built using >>> Mike Kronenberg's Build Environment 1.1.5. >>> >> I tested this last night myself and am running winetest now. I still >> get a few d3d texture failures but that could be because my mini's a >> POS with the Intel GMA card. I'm interested in seeing other results so >> if you get a chance could you (or anyone else lurking with OS X) do a >> winetest run? >> > > Ideally, against a more recent wine version. > > Shameless plug: > I've got a script to do it, but no one that I know of is testing it on > OS X. If someone could test it, I'll add any needed fixes: > http://winezeug.googlecode.com/svn/trunk/build_script/daily.sh > > Austin: Contact Mike Kronenberg or Zach Drayer and see what they currently have. I know that Mike's builds add all of the necessary libraries to the Application Object. That keeps the system clean and allows for 'Drag and Drop' installation/removal of Wine for MacOSX. Your script seems to be clean as well, but has no MacOSX functionality added to it. Would be nice if it were there. James McKenzie

May 17, 2009

Re: [Article] WINE and the importance of application compatibility

by Scott Ritchie

nn wrote: > > > WINE and the importance of application compatibility > > http://community.zdnet.co.uk/blog/0,1000000567,10012751o-2000630136b,00.htm > > It's a good article, though it's sad to see a mention of "WineX" as a serious alternative to Wine. WineX was obsolete years ago (and the consensus about its successor Cedega on the various web forums seems to be that it's often substantially behind Crossover Games). Codeweavers, you need to do a better job letting people know Crossover Games exists. Thanks, Scott Ritchie

May 17, 2009

[Article] WINE and the importance of application compatibility

by nn

WINE and the importance of application compatibility http://community.zdnet.co.uk/blog/0,1000000567,10012751o-2000630136b,00.htm Need a Holiday? Win a $10,000 Holiday of your choice. Enter now.http://us.lrd.yahoo.com/_ylc=X3oDMTJxN2x2ZmNpBF9zAzIwMjM2MTY2MTMEdG1fZG…

May 17, 2009

Re: DIB Engine - Mostly fixed against test suite

by Scott Ritchie

Massimo Del Fedele wrote: > There are still some missing/buggy features rarely used that aren't > spotted by testsuite; > by now I've no time to fix them, anyways no one felt into them up to now > :-) Hey Max, It sounds like you're in a better position than most to write a conformance test for these missing/buggy features, since you're aware of them. That might help everyone, and also make your DIB engine more attractive since it'll be passing even more tests that current Wine may not be. Keep up the good work :) Thanks, Scott Ritchie

May 17, 2009

Re: News on Wine 1.1.21/MacOSX/XQuartz 2.3.3

by ryan woodsmall

On May 17, 2009, at 3:45 PM, Austin English wrote: > Ideally, against a more recent wine version. > > Shameless plug: > I've got a script to do it, but no one that I know of is testing it on > OS X. If someone could test it, I'll add any needed fixes: > http://winezeug.googlecode.com/svn/trunk/build_script/daily.sh I have (yet another) build script, but OS X requires a number of deps to be compiled and installed as Apple doesn't ship some libraries, headers, or ships incomplete packages here and there. This is all pretty bare bones stuff. I can vouch for functionality with Mac OS X 10.5.7 + XQuartz 2.3.3.1 + Wine 1.1.21 (from source). If and when I can find some time IRL, I can get the entire Wine compile and install with deps scripted up. This of course depends on free time, which is always somewhat lacking. Your script looks good, Austin - lots of functionality there! ryan woodsmall rwoodsmall(a)mac.com "Be well, do good work, and keep in touch." - Garrison Keillor

May 17, 2009

Re: DIB Engine - Mostly fixed against test suite

by Michael Karcher

Am Sonntag, den 17.05.2009, 17:35 +0200 schrieb Massimo Del Fedele: > 1) Some color on monochrome bitmaps.... here I guess nobody knows how to do it right. I fixed some todo wine (most) but have 2 failures which wine does right. > Seldom used anyways, and happens only on weird palettes. I guess not ever Microsoft knows what they did on this respect :-) Be careful with such statements. Look at bug 6519 for example. Regards, Michael Karcher

May 17, 2009

Re: SoC 2009 / Application Test Suite Update

by Austin English

On Sun, May 17, 2009 at 3:28 AM, Scott Ritchie <scott(a)open-vote.org> wrote: > Austin English wrote: >> >> Howdy all, >> >> I've been working on the test suite. I've got a few basic tests set up >> with notepad, and I'm currently working on setting up the framework, >> using AutoHotKey to both run all the tests and parse the logs for >> failures/passing todo's. >> > > You may have already had this idea, but today I was just thinking of the > concept of running performance tests alongside Wine's conformance tests. > Your test suite would be a great place for that - just integrate scripts > for the various benchmarking tools. Bonus points if you can put the output > from the benchmark programs themselves into some sort of machine parseable > format. Then we could have a rough chart of performance data on various > things as development continues; in particular we'd catch bugs that still > behave correctly but are drastically inefficient. Possibly, I may look into doing that. My current plan is to gather all the low hanging fruit. Small, simple applications give us a large range of stuff to test, without adding much difficulty/complexity. Once all that is done, more complex stuff can be added. -- -Austin

May 17, 2009

Re: News on Wine 1.1.21/MacOSX/XQuartz 2.3.3

by Austin English

On Sun, May 17, 2009 at 6:49 AM, Steven Edwards <sedwards(a)bordeauxgroup.com> wrote: > On Sat, May 16, 2009 at 11:23 PM, James McKenzie > <jjmckenzie51(a)earthlink.net> wrote: >> BTW, the version of Wine for Mac that I used for testing was built using >> Mike Kronenberg's Build Environment 1.1.5. > > I tested this last night myself and am running winetest now. I still > get a few d3d texture failures but that could be because my mini's a > POS with the Intel GMA card. I'm interested in seeing other results so > if you get a chance could you (or anyone else lurking with OS X) do a > winetest run? Ideally, against a more recent wine version. Shameless plug: I've got a script to do it, but no one that I know of is testing it on OS X. If someone could test it, I'll add any needed fixes: http://winezeug.googlecode.com/svn/trunk/build_script/daily.sh -- -Austin

May 17, 2009

Re: [shell32] Improve the Dutch 'about' message box

by Mikołaj Zalewski

> Yes, handling the translation of Wine's resource files would be really > nice. It would let us leverage a lot of the po tools, especially the > website based ones. This would make it much easier for users to > contribute to the translations (right now it's pretty intimidating). I'm > not sure how to handle the widget layout though. > I also think I would be better to use po files (without them, our translations get out-of-sync - e.g. in start a new /Unix switch was intruduced, but only 7 out of 16 languages has it in the help message. For the users of the other 9 languages, we are providing an incorrect help message. This is adding a new line to an existing message, so wrc --verify-translation won't notice it). I was thinking about the widget layout that may need to be different in a translation and I think this can be solved by adding a possibility to add some transformations of controls relative to the English ones. Something like: msgid "transform.dialog.133" msgstr "" "control 12 resize by (10, 10)" "control 13 move by (10, 10)" Making the transformations relative should make updating such resources not very common (and in most cases there will be even no need for this). There may still be cases when it looks ugly if e.g. one adds a new button to the English dialog while the localized ones are enlarged and takes a place where the new button is added, but we could be solved by adding to msgid e.g. a hash of the English resource with localizable stirngs removed, so that the translation will be fuzzy after a merge. I could try to look into po2rc and rc2po if they work and can be augmented with such a functionality, but I'm not sure if I will have time soon. Mikołaj

May 17, 2009

Re: WINE Intel

by Stefan Dösinger

Am Sonntag, 17. Mai 2009 13:16:01 schrieb Roderick Colenbrander: > Intel needs to fix their drivers. Note that the intel drivers are open source, so you(The thread starter) can speed up this process by testing games, isolating the problems and filing bug reports in the Mesa or DRI bugzilla. I am pretty sure the developers could use extra manpower too.

May 17, 2009

SourceForge 2009 Community Choice Award

by André Hentschel

Last Year we got a funny award, lets nominate Wine for some serios things at http://sourceforge.net/community/cca09

May 17, 2009

DIB Engine - Mostly fixed against test suite

by Massimo Del Fedele

Remaining bugs are related to : 1) Some color on monochrome bitmaps.... here I guess nobody knows how to do it right. I fixed some todo wine (most) but have 2 failures which wine does right. Seldom used anyways, and happens only on weird palettes. I guess not ever Microsoft knows what they did on this respect :-) 2) an AlphaBlend() call which should fail and doesn't. Here I really don't know why it should fail..... Uninfluent, anyways. 3) GetDIBits on a source DIB with BPP <= 8 fails to retrieve the original DIB palette, and synthesizes a new one instead. For the moment I found no simple way to grab the palette from inside GetDIBits without maintaining a linked list of HBITMAP <--> internal bitmaps. Not worth the effort for the moment anyways. If somebody notices weird colors due to it, I'll try to fix..... There are still some missing/buggy features rarely used that aren't spotted by testsuite; by now I've no time to fix them, anyways no one felt into them up to now :-) Austin, could you please retest it against test suite ? (code on Bug421 page) Ciao Max

May 17, 2009

Re: News on Wine 1.1.21/MacOSX/XQuartz 2.3.3

by Steven Edwards

On Sat, May 16, 2009 at 11:23 PM, James McKenzie <jjmckenzie51(a)earthlink.net> wrote: > BTW, the version of Wine for Mac that I used for testing was built using > Mike Kronenberg's Build Environment 1.1.5. I tested this last night myself and am running winetest now. I still get a few d3d texture failures but that could be because my mini's a POS with the Intel GMA card. I'm interested in seeing other results so if you get a chance could you (or anyone else lurking with OS X) do a winetest run? 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 17, 2009

Re: WINE Intel

by Roderick Colenbrander

> I do not know but I suspect that WINE's various Direct3D code utilizes > OpenGL nVidia Extension or higher level OpenGL ARB Extension rather that > lower one. > > That's why while INTEL OpenGL driver does support DirectX7, DirectX8 level > 3D wine does not able to run many games on INTEL Linux graphics driver. > While those many games run on nVidia Linux driver. > > I hope WINE will someday have better INTEL OpenGL support. Wine is doing nothing wrong we use generic OpenGL extensions all through Wine. The issue is that the intel drivers don't offer all opengl extensions we need for decent d3d9 support, if the gl support isn't there we can't support it. Second the quality of the intel drivers still isn't very good, sure recent versions support GLSL, FBOs and other things but the drivers are first of all buggy and second very slow for those purposes. Further ATI works reasonably well with Wine as well these days (it used to be crap). Intel needs to fix their drivers. Roderick

May 17, 2009

Re: WINE Intel

by Ben Klein

2009/5/17 MD.IMAM HOSSAIN <imamdxl8805(a)gmail.com>: > Majority of the C.P.U comes up with the INTEL integrated graphics card. No CPU comes with integrated GPU (yet). Most (all?) Intel-based motherboards (including those for laptops) that have integrated graphics use Intel-brand graphics. This does not constitute "most" motherboards, as there are no Intel-brand GPUs on AMD CPU-compatible motherboards, and there are even Intel CPU-compatible motherboards that have nVidia graphics chips. > We > all very well know that their Linux driver lack most of the modern 3D bits. > But most of the user do not know about that. They just get frustrated with > WINE. Also make sure the the hardware supports the "missing" features. Intel cards are designed to be integrated into motherboards, not to compete with high-end nVidia or AMD/ATI discrete cards. > Some DirectX 7 games runs very well in nVidia graphics card but not in > INTEL. Same thing is for some DirectX8, DirectX8.1. > > I do not know but I suspect that WINE's various Direct3D code utilizes > OpenGL nVidia Extension or higher level OpenGL ARB Extension rather that > lower one. You can (and should have) research this yourself. Wine is 100% opensource. > That's why while INTEL OpenGL driver does support DirectX7, DirectX8 level > 3D wine does not able to run many games on INTEL Linux graphics driver. > While those many games run on nVidia Linux driver. Note that no Linux video driver supports any form of DirectX. Wine translates DirectX calls to OpenGL etc. calls. > I hope WINE will someday have better INTEL OpenGL support. Most likely, improved drivers would fix this, however reporting bugs regarding Intel graphics and proposing patches to Wine (assuming they are well-formed and proper, and don't break support with other cards) are more than welcome.

May 17, 2009

WINE Intel

by MD.IMAM HOSSAIN

Dear WINE Developers, Good morning. A great journey to WINE's Direct3D support since the beginning of its life time. Now it is so mature that I can play big games like FIFA 2006-2009, Need For Speed ProStreet, Need For Speed Undercover, Hitman Blood Money and so many easily. It already has Shader Model 1, Shader Model 2, Shader Model 3 support. What is I am going to say is that all of the bits of 3D it has are only and fully supported on nVidia based graphics card due to their superior Linux driver. But nVidia is not alone in the graphics card building field. There are other manufacturer around them. Majority of the C.P.U comes up with the INTEL integrated graphics card. We all very well know that their Linux driver lack most of the modern 3D bits. But most of the user do not know about that. They just get frustrated with WINE. Some DirectX 7 games runs very well in nVidia graphics card but not in INTEL. Same thing is for some DirectX8, DirectX8.1. I do not know but I suspect that WINE's various Direct3D code utilizes OpenGL nVidia Extension or higher level OpenGL ARB Extension rather that lower one. That's why while INTEL OpenGL driver does support DirectX7, DirectX8 level 3D wine does not able to run many games on INTEL Linux graphics driver. While those many games run on nVidia Linux driver. I hope WINE will someday have better INTEL OpenGL support. Your sincerely, MD. IMAM HOSSAIN

May 17, 2009

Re: SoC 2009 / Application Test Suite Update

by Scott Ritchie

Austin English wrote: > Howdy all, > > I've been working on the test suite. I've got a few basic tests set up > with notepad, and I'm currently working on setting up the framework, > using AutoHotKey to both run all the tests and parse the logs for > failures/passing todo's. > You may have already had this idea, but today I was just thinking of the concept of running performance tests alongside Wine's conformance tests. Your test suite would be a great place for that - just integrate scripts for the various benchmarking tools. Bonus points if you can put the output from the benchmark programs themselves into some sort of machine parseable format. Then we could have a rough chart of performance data on various things as development continues; in particular we'd catch bugs that still behave correctly but are drastically inefficient. Thanks, Scott Ritchie

May 17, 2009

News on Wine 1.1.21/MacOSX/XQuartz 2.3.3

by James McKenzie

The news is good. First, if you are using Tiger, X11 is still broken and probably will remain so. Second, you do not need to upgrade to Leopard 10.5.7 to use XQuartz 2.3.3, the installer was fixed so it would install on 10.5.6. Third, Graphical games that depend on GLSL functions work. I tried dOOm, the Windows95 version, and it is definitely playable. Frame rates drop whenever you pick something up, but this also happens with CrossOver Games for Mac. This does not happen with Crossover Pro for Mac 7.1. I do not have any other programs that depend on GLSL functionality, but I suspect they will work on this combination. BTW, the version of Wine for Mac that I used for testing was built using Mike Kronenberg's Build Environment 1.1.5. James McKenzie

May 17, 2009

Re: comdlg32: Optimize german Find and FindReplace Dialog(try2)

by James Mckenzie

Dawncrow: Your fix does not match what is displayed in W2K. What does this dialog look like in WindowsXP? James McKenzie -----Original Message----- >From: Dawncrow <webmaster(a)dawncrow.de> >Sent: May 15, 2009 11:14 AM >To: wine-patches <wine-patches(a)winehq.org> >Subject: comdlg32: Optimize german Find and FindReplace Dialog(try2) > >compare can be found here: >http://www.dritimage.de/uploads/bilder/124241122145_comdlg32winepatch.jpeg >--- > dlls/comdlg32/cdlg_De.rc | 14 +++++++------- > 1 files changed, 7 insertions(+), 7 deletions(-) > >

May 16, 2009

Re: Detecting an invalid handle in setupapi

by Juan Lang

Hi Paul, > On Windows (tested on W2K3) this will lead to a failure of > SetupFindFirstLineA with a last error of ERROR_INVALID_HANDLE. On Wine we > don't check the handle and thus the outcome cannot be predicted (mostly > crash). > > What ways do we have to detect invalid handles or better yet how can this be > solved? When we detect application usage like this, the usual approach is to avoid returning pointers as handles, and instead introduce the use of a handle table. Then closed handles can be detected. --Juan

May 16, 2009

Detecting an invalid handle in setupapi

by Paul Vriens

Hi, I'm trying to install Microsoft's MMC (W2K3) and it crashes every now and then with different symptoms. I've tracked it down to what I think is a fault in the application that triggers a bug in Wine. All inf files that are read are closed with SetupCloseInfFile but the app is still trying to use the handle in a call to SetupFindFirstLineA. On Windows (tested on W2K3) this will lead to a failure of SetupFindFirstLineA with a last error of ERROR_INVALID_HANDLE. On Wine we don't check the handle and thus the outcome cannot be predicted (mostly crash). What ways do we have to detect invalid handles or better yet how can this be solved? -- Cheers, Paul.

May 16, 2009

Error in a shader compilation

by Doffle Alain

Hi, I'm trying to get rid of an error I observe in a wine trace (cf. attachement). fixme:d3d_shader:print_glsl_info_log Error received from GLSL shader #32: "0(37) : error C1068: array index out of bounds\n" In my understanding, it comes from an incompatibility between the two lines : trace:d3d_shader:shader_vaddline GL HW (2, 13) : uniform vec4 VC[253]; and trace:d3d_shader:shader_vaddline GL HW (37, 1057) : gl_Position.zw = (VC[254].xy); Can you please give me some help/hint/advice about the correct way to solve this problem please ?

May 16, 2009

Re: ole32: process all sent and some posted messages inCoWaitForMultipleHandles

by Dmitry Timoshkov

"Vincent Povirk" <vincent(a)codeweavers.com> wrote: > With a test program that uses CoWaitForMultipleHandles in a single-thread > apartment as a main loop, I found that on Windows all sent messages were > processed, the program's window did redraw, keyboard and mouse input was >ignored, and only posted messsages from 0x3e0 through 0x3e8 were processed. > This brings Wine's behavior in line with what I observed. That's WM_DDE_FIRST and WM_DDE_LAST. -- Dmitry.

May 16, 2009

Re: Add tests for DirectDraw surface reference counting

by James McKenzie

Luke Benstead wrote: > 2009/5/15 Stefan Dösinger <stefandoesinger(a)gmx.at>: > >> Am Freitag, 15. Mai 2009 13:52:23 schrieb Luke Benstead: >> >>> Reference counts are wrong in Wine which causes some games to fail. >>> I'm working patches to make these tests pass so we can remove the >>> todo_wine's. >>> >>> Luke. >>> >> The patch adds trailing whitespeaces in a few lines. Please remove them. >> Otherwise the code looks good to me. >> >> > > Oops, same patch without the trailing whitespace. > > Send it to wine-patches as (try 2) with a comment about removing the white spaces :) James McKenzie

May 16, 2009

Re: [shell32] Improve the Dutch 'about' message box

by Francois Gouget

On Tue, 12 May 2009, Reece Dunn wrote: [...] > What I would like to do is get an automated (or semi-automated) tool, > ideally with a GUI interface to it. That would ultimately put the > designer in charge. Hopefully, this would also mean that you have a > base resource file that produces the English resources and generate > the others using the standard po files - thus making it easier to > translate. Yes, handling the translation of Wine's resource files would be really nice. It would let us leverage a lot of the po tools, especially the website based ones. This would make it much easier for users to contribute to the translations (right now it's pretty intimidating). I'm not sure how to handle the widget layout though. But I have just stumbled on this pair of tools from the translate-toolkit packag (on Debian) that seem to be made just for this purpose: * po2rc convert Gettext PO localization files to Windows Resource (.rc) files http://translate.sourceforge.net/wiki/toolkit/rc2po * rc2po convert .rc files to Gettext PO localization files http://translate.sourceforge.net/wiki/toolkit/rc2po I don't have time to play with them but with luck someone else does. Getting it going with Wine would be really great. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ Cahn's Axiom: When all else fails, read the instructions.

May 15, 2009

Re: wine-devel Digest, Vol 46, Issue 55

by Steve Dodier

Hello, If it's clear the distro list is quite messed, I think the distinction between Ubuntu Kubuntu and Xubuntu must be kept, because for install, Ubuntu ships with PulseAudio and Compiz by default, which cause a lot of problems, while Xubuntu is free of that and has its compositor shutdown by default. Another way to get rid of that would be to add a few checkboxes for the known problematic bits of the tests (ie. kind of GPU / Presence of Pulse/Compiz / use of winetricks), which would result in easier work for the bug triagers. Anyways, I don't want my post to be a "severity levels" 2, so let me know if you think there's interest in digging into this and i'll post on the forum. Cordially, SD. PS : this is the first time i post on this list. I'm merely an user, sometimes helping other ones on #winehq and in launchpad. I'm also the self-appointed part-time apprentice of the guru Scott Ritchie :p -- Steve Dodier OpenPGP : 0E5E4ECB IRC : SiDi on irc.freenode.net Jabber : sidi(a)im.apinc.org steve.dodier(a)gmail.com https://launchpad.net/~sidi

May 15, 2009

Re: (try3)Fix ATI HD4800 being reported as ATI 9500

by Ricardo Filipe

2009/5/15 Robert Key <hpestilence(a)gmail.com> > Same patch but with the 2048MB X2 comment removed, thanks > Roderick. > > the previous try has been commited today... so if you want to fix the comment you have to send another patch, or leave it like it is.

May 15, 2009

AppDB and Distributions

by André Hentschel

Hi, It's getting more and more strange in our AppDB. If a user is running Ubuntu 9.04, he has 14 options which distribution called Ubuntu 9.04 to choose. 14? There only should be two, the 32-Bit and the 64-Bit Version. If we don't stop that we get more and more chaos in our DB. So why this mess? I guess the users choose one and then see a way deeper some fields called "Distribution Name:" and "Distribution URL:", but they don't read the headline "New Distribution". Maybe we should do something like "IF (choosen distribution) THEN (dont allow to make new one)". Or maybe hide the "New Distribution"-Fields a bit more or make the "New" bigger. Beside clones like "Ubuntu 9.04 Jaunty x86_64" and "Ubuntu 9.04 "Jaunty" x86_64 (+ variants like Kubuntu)" there are also old Alphas which should be removed, same thing for other Versions. see also Bug 17401 Thanks for reading Best regards André Hentschel

May 15, 2009

Re: Add tests for DirectDraw surface reference counting

by Luke Benstead

2009/5/15 Stefan Dösinger <stefandoesinger(a)gmx.at>: > Am Freitag, 15. Mai 2009 13:52:23 schrieb Luke Benstead: >> Reference counts are wrong in Wine which causes some games to fail. >> I'm working patches to make these tests pass so we can remove the >> todo_wine's. >> >> Luke. > > The patch adds trailing whitespeaces in a few lines. Please remove them. > Otherwise the code looks good to me. > Oops, same patch without the trailing whitespace. Luke.

May 15, 2009

Re: Add tests for DirectDraw surface reference counting

by Stefan Dösinger

Am Freitag, 15. Mai 2009 13:52:23 schrieb Luke Benstead: > Reference counts are wrong in Wine which causes some games to fail. > I'm working patches to make these tests pass so we can remove the > todo_wine's. > > Luke. The patch adds trailing whitespeaces in a few lines. Please remove them. Otherwise the code looks good to me.

May 15, 2009

Re: [1/2] winetest: malloc() & co are encapsulated, so encapsulate free() too.

by Alexandre Julliard

Francois Gouget <fgouget(a)free.fr> writes: > It's not very clean to encapsulate malloc() & co with xmalloc(), etc, > but to then call free() directly. It means if the implementation of > xmalloc() is changed to call HeapAlloc() all the free() have to be > changed. So encapsulate free() too. xmalloc() is clearly a wrapper around malloc(), so there's no need to rename free(). If you want to change the allocation you should rename both to heap_alloc/heap_free or something like that. -- Alexandre Julliard julliard(a)winehq.org

May 15, 2009

Re: Fiddling with EnumServicesStatusExW

by Paul Vriens

Rolf Kalbermatter wrote: >> From: Paul Vriens [mailto:paul.vriens.wine(a)gmail.com] >> >> How can I make sure the pointers to the strings are correctly >> passed back as well? Should the RPC stuff take care of these >> pointers and 'translate' them? > > Those pointers are not really pointers but byte offsets from the start > of the buffer. It's been a long time that I have looked into this but > I believe that this is even the case on the client side (e.g. the > caller). So there should be no problem with this, as RPC simply would > need to copy the entire buffer including the strings section. > Sure, RPC does return the structs and the strings but the pointers (byte offsets) are wrong. How can I teach RPC to respect (change) those pointers? >> We could of course teach EnumServicesStatusExW to change the >> pointers to the appropriate ones. We know exactly where there >> strings are so it should be fairly trivial to change those >> pointers. This however seems like a hack. > > Well the original MS service control API has separate RPC calls for > the A and W calls and the offsets are therefore calculated by the > service control service itself correctly. > If you want to implement the A call on top of the W call as is > currently done for the other servicecontrol APIs too, you will > probably have to adjust those offsets accordingly in the W to A > translation of the strings. Yeah, I know. I have the thing working with this (and that mentioned hack) but I'm obviously looking for the best (read correct) solution. > > In the interest of a really compatible RPC interface to the MS > service control service however, it would be better to implement > the separate RPC calls for the A and W version. > > Currently an MS Window client trying to call the Wine service > control service over RPC will fail for the A calls (but there > are also other RPC problems that make Windows-Wine RPC not work > well). More things to fix then ;) -- Cheers, Paul.

May 15, 2009

Re: (try2)Fix ATI HD4800 being reported as ATI 9500

by Roderick Colenbrander

The patch itself is correct but the comment regarding the X2 4800 is incorrect. Those cards indeed have 2GB of video memory (and the PR people mention that to you) but the boards contain two GPUs and both need a have a copy of textures and other resources (though the GPUs can communicate using a high speed bus). Effectively the amount of video memory is still 1GB. Roderick On Fri, May 15, 2009 at 2:29 AM, Robert Key <hpestilence(a)gmail.com> wrote: > Changelog: > * Added support for the ATI HD 4800 series (should be all of them). > Used a HD4830 device id for HD4800 cards in wined3d_gl.h. > > > >

May 15, 2009

RE: Fiddling with EnumServicesStatusExW

by Rolf Kalbermatter

> From: Paul Vriens [mailto:paul.vriens.wine(a)gmail.com] > > How can I make sure the pointers to the strings are correctly > passed back as well? Should the RPC stuff take care of these > pointers and 'translate' them? Those pointers are not really pointers but byte offsets from the start of the buffer. It's been a long time that I have looked into this but I believe that this is even the case on the client side (e.g. the caller). So there should be no problem with this, as RPC simply would need to copy the entire buffer including the strings section. > We could of course teach EnumServicesStatusExW to change the > pointers to the appropriate ones. We know exactly where there > strings are so it should be fairly trivial to change those > pointers. This however seems like a hack. Well the original MS service control API has separate RPC calls for the A and W calls and the offsets are therefore calculated by the service control service itself correctly. If you want to implement the A call on top of the W call as is currently done for the other servicecontrol APIs too, you will probably have to adjust those offsets accordingly in the W to A translation of the strings. In the interest of a really compatible RPC interface to the MS service control service however, it would be better to implement the separate RPC calls for the A and W version. Currently an MS Window client trying to call the Wine service control service over RPC will fail for the A calls (but there are also other RPC problems that make Windows-Wine RPC not work well). Rolf Kalbermatter

May 14, 2009

Re: DIB Engine - first set of fixings agains wine test suite

by Massimo Del Fedele

Zachary Goldberg ha scritto: > On Thu, May 14, 2009 at 5:01 AM, Massimo Del Fedele <max(a)veneto.com> wrote: >> Giuseppe Bilotta ha scritto: >>> On Thursday 14 May 2009 02:02, Massimo Del Fedele wrote: >>> >>>> I started fixing failures against test suite. >>>> Most of bitmap ones are fixed, remaining are due >>>> to still stubbed funcs. >>>> >>>> Now the problem is that it fixed also most todo_wines on bitmap suite.... >>>> >>>> As usual, on bug 421 page for who wants to test it. >>> I noticed that you patches are not created with git format-patch (and >>> thus cannot be applied with git am). Which tool are you using to >>> maintain them? Maybe you could set up a public git repository with >>> your patches applied on top of official Wine. >>> >> I use stacked git to maintaint my patches. >> Instructions are on bug 421 page, but I'll repeat them here : >> >> 1) Install stacked git if you don't already have it : >> sudo apt-get install stgit (or whathever your distro needs) >> >> 2) switch to a new branch (stgit operates on branches, not on origin) >> git checkout -b dibeng-max >> >> 3) init stacked git branch (needed only first time) >> stg init >> >> 4) import the patchset >> stg import -s /path/to/patchset/series >> >> 5) if you want to get rid of stgit data, just commit the patchset >> that's not needed if you want to continue using stgit to push/pop/rebase >> the patchset >> stg commit (this one will leave you with a standard git tree again) >> >> 6) run autoconf -- that's needed because 'configure' file is NOT included in >> my >> patchset, as it changes too much from git releases and it is usually quite >> big patch >> autoconf >> >> 7) build as usual >> ./configure && make depend && make >> >> 8) enable the engine before running apps >> export WINEDIB=ON >> *or* >> fiddle with registry, as explained on bug 421 page if you want it permanent >> >> Ciao >> >> Max >> >> >> >> > > Max, > > Would it be possible to please make a wiki page with all of this > information? Theres something like 250 comments on bug 421 and its > difficult to find the posts you refer to sometimes :) > > Thanks! > -Zach > > > Eh, sorry but I've got no time now.... But if some volunteer wants to do it for me is ok :-) Ciao Max

May 14, 2009

Request for update of the AUTHORS-file

by André Hentschel

The Authors file wasnt updated since 2008-06-16. I maybe would send a patch but i bet Julliard has a Script :)

May 14, 2009

Re: DIB Engine - first set of fixings agains wine test suite

by Zachary Goldberg

On Thu, May 14, 2009 at 5:01 AM, Massimo Del Fedele <max(a)veneto.com> wrote: > Giuseppe Bilotta ha scritto: >> >> On Thursday 14 May 2009 02:02, Massimo Del Fedele wrote: >> >>> I started fixing failures against test suite. >>> Most of bitmap ones are fixed, remaining are due >>> to still stubbed funcs. >>> >>> Now the problem is that it fixed also most todo_wines on bitmap suite.... >>> >>> As usual, on bug 421 page for who wants to test it. >> >> I noticed that you patches are not created with git format-patch (and >> thus cannot be applied with git am). Which tool are you using to >> maintain them? Maybe you could set up a public git repository with >> your patches applied on top of official Wine. >> > > I use stacked git to maintaint my patches. > Instructions are on bug 421 page, but I'll repeat them here : > > 1) Install stacked git if you don't already have it : > sudo apt-get install stgit (or whathever your distro needs) > > 2) switch to a new branch (stgit operates on branches, not on origin) > git checkout -b dibeng-max > > 3) init stacked git branch (needed only first time) > stg init > > 4) import the patchset > stg import -s /path/to/patchset/series > > 5) if you want to get rid of stgit data, just commit the patchset > that's not needed if you want to continue using stgit to push/pop/rebase > the patchset > stg commit (this one will leave you with a standard git tree again) > > 6) run autoconf -- that's needed because 'configure' file is NOT included in > my > patchset, as it changes too much from git releases and it is usually quite > big patch > autoconf > > 7) build as usual > ./configure && make depend && make > > 8) enable the engine before running apps > export WINEDIB=ON > *or* > fiddle with registry, as explained on bug 421 page if you want it permanent > > Ciao > > Max > > > > Max, Would it be possible to please make a wiki page with all of this information? Theres something like 250 comments on bug 421 and its difficult to find the posts you refer to sometimes :) Thanks! -Zach

May 14, 2009