June 2008 - Wine-devel - list.winehq.org

What to do with wrong AeDebug entries in the registry on Windows boxes?
by Paul Vriens 25 Jun '08

25 Jun '08

Hi, I guess it's a leftover from old kernel/debugger tests but on some Windows boxes this registry key is filled with our test-debugger information. This is maybe/probably the reason some tests show "Timeout" for one box and "Crashed" for others. What would be the best approach to "restore" this key? I guess if we find the mentioning of our test in this registry key we should delete it. But what do we replace it with? I ran 'drwtsn32 -i' on my boxes to at least have the default in there, but that's of course not correct for people running other debuggers. -- Cheers, Paul.

1 0

Some Questions From The Bugzilla Project
by Max Kanat-Alexander 25 Jun '08

25 Jun '08

Hey there Wine Bugzilla folks. I've been funded by the Mozilla Foundation to do a survey of the major Bugzilla-using organizations in the world, to find out what people like and don't like about Bugzilla, what we could improve, what changes you'd like to see in Bugzilla, etc., and you guys are one of the organizations picked for the survey. :-) The Bugzilla Project is going to use this information to prioritize its work on future releases, and we may even be able to get a grant from the Mozilla Foundation to work on some of the most popular or pressing issues. In other words, what you say here will really matter. I was wondering--who's the best contact there who I could ask a few questions to about how you guys use Bugzilla? It'd just be over email, unless you want to do it over IRC or on the phone. (Oh, and make sure you reply to me directly, since I'm not on the list.) -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla and Perl Services. Everything Else, too.

5 7

Re: [1/2] gdi32: defines for CreateFontIndirectEx (try3)
by Dmitry Timoshkov 24 Jun '08

24 Jun '08

"Nikolay Sivov" <bunglehead(a)gmail.com> wrote: > --- a/include/wingdi.h > +++ b/include/wingdi.h > @@ -573,8 +573,8 @@ DECL_WINELIB_TYPE_AW(LPLOGFONT) > typedef struct > { > LOGFONTA elfLogFont; > - BYTE elfFullName[LF_FULLFACESIZE]; > - BYTE elfStyle[LF_FACESIZE]; > + CHAR elfFullName[LF_FULLFACESIZE]; > + CHAR elfStyle[LF_FACESIZE]; > } ENUMLOGFONTA, *LPENUMLOGFONTA; > > typedef struct > @@ -590,9 +590,9 @@ DECL_WINELIB_TYPE_AW(LPENUMLOGFONT) > typedef struct > { > LOGFONTA elfLogFont; > - BYTE elfFullName[LF_FULLFACESIZE]; > - BYTE elfStyle[LF_FACESIZE]; > - BYTE elfScript[LF_FACESIZE]; > + CHAR elfFullName[LF_FULLFACESIZE]; > + CHAR elfStyle[LF_FACESIZE]; > + CHAR elfScript[LF_FACESIZE]; > } ENUMLOGFONTEXA,*LPENUMLOGFONTEXA; You can't change that. -- Dmitry.

1 0

Re: ntdll: Add timestamp channel to log output.
by Dmitry Timoshkov 24 Jun '08

24 Jun '08

"Peter Urbanec" <winehq.org(a)urbanec.net> wrote: > @@ -164,8 +166,16 @@ static int NTDLL_dbg_vlog( enum __wine_debug_class cls, struct __wine_debug_chan > /* only print header if we are at the beginning of the line */ > if (info->out_pos == info->output || info->out_pos[-1] == '\n') > { > + /* Prepend a timestamp to each line, if requested. */ > + if (TRACE_ON(timestamps)) > + { > + struct timeval tv; > + if (!gettimeofday(&tv, NULL)) > + ret += wine_dbg_printf( "[%ld.%06ld] ", tv.tv_sec, tv.tv_usec); > + } > + > if (TRACE_ON(tid)) > - ret = wine_dbg_printf( "%04x:", GetCurrentThreadId() ); > + ret += wine_dbg_printf( "%04x:", GetCurrentThreadId() ); > if (cls < sizeof(classes)/sizeof(classes[0])) > ret += wine_dbg_printf( "%s:%s:%s ", classes[cls], channel->name, function ); > } What about using the same indentation style as the existing code does? -- Dmitry.

1 0

sorry forgot to cut and paste some code =)
by celticht32＠aol.com 24 Jun '08

