wine-devel September 2006

wine-devel@winehq.org

139 participants
257 discussions

make test failure #3
by James Hawkins 29 Sep '06

29 Sep '06

Hi, make[2]: Entering directory `/usr/local/src/wine/dlls/shell32/tests' ../../../tools/runtest -q -P wine -M shell32.dll -T ../../.. -p shell32_test.exe.so shlfileop.c && touch shlfileop.ok shlfileop.c:168: Test failed: The requested file does not exist, ret=3 make[2]: *** [shlfileop.ok] Error 1 -- James Hawkins

2 1

make test failure #5
by James Hawkins 29 Sep '06

29 Sep '06

Hi, make[2]: Entering directory `/usr/local/src/wine/dlls/user/tests' msg.c:3700: Test failed: DrawMenuBar: the msg sequence is not complete: expected 0000 - actual 0021 msg.c:3727: Test failed: MsgWaitForMultipleObjects returned 0 fixme:msg:pack_message msg 14 (WM_ERASEBKGND) not supported yet fixme:msg:pack_message msg 14 (WM_ERASEBKGND) not supported yet msg.c:6768: Test failed: WmEmpty: the msg sequence is not complete: expected 0000 - actual 0014 make[2]: *** [msg.ok] Error 3 -- James Hawkins

2 2

make test failure #2
by James Hawkins 28 Sep '06

28 Sep '06

Hi, This test passes on my machine, should it not? make[2]: Entering directory `/usr/local/src/wine/dlls/d3d9/tests' ../../../tools/runtest -q -P wine -M d3d9.dll -T ../../.. -p d3d9_test.exe.so surface.c && touch surface.ok fixme:d3d:IWineD3DDeviceImpl_GetAvailableTextureMem (0x18cd10) : stub, simulating 64MB for now, returning 64MB left surface.c:131: Test succeeded inside todo block: Got pitch 12, expected 12 make[2]: *** [surface.ok] Error 1 -- James Hawkins

3 3

make test failure #6
by James Hawkins 28 Sep '06

28 Sep '06

Hi, This is with a clean .wine. make[2]: Entering directory `/usr/local/src/wine/dlls/user/tests' ../../../tools/runtest -q -P wine -M user32.dll -T ../../.. -p user32_test.exe.so sysparams.c && touch sysparams.ok sysparams.c:1471: Test failed: wrong value in registry -1, expected 154 sysparams.c:1474: Test failed: wrong value in registry -1, expected 0 sysparams.c:1477: Test failed: wrong value in registry -1, expected 0 sysparams.c:1480: Test failed: wrong value in registry -1, expected 8 make[2]: *** [sysparams.ok] Error 4 -- James Hawkins

1 0

make test failure #4
by James Hawkins 28 Sep '06

28 Sep '06

