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

Re: [PATCH] wine.inf: Change Msi.Package actions to have the full msiexec path. (try 2)

by Lei Zhang

On Thu, Jul 31, 2008 at 1:45 PM, Alexandre Julliard <julliard(a)winehq.org> wrote: > "Lei Zhang" <thestig(a)google.com> writes: > >> While mucking around in programs/cmd/wcmdmain.c, I noticed >> console = SHGetFileInfo(); >> always returned 0 for just "msiexec". > > cmd is supposed to build a full path here, but either way it won't work > because SHGetFileInfo doesn't work for builtins. This is the real bug > that needs fixing. The first bug is in FindExecutuable. On Windows, FindExecutable("msiexec", ...) return the full path, but just msiexec.exe on Wine.

July 31, 2008

Re: Hang in mshtml/tests/dom.c

by Dan Kegel

On Thu, Jul 31, 2008 at 1:50 PM, Jacek Caban <jacek(a)codeweavers.com> wrote: >> While running mshtml/tests/dom.c on a slow dual processor >> under valgrind, I got the following hang: > > I know about this bug and it's not easy to fix (because it's hard to > reproduce it). It's on my TODO list. OK. It hasn't happened again; it only happened when I overloaded a 1GHz single-core machine by doing "make -j2 test" with my parallel test patch and valgrind. That was an accident, I thought I was on a dual core machine. So I'm quite happy without a fix for now. - Dan

July 31, 2008

Re: shdocvw(2/2): rudimentary implementation of CLSID_InternetShortcut (try 3)

by Jacek Caban

