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

Wine with multiple threads on Dual processor - any suggestions please
by Ananth M 08 Feb '06

08 Feb '06

Hi, I am having an application with the processing can be done paralally using multiple threads. If I compile (with one thread ) and execute this application in Linux , on a Dual processor machine , I am getting execution time ~600 sec. If I compile ( with 2 threads ), and execute this application in Linux on a Dual processor machine , I am getting execution time ~300 sec. If I compile the same program (with One thread) using wineg++ and execute the program ,I am getting execution time as ~500 sec If I compile the same program ( with 2 threads ) using wineg++ and execute the program , I am getting the same execution time ~500 sec. Is there any isses with wine on Dual processor machines ( Intel Xeon processor ) w.r.t multi threaded programming? Does any one got this type of problem ? Any suggestions please.... Thank you, Regards Ajay

1 0

Re: VC++ demangling tool
by Eric Pouech 08 Feb '06

08 Feb '06

Michael Stefaniuc wrote: > Hello! > > winedump has a VC++ symbol demangling function but that is bitrotting as > it is a copy of the msvcrt.__unDname . As i wanted to use the newer > msvcrt.__unDname funtion i have written a quick and dirty program that > is basicaly only a wrapper around UnDecorateSymbolName(). Most importand > feature is that it runs on the command line. > I'm not expecting it to go into Wine but others might find it usefull. > After applying the patch configure needs to be regenerated. actually, there's a tool in the MS SDK called undname that does exactly this... it has also a couple of other options (like demangling all symbols listed in a text file)... but what should be done is to port back the code from msvcrt into winedump A+ -- Eric Pouech

6 8

Re: Add missing LANG_xxx and SUBLANG_xxx macros
by Alexandre Julliard 08 Feb '06

08 Feb '06

Francois Gouget <fgouget(a)free.fr> writes: > On Tue, 7 Feb 2006, Huw D M Davies wrote: > [...] >> Why is WELSH in between TIBETAN and TIGRIGNA ? > > No idea. Must be a bug in the sort algorithm ;-) > Here's a corrected patch. ... > +#define LANG_YORUBA 0x6a > +#define LANG_WELSH 0x52 > +#define LANG_ZULU 0x35 The sort algorithm still needs some work ;-) On a more serious note, you'll need to fix the registry entries in wine.inf, otherwise the tests fail. -- Alexandre Julliard julliard(a)winehq.org

1 0

[dinput] dynamic handling of buttons of a device
by Christoph Frick 08 Feb '06

08 Feb '06