Hi, make[2]: Entering directory `/usr/local/src/wine/dlls/user/tests' err:x11settings:X11DRV_ChangeDisplaySettingsEx No matching mode found! (XRandR) monitor.c:143: Test failed: Failed to change resolution[0]: -2 err:x11settings:X11DRV_ChangeDisplaySettingsEx No matching mode found! (XRandR) monitor.c:143: Test failed: Failed to change resolution[1]: -2 err:x11settings:X11DRV_ChangeDisplaySettingsEx No matching mode found! (XRandR) monitor.c:143: Test failed: Failed to change resolution[2]: -2 err:x11settings:X11DRV_ChangeDisplaySettingsEx No matching mode found! (XRandR) monitor.c:143: Test failed: Failed to change resolution[3]: -2 err:x11settings:X11DRV_ChangeDisplaySettingsEx No matching mode found! (XRandR) err:x11settings:X11DRV_ChangeDisplaySettingsEx No matching mode found! (XRandR) make[2]: *** [monitor.ok] Error 4 -- James Hawkins

1 0

Re: Route WGL font code through gdi32.dll
by Huw Davies 28 Sep '06

28 Sep '06

On Thu, Sep 28, 2006 at 08:20:51PM +0200, Roderick Colenbrander wrote: > Again as mentioned by Huw, the gdi32.spec file wasn't correct. > It should be correct this time. No. Your gdi32.spec was fine. It was the opengl32.spec that was wrong (hint: that's why I quoted that bit of the patch ;-). Your patch is for the wglUseFont*Bitmaps* functions and not the wglUseFont*Outlines* functions, so the only thing that should be changing is the former and not the latter. So in opengl32.spec you need to forward the wglUseFont*Bitmaps* functions to functions of the same name in gdi32. Huw.

2 1

Re: [rpcrt4] Fix RpcMgmtSetServerStackSize prototype (2nd attempt)
by Vitaliy Margolen 28 Sep '06

28 Sep '06

Thomas Weidenmueller wrote: > The parameter of RpcMgmtSetServerStackSize needs to be unsigned long, > not unsigned int. > > - Thomas > It's been discussed numerous times, you should avoid use of 'long' in Wine. On win64 sizeof(long) == 4. On Linux64 sizeof(long) == 8. Vitaliy.

1 1

Re: Patchwork (was Re: Governance revisited)
by Ge van Geldorp 28 Sep '06

28 Sep '06

> From: Vitaliy Margolen <wine-devel(a)kievinfo.com> > > So in a sense you will require some one to respond for any > incoming e-mail to wine-patches. And if no one does, > Alexandre don't get to see the status? Not sure I understand what you mean. If no-one responds to the patch on wine-devel the patch would remain queued and it would show up in Alexandres list. > What if he already > applied the patch? Now you slowing down what would have > worked just fine before. If the patch is already applied it would be marked as such in the database. When a message is sent to wine-devel after the fact, it won't get magically un-applied. > Ok now you making it dependant on an e-mail client. Yet > that's exactly what we are trying avoid with GIT. Actually, my preference would be to do patch management via a web-based interface. But that's just my preference, I assume a lot of other people prefer the mailinglist method. So let's try to support both. > Not really. You can't make some one to review something that > don't understand. Or if they are busy/on vacation/away from > PC/etc. I'm not trying to change the review process, it would remain as-is. The only addition would be a bot which could do some checks (e.g. does the patch apply cleanly?). But that bot could be introduced anyway, even if Patchwork isn't introduced, so I guess it's not an integral part of the proposed system. > So in the end you'll end up with either huge queue > that no one wants to touch. Or a "clean up" jobs that will > once in a while go and mark all patches as old and will > require authors to resubmit. How's that better then what we use now? If no-one touches a patch, it would end up on Alexandres plate. He could review the patch himself or ask a subsystem maintainer to review it. Again, that's not different from the current system. If the queue of patches waiting for commit grows without bounds, that's a clear indication that Alexandre is overloaded and the project should find ways to remove some of his workload. The same would happen without a patch management system, but perhaps it wouldn't be as visible, so I'm chalking this one up as an added benefit of a patch management system. The system would also be self-cleaning. If a patch has been in RFC status too long it would be deleted from the queue (with appropriate warning email to the author) http://www.winehq.org/pipermail/wine-devel/2006-September/051114.html > When people well send out right hacks and expect some one to > tell then what they really should do. Current system allows > to no waste any time on such craft. We seem to have fundamentally different views of the "peripheral" (non-core) Wine developers. You seem to view them as potentially bad guys, going out of their way to submit hacks and decrease the quality of Wine code as much as possible, people you'd rather see leave. I see people willing to donate their time to improve Wine. Sure, they make mistakes but at least they make an effort. > No, by requiring some one to respond you making them > responsible (at least until they respond). Of course > responses like "sucks" wouldn't be nice, so some one who does > understand the subject will have to spend their time to > understand the patch, write a review of the patch and send > it. I don't get your point here. Isn't the purpose of reviewing to actually review the patch? > And you want that ASAP! Which means whenever patch > arrives in wine-patches some one (most likely more then one > person) will stop everything they are doing, and start > writing a review? No, I don't want to change the review process. It can remain just as it is now. My objective is to improve Wine by maximizing the number of patches of acceptable quality. In my opinion, this can be done by: 1) assuring no patches get lost 2) assuring an author gets informed about why his patch is not acceptable in its current form so he can improve it. Ge van Geldorp.

4 6

Award for solving bug 6183
by Mirek 28 Sep '06

28 Sep '06

There is bug in wine, which prevents me to play NFS MW with sound (and even Call of Duty). I would like to offer some money for solving this bug. I dont know how much will be good and i can give you all info from my system to solve this (debug, system info). If you are interested in just reply on my email address. Thanks, Mirek

1 0

Re: Setupapi: add stubs [resend]
by Alexandre Julliard 28 Sep '06

28 Sep '06

Julien <julienc(a)psychologie-fr.org> writes: > +/*********************************************************************** > + * SetupDiDestroyClassImageList(SETUPAPI.@) > + */ > +BOOL WINAPI SetupDiDestroyClassImageList(PSP_CLASSIMAGELIST_DATA ClassImageListData) > +{ > + FIXME ("Stub %p\n", ClassImageListData); > + SetLastError(ERROR_CALL_NOT_IMPLEMENTED); > + return TRUE; > +} > + > +/*********************************************************************** > + * SetupDiGetClassImageList(SETUPAPI.@) > + */ > +BOOL WINAPI SetupDiGetClassImageList(PSP_CLASSIMAGELIST_DATA ClassImageListData) > +{ > + FIXME ("Stub %p\n", ClassImageListData); > + SetLastError(ERROR_CALL_NOT_IMPLEMENTED); > + return TRUE; > +} It makes no sense to set last error if you return success. And you really shouldn't return success unless you also store the right things in that data structure. -- Alexandre Julliard julliard(a)winehq.org

1 0

← Newer
1
2
3
4
5
6
7
8
...
26
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel September 2006