24 Jun '08

the code is in : wine-1.0/dlls/wined3d/context.c here is the changed code : /* This function takes care of WineD3D pixel format selection. */ static int WineD3D_ChoosePixelFormat(IWineD3DDeviceImpl *This, HDC hdc, WINED3DFORMAT ColorFormat, WINED3DFORMAT DepthStencilFormat, BOOL auxBuffers, int numSamples, BOOL pbuffer, BOOL findCompatible) { ??? int iPixelFormat=0; ??? short redBits, greenBits, blueBits, alphaBits, colorBits; ??? short depthBits=0, stencilBits=0; ??? int i = 0; ??? int nCfgs = This->adapter->nCfgs; ??? WineD3D_PixelFormat *cfgs = This->adapter->cfgs; ??? BOOL exactDepthMatch = FALSE;? /*Changed june 23,08 */?? ??? PIXELFORMATDESCRIPTOR pfd;???? /*Changed june 23,08 */ ??? TRACE("ColorFormat=%s, DepthStencilFormat=%s, auxBuffers=%d, numSamples=%d, pbuffer=%d, findCompatible=%d\n", ????????? debug_d3dformat(ColorFormat), debug_d3dformat(DepthStencilFormat), auxBuffers, numSamples, pbuffer, findCompatible); ??? if (!getColorBits(ColorFormat, &redBits, &greenBits, &blueBits, &alphaBits, &colorBits)) ???? { ??????? ERR("Unable to get color bits for format %s (%#x)!\n", debug_d3dformat(ColorFormat), ColorFormat); ??????? return 0; ??? } ??? /* In WGL both color, depth and stencil are features of a pixel format. In case of D3D they are separate. ???? * You are able to add a depth + stencil surface at a later stage when you need it. ???? * In order to support this properly in WineD3D we need the ability to recreate the opengl context and ???? * drawable when this is required. This is very tricky as we need to reapply ALL opengl states for the new ???? * context, need torecreate shaders, textures and other resources. ???? * ???? * The context manager already takes care of the state problem and for the other tasks code from Reset ???? * can be used. These changes are way to risky during the 1.0 code freeze which is taking place right now. ???? * Likely a lot of other new bugs will be exposed. For that reason request a depth stencil surface all the ???? * time. It can cause a slight performance hit but fixes a lot of regressions. A fixme reminds of that this ???? * issue needs to be fixed. */ ??? if (DepthStencilFormat != WINED3DFMT_D24S8) ??????? FIXME("Add OpenGL context recreation support to SetDepthStencilSurface\n"); ??? DepthStencilFormat = WINED3DFMT_D24S8; /* Changed Section June 24,08 */ /*??? if(DepthStencilFormat) {???????????????????? Changed June 19,08*/ ??? getDepthStencilBits(DepthStencilFormat, &depthBits, &stencilBits); /*??? }?? This if will always be true because of the above? so just call getDepthStencilBits */ ??? /* Find a pixel format which EXACTLY matches our requirements (except for depth) */ ??? for(i=0; i<nCfgs; i++) ????? { ??????? cfgs = &This->adapter->cfgs[i]; ??????????????????? ??????? /* For now only accept RGBA formats. Perhaps some day we will ???????? * allow floating point formats for pbuffers. */ ??????? if (cfgs->iPixelType != WGL_TYPE_RGBA_ARB) ?????????? continue; ??????? /* In window mode (!pbuffer) we need a window drawable format and double buffering. */ ??????? if (!pbuffer && !(cfgs->windowDrawable && cfgs->doubleBuffer)) ?????????? continue; ?????? /* We like to have aux buffers in backbuffer mode */ ??????? if (auxBuffers && !cfgs->auxBuffers) ?????????? continue; ??????? /* In pbuffer-mode we need a pbuffer-capable format but we don't want double buffering */ ??????? if (pbuffer && (!cfgs->pbufferDrawable || cfgs->doubleBuffer)) ???????????? continue; /* This is faster and more efficient code wise since they are all related so evaluate them together Changed June 19,08 */ ??????? if ((cfgs->redSize != redBits) || (cfgs->greenSize != greenBits) || (cfgs->blueSize != blueBits) || (cfgs->alphaSize != alphaBits)) ???????????? continue; ??????? /* In all cases make sure the number of stencil bits matches our requirements ???????? * even when we don't need stencil because it could affect performance EXCEPT ???????? * on cards which don't offer depth formats without stencil like the i915 drivers ???????? * on Linux. */ ??????? if ((stencilBits != cfgs->stencilSize) && !((This->adapter->brokenStencil && stencilBits) <= cfgs->stencilSize)) ???????????? continue; ??????? /* Check multisampling support */ ??????? if (cfgs->numSamples != numSamples) ???????????? continue; ??????? /* We try to locate a format which matches our requirements exactly. In case of ???????? * depth it is no problem to emulate 16-bit using e.g. 24-bit, so accept that. */ ???????? if (cfgs->depthSize !=? depthBits)? /* Changed June 24,08 */ ??????????? continue; ??????? /* Exit the loop as we have found a format :) */ ??????? if (exactDepthMatch) ?????????? { ??????????? TRACE("Exact Depth Match\n"); ??????????? iPixelFormat = cfgs->iPixelFormat; ??????????? break; ?????????? } ??????? if (!iPixelFormat) ????????? { ??????????? /* In the end we might end up with a format which doesn't exactly match our depth ???????????? * requirements. Accept the first format we found because formats with higher iPixelFormat ???????????? * values tend to have more extended capabilities (e.g. multisampling) which we don't need. */ ??????????? TRACE("Emulating %d\n",cfgs->iPixelFormat); ??????????? iPixelFormat = cfgs->iPixelFormat; ??????????? break; /* Added June 24,08 */ ????????? } ??? } ??? /* When findCompatible is set and no suitable format was found, let ChoosePixelFormat choose a pixel format in order not to crash. */ /*??? if (!iPixelFormat && !findCompatible) ????? { ??????? ERR("Can't find a suitable iPixelFormat\n"); ??????? return FALSE; ????? } Remarked this out. Yes it will cycle through the 3 adapters (I am running dual head and for some reason it thinks I have 3 adapters not just the 2 for dual head) Why would findCompatible not be set for all adapters? this is what the DX 9c specs? say it should do then the application picks the best of all */ ????? ??? if (!iPixelFormat) ????? { ??????? TRACE("iPixelFormat = %d FindCompatible=%d\n",iPixelFormat, findCompatible); ??????? TRACE("Falling back to ChoosePixelFormat as we weren't able to find an exactly matching pixel format\n"); ??????? /* PixelFormat selection */ ??????? ZeroMemory(&pfd, sizeof(pfd)); ??????? pfd.nSize?????????? = sizeof(pfd); ??????? pfd.nVersion????? = 1; /* Should this be hard Coded or put into a #DEFINE so it can be changed later if needed */ ??????? pfd.dwFlags????? = PFD_SUPPORT_OPENGL | PFD_DOUBLEBUFFER | PFD_DRAW_TO_WINDOW;/*PFD_GENERIC_ACCELERATED*/ ??????? pfd.iPixelType?? = PFD_TYPE_RGBA; ??????? pfd.cAlphaBits?? = alphaBits; ??????? pfd.cColorBits??? = colorBits; ??????? pfd.cDepthBits?? = depthBits; ??????? pfd.cStencilBits? = stencilBits; ??????? pfd.iLayerType? = PFD_MAIN_PLANE; ??????? iPixelFormat????? = ChoosePixelFormat(hdc, &pfd); ??????? if (!iPixelFormat) ????????? { ??????????? /* If this happens something is very wrong as ChoosePixelFormat barely fails */ ?????????? ERR("Can't find a suitable iPixelFormat\n"); ?????????? return FALSE; ????????? } ????? } ??? TRACE("Found iPixelFormat\n"); ??? return iPixelFormat; } Chris

