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

DLL loading prolem when injecting into another process
by Hongbo Ni 02 Aug '08

02 Aug '08

Hi, I have observed a DLL loading prolem when injecting into another process. For example, In folder C:\DirA\, I have A.exe which is linked to B.dll, and B.dll is linked to C.dll. B.dll and C.dll are in same folder as A.exe. If I run A.exe, B.dll and C.dll will be loaded without problem since they are in same folder. Support there is a process running C:\DirX\X.exe, and C:\DirX\ is not the current folder and it's not on PATH. Now I inject B.dll from A.exe into process X.exe, the System will map C:\DirA\B.dll into process X.exe. Since B.dll is linked to C.dll, the system will try to load C.dll for process X.exe. But because C.dll is not in same folder of process X.exe, wine failed to load C.dll for X.exe. This cause DLL injection to fail. Windows does not have this problem. So I am trying to find a solution. 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. Alexandre, can you please comment ? Regards Hongbo Ni _________________________________________________________________ Want to help Windows Live Messenger plant more Aussie trees? http://livelife.ninemsn.com.au/article.aspx?id=443698

5 10

Re: [2/2] netapi32: Added partial implementation of NetShareGetInfo
by Juan Lang 02 Aug '08

02 Aug '08

Hi again Vitaliy, +/************************************************************/ +WCHAR *ParseParam(WCHAR **paramStr, const WCHAR *name) This should be static. The name of the function also shouldn't be capitalized like this, to make it clear that it isn't a Win32 function. Looking at other source files in netapi32, either NETAPI_ParseParam or simply parse_param would be better. Also, some comments for it would be nice. In particular, the meaning of paramStr and the return value aren't clear from the function name. + FIXME("(%s %s %d %p) partially implemented\n", debugstr_w(servername), + debugstr_w(netname), level, bufptr); As with patch 1, a TRACE is probably better here. + size = 512; + result = RegQueryValueExW(hKey, netname, NULL, NULL, (LPBYTE) paramStr, &size); This isn't actually a correct value for size, size = sizeof(paramStr) would be correct (and less prone to future error.) Can the value become bigger than 512 characters? --Juan

1 0

Re: [1/2] netapi32: Added partial implementation of NetShareAdd
by Juan Lang 02 Aug '08

02 Aug '08

Hi Vitaliy, overall your patch looks pretty good. A few minor points: + FIXME("(%s %d %p) partially implemented\n", debugstr_w(servername), level, buf); Because you add a more specific FIXME for every unimplemented path, it seems to me this would be better as a TRACE. + result = RegCreateKeyExA(HKEY_LOCAL_MACHINE, regKey, 0, NULL, 0, KEY_WRITE, + NULL, &hKey, &disposition); + if (result != ERROR_SUCCESS) + { + FIXME("Unable to open/create key 'HKLM\\%s'\n", regKey); + return result; This shouldn't be a FIXME, as there's nothing to "fix" in the code: if the key couldn't be created, there's a setup problem or some other unrecoverable error. A TRACE is fine. + /* FIXME: A duplicate patch checking should be implemented here */ Do you mean a duplicate path? --Juan

1 0

mono progress on mixed-mode assemblies...
by Dan Kegel 02 Aug '08

02 Aug '08

http://lists.ximian.com/pipermail/mono-devel-list/2008-May/027767.html shows that Pál Kornél is now working on supporting apps that use msvcrt. Go Pal go!

7 15

Re: one liner patch to stop crash, everquest2.exe
by H. Verbeet 02 Aug '08

02 Aug '08

2008/7/17 Andrew Fenn <andrewfenn(a)gmail.com>: > I added a check to make sure This->shader_priv wasn't null. Before > Everquest2.exe would crash when I tried to alt+enter from windowed mode. > This stops it crashing wine. > This->shader_priv shouldn't be NULL. It probably means the backend was already destroyed when shader_glsl_free() was called.

4 22

Re: dinput: the DIK_ keycode is not the same as the scancode.
by Vitaliy Margolen 01 Aug '08

01 Aug '08

James Mckenzie wrote: > Vitaliy Margolen <wine-devel(a)kievinfo.com> at Jul 31, 2008 10:10 PM (PNT) wrote about Re: dinput: the DIK_ keycode is not the same as the scancode. >>> - dik_code = hook->scanCode & 0xff; >>> + dik_code = This->ScanCodemap[hook->scanCode]; >> Scan code can be larger then 256 so "& 0xff" is really necessary. >> > What is the type of scanCode. If it is BYTE and BYTE is properly defined as being between 0x00 and 0xff, then the check is not necessary. If it is defined as something else, then the check IS necessary and should nto be dropped typedef struct tagKBDLLHOOKSTRUCT { DWORD vkCode; DWORD scanCode; DWORD flags; DWORD time; ULONG_PTR dwExtraInfo; } KBDLLHOOKSTRUCT, *LPKBDLLHOOKSTRUCT, *PKBDLLHOOKSTRUCT; (scanCode & 0x100) != 0 indicates an extended key. > In this case, I feel that map_dik_code should be defined as BYTE and no other type. Was that the intent of your comment? That and definitions of the variables and the array type. Vitaliy.

1 0

Re: crypt32(3/3): More fully implement CryptSIPRetrieveSubjectGuid
by James Mckenzie 01 Aug '08

01 Aug '08

Juan: Please put something in the title to let us know that this is a resumission like (try 2). Some folks resend and resend their patches when Alexandre does not 'immediately' react to them. Thank you. James McKenzie -----Original Message----- >From: Juan Lang <juan.lang(a)gmail.com> >Sent: Aug 1, 2008 10:22 AM >To: wine-patches(a)winehq.org >Subject: crypt32(3/3): More fully implement CryptSIPRetrieveSubjectGuid > >Also just rediffed. Need a full change log here as well. >--Juan

3 2

Re: [2/7] WineD3D: use the drawable size to set up blitting
by Stefan Dösinger 01 Aug '08

01 Aug '08

> this patch break PP effects even more with Max Payne 2 (demo) and > ORM=backbuffer. > Bullettime PP works, but cutscene PP breaks. Interested in a screenshot? I'm sorry, I cannot reproduce this. Which settings are you using? cutscene post processing works flawlessly here with this patch, even if I disable GL_ARB_texture_non_power_of_two and force wined3d to fall back to GL_ARB_texture_rectangle. Offscreen rendering mode is backbuffer, post processing effects set to high, resolution 640x480. For testing I am using the very first cutscene when the view is moving into the hospital room where the interactive part of the demo starts

2 2

New valgrind warnings in wined3d/arb_program_shader.c
by Dan Kegel 01 Aug '08

01 Aug '08

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.t… + 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

3 5

Re: [1/7] WineD3D: use the window size as drawable size
by Alexandre Julliard 01 Aug '08

01 Aug '08

Stefan Dösinger <stefan(a)codeweavers.com> writes: > @@ -4681,7 +4681,9 @@ static void viewport_miscpart(DWORD state, IWineD3DStateBlockImpl *stateblock, W > stateblock->viewport.Width, stateblock->viewport.Height); > } else { > target = (IWineD3DSurfaceImpl *) stateblock->wineD3DDevice->render_targets[0]; > + LEAVE_GL(); > target->get_drawable_size(target, &width, &height); > + ENTER_GL(); That's ugly, the lock isn't even entered in that function. Can we please start to clean up the ENTER_GL mess to only grab the lock around GL calls and not over huge amounts of code including nested functions? -- Alexandre Julliard julliard(a)winehq.org

2 3