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

Re: Update: comctl32: fix listview select-all
by Vitaliy Margolen 06 Jul '08

06 Jul '08

winehq.10.drkshadow(a)spamgourmet.com wrote: > Fixes the Listview control to not individually select and focus each > items. Has the added bugfix that it keeps the same item focused as was > to begin with, and doesn't scroll the list. > > Updated: my if was incorrect and it was handling cases it shouldn't have > handled. It's improved now, and as far as I can tell handles only the > select-all case. Please fix the formatting - 4 spaces indentation. No tabs. Do not reformat the lines that you did not modify. Follow the file style with curly brackets - here they go on the separate line. Is there a reason you added whole new function SelectAll() which is used in only one place and has only 4 lines? And the most important - you missed your real name. Patches from anonymous posters are not accepted. Vitaliy.

1 0

Tricking program into seeing actual gfx driver not WINE's
by Seth Shelnutt 05 Jul '08

05 Jul '08

Hello All, We have run into an interesting problem while trying to get the latest version of Stanford's Folding at Home GPU client to work in Linux via WINE. The programs says it does not detect a compatible GPU. Even when the user has installed the correct Nvidia drivers (with CUDA support) and has a compatible GPU. The problem I believe lies in the fact that the program is not told that there is a Nvidia 8800 installed, instead by the nature of WINE it see that "WINE" is the graphics card, as WINE first translate the direct3d calls into opengl calls that are then passed on to the GPU. So the question is, is it possible to trick programs into believing they are running on the right hardware? (As in fact they are). I remember a while ago the steam system spec survey was used to see how many people run steam via WINE. This was done by noting the graphics driver installed and how the wine one appeared when running WINE. Well this is fine but what we need is a way to make the program to see that it is actually running on Nvidia hardware. Because if the client would just start then the direct3d calls can be translated into opengl calls and the Nvidia linux drivers can then handle them and run it all fine and dandy. Here is the post, with error message about wrong graphics card detected, http://www.ocforums.com/showpost.php?p=5698997&postcount=19 . Thanks, Seth Shelnutt

6 11

New valgrind warnings in NdrComplexArrayUnmarshall (oleaut32/tests/tmarshal)
by Dan Kegel 05 Jul '08

05 Jul '08

Probably triggered by Rob's five rpcrt4 patches on July 3rd, who knows, perhaps the removal of the memset in http://www.winehq.org/pipermail/wine-cvs/2008-July/045025.html Rob, can you have a look? http://kegel.com/wine/valgrind/logs-2008-07-04/vg-oleaut32_tmarshal-diff.txt e.g. + Conditional jump or move depends on uninitialised value(s) + at VARIANT_ValidateType (variant.c:545) + by VariantClear (variant.c:598) + by VARIANT_UserUnmarshal (usrmarshal.c:594) + by NdrUserMarshalUnmarshall (ndr_marshall.c:3772) + by ComplexUnmarshall (ndr_marshall.c:2439) + by NdrComplexArrayUnmarshall (ndr_marshall.c:3505) + by PointerUnmarshall (ndr_marshall.c:1302) + by EmbeddedPointerUnmarshall (ndr_marshall.c:1622) + by NdrSimpleStructUnmarshall (ndr_marshall.c:2059) + by PointerUnmarshall (ndr_marshall.c:1302) + by NdrPointerUnmarshall (ndr_marshall.c:1886) + by IDispatch_RemoteInvoke_Stub (oleaut32_oaidl_p.c:838) + by CStdStubBuffer_Invoke (cstub.c:433) + by RPC_ExecuteCall (rpc.c:1392) + by apartment_wndproc (compobj.c:547) + by ??? (library.h:163) + by call_window_proc (winproc.c:457) + by WINPROC_CallProcAtoW (winproc.c:1011) + by WINPROC_call_window (winproc.c:2209) + by DispatchMessageA (message.c:3067) + Uninitialised value was created by a client request + at mark_block_uninitialized (heap.c:164) + by RtlAllocateHeap (heap.c:1239) + by IMalloc_fnAlloc (ifs.c:186) + by CoTaskMemAlloc (ifs.c:562) + by NdrOleAllocate (ndr_ole.c:359) + by NdrAllocate (ndr_marshall.c:381) + by NdrComplexArrayUnmarshall (ndr_marshall.c:3498) + by PointerUnmarshall (ndr_marshall.c:1302) + by EmbeddedPointerUnmarshall (ndr_marshall.c:1622) + by NdrSimpleStructUnmarshall (ndr_marshall.c:2059) + by PointerUnmarshall (ndr_marshall.c:1302) + by NdrPointerUnmarshall (ndr_marshall.c:1886) + by IDispatch_RemoteInvoke_Stub (oleaut32_oaidl_p.c:838) + by CStdStubBuffer_Invoke (cstub.c:433) + by RPC_ExecuteCall (rpc.c:1392) + by apartment_wndproc (compobj.c:547) + by ??? (library.h:163) + by call_window_proc (winproc.c:457) + by WINPROC_CallProcAtoW (winproc.c:1011) + by WINPROC_call_window (winproc.c:2209) ...