2 1

Code Review and findings in d3d while working on figuring out why...
by celticht32＠aol.com 24 Jun '08

24 Jun '08

Ok I have been wandering around the code in context.c and have found a few things that I have opened a bug on (14000) but in further looking in context.c if I comment out the lines between 237 and 245 wine seems to continue working better infact? (I no longer get no iPixel errors using wine 1.0 with the latest ATI drivers) My question is this why wouldn't you want to find a compatible mode to use and just call the next few lines where it calls choose pixel format and if that fails for what ever reason then say you cant find a suitable iPixel format? If you leave the section there the following occurs. Start up EverQuest2.exe? it calls the iPixel function 3 times for some reason without the fix in bug 14000 it fails immediately. With the fix the first one succeeds then the second and third times it returns the no iPixel format to the application. If I comment out the above section it no longer fails at all but gets farther along. before throwing an unhandled exception (which happened before I started working with this problem ) which is documented in another bug (forget the number right now). Chris p.s. if needed I can post my context.c on the bug above or to the mailing list.. .just the function I have been working on....

2 1

Re: quartz: Have thread safety in memallocator
by Rob Shearman 24 Jun '08

24 Jun '08

2008/6/23 Maarten Lankhorst <m.b.lankhorst(a)gmail.com>: > @@ -286,19 +287,24 @@ static HRESULT WINAPI BaseMemAllocator_GetBuffer(IMemAllocator * iface, IMediaSa > > *pSample = NULL; > > - if (!This->bCommitted) > - return VFW_E_NOT_COMMITTED; > + EnterCriticalSection(This->pCritSect); > + if (!This->bCommitted || This->bDecommitQueued) > + hr = VFW_E_NOT_COMMITTED; > + else > + ++This->lWaiting; > + LeaveCriticalSection(This->pCritSect); > + if (FAILED(hr)) > + return hr; > > - This->lWaiting++; > if (WaitForSingleObject(This->hSemWaiting, (dwFlags & AM_GBF_NOWAIT) ? 0 : INFINITE) != WAIT_OBJECT_0) > { > - This->lWaiting--; > + InterlockedDecrement(&This->lWaiting); > return VFW_E_TIMEOUT; > } > - This->lWaiting--; > > EnterCriticalSection(This->pCritSect); > { > + --This->lWaiting; > if (!This->bCommitted) > hr = VFW_E_NOT_COMMITTED; > else if (This->bDecommitQueued) Just because you increment a variable inside a critical section, it doesn't mean that it's safe against another thread using InterlockedIncrement/Decrement on it. Either only change the variable inside a critical section or only change it using interlocked functions. -- Rob Shearman

1 0

new failing tests
by James Hawkins 24 Jun '08

24 Jun '08

Hi Alex, The following commit introduces several windows test failures across the board in riched20: commit 0e9ed5c10e3ac6b253712037f0b30046a5656239 Author: Alex Villacís Lasso <a_villacis(a)palosanto.com> Date: Sun May 11 09:54:58 2008 -0500 richedit: Empty text should result in a scroll range of 0. Tests for this behavior. Please take a look at the test results and either fix the tests or send in a patch to remove them. http://test.winehq.org Thanks, James Hawkins

2 3

Re: ntdll: Add time stamps to log output.
by Dmitry Timoshkov 24 Jun '08

24 Jun '08

"Peter Urbanec" <winehq.org(a)urbanec.net> wrote: > This patch will prefix every line of log output with a time stamp. > > The time stamps are formatted as [seconds.microseconds] and measured as > elapsed time from the first time a message is output. This helps with > tracking down time sensitive bugs and it may also come in handy when > investigating performance. At the very least this should be a separate debug channel, if it ever gets included at all. -- Dmitry.

2 1

Re: [resend] gdi32/tests: Add tests for GdiGetCodePage.
by Dmitry Timoshkov 24 Jun '08

24 Jun '08

"Huang, Zhangrong" <hzhrong(a)gmail.com> wrote: > As discussed in Bug 4065 (http://bugs.winehq.org/show_bug.cgi?id=4065) In the bug 4065 I suggested to comment out the failing tests before sending it to wine-patches. -- Dmitry.

2 5