September 2009 - Wine-Devel

Re: wininet(2/7): Separate loading libssl from loading libcrypto

by Alexandre Julliard

Juan Lang <juan.lang(a)gmail.com> writes: >> There's no reason to invent such complicated locking mechanisms. Just >> put the whole thing inside a critical section and be done with it. > > I already did, in yesterday's patch series. Would you like me to resend? That series is still trying to be too smart for its own good and potentially leaking references. Keep it simple. -- Alexandre Julliard julliard(a)winehq.org

Sept. 30, 2009

Re: [4/5] WineD3D: Add a create flag for addref in GetPrivateData

by Henri Verbeet

2009/9/30 Stefan Dösinger <stefan(a)codeweavers.com>: > This is hard to implement in the client lib - it would require to remove the > AddRef from wined3d altogether, and pass the priv data flags to the client, > and then AddRef in d3d8, d3d9 and dxgi/d3d10. I can't use a Release in ddraw > because we're calling application code here which might break if the app's > AddRef() implementation is broken. Handling the AddRef in d3d8/9/10 is a lot > of work because those libs don't have any IDirect3D*Resource base class that > could do this in a central place. I'm not sure why you'd need an entire baseclass, an utility function (which is how it's done in wined3d!) should do just fine. > +const UINT WINED3DCREATE_GET_PRIV_DATA_NO_ADDREFF = 0x00000004; There should only be a single 'F' in ADDREF.

Sept. 30, 2009

Re: [2/5] WineD3D: Start replacing dxVersion with create flags

by Henri Verbeet

2009/9/30 Stefan Dösinger <stefan(a)codeweavers.com>: > Is there a real reason this (and the flag from the next patch) has to be set on the wined3d object? If there is, I think WINED3D_CREATE_BUFFER_NO_CONVERSION and WINED3D_CREATE_BUFFER_STATIC_FORMAT would be more appropriate names.

Sept. 30, 2009

Re: [comctl32/tests] Fix a test failure on several platforms

by Paul Vriens

On 09/30/2009 02:21 PM, Paul Vriens wrote: > Hi, > > Positioning the point test a bit to the left makes this test succeed on > more boxes. > > (Maybe we should add MCHT_TITLEYEAR to the possible outcomes but I'm not > too sure about that). > > Changelog > Fix a test failure on several platforms > Just checked some other test failures on an XP. This one has more issues but also shows MCHT_TITLEMONTH for the test changed in this patch. Now I'm pretty convinced the fix is not correct, but I stand corrected. -- Cheers, Paul.

Sept. 30, 2009

Re: sti [2/2]: add stubs for the IStillImageW interface

by Alexandre Julliard

Damjan Jovanovic <damjan.jov(a)gmail.com> writes: > +static const struct IUnknownVtbl internal_unk_vtbl = > +{ > + Internal_QueryInterface, > + Internal_AddRef, > + Internal_Release > +}; > + > +static const struct IStillImageWVtbl stillimagew_vtbl = > +{ > + stillimagew_QueryInterface, > + stillimagew_AddRef, > + stillimagew_Release, > + stillimagew_Initialize, > + stillimagew_GetDeviceList, > + stillimagew_GetDeviceInfo, > + stillimagew_CreateDevice, > + stillimagew_GetDeviceValue, > + stillimagew_SetDeviceValue, > + stillimagew_GetSTILaunchInformation, > + stillimagew_RegisterLaunchApplication, > + stillimagew_UnregisterLaunchApplication, > + stillimagew_EnableHwNotifications, > + stillimagew_GetHwNotificationState, > + stillimagew_RefreshDeviceBus, > + stillimagew_LaunchApplicationForDevice, > + stillimagew_SetupDeviceParameters, > + stillimagew_WriteToErrorLog > +}; You don't really need a separate vtbl for IUnknown. -- Alexandre Julliard julliard(a)winehq.org

Sept. 30, 2009

Re: wininet(2/7): Separate loading libssl from loading libcrypto

by Juan Lang

> There's no reason to invent such complicated locking mechanisms. Just > put the whole thing inside a critical section and be done with it. I already did, in yesterday's patch series. Would you like me to resend? --Juan

Sept. 30, 2009

Re: wininet(2/7): Separate loading libssl from loading libcrypto

by Alexandre Julliard

Juan Lang <juan.lang(a)gmail.com> writes: > This is a step toward relieving lock serialization, as the two > libraries can be loaded independently. (There is no lock yet, though, > and this still crashes in utorrent. Fixes in the next two patches.) There's no reason to invent such complicated locking mechanisms. Just put the whole thing inside a critical section and be done with it. -- Alexandre Julliard julliard(a)winehq.org

Sept. 30, 2009

Re: [PATCH 3/7] comctl32/monthcal: Use a single calendar for hittesting tests, make point calculation at runtime

by Nikolay Sivov

Paul Vriens wrote: > On 09/29/2009 12:36 PM, Nikolay Sivov wrote: >> Changelog: >> - be sure we have a single view calendar for hittesting >> >> >> ------------------------------------------------------------------------ >> >> > Hi Nikolay, > > This one introduces a test failure on several platforms: > > monthcal.c:1002: Test failed: Expected 10000, got 10002 > > I fixed it on my NT4 box by checking the point more to the left (see > attached). > > I somehow doubt it's the correct fix though. Aren't these tests with > more-or-less fixed points error-prone (aka, locale/font/dpi dependent)? > Hi, Paul. I certainly noticed that. A problem for me is that it doesn't fail on mine XP. Could you please send me (offlist) a crossbuilt binary with this patch - I'm not able to built it myself at the moment. About fragility of these test - it was a reason why I use dynamic point calculation here, it was fixed before. So now it should be less dpi/font dependent I hope. It isn't affected by locale too much I think.

Sept. 30, 2009

Re: Compile error on current Git

by Paul Vriens

On 09/30/2009 10:39 AM, Michael Stefaniuc wrote: > Hello Paul, > > Paul Vriens wrote: >> Anyone else seeing this: > yes, I have pinged Alexandre yesterdays about this and todays commit > round will include the fixes. If you don't want to wait the fixes are: > - system.drv16 and toolhelp.dll16 need an IMPORT ntdll > - ntdll/tests need a GetProcAddress on NtCurrentTeb Thanks. > >> make[2]: Entering directory `/wine/wine-git/dlls/system.drv16' >> ccache gcc -m32 -m32 -c -I. -I. -I../../include -I../../include >> -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing >> -Wdeclaration-after-statement -Wwrite-strings -Wtype-limits >> -Wpointer-arith -Wcast-qual -Wlogical-op -o system.o system.c >> ../../tools/winegcc/winegcc -m32 -B../../tools/winebuild --sysroot=../.. >> -shared ./system.drv16.spec system.o -Wb,--subsystem,win16 -o >> system.drv16.so -lkernel32 ../../libs/port/libwine_port.a >> system.o: In function `call_timer_proc16': >> system.c:(.text+0x54a): undefined reference to `NtCurrentTeb' >> collect2: ld returned 1 exit status >> winegcc: ccache failed >> make[2]: *** [system.drv16.so] Error 2 >> make[2]: Leaving directory `/wine/wine-git/dlls/system.drv16' >> make[1]: *** [system.drv16] Error 2 >> >> (Fedora 11, gcc 4.4.1) > 32 or 64-bit F11? I have a 64-bit F11 and I didn't run into the problem; > I run into the problem with my gcc-3.1.1 based Smatch compile. 64-bit. > > bye > michael -- Cheers, Paul.

Sept. 30, 2009

Re: Compile error on current Git

by Michael Stefaniuc

Hello Paul, Paul Vriens wrote: > Anyone else seeing this: yes, I have pinged Alexandre yesterdays about this and todays commit round will include the fixes. If you don't want to wait the fixes are: - system.drv16 and toolhelp.dll16 need an IMPORT ntdll - ntdll/tests need a GetProcAddress on NtCurrentTeb > make[2]: Entering directory `/wine/wine-git/dlls/system.drv16' > ccache gcc -m32 -m32 -c -I. -I. -I../../include -I../../include > -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing > -Wdeclaration-after-statement -Wwrite-strings -Wtype-limits > -Wpointer-arith -Wcast-qual -Wlogical-op -o system.o system.c > ../../tools/winegcc/winegcc -m32 -B../../tools/winebuild --sysroot=../.. > -shared ./system.drv16.spec system.o -Wb,--subsystem,win16 -o > system.drv16.so -lkernel32 ../../libs/port/libwine_port.a > system.o: In function `call_timer_proc16': > system.c:(.text+0x54a): undefined reference to `NtCurrentTeb' > collect2: ld returned 1 exit status > winegcc: ccache failed > make[2]: *** [system.drv16.so] Error 2 > make[2]: Leaving directory `/wine/wine-git/dlls/system.drv16' > make[1]: *** [system.drv16] Error 2 > > (Fedora 11, gcc 4.4.1) 32 or 64-bit F11? I have a 64-bit F11 and I didn't run into the problem; I run into the problem with my gcc-3.1.1 based Smatch compile. bye michael

Sept. 30, 2009