1 0

[Fwd: Re: richedit: Store richedit version rather than boolean bEmulateVersion10 value]
by James McKenzie 05 Jul '08

05 Jul '08

forgot to hit the Reply-All button... -------- Original Message -------- Phil Krylov wrote: > On 03/07/2008, Dylan Smith <dylan.ah.smith(a)gmail.com> wrote: > > On Thu, Jul 3, 2008 at 2:01 PM, Juan Lang <juan.lang(a)gmail.com> wrote: > > > > > Hi Dylan, > > > > > > - if (!editor->bEmulateVersion10 || (editor->nEventMask & ENM_UPDATE)) > > > + if (!editor->dwEmulatedVersion || (editor->nEventMask & ENM_UPDATE)) > > > > > > This change is incorrect, as dwEmulatedVersion is never set to 0. I > > > believe you mean if (editor->dwEmulatedVersion > 0x100 || ... > > > > > > > You're right, that was a mistake. Thanks for catching it. > > > > > I have to ask, though: what bug does this fix? > > > > > > > This doesn't fix a bug, but it allows me to add functionality for > > msftedit.dll without changing the way riched20.dll works when loaded > > directly. Without storing more than a boolean value it will be hard to > > support the multiple versions of richedit controls. > > > > I would like to properly implement tables for richedit controls, which > > greatly differs in how it is implemented between riched20.dll and > > msftedit.dll. Should I only worry about how it is done in the newer > > richedit controls? I am worried that this will cause problems considering > > that amy program that loads msftedit.dll assumes that they are getting a > > specific implementation. > > > IMHO no real applications depend on poverty of table functionality of > versions 2 and 3. If somebody finds one, we could think about it > then... To my knowledge, there is just one thing better in table > support of 2.0 than in 3.0 and IIRC 4.1: better breaking of long > tables on page boundaries when printing. But I consider it a bug in > versions >2.0 which we should not replicate (when EM_FORMATRANGE will > be supported). > I will look into this as time permits. I am now on a three hour commute for my present employment committment, which is through the end of July. I may be extended, picked up by the future company, discarded or find employment closer to my domincile, or any combination. I have looked at Troy Rollo's code and it was current as of 0.9.59. If someone wants it, I can zip up the difference file and send it to them. I can also add it to the issue I was working with. James McKenzie

1 0

Tricking program into seeing actual gfx driver not WINE's
by Martijn Berger 04 Jul '08

04 Jul '08

>* Hello All, *>* *>* We have run into an interesting problem while trying to get the latest *>* version of Stanford's Folding at Home GPU client to work in Linux via WINE. *>* The programs says it does not detect a compatible GPU. Even when the user *>* has installed the correct Nvidia drivers (with CUDA support) and has a *>* compatible GPU. The problem I believe lies in the fact that the program is *>* not told that there is a Nvidia 8800 installed, instead by the nature of *>* WINE it see that "WINE" is the graphics card, as WINE first translate the *>* direct3d calls into opengl calls that are then passed on to the GPU. So the *>* question is, is it possible to trick programs into believing they are *>* running on the right hardware? (As in fact they are). *>* *>* I remember a while ago the steam system spec survey was used to see how many *>* people run steam via WINE. This was done by noting the graphics driver *>* installed and how the wine one appeared when running WINE. Well this is fine *>* but what we need is a way to make the program to see that it is actually *>* running on Nvidia hardware. Because if the client would just start then the *>* direct3d calls can be translated into opengl calls and the Nvidia linux *>* drivers can then handle them and run it all fine and dandy. *>* *>* Here is the post, with error message about wrong graphics card detected, *>* http://www.ocforums.com/showpost.php?p=5698997&postcount=19 . * I think you would have to create wrapper dll's that pass the function calls along to libcudart.so.2.0 The following libraries are in the CUDA download for linux. libcublas.so.2.0 libcublasemu.so.2.0 libcudart.so.2.0 libcufft.so.2.0 libcufftemu.so.2.0 I am unsure if you would need to modify more but I am pretty sure that running the windows veersions of those dlls directly o wine is nto what you want.

1 0

OT: Main website is down / misconfigured
by Paul Chitescu 04 Jul '08

04 Jul '08

http://www.winehq.org/ Fatal error: Call to undefined function () in /home/winehq/opt/website/include/config.php on line 51 Does it ring a bell?

1 0

Re: [1/2] wininet: Add support of INTERNET_FLAG_NO_CACHE_WRITE
by Hans Leidekker 04 Jul '08

04 Jul '08

On Friday 04 July 2008 10:15:57 Alexander Morozov wrote: + if ((lpwhr->hdr.dwFlags & INTERNET_FLAG_NO_CACHE_WRITE) && + CSTR_EQUAL == CompareStringW(LOCALE_SYSTEM_DEFAULT, 0, + lpwhr->lpszVerb, strlenW(lpwhr->lpszVerb), szPOST, strlenW(szPOST))) No need to use CompareStringW here, these are fixed strings, defined by the protocol. -Hans

1 0

Re: quartz: Implement state transitions in video renderer
by Maarten Lankhorst 04 Jul '08

04 Jul '08

2008/7/4 Maarten Lankhorst <m.b.lankhorst(a)gmail.com>: > --- > Fixes video renderer in the same way as directsound renderer Wait with this patch, it doesn't apply. Apparantly I accidentally touched the video renderer in an earlier patch in my tree which messed this one up.

1 0

Re: richedit: Store richedit version rather than boolean bEmulateVersion10 value
by Phil Krylov 04 Jul '08

04 Jul '08

On 03/07/2008, Dylan Smith <dylan.ah.smith(a)gmail.com> wrote: > On Thu, Jul 3, 2008 at 2:01 PM, Juan Lang <juan.lang(a)gmail.com> wrote: > > > Hi Dylan, > > > > - if (!editor->bEmulateVersion10 || (editor->nEventMask & ENM_UPDATE)) > > + if (!editor->dwEmulatedVersion || (editor->nEventMask & ENM_UPDATE)) > > > > This change is incorrect, as dwEmulatedVersion is never set to 0. I > > believe you mean if (editor->dwEmulatedVersion > 0x100 || ... > > > > You're right, that was a mistake. Thanks for catching it. > > > I have to ask, though: what bug does this fix? > > > > This doesn't fix a bug, but it allows me to add functionality for > msftedit.dll without changing the way riched20.dll works when loaded > directly. Without storing more than a boolean value it will be hard to > support the multiple versions of richedit controls. > > I would like to properly implement tables for richedit controls, which > greatly differs in how it is implemented between riched20.dll and > msftedit.dll. Should I only worry about how it is done in the newer > richedit controls? I am worried that this will cause problems considering > that amy program that loads msftedit.dll assumes that they are getting a > specific implementation. IMHO no real applications depend on poverty of table functionality of versions 2 and 3. If somebody finds one, we could think about it then... To my knowledge, there is just one thing better in table support of 2.0 than in 3.0 and IIRC 4.1: better breaking of long tables on page boundaries when printing. But I consider it a bug in versions >2.0 which we should not replicate (when EM_FORMATRANGE will be supported). -- Ph.

1 0

Re: [UPDATE] shell32: Check registry entry for cpl files (in standard control panel)
by Rob Shearman 03 Jul '08

03 Jul '08

2008/7/2 Owen Rudge <owen(a)owenrudge.net>: > This patch fixes bug #12534. It adds a check to the built-in control > panel for any .cpl files in the registry, in addition to those .cpl > files in the system directory. Control Panel applets can also be registered in "HKCU\Control Panel\MMCPL". -- Rob Shearman

4 5