September 2006 - Wine-devel

Re: riched20: move some selection code from message handler to ME_SetSelection
by Alexandre Julliard 13 Sep '06

13 Sep '06

"Matt Finnicum" <mattfinn(a)gmail.com> writes: > The special cases handled by EM_EXSETSEL should also be handled by > EM_SETSEL, so this patch moves that code into the common > ME_SetSelection function. Before this patch, sending EM_SETSEL with > any value less than -1 would crash richedit. > > Changelog: move some selection code from message handlers to ME_SetSelection This fails make test: ../../../tools/runtest -q -P wine -M riched20.dll -T ../../.. -p riched20_test.exe.so editor.c && touch editor.ok editor.c:1335: Test failed: EM_EXSETSEL: expected: 18 actual: 17 make: *** [editor.ok] Error 1 -- Alexandre Julliard julliard(a)winehq.org

1 0

[PATCH] Also show 24bit modes as supported, but still handle them like 32bit later
by Christoph Frick 13 Sep '06

13 Sep '06

hi would someone please comment on that patch? this is a nearly unchanged version of my previous attempt - but this time against current git. --- dlls/winex11.drv/settings.c | 9 ++++----- 1 files changed, 4 insertions(+), 5 deletions(-) diff --git a/dlls/winex11.drv/settings.c b/dlls/winex11.drv/settings.c index 5de07eb..c9bced2 100644 --- a/dlls/winex11.drv/settings.c +++ b/dlls/winex11.drv/settings.c @@ -39,7 +39,8 @@ static LPDDHALMODEINFO dd_modes = NULL; static unsigned int dd_mode_count = 0; static unsigned int dd_max_modes = 0; static int dd_mode_default = 0; -static const unsigned int depths[] = {8, 16, 32}; +static const unsigned int depths[] = {8, 16, 32, 24}; +static const unsigned int nr_depths = sizeof(depths) / sizeof(depths[0]); /* pointers to functions that actually do the hard stuff */ static int (*pGetCurrentMode)(void); @@ -62,7 +63,7 @@ LPDDHALMODEINFO X11DRV_Settings_SetHandl TRACE("Resolution settings now handled by: %s\n", name); if (reserve_depths) /* leave room for other depths */ - dd_max_modes = (3+1)*(nmodes); + dd_max_modes = nr_depths*nmodes; else dd_max_modes = nmodes; @@ -111,7 +112,7 @@ void X11DRV_Settings_AddDepthModes(void) int existing_modes = dd_mode_count; DWORD dwBpp = screen_depth; if (dwBpp == 24) dwBpp = 32; - for (j=0; j<3; j++) + for (j=0; j<nr_depths; j++) { if (depths[j] != dwBpp) { @@ -164,8 +165,6 @@ void X11DRV_Settings_Init(void) */ BOOL X11DRV_EnumDisplaySettingsEx( LPCWSTR name, DWORD n, LPDEVMODEW devmode, DWORD flags) { - DWORD dwBpp = screen_depth; - if (dwBpp == 24) dwBpp = 32; devmode->dmDisplayFlags = 0; devmode->dmDisplayFrequency = 0; devmode->dmSize = sizeof(DEVMODEW); -- 1.4.2

1 0

question about storage32.c code and while loop
by EA Durbin 13 Sep '06

13 Sep '06

I've mentioned this before but I'm no expert C programmer. Can someone explain why we do the following in storage32.c? if (cbRead > 0) { cbTotalRead += cbRead; resWrite = BlockChainStream_WriteAt(bbTempChain, offset, cbRead, buffer, &cbWritten); if (FAILED(resWrite)) break; cbTotalWritten += cbWritten; offset.u.LowPart += This->smallBlockSize; } } while (cbRead > 0); HeapFree(GetProcessHeap(),0,buffer); if (FAILED(resRead) || FAILED(resWrite)) { ERR("conversion failed: resRead = 0x%08lx, resWrite = 0x%08lx\n", resRead, resWrite); BlockChainStream_Destroy(bbTempChain); return NULL; } in the while loop above while (cbRead > 0); it appears it terminates without doing anything due to the semicolon, is this intentional or is this semicolon not supposed to be there and its supposed to execute the line below it? If it is intentional why is the empty while loop here?

1 1

wine complation fails with latest git
by EA Durbin 13 Sep '06

13 Sep '06

I'm not able to compile wine with the latest source from git. gcc-3.4 -c -I. -I. -I../../include -I../../include -Wall -pipe -fno-strict-aliasing -gstabs+ -Wdeclaration-after-statement -Wwrite-strings -Wpointer-arith -g -O2 -o parser.yy.o parser.yy.c parser.l: In function `parser_lex': parser.l:129: error: `parser_lval' undeclared (first use in this function) parser.l:129: error: (Each undeclared identifier is reported only once parser.l:129: error: for each function it appears in.) parser.l: In function `kw_token': parser.l:342: error: `parser_lval' undeclared (first use in this function) make[2]: *** [parser.yy.o] Error 1 make[2]: Leaving directory `/home/eric/wine/tools/widl' make[1]: *** [widl] Error 2 make[1]: Leaving directory `/home/eric/wine/tools' make: *** [tools] Error 2

2 2

Help with git
by Kapila De Silva 13 Sep '06

13 Sep '06

Hi all, Hope this is the right place to post this, if not, my apologies. Im trying to track down an issue that occurred between 0.9.19 and 0.9.20, and am using git bisect to track the issue. In the process of trying to identify the cause of the issue, I would like to be able to get the code up till a certain patch, and then apply patches one by one as well. I have not been able to find out how to do this, despite several web searches and man pages. Can anyone give me any pointers to this please? Thanks in advance Kapila

3 2

State management in D3D
by Ivan Gyurdiev 12 Sep '06

12 Sep '06

State management in D3D... is currently kind of a mess. Stefan D. posted a message about this some time ago, but I can't find it right now... - some states are applied immediately (via Set* calls) - some are applied at draw time (like shaders, textures, transforms, ...) - some are recorded into a stateblock structure, and applied when the app says apply(). - the GL code is all over the place, tightly coupled to the d3d code. =============================== There's a number of projects going on at the moment, from what I understand: - Roderick is working on making wined3d -> wgl - Stefan D. has expressed concern about multithreaded d3d (where the D3D device state is shared, but not necessarily the GL one - or can GL contexts be shared between multiple threads?) - I'm trying to get FBOs to work, where the FBO needs to be bound once both the render and stencil target have been assigned (that's 2 calls from the app in any order) - i.e I need those states to be applied in a delayed fashion, before draw - Henri Verbeet wants multiple render target support added to that (meaning the FBO needs to be bound once *all* render targets are assigned in addition to the depth/stencil one). ================================ All of the above have a common theme - better state management is needed, with more encapsulation, and better separation between D3D and GL. So, let's come up with a plan, and try to implement it. How about we redesign the stateblock object like this: - remove deltas. I.E. if a SetLightEnable() command is sent, fetch the light, enable it, then save the light back - store only state, and no deltas. This should make the recording stateblock (updateStateBlock) the same as the initial device stateblock, which stores states - provide a uniform internal interface for accessing states inside the stateblock - like: SetState(stateblock, ID_XYZ, (void*) state_data); GetState(stateblock, ID_XYZ, (void**) state_data); CaptureState(stateblock, ID_XYZ); ApplyState(stateblock, ID_XYZ); ID_XYZ could be an individual state, or a "trigger" keyword, which will refer to a whole group of states. Those would be private functions in addition to the standard interface. - provide a fn pointer table inside the stateblock [ which can be directed to OGL or WGL or AGL ], which, for each ID_XYZ, maps a get and set function using the same interface - move all device.c GL code into those functions - now all device.c Get* and Set* requests will do is: - error checking - recording into updateStateBlock - or writing to stateBlock (which may be applied later, at our discretion). - apply() would just loop through all the IDs and call the corresponding function pointer if the states are marked dirty (we'll keep the 'dirty' field) - capture() would do the same in the get* direction. - new object can be instantiated per device, or per device per thread to address multithreading. It could have an associated glContext, and can be locked as necessary. - it would use ideas from the d3d9 test framework for stateblock, except of course more competently written, and cleaner :)