attempt #2: this patch detects and maps the buttons dynamically instead of the hardcoded way it was before. this fixes the problems with devices, that report events in the joystick _and_ gamepad range of button events License: LGPL ChangeLog: 2006-02-08 Christoph Frick <rid(a)zefix.tv> - dlls/dinput/joystick_linuxinput.c dynamic assignment of buttons on a device -- cu Index: dlls/dinput/joystick_linuxinput.c =================================================================== RCS file: /home/wine/wine/dlls/dinput/joystick_linuxinput.c,v retrieving revision 1.35 diff -u -r1.35 joystick_linuxinput.c --- dlls/dinput/joystick_linuxinput.c 23 Nov 2005 19:29:19 -0000 1.35 +++ dlls/dinput/joystick_linuxinput.c 8 Feb 2006 12:22:53 -0000 @@ -120,7 +120,9 @@ int ff_state; /* data returned by the EVIOCGABS() ioctl */ - int axes[ABS_MAX+1][5]; + int axes[ABS_MAX][5]; + /* LUT for KEY_ to offset in rgbButtons */ + BYTE buttons[KEY_MAX]; #define AXE_ABS 0 #define AXE_ABSMIN 1 @@ -457,7 +459,7 @@ */ static HRESULT WINAPI JoystickAImpl_Acquire(LPDIRECTINPUTDEVICE8A iface) { - int i; + int i,buttons; JoystickImpl *This = (JoystickImpl *)iface; char buf[200]; BOOL readonly = TRUE; @@ -529,7 +531,7 @@ if (test_bit(This->absbits,i)) { if (-1==ioctl(This->joyfd,EVIOCGABS(i),&(This->axes[i]))) continue; - FIXME("axe %d: cur=%d, min=%d, max=%d, fuzz=%d, flat=%d\n", + TRACE("axe %d: cur=%d, min=%d, max=%d, fuzz=%d, flat=%d\n", i, This->axes[i][AXE_ABS], This->axes[i][AXE_ABSMIN], @@ -541,7 +543,14 @@ This->havemax[i] = This->axes[i][AXE_ABSMAX]; } } - MESSAGE("\n"); + buttons = 0; + for (i=0;i<KEY_MAX;i++) { + if (test_bit(This->keybits,i)) { + TRACE("button %d: %d\n", i, buttons); + This->buttons[i] = 0x80 | buttons; + buttons++; + } + } fake_current_js_state(This); @@ -661,6 +670,7 @@ struct timeval tv; fd_set readfds; struct input_event ie; + int btn; if (This->joyfd==-1) return; @@ -680,76 +690,14 @@ TRACE("input_event: type %d, code %d, value %d\n",ie.type,ie.code,ie.value); switch (ie.type) { case EV_KEY: /* button */ - switch (ie.code) { - case BTN_TRIGGER: /* normal flight stick */ - case BTN_A: /* gamepad */ - case BTN_1: /* generic */ - This->js.rgbButtons[0] = ie.value?0x80:0x00; - GEN_EVENT(DIJOFS_BUTTON(0),ie.value?0x80:0x0,ie.time.tv_usec,(This->dinput->evsequence)++); - break; - case BTN_THUMB: - case BTN_B: - case BTN_2: - This->js.rgbButtons[1] = ie.value?0x80:0x00; - GEN_EVENT(DIJOFS_BUTTON(1),ie.value?0x80:0x0,ie.time.tv_usec,(This->dinput->evsequence)++); - break; - case BTN_THUMB2: - case BTN_C: - case BTN_3: - This->js.rgbButtons[2] = ie.value?0x80:0x00; - GEN_EVENT(DIJOFS_BUTTON(2),ie.value?0x80:0x0,ie.time.tv_usec,(This->dinput->evsequence)++); - break; - case BTN_TOP: - case BTN_X: - case BTN_4: - This->js.rgbButtons[3] = ie.value?0x80:0x00; - GEN_EVENT(DIJOFS_BUTTON(3),ie.value?0x80:0x0,ie.time.tv_usec,(This->dinput->evsequence)++); - break; - case BTN_TOP2: - case BTN_Y: - case BTN_5: - This->js.rgbButtons[4] = ie.value?0x80:0x00; - GEN_EVENT(DIJOFS_BUTTON(4),ie.value?0x80:0x0,ie.time.tv_usec,(This->dinput->evsequence)++); - break; - case BTN_PINKIE: - case BTN_Z: - case BTN_6: - This->js.rgbButtons[5] = ie.value?0x80:0x00; - GEN_EVENT(DIJOFS_BUTTON(5),ie.value?0x80:0x0,ie.time.tv_usec,(This->dinput->evsequence)++); + btn = This->buttons[ie.code]; + TRACE("(%p) %d -> %d\n", This, ie.code, btn); + if (btn&0x80) { + btn &= 0x7F; + This->js.rgbButtons[btn] = ie.value?0x80:0x00; + GEN_EVENT(DIJOFS_BUTTON(btn),ie.value?0x80:0x0,ie.time.tv_usec,(This->dinput->evsequence)++); + } break; - case BTN_BASE: - case BTN_TL: - case BTN_7: - This->js.rgbButtons[6] = ie.value?0x80:0x00; - GEN_EVENT(DIJOFS_BUTTON(6),ie.value?0x80:0x0,ie.time.tv_usec,(This->dinput->evsequence)++); - break; - case BTN_BASE2: - case BTN_TR: - case BTN_8: - This->js.rgbButtons[7] = ie.value?0x80:0x00; - GEN_EVENT(DIJOFS_BUTTON(7),ie.value?0x80:0x0,ie.time.tv_usec,(This->dinput->evsequence)++); - break; - case BTN_BASE3: - case BTN_TL2: - case BTN_9: - This->js.rgbButtons[8] = ie.value?0x80:0x00; - GEN_EVENT(DIJOFS_BUTTON(8),ie.value?0x80:0x0,ie.time.tv_usec,(This->dinput->evsequence)++); - break; - case BTN_BASE4: - case BTN_TR2: - This->js.rgbButtons[9] = ie.value?0x80:0x00; - GEN_EVENT(DIJOFS_BUTTON(9),ie.value?0x80:0x0,ie.time.tv_usec,(This->dinput->evsequence)++); - break; - case BTN_BASE5: - case BTN_SELECT: - This->js.rgbButtons[10] = ie.value?0x80:0x00; - GEN_EVENT(DIJOFS_BUTTON(10),ie.value?0x80:0x0,ie.time.tv_usec,(This->dinput->evsequence)++); - break; - default: - FIXME("unhandled joystick button %x, value %d\n",ie.code,ie.value); - break; - } - break; case EV_ABS: switch (ie.code) { case ABS_X: @@ -794,6 +742,9 @@ This->ff_state = ie.value; break; #endif + case EV_SYN: + /* there is nothing to do */ + break; default: FIXME("joystick cannot handle type %d event (code %d)\n",ie.type,ie.code); break; @@ -1141,7 +1092,7 @@ if ((dwFlags == DIDFT_ALL) || (dwFlags & DIDFT_BUTTON)) { - int i; + int i, btncount=0; /*The DInput SDK says that GUID_Button is only for mouse buttons but well*/ @@ -1149,74 +1100,10 @@ for (i = 0; i < KEY_MAX; i++) { if (!test_bit(This->keybits,i)) continue; - - switch (i) { - case BTN_TRIGGER: - case BTN_A: - case BTN_1: - ddoi.dwOfs = DIJOFS_BUTTON(0); - ddoi.dwType = DIDFT_MAKEINSTANCE((0x0001 << 0) << WINE_JOYSTICK_BUTTON_BASE) | DIDFT_PSHBUTTON; - break; - case BTN_THUMB: - case BTN_B: - case BTN_2: - ddoi.dwOfs = DIJOFS_BUTTON(1); - ddoi.dwType = DIDFT_MAKEINSTANCE((0x0001 << 1) << WINE_JOYSTICK_BUTTON_BASE) | DIDFT_PSHBUTTON; - break; - case BTN_THUMB2: - case BTN_C: - case BTN_3: - ddoi.dwOfs = DIJOFS_BUTTON(2); - ddoi.dwType = DIDFT_MAKEINSTANCE((0x0001 << 2) << WINE_JOYSTICK_BUTTON_BASE) | DIDFT_PSHBUTTON; - break; - case BTN_TOP: - case BTN_X: - case BTN_4: - ddoi.dwOfs = DIJOFS_BUTTON(3); - ddoi.dwType = DIDFT_MAKEINSTANCE((0x0001 << 3) << WINE_JOYSTICK_BUTTON_BASE) | DIDFT_PSHBUTTON; - break; - case BTN_TOP2: - case BTN_Y: - case BTN_5: - ddoi.dwOfs = DIJOFS_BUTTON(4); - ddoi.dwType = DIDFT_MAKEINSTANCE((0x0001 << 4) << WINE_JOYSTICK_BUTTON_BASE) | DIDFT_PSHBUTTON; - break; - case BTN_PINKIE: - case BTN_Z: - case BTN_6: - ddoi.dwOfs = DIJOFS_BUTTON(5); - ddoi.dwType = DIDFT_MAKEINSTANCE((0x0001 << 5) << WINE_JOYSTICK_BUTTON_BASE) | DIDFT_PSHBUTTON; - break; - case BTN_BASE: - case BTN_TL: - case BTN_7: - ddoi.dwOfs = DIJOFS_BUTTON(6); - ddoi.dwType = DIDFT_MAKEINSTANCE((0x0001 << 6) << WINE_JOYSTICK_BUTTON_BASE) | DIDFT_PSHBUTTON; - break; - case BTN_BASE2: - case BTN_TR: - case BTN_8: - ddoi.dwOfs = DIJOFS_BUTTON(7); - ddoi.dwType = DIDFT_MAKEINSTANCE((0x0001 << 7) << WINE_JOYSTICK_BUTTON_BASE) | DIDFT_PSHBUTTON; - break; - case BTN_BASE3: - case BTN_TL2: - case BTN_9: - ddoi.dwOfs = DIJOFS_BUTTON(8); - ddoi.dwType = DIDFT_MAKEINSTANCE((0x0001 << 8) << WINE_JOYSTICK_BUTTON_BASE) | DIDFT_PSHBUTTON; - break; - case BTN_BASE4: - case BTN_TR2: - ddoi.dwOfs = DIJOFS_BUTTON(9); - ddoi.dwType = DIDFT_MAKEINSTANCE((0x0001 << 9) << WINE_JOYSTICK_BUTTON_BASE) | DIDFT_PSHBUTTON; - break; - case BTN_BASE5: - case BTN_SELECT: - ddoi.dwOfs = DIJOFS_BUTTON(10); - ddoi.dwType = DIDFT_MAKEINSTANCE((0x0001 << 10) << WINE_JOYSTICK_BUTTON_BASE) | DIDFT_PSHBUTTON; - break; - } - sprintf(ddoi.tszName, "%d-Button", i); + ddoi.dwOfs = DIJOFS_BUTTON(btncount); + ddoi.dwType = DIDFT_MAKEINSTANCE(btncount << WINE_JOYSTICK_BUTTON_BASE) | DIDFT_PSHBUTTON; + sprintf(ddoi.tszName, "%d-Button", btncount); + btncount++; _dump_OBJECTINSTANCEA(&ddoi); if (lpCallback(&ddoi, lpvRef) != DIENUM_CONTINUE) { /* return to unaquired state if that's where we were */

