February 2012 - Wine-devel - list.winehq.org

Re: [PATCH 1/3] Minimal fix for IOCTL_DVD_READ_STRUCTURE output format
by Dan Kegel 20 Feb '12

20 Feb '12

On Fri, Feb 17, 2012 at 12:32 AM, Dan Kegel <dank(a)kegel.com> wrote: > This is a minimal patch that should fix Dragon Age disc detection, > http://bugs.winehq.org/show_bug.cgi?id=29669 > > The remaining problems can be dealt with after release. > > Test passes on Linux and Windows with the Dragon Age disc in the drive. This is missing a level of indirection on mac. I'll send a corrected patch.

1 0

Re: kernel32: CreateMemoryResourceNotification stub should return a waitable handle
by Dan Kegel 20 Feb '12

20 Feb '12

On Mon, Feb 20, 2012 at 6:38 AM, Vitaliy Margolen <wine-devel(a)kievinfo.com> wrote: >>>>> + return CreateEventA(NULL, FALSE, FALSE, "Fake >>>>> MemoryResourceNotification"); >>>> >>>> I don't think you want a named event here. Anonymous would be better, in >>>> case the program will ask for another event. >>> >>> Oh, right. Anonymous it is, then. >> >> Hang on - those events will never fire, so what does it matter if >> the same event gets two handles? > > My bad. Was just trying to make sure it won't conflict with anything. > > Re-read description of this function on MSDN which indicates it's a system > wide event. So you should be good with the named event. Good, the patch stands then. - Dan

1 0

know more about Win API's
by prateek papriwal 20 Feb '12

20 Feb '12

hello, can anyone suggest me how to get knowledge of windows API's and Wine Internals. I am reading the documentation provided on the site but i am finding it hard to grasp the things .. if u can suggest me some good readings or moreover a structured way of reading things it would be helpful for me ...

3 2

Re: windowscodecs: Make MetadataReader_Create() static.
by Vincent Povirk 20 Feb '12

20 Feb '12

This function will be used from other files in the future. On Sun, Feb 19, 2012 at 4:32 PM, Francois Gouget <fgouget(a)free.fr> wrote: > --- > dlls/windowscodecs/metadatahandler.c | 2 +- > dlls/windowscodecs/wincodecs_private.h | 1 - > 2 files changed, 1 insertions(+), 2 deletions(-) > > diff --git a/dlls/windowscodecs/metadatahandler.c b/dlls/windowscodecs/metadatahandler.c > index afcff21..53aa22a 100644 > --- a/dlls/windowscodecs/metadatahandler.c > +++ b/dlls/windowscodecs/metadatahandler.c > @@ -317,7 +317,7 @@ static const IWICPersistStreamVtbl MetadataHandler_PersistStream_Vtbl = { > MetadataHandler_SaveEx > }; > > -HRESULT MetadataReader_Create(const MetadataHandlerVtbl *vtable, IUnknown *pUnkOuter, REFIID iid, void** ppv) > +static HRESULT MetadataReader_Create(const MetadataHandlerVtbl *vtable, IUnknown *pUnkOuter, REFIID iid, void** ppv) > { > MetadataHandler *This; > HRESULT hr; > diff --git a/dlls/windowscodecs/wincodecs_private.h b/dlls/windowscodecs/wincodecs_private.h > index 691b1ec..9cbeaa1 100644 > --- a/dlls/windowscodecs/wincodecs_private.h > +++ b/dlls/windowscodecs/wincodecs_private.h > @@ -83,7 +83,6 @@ typedef struct _MetadataHandlerVtbl > ULARGE_INTEGER *size); > } MetadataHandlerVtbl; > > -extern HRESULT MetadataReader_Create(const MetadataHandlerVtbl *vtable, IUnknown *pUnkOuter, REFIID iid, void** ppv) DECLSPEC_HIDDEN; > > extern HRESULT UnknownMetadataReader_CreateInstance(IUnknown *pUnkOuter, REFIID iid, void** ppv) DECLSPEC_HIDDEN; > > -- > 1.7.9 > > >

1 0

Re: kernel32: CreateMemoryResourceNotification stub should return a waitable handle
by Vitaliy Margolen 19 Feb '12

19 Feb '12

On 02/19/2012 09:26 AM, Dan Kegel wrote: > Otherwise jqs spins. > Fixes http://bugs.winehq.org/show_bug.cgi?id=29936 > > + return CreateEventA(NULL, FALSE, FALSE, "Fake MemoryResourceNotification"); I don't think you want a named event here. Anonymous would be better, in case the program will ask for another event. Vitaliy.

2 1