Hi Damjan, Damjan Jovanovic wrote: > Changelog: > * Added a rudimentary implementation of CLSID_InternetShorcut, with > tests (#3546). > > Damjan Jovanovic > + +static HRESULT strdupAtoW(LPCSTR in, LPWSTR *out) +{ + INT len; + if (in == NULL) + { + *out = NULL; + return S_OK; + } + len = MultiByteToWideChar(CP_ACP, 0, in, -1, NULL, 0); + *out = HeapAlloc(GetProcessHeap(), 0, len*sizeof(WCHAR)); + if (!*out) + return E_OUTOFMEMORY; + MultiByteToWideChar(CP_ACP, 0, in, -1, *out, len); + return S_OK; +} + +static HRESULT strdupWtoA(LPCWSTR in, LPSTR *out) +{ + INT len; + if (in == NULL) + { + *out = NULL; + return S_OK; + } + len = WideCharToMultiByte(CP_ACP, 0, in, -1, NULL, 0, 0, 0); + *out = HeapAlloc(GetProcessHeap(), 0, len); + if (!*out) + return E_OUTOFMEMORY; + WideCharToMultiByte(CP_ACP, 0, in, -1, *out, len, 0, 0); + return S_OK; +} These function should go to shdocvw.h and be named heap_strdup*. You may copy them from dlls/mshtml/mshtml_private.h. + else if (IsEqualGUID(&IID_IShellLinkA, riid)) + { + FIXME("The IShellLinkA interface is not yet supported by InternetShortcut\n"); + return E_NOTIMPL; E_NOINTERFACE is better choice. + } + else if (IsEqualGUID(&IID_IShellLinkW, riid)) + { + FIXME("The IShellLinkW interface is not yet supported by InternetShortcut\n"); + return E_NOTIMPL; Same here. + } + else + { + FIXME("Interface with GUID %s not yet implemented by InternetShortcut\n", debugstr_guid(riid)); + return E_NOINTERFACE; + } You should set ppvObject to NULL here. Also, the order of function is strange. The convention is to order function as they are ordered in the interface declaration and not mix interfaces. Also there are heap_alloc, heap_alloc_zero and heap_free functions in shdocvw.h that you should use instead of HeapAlloc/HeapFree. Jacek

July 31, 2008

Re: Hang in mshtml/tests/dom.c

by Jacek Caban

Hi Dan, Dan Kegel wrote: > While running mshtml/tests/dom.c on a slow dual processor > under valgrind, I got the following hang: > ... > 7 0x04b22c1c GetMessageA+0x60(msg=0x7f21fdc8, hwnd=0x0, first=0x0, > last=0x0) [dlls/user32/message.c:2976] in user32 (0x7f21fda8) > 8 0x04946eb1 run_domtest+0x91(str=0x495fab0, test=0x493daa4) > [dlls/mshtml/tests/dom.c:2597] in mshtml_test (0x7f21fdf8) > 9 0x0494711c func_dom+0x45() [dlls/mshtml/tests/dom.c:2652] in > mshtml_test (0x7f21fe18) > ... > > The offending GetMessage call is in the following loop in tests/dom.c: > > while(!doc_complete && GetMessage(&msg, NULL, 0, 0)) { > TranslateMessage(&msg); > DispatchMessage(&msg); > } > > The doc_complete test has been in that file since the test was added; > git blame says it was added by this commit: > > commit 1534267ba500156e7965fdc399247ca69eb7c014 > Author: Jacek Caban <jacek(a)codeweavers.com> > Date: Sun Jun 24 21:09:03 2007 +0200 > > mshtml: Added beginning DOM tests. > > Jacek, could you have a look and see if there's some obvious race you could fix? > I know about this bug and it's not easy to fix (because it's hard to reproduce it). It's on my TODO list. Jacek

July 31, 2008

RE: DLL loading prolem when injecting into another process

by Rolf Kalbermatter

Hongbo Ni wrote: >I think when processing the imports for C:\DirA\B.dll to load C.dll, it should >try C:\DirA\C.dll first, then form the standard load locations. > >I think it should call load_library( "C:\DirA\C.dll ", LOAD_WITH_ALTERED_SEARCH_PATH) >so C.dll can be loaded into C:\DirX\X.exe process. Not sure about what you mean with injecting here but in normal application operation when loading a DLL explicitedly from a specific directory (which is not the current directory nor the application directory or one of the standard search paths), Windows will not resolve to other DLLs implicitedly loaded by that DLL eventhough they are in the same directory than the referencing DLL. Rolf Kalbermatter

July 31, 2008

Re: [PATCH] wine.inf: Change Msi.Package actions to have the full msiexec path. (try 2)

by Alexandre Julliard

"Lei Zhang" <thestig(a)google.com> writes: > While mucking around in programs/cmd/wcmdmain.c, I noticed > console = SHGetFileInfo(); > always returned 0 for just "msiexec". cmd is supposed to build a full path here, but either way it won't work because SHGetFileInfo doesn't work for builtins. This is the real bug that needs fixing. -- Alexandre Julliard julliard(a)winehq.org

July 31, 2008

RE: [5/7] WineD3D: Only set D3D caps when GL was loaded successfully

by Stefan Dösinger

> 2008/7/31 Stefan Dösinger <stefan(a)codeweavers.com>: > > + if(Adapters[0].opengl) { > Shouldn't you be checking the adapter for which the caps are requested > instead? True. In practise it doesn't matter because its unlikely one adapter has GL support and the other doesn't, but still using 0 here isn't right

July 31, 2008

RE: New valgrind warnings in wined3d/arb_program_shader.c

by Stefan Dösinger

Does the attached patch fix the warnings? > -----Original Message----- > From: daniel.r.kegel(a)gmail.com [mailto:daniel.r.kegel(a)gmail.com] On > Behalf Of Dan Kegel > Sent: Thursday, July 31, 2008 12:22 PM > To: wine-devel > Cc: Stefan Dösinger > Subject: New valgrind warnings in wined3d/arb_program_shader.c > > Hi Stefan, > your recent round of changes (circa > http://www.winehq.org/pipermail/wine-cvs/2008-July/045946.html) > seems to have triggered a whole bunch of valgrind warnings, e.g. > > http://kegel.com/wine/valgrind/logs/2008-07-31-07.46/vg-d3d9_visual- > diff.txt > + Use of uninitialised value of size 4 > + at hash_table_get_by_idx (utils.c:1600) > + by hash_table_get (utils.c:1750) > + by find_ffp_shader (utils.c:1961) > + by fragment_prog_arbfp (arb_program_shader.c:2761) > + by ActivateContext (context.c:1169) > + by drawPrimitive (drawprim.c:950) > + by IWineD3DDeviceImpl_DrawIndexedPrimitiveUP (device.c:5350) > + by IDirect3DDevice9Impl_DrawIndexedPrimitiveUP (device.c:1227) > + by lighting_test (visual.c:300) > + by func_visual (visual.c:9234) > + by run_test (test.h:488) > + by main (test.h:537) > + Uninitialised value was created by a stack allocation > + at fragment_prog_arbfp (arb_program_shader.c:2745) > > http://kegel.com/wine/valgrind/logs/2008-07-31-07.46/vg-ddraw_visual- > diff.txt > + Use of uninitialised value of size 4 > + at hash_table_get_by_idx (utils.c:1600) > + by hash_table_get (utils.c:1750) > + by find_ffp_shader (utils.c:1961) > + by fragment_prog_arbfp (arb_program_shader.c:2761) > + by ActivateContext (context.c:1169) > + by drawPrimitive (drawprim.c:950) > + by IWineD3DDeviceImpl_DrawIndexedPrimitiveUP (device.c:5350) > + by IDirect3DDeviceImpl_7_DrawIndexedPrimitive (device.c:3731) > + by IDirect3DDeviceImpl_7_DrawIndexedPrimitive_FPUSetup > (device.c:3754) > + by lighting_test (visual.c:276) > + by func_visual (visual.c:2649) > + by run_test (test.h:488) > + by main (test.h:537) > + Uninitialised value was created by a stack allocation > + at fragment_prog_arbfp (arb_program_shader.c:2745) > > Could you have a look? > > Thanks, > Dan

July 31, 2008

Re: [resent] Fix some hackish usages of WideCharToMultiByte

by Colin Finck

Alexandre Julliard wrote: > It would be cleaner to pass the actual buffer size to the function, it's > complex enough that it would be easy to inadvertently break the > guarantee that the allocated space is large enough. We already pass a length pointer to that "convert_PCREDENTIALW_to_PCREDENTIALA" function, but its value is zeroed before the actual conversion takes place. Its value is increased while the length of all strings is determined during the conversion. Therefore this parameter is unusable as a length variable for WideCharToMultiByte. So all in all, getting that function to use a passed length instead of 0x7FFFFFFF requires rewriting most code, which currently calls it, and I don't feel like doing this now ;-) As the rest of the patch is already applied to HEAD, I'd suggest we drop that advapi32/cred.c change for the moment. The rest of my patches are independent from it anyway. If there are any more problems with them, please let me know. Best regards, Colin

July 31, 2008

Re: [PATCH] wine.inf: Change Msi.Package actions to have the full msiexec path. (try 2)

by Lei Zhang

On Thu, Jul 31, 2008 at 3:11 AM, Alexandre Julliard <julliard(a)winehq.org> wrote: > You should be using %11% instead of hardcoding system32, but it > shouldn't make any difference either way. Why do you need to change > this? While mucking around in programs/cmd/wcmdmain.c, I noticed console = SHGetFileInfo(); always returned 0 for just "msiexec". This is part of why running foo.msi from the command prompt does not return immediately, like it does on Windows.

July 31, 2008