1 0

[wined3d] better warn/fixme for query handling
by Christoph Frick 08 Feb '06

08 Feb '06

hiho, this is one of three patches i still have in my cvs-tree that are not supplied. like the following i tired to submit several times - except for this one i never got a feedback, whats wrong. Licence: LGPL ChangeLog: 2006-02-08 Christoph Frick <rid(a)zefix.tv> - dlls/wined3d/device.c more granular handling of errors for queries -- cu Index: dlls/wined3d/device.c =================================================================== RCS file: /home/wine/wine/dlls/wined3d/device.c,v retrieving revision 1.125 diff -u -r1.125 device.c --- dlls/wined3d/device.c 7 Feb 2006 16:02:51 -0000 1.125 +++ dlls/wined3d/device.c 8 Feb 2006 12:23:00 -0000 @@ -1095,8 +1095,14 @@ if (NULL == ppQuery) { /* Just a check to see if we support this type of query */ HRESULT hr = D3DERR_NOTAVAILABLE; - /* Lie and say everything is good (we can return ok fake data from a stub) */ switch(Type) { + case WINED3DQUERYTYPE_OCCLUSION: + TRACE("(%p) occlusion query\n", This); + if (GL_SUPPORT(ARB_OCCLUSION_QUERY) || GL_SUPPORT(NV_OCCLUSION_QUERY)) + hr = D3D_OK; + else + WARN("Unsupported in local OpenGL implementation: ARB_OCCLUSION_QUERY/NV_OCCLUSION_QUERY\n"); + break; case WINED3DQUERYTYPE_VCACHE: case WINED3DQUERYTYPE_RESOURCEMANAGER: case WINED3DQUERYTYPE_VERTEXSTATS: @@ -1110,16 +1116,11 @@ case WINED3DQUERYTYPE_PIXELTIMINGS: case WINED3DQUERYTYPE_BANDWIDTHTIMINGS: case WINED3DQUERYTYPE_CACHEUTILIZATION: - break; - case WINED3DQUERYTYPE_OCCLUSION: - TRACE("(%p) occlusion query\n", This); - if (GL_SUPPORT(ARB_OCCLUSION_QUERY) || GL_SUPPORT(NV_OCCLUSION_QUERY)) - hr = D3D_OK; - break; + FIXME("(%p) Unsupported query type %d\n", This, Type); + break; default: - FIXME("(%p) Unhandled query type %d\n",This , Type); + FIXME("(%p) Unhandled query type %d\n", This, Type); } - FIXME("(%p) : Stub request for query type %d returned %ld\n", This, Type, hr); return hr; }