3 12

Help with shader code
by Kapila De Silva 12 Sep '06

12 Sep '06

Hi All, can someone help me understand some code from dlls/wined3d/vertexshader.c please? Im new to shader code, but to me the following looks a bit strange: shader_addline(&buffer, "ADD result.position.x, TMP_OUT.x, PROJECTIONX.w;\n"); shader_addline(&buffer, "ADD result.position.y, TMP_OUT.y, PROJECTIONY.w;\n"); /* Account for any inverted textures (render to texture case) by reversing the y coordinate * (this is handled in drawPrim() when it sets the MODELVIEW and PROJECTION matrices) */ shader_addline(&buffer, "MUL result.position.y, TMP_OUT.y, PROJECTIONY.y;\n"); Am I correct that the last line makes the second line redundant? Wont result.position.y be equal to TMP_OUT.y * PROJECTIONY.y no matter what? Thanks in advance. Kapila.

2 2

Re: comctl32: Remove dead code in tooltips.c (coverity)
by Alexandre Julliard 12 Sep '06

12 Sep '06

Detlef Riekenberg <wine.dev(a)web.de> writes: > We return with FALSE at the top of the Function, > when lpToolInfo is NULL. I think that's where the real bug is, we shouldn't always return FALSE in that case. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: X11Drv: move WGL extension code
by Lionel Ulmer 12 Sep '06

12 Sep '06

On Fri, Sep 01, 2006 at 01:57:24PM +0200, Roderick Colenbrander wrote: > The way WGL extensions are loaded is different. The old code correctly > advertised the names of available WGL extensions but the wglGetProcAddress > code didn't work correctly. Even if an extension wasn't advertised you could > get a function pointer to the functions. On Windows wglGetProcAddress would > return NULL. Note that (as far as I know), 'wglGetProcAddress' returns NULL on non-existant extensions for all extensions, whether they are GL or WGL ones. This means that our implementation of it is broken (at least on DRI / Mesa) as 'glXGetProcAddress' may return a non-NULL value when querying a non-supported extension. So if we really want to be windows-like, we would need to add a 'function name / extension name' database and check if the extension corresponding to the function is present before actually calling 'glXGetProcAddress'. But as I ever only once got a bug report linked to that, I never took the pain to fix it :-) Lionel (catching up his old mails) PS: I guess that this 'database' may be automatically build by the 'make_opengl' script though so it should not be that hard to do :-) -- Lionel Ulmer - http://www.bbrox.org/

1 0

Storage32 error
by EA Durbin 12 Sep '06

12 Sep '06

I've been experiencing an error in several installers and it just appeared lately in installers that used to succeed, such as the battlefield 2 demo installer, this error is causing them to fail. Was this caused by a recent patch? err:storage:Storage32Impl_SmallBlocksToBigBlocks conversion failed: resRead = 0x8003001e, resWrite = 0x00000000 err:storage:Storage32Impl_SmallBlocksToBigBlocks conversion failed: resRead = 0x8003001e, resWrite = 0x00000000 err:storage:Storage32Impl_SmallBlocksToBigBlocks conversion failed: resRead = 0x8003001e, resWrite = 0x00000000

1 0