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

Re: The: "Wine Status - ChangeLog"

by Tom Wickline

On 6/29/07, Tomas.Zijdemans(a)student.uib.no <Tomas.Zijdemans(a)student.uib.no> wrote: > This page has been dead since October 1. > > Since I'm not producing code for the Wine project, this is an area I'd like to > contribute to. (I'm already taking screenshots of the API status page to see > what happens from release to release :)) I plan to start updating the status pages next week, I have already contacted a couple people and ask for the opinion on the current status of the components that they have been working on. Cheers, Tom > > Is there some WineHQ folks here that would be willing to give me accsess? > > Regards. >

June 30, 2007

Re: [1/2] gdi32: Added PolyDraw tests to tests/path.c [try2]

by Misha Koshelev

On Fri, 2007-06-29 at 14:49 -0700, Evan Stade wrote: > Thanks a lot for your help. No prob. > > Your shorter diff may make the tests conform, but it incorrectly > assigns lastmove.x = dc->CursPosX. This only makes it conform to the > tests because the tests happen to have a MoveToEx as the last path > point before the PolyDraw is called. You should include this in your tests, e.g., by calling LineTo after the MoveToEx and before the first PolyDraw. This immediately makes it clear why you need to have separate path and non-path cases. (I personally think about conformance tests like this - you worked hard to figure out how the function works on native and implemented your own version, but someone might commit a patch sometime in the future to fix something else that screws up all your hard work; that's why you need to put this knowledge into conformance tests, so once that feature is implemented in wine it will never break again). > Also, your diff doesn't > correctly check the point types. The test if( lpbTypes[i] == > PT_MOVETO) (which was there before your changes) is wrong because it > returns false for PT_MOVETO | PT_LINETO, when it should return true > (according to my testing which was not a part of the test I > submitted). Also, your diff does not MoveToEx to orig_pos at the > second "return FALSE". This is incorrect but again does not show up > in the tests. Again, these are things that should ideally be a part of your conformance test. That would make the rationale for your extensive changes in your second patch clearer and would improve the likelihood of the patches going in. > > So while a small and simple diff can make these specific tests > conform, it is not correct. However I still don't understand how this > influences whether the test patch got accepted. Your explanation of > why the fix patch didn't get accepted on the other hand does make > sense. > I am not sure why the test patch was not accepted (unless maybe Alexandre wants both patches ready to go before committing either, as if you make any changes to the second one you might find you need to add something to the tests... don't know), but having the whole patchset complete and good to go certainly wouldn't hurt either patch. Misha

June 30, 2007

Re: request to change appdb message

by Chris Morgan

On 6/29/07, Ben Hodgetts <ben(a)atomnet.co.uk> wrote: > Chris Morgan wrote: > > On 6/29/07, Chris Morgan <chmorgan(a)gmail.com> wrote: > >> On 6/29/07, Jesse Allen <the3dfxdude(a)gmail.com> wrote: > >> > On 6/29/07, Louis Lenders <xerox_xerox2000(a)yahoo.co.uk> wrote: > >> > > > >> > > Yeah, so maybe we could add a list of "Common failures" to the > >> documention, > >> > > with the solution. I can live with that. Then we could point > >> garbage test > >> > > submitters to that page. That would be a nice work around. I'll > >> have to > >> > > figure out how wiki works, and then i could give it a shot > >> lateron i guess. > >> > > > >> > > Something like: > >> > > > >> > > Problem: > >> > > err:module:import_dll Library MSVBVM60.DLL (needed by > >> L"C:\\app.exe") > >> > > not found > >> > > err:module:LdrInitializeThunk Main exe initialization for > >> L"C:\\app.exe" > >> > > failed,status c0000135 > >> > > > >> > > Solution: > >> > > winetricks vcrun60 > >> > > > >> > > or > >> > > > >> > > Problem: > >> > > wine app.exe > >> > > err:ole:CoGetClassObject class > >> {00000514-0000-0010-8000-00aa006d2ea4} > >> > > not registered > >> > > err:ole:create_server class {00000514-0000-0010-8000-00aa006d2ea4} > >> > > not registered > >> > > err:ole:CoGetClassObject no class object > >> > > {00000514-0000-0010-8000-00aa006d2ea4}could be created for > >> > > context 0x5 > >> > > Unhandled page fault etc......... > >> > > > >> > > Solution: > >> > > winetricks mdac27 > >> > > > >> > > Would that be something useful? > >> > > > >> > > Cheers, Louis > >> > > > >> > > > >> > > > >> > > >> > Well, yeah. But the maintainer should be doing that already using > >> > appdb notes based on his own knowledge or reading test reports. The > >> > maintainer already screens the reports. So I can't see why we need to > >> > be more automatic. > >> > > >> > However we should set up a wiki for common problems or procedures so > >> > the maintainer can link to them from the notes. > >> > > >> > >> Checking it automatically lets us skip the round trip of submission, > >> review, rejection and resubmission. We can check the submission and > >> report suggestions before the user even submits the test results, thus > >> avoiding the problem where each of our 800+ maintainers knows about > >> those problems. > > > > That last sentence should have been "where each of our 800+ maintainer > > has to know about those problems and common solutions". > > > > Chris > > > > > I think the main problem is that there is a lack of maintainers and the > ones that exist seem to be mainly inactive. If they were active then > there would already be notes pointing to easy fixes for the apps like > NoCD patches, d3dx9xx.dll files, etc. I agree a pre-parser for common > issues would be nice, but probably quite a bit of coding work and likely > to get many wrong hits. It's a messy situation really. > It isn't all that complex. It would require someone to start to collect common debug output from users and then look at how we might look for particular dlls or errors to identify the particular issue. For someone with lots of experience it wouldn't seem to be all that difficult but it really depends on how generic some errors are. Chris

June 29, 2007

Re: request to change appdb message

by Ben Hodgetts

Chris Morgan wrote: > On 6/29/07, Chris Morgan <chmorgan(a)gmail.com> wrote: >> On 6/29/07, Jesse Allen <the3dfxdude(a)gmail.com> wrote: >> > On 6/29/07, Louis Lenders <xerox_xerox2000(a)yahoo.co.uk> wrote: >> > > >> > > Yeah, so maybe we could add a list of "Common failures" to the >> documention, >> > > with the solution. I can live with that. Then we could point >> garbage test >> > > submitters to that page. That would be a nice work around. I'll >> have to >> > > figure out how wiki works, and then i could give it a shot >> lateron i guess. >> > > >> > > Something like: >> > > >> > > Problem: >> > > err:module:import_dll Library MSVBVM60.DLL (needed by >> L"C:\\app.exe") >> > > not found >> > > err:module:LdrInitializeThunk Main exe initialization for >> L"C:\\app.exe" >> > > failed,status c0000135 >> > > >> > > Solution: >> > > winetricks vcrun60 >> > > >> > > or >> > > >> > > Problem: >> > > wine app.exe >> > > err:ole:CoGetClassObject class >> {00000514-0000-0010-8000-00aa006d2ea4} >> > > not registered >> > > err:ole:create_server class {00000514-0000-0010-8000-00aa006d2ea4} >> > > not registered >> > > err:ole:CoGetClassObject no class object >> > > {00000514-0000-0010-8000-00aa006d2ea4}could be created for >> > > context 0x5 >> > > Unhandled page fault etc......... >> > > >> > > Solution: >> > > winetricks mdac27 >> > > >> > > Would that be something useful? >> > > >> > > Cheers, Louis >> > > >> > > >> > > >> > >> > Well, yeah. But the maintainer should be doing that already using >> > appdb notes based on his own knowledge or reading test reports. The >> > maintainer already screens the reports. So I can't see why we need to >> > be more automatic. >> > >> > However we should set up a wiki for common problems or procedures so >> > the maintainer can link to them from the notes. >> > >> >> Checking it automatically lets us skip the round trip of submission, >> review, rejection and resubmission. We can check the submission and >> report suggestions before the user even submits the test results, thus >> avoiding the problem where each of our 800+ maintainers knows about >> those problems. > > That last sentence should have been "where each of our 800+ maintainer > has to know about those problems and common solutions". > > Chris > > I think the main problem is that there is a lack of maintainers and the ones that exist seem to be mainly inactive. If they were active then there would already be notes pointing to easy fixes for the apps like NoCD patches, d3dx9xx.dll files, etc. I agree a pre-parser for common issues would be nice, but probably quite a bit of coding work and likely to get many wrong hits. It's a messy situation really. Ben H.

June 29, 2007

Re: [1/2] gdi32: Added PolyDraw tests to tests/path.c [try2]

by Evan Stade

On 6/29/07, Koshelev, Misha Vladislavo <mk144210(a)bcm.tmc.edu> wrote: > > > > On 6/27/07, Evan Stade <estade at gmail.com> wrote: > > Hi, > > > > [try2] The patch I sent yesterday was not properly todo_wined. Also, > > this test is a bit more extensive (about twice as many points drawn). > > It uses various point-type combination (even non-sensical ones such as > > PT_LINETO | PT_MOVETO) to test the exact logic of PolyDraw with an > > open path. > > > > changelog: > > * added polydraw test to path testing (5 more todo_wines) > > > > dlls/gdi32/tests/path.c | 70 > +++++++++++++++++++++++++++++++++++++++++++++++ > > 1 files changed, 70 insertions(+), 0 deletions(-) > > > > -- > > Evan Stade > > > > > > Also, I'd add a PT_MOVETO into your first PolyDraw call so you can tell > whether > PT_CLOSEFIGURE adds a PT_MOVETO to orig_pos or lastmove, as the current > version > does not differentiate this. > > Misha > > > Thanks a lot for your help. Your shorter diff may make the tests conform, but it incorrectly assigns lastmove.x = dc->CursPosX. This only makes it conform to the tests because the tests happen to have a MoveToEx as the last path point before the PolyDraw is called. Also, your diff doesn't correctly check the point types. The test if( lpbTypes[i] == PT_MOVETO) (which was there before your changes) is wrong because it returns false for PT_MOVETO | PT_LINETO, when it should return true (according to my testing which was not a part of the test I submitted). Also, your diff does not MoveToEx to orig_pos at the second "return FALSE". This is incorrect but again does not show up in the tests. So while a small and simple diff can make these specific tests conform, it is not correct. However I still don't understand how this influences whether the test patch got accepted. Your explanation of why the fix patch didn't get accepted on the other hand does make sense. -- Evan Stade

June 29, 2007

Re: request to change appdb message

by Chris Morgan

On 6/29/07, Chris Morgan <chmorgan(a)gmail.com> wrote: > On 6/29/07, Jesse Allen <the3dfxdude(a)gmail.com> wrote: > > On 6/29/07, Louis Lenders <xerox_xerox2000(a)yahoo.co.uk> wrote: > > > > > > Yeah, so maybe we could add a list of "Common failures" to the documention, > > > with the solution. I can live with that. Then we could point garbage test > > > submitters to that page. That would be a nice work around. I'll have to > > > figure out how wiki works, and then i could give it a shot lateron i guess. > > > > > > Something like: > > > > > > Problem: > > > err:module:import_dll Library MSVBVM60.DLL (needed by L"C:\\app.exe") > > > not found > > > err:module:LdrInitializeThunk Main exe initialization for L"C:\\app.exe" > > > failed,status c0000135 > > > > > > Solution: > > > winetricks vcrun60 > > > > > > or > > > > > > Problem: > > > wine app.exe > > > err:ole:CoGetClassObject class {00000514-0000-0010-8000-00aa006d2ea4} > > > not registered > > > err:ole:create_server class {00000514-0000-0010-8000-00aa006d2ea4} > > > not registered > > > err:ole:CoGetClassObject no class object > > > {00000514-0000-0010-8000-00aa006d2ea4}could be created for > > > context 0x5 > > > Unhandled page fault etc......... > > > > > > Solution: > > > winetricks mdac27 > > > > > > Would that be something useful? > > > > > > Cheers, Louis > > > > > > > > > > > > > Well, yeah. But the maintainer should be doing that already using > > appdb notes based on his own knowledge or reading test reports. The > > maintainer already screens the reports. So I can't see why we need to > > be more automatic. > > > > However we should set up a wiki for common problems or procedures so > > the maintainer can link to them from the notes. > > > > Checking it automatically lets us skip the round trip of submission, > review, rejection and resubmission. We can check the submission and > report suggestions before the user even submits the test results, thus > avoiding the problem where each of our 800+ maintainers knows about > those problems. That last sentence should have been "where each of our 800+ maintainer has to know about those problems and common solutions". Chris

June 29, 2007

Re: Announcing WineConf 2007

by Steven Edwards

On 6/29/07, Mike Hearn <mike(a)plan99.net> wrote: > 6th/7th October. Be there or be square. If anyone from the US is planing on attending and does not currently have your passport, you need to apply for it NOW. Due to insane US policy there is about a 3 month backlog on passport application processing. -- 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

June 29, 2007

Re: request to change appdb message

by Chris Morgan

On 6/29/07, Jesse Allen <the3dfxdude(a)gmail.com> wrote: > On 6/29/07, Louis Lenders <xerox_xerox2000(a)yahoo.co.uk> wrote: > > > > Yeah, so maybe we could add a list of "Common failures" to the documention, > > with the solution. I can live with that. Then we could point garbage test > > submitters to that page. That would be a nice work around. I'll have to > > figure out how wiki works, and then i could give it a shot lateron i guess. > > > > Something like: > > > > Problem: > > err:module:import_dll Library MSVBVM60.DLL (needed by L"C:\\app.exe") > > not found > > err:module:LdrInitializeThunk Main exe initialization for L"C:\\app.exe" > > failed,status c0000135 > > > > Solution: > > winetricks vcrun60 > > > > or > > > > Problem: > > wine app.exe > > err:ole:CoGetClassObject class {00000514-0000-0010-8000-00aa006d2ea4} > > not registered > > err:ole:create_server class {00000514-0000-0010-8000-00aa006d2ea4} > > not registered > > err:ole:CoGetClassObject no class object > > {00000514-0000-0010-8000-00aa006d2ea4}could be created for > > context 0x5 > > Unhandled page fault etc......... > > > > Solution: > > winetricks mdac27 > > > > Would that be something useful? > > > > Cheers, Louis > > > > > > > > Well, yeah. But the maintainer should be doing that already using > appdb notes based on his own knowledge or reading test reports. The > maintainer already screens the reports. So I can't see why we need to > be more automatic. > > However we should set up a wiki for common problems or procedures so > the maintainer can link to them from the notes. > Checking it automatically lets us skip the round trip of submission, review, rejection and resubmission. We can check the submission and report suggestions before the user even submits the test results, thus avoiding the problem where each of our 800+ maintainers knows about those problems. Chris

June 29, 2007

Announcing WineConf 2007

by Mike Hearn

Yes, it's true! The moment you've all been waiting for! On 6th/7th October, once more Wine hackers from around the world will meet to eat, drink, make merry, and discuss the finer details of reimplementing the Windows API. This year it's Googles turn to host it, and it'll be at the engineering office in Zurich. You too can chill out with these awesome froods by signing up for the wineconf mailing list, and surfing over to: http://wiki.winehq.org/WineConf2007 ... which is currently a bit sparse but will populate nearer the time. Fascinating talks! Interesting people! Hackfests galore ... and maybe even fondue! 6th/7th October. Be there or be square.

June 29, 2007

Re: request to change appdb message

by Jesse Allen

On 6/29/07, Louis Lenders <xerox_xerox2000(a)yahoo.co.uk> wrote: > > Yeah, so maybe we could add a list of "Common failures" to the documention, > with the solution. I can live with that. Then we could point garbage test > submitters to that page. That would be a nice work around. I'll have to > figure out how wiki works, and then i could give it a shot lateron i guess. > > Something like: > > Problem: > err:module:import_dll Library MSVBVM60.DLL (needed by L"C:\\app.exe") > not found > err:module:LdrInitializeThunk Main exe initialization for L"C:\\app.exe" > failed,status c0000135 > > Solution: > winetricks vcrun60 > > or > > Problem: > wine app.exe > err:ole:CoGetClassObject class {00000514-0000-0010-8000-00aa006d2ea4} > not registered > err:ole:create_server class {00000514-0000-0010-8000-00aa006d2ea4} > not registered > err:ole:CoGetClassObject no class object > {00000514-0000-0010-8000-00aa006d2ea4}could be created for > context 0x5 > Unhandled page fault etc......... > > Solution: > winetricks mdac27 > > Would that be something useful? > > Cheers, Louis > > > Well, yeah. But the maintainer should be doing that already using appdb notes based on his own knowledge or reading test reports. The maintainer already screens the reports. So I can't see why we need to be more automatic. However we should set up a wiki for common problems or procedures so the maintainer can link to them from the notes.

June 29, 2007