1 0

re: riched20 conformance test + find fix [bug 4479]
by Dan Kegel 07 Feb '06

07 Feb '06

Thomas Kho wrote in http://www.winehq.org/pipermail/wine-patches/2006-February/023959.html : > ... fixes bug 4479 (find has a bounds bug). > Additionally, this patch adds a conformance test for rich edit with > tests for EM_FINDTEXT and EM_FINDTEXTEX. Tommy, your haystack[] variable is long and complex. Can you get the same testing out of a shorter sample string? Can you add a comment for each little check, translating it into english? All your tests seem to use the FR_MATCHCASE and FR_DOWN flags, could you also test without those flags a bit more? How sure are you about the bugfix? Are there other places in the source where a similar off-by-one error is made? Otherwise this looks great. - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

1 0

Re: server: allow OpenClipboard to succeed when already open
by Eric Frias 07 Feb '06

07 Feb '06

James Hawkins wrote: > On 2/7/06, Eric Frias <efrias(a)syncad.com> wrote: > >> I think I submitted a version >> of this patch a year or two back, but it wasn't accepted. > > You should add a unit test for this case in Wine's test suite. It > would be pretty easy to write, and it would verify this information, > making your fix more likely to be accepted. Yeah, I didn't write a test on first go-around and I didn't follow up, so I'm not entirely surprised that the patch didn't get accepted. This is the first time I've tried to write a test, and I was pleased to find out that it was easy to do and the documentation on test-writing and compiling was accurate. Eric

1 0

wined3d: CheckDeviceMultiSampleType
by Vitaly Budovski 07 Feb '06

07 Feb '06

Can I have some feedback on the attached patch? I'm not entirely sure it's correct. Thanks, Vitaly diff --git a/dlls/wined3d/directx.c b/dlls/wined3d/directx.c index 7aa8d5d..8394362 100644 --- a/dlls/wined3d/directx.c +++ b/dlls/wined3d/directx.c @@ -1245,6 +1245,13 @@ HRESULT WINAPI IWineD3DImpl_CheckDeviceM BOOL Windowed, D3DMULTISAMPLE_TYPE MultiSampleType, DWORD* pQualityLevels) { IWineD3DImpl *This = (IWineD3DImpl *)iface; + HDC deviceContext; + Display * pDisplay; + GLXFBConfig * pConfig; + int attributeList[5] = {GLX_SAMPLE_BUFFERS_ARB, 1, GLX_SAMPLES_ARB, MultiSampleType, 0}; + int configCount; + int attributeValue; + TRACE_(d3d_caps)("(%p)-> (STUB) (Adptr:%d, DevType:(%x,%s), SurfFmt:(%x,%s), Win?%d, MultiSamp:%x, pQual:%p)\n", This, Adapter, @@ -1267,7 +1274,32 @@ HRESULT WINAPI IWineD3DImpl_CheckDeviceM *pQualityLevels = 1; /* Guess at a value! */ } - if (D3DMULTISAMPLE_NONE == MultiSampleType) return D3D_OK; + if(D3DMULTISAMPLE_NONE == MultiSampleType) return D3D_OK; + + /* Get the display */ + deviceContext = GetDC(0); + pDisplay = get_display(deviceContext); + + ENTER_GL(); + + pConfig = glXChooseFBConfig(pDisplay, 0, attributeList, &configCount); + if(pConfig) { + if(!glXGetFBConfigAttrib(pDisplay, *pConfig, GLX_SAMPLES, &attributeValue)) { + XFree(pConfig); + + LEAVE_GL(); + ReleaseDC(0, deviceContext); + + return D3D_OK; + } + } else { + FIXME("Error retrieving FBConfig\n"); + } + XFree(pConfig); + + LEAVE_GL(); + ReleaseDC(0, deviceContext); + return D3DERR_NOTAVAILABLE; }

2 1

Re: server: allow OpenClipboard to succeed when already open
by James Hawkins 07 Feb '06

07 Feb '06

On 2/7/06, Eric Frias <efrias(a)syncad.com> wrote: > When OpenClipboard is called twice in a row with the same HWND as a > parameter, wine lets the first call succeed, but the second call fails > because the clipboard was already locked. Although it's not specified > in the docs, Windows allows the second call to succeed (and something > deep inside of our app depends on this). I think I submitted a version > of this patch a year or two back, but it wasn't accepted. > You should add a unit test for this case in Wine's test suite. It would be pretty easy to write, and it would verify this information, making your fix more likely to be accepted. -- James Hawkins

3 3

Re: shell32: SHELL32_GetItemAttributes()
by Martin Fuchs 07 Feb '06

07 Feb '06

is there anything wrong with this patch to get Photoshop launching again? On 31.01.2006 22:58:34 Martin Fuchs wrote: > Changelog: > - retrieve file attributes using SHGetPathFromIDListW() when they are not already > present in the internal PIDL structures > - correct documentation which incorrectly claimed not to set any attribute bits

1 0