Re: [user32] quiet two noisy fixmes
by Dan Kegel 19 Feb '12

19 Feb '12

On Sun, Feb 19, 2012 at 1:47 AM, Dan Kegel <dank(a)kegel.com> wrote: > Since Java 6 SE 10, Java installs a "Java Quick Start" service which calls > these two functions multiple times per second. Please ignore this patch. Even with the messages suppressed, JQS burns CPU. The console spew is a useful reminder of http://bugs.winehq.org/show_bug.cgi?id=29936

1 0

Re: [1/3] comdlg32: Adjust the size of CHOOSE_COLOR dialog.
by Dmitry Timoshkov 19 Feb '12

19 Feb '12

Gustavo Henrique Milaré <gugamilare(a)gmail.com> wrote: > Adjusting size for the translation to fit. You can't do that, read the comment in that file slightly before all common dialog templates. -- Dmitry.

4 11

Re: [PATCH] quartz: fixed sizeof()s to IsBadReadPtr (Coverity)
by Marvin 18 Feb '12

18 Feb '12

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at http://testbot.winehq.org/JobDetails.pl?Key=17015 Your paranoid android. === WNT4WSSP6 (32 bit filtermapper) === filtermapper.c:96: Test failed: CoCreateInstance failed with 80040154 filtermapper.c:233: Test failed: CoCreateInstance failed with 80040154 filtermapper.c:347: Test failed: CoCreateInstance failed with 80040154 filtermapper.c:405: Test failed: CoCreateInstance failed with 80040154

1 0

kernel32/tests: initial tests for cdrom.c
by Joerg-Cyril.Hoehle＠t-systems.com 18 Feb '12

18 Feb '12

Dan Kegel wrote: >These require a DVD in the drive, so they are skipped without >WINETEST_INTERACTIVE=1. I don't see the causality. Presumably the tests require no human intervention. winmm/tests/mcicda also skips tests if no CD-ROM is in the bay. However, even a regular winetest.exe run *will* run as many tests as it can should it find a CD-ROM. Users are invited to submit test results to test.winehq with audio and/or mixed data CD-ROMs in the drive. There's no need for winetest_interactive here. Regards, Jörg Höhle

3 3

Re: OpenGL child windows (SketchUp)
by Roderick Colenbrander 17 Feb '12

17 Feb '12

Re-adding wine-devel. On Wed, Feb 8, 2012 at 2:42 PM, Brian Bloniarz <brian.bloniarz(a)gmail.com> wrote: > On Wed, Feb 8, 2012 at 12:33 PM, Roderick Colenbrander > <thunderbird2k(a)gmail.com> wrote: >> >> On Wed, Feb 8, 2012 at 6:31 PM, Matteo Bruni <matteo.mystral(a)gmail.com> >> wrote: >> > I'm not really such an expert in the area, but I think both (1) and >> > (2) make sense. I'm not sure in (1) case about the glXWaitGL call, as >> > technically glXSwapBuffers is not a GL call, but given that it works >> > for you (while XSync doesn't) on Nvidia, I guess it's fine... Make >> > sure it works correctly on all the drivers you mentioned, or even that >> > e.g. it doesn't cause excessive slowdowns. >> > >> > > > ... >> >> glXWaitGL and friends were intended for syncing GLX and X, so this may >> >> be the most reliable way. As you pointed out there may be bugs in DRI, >> but this needs a careful read of the specs (will try to look at it). >> As you said the damage extension can be used as well, but I think I >> would lean to using the classic glX/X synchronization features first. > > > Thanks for looking, both of you! > > I'm looking at the GLX1.3 spec at: > http://www.lri.fr/~mbl/ENS/IG2/docs/glx1.3.pdf > > "Sequentiality" has: > "glXSwapBuffers is in the OpenGL stream if and only if > the display and drawable are those belonging to the calling thread's > current context; otherwise it is in the X stream." > > That would put our glXSwapBuffers in the OpenGL stream, > and hence something that should be serialized by a call > to glXWaitGL(). I wouldn't test it in court though :) > > Whatever the approach, I'd be happy to test and/or benchmark > on the 4 renderers I have access to. > > Thanks, > -Brian A patch like this is what should do the job. I'm not sure what the penalty will be. Remember glXSwapBuffers already performs a glFlush, so a glXWaitGL on top of that may not be too bad. I can't quickly think of a good test application. You would like a game or some benchmark, but I can't think of anything stressful now which uses a child window (an application which has a menu bar, doesn't use a child window). Google Earth always was a good test. We need to figure out if the DRI drivers are indeed buggy. I will see if I have time to look at it, but my time is very limited these days :( Roderick

2 2