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

Re: xinput implementation
by chourmovs Aug. 3, 2008

Aug. 3, 2008

Jeff Zaroyko wrote: > > > It's in C++ and the license looks incompatible with the LGPL. So, no > it doesn't look like it can be used. If you're looking to contribute > code, it's probably in your best interest to learn to program in C by > picking up a book such as 'The C Programming Language, second edition' > by K&R as a start, otherwise you have a large gap between not knowing > how to program in C and being able to contribute to the degree which > you've expressed interest. > > -Jeff > Hi Jeff thank you for your support I've got few notion of c, and i've never tried class programming with c++ The fact is what i found about xinput on the web use xinput msnd classes like windows.h and xinput.h How could i rewrite what is included in msdn ? How could i intercept xinput signal with c coding without any classes ? To Follow Dan instruction, my first and only aim is to write conformance test for the moment but i'm not sure i have understood what i've to do -- View this message in context: http://www.nabble.com/xinput-implementation-tp18748649p18800318.html Sent from the Wine - Devel mailing list archive at Nabble.com.

1 0

Re: msvfw32: Rename macro parameter to avoid string coincidence
by Andrew Talbot Aug. 3, 2008

Aug. 3, 2008

You might want to forget this one. I guess no one is compiling Wine on a broken, pre-ANSI compiler. So the expansion of macro parameters inside string literals may well, in effect, be a non-issue. -- Andy.

1 0

(no subject)
by chourmovs vs Aug. 3, 2008

Aug. 3, 2008

chourmovs(a)gmail.com

1 0

winetest sometimes shows 'crashed' and sometimes 'timeout'
by Paul Vriens Aug. 3, 2008

Aug. 3, 2008

Hi, A few months ago I mentioned the fact that due to some issues with old kernel32/debugger tests there were some leftovers in the registry: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug (contains 'Debugger' which points to kernel32_test.exe) I have a feeling that on systems where this AeDebug contains normal debugger information we sometimes see 'crashed' whereas we see 'timeout' when the key still contains our own entry. Can anybody confirm this finding? What I'm actually looking for is people having a look at that registry key to see the contents. If it's indeed something containing "kernel32_test.exe" I'd like to hear about it (preferably with the tag they have used for the winetest run). One way to fix this registry key is to run 'drwtsn32 -i'. This of course restores the basic dr watson entry and not some specific debug program that was there before. -- Cheers, Paul.

1 0

re: problem loading wine test projects windows vista
by Dan Kegel Aug. 3, 2008

Aug. 3, 2008

Hongbo wrote: > I really need to compile and run existing tests on window before I can write any test case for wine. The easiest way is to cross-compile them on wine and then run them on windows. To do this, say make crosstest See http://www.winehq.org/site/docs/winedev-guide/cross-compiling-tests - Dan

1 0

Re: [3/9] WineD3D: Beware of the frontbuffer coordinate system difference
by H. Verbeet Aug. 3, 2008

Aug. 3, 2008

2008/8/3 Stefan Dösinger <stefan(a)codeweavers.com>: > + src_rect->x1 -= offset.x; dst_rect->x2 -=offset.x; Why are you modifying dst_rect here?

2 1

Re: fusion: Use proper function pointer
by James Hawkins Aug. 3, 2008

Aug. 3, 2008

On Sat, Aug 2, 2008 at 4:09 PM, Andrew Talbot <andrew.talbot(a)talbotville.com> wrote: > Changelog: > fusion: Use proper function pointer. > > diff --git a/dlls/fusion/fusion.c b/dlls/fusion/fusion.c > index ac01cf4..637346c 100644 > --- a/dlls/fusion/fusion.c > +++ b/dlls/fusion/fusion.c > @@ -32,6 +32,9 @@ > > WINE_DEFAULT_DEBUG_CHANNEL(fusion); > > +typedef HRESULT (WINAPI *PFNGETCORVERSION)(LPWSTR pbuffer, DWORD cchBuffer, > + DWORD *dwLength); > + > /****************************************************************** > * ClearDownloadCache (FUSION.@) > */ > @@ -89,20 +92,18 @@ HRESULT WINAPI GetAssemblyIdentityFromFile(LPCWSTR pwzFilePath, REFIID riid, > return E_NOTIMPL; > } > > -static HRESULT (WINAPI *pGetCORVersion)(LPWSTR pbuffer, DWORD cchBuffer, > - DWORD *dwLength); > - There's nothing wrong with this. We use this type of function pointer all over the code base. -- James Hawkins

3 2

Re: msxml3: off-by-one fix for Qname allocation
by Piotr Caban Aug. 3, 2008

Aug. 3, 2008

Hi Joris, SysAllocStringLen allocates additional space for NULL byte. It's not needed to change string size. On the other hand QNames should be created differently. I will send patches changing it soon. Regards, Piotr

1 0

re: xinput implementation
by Dan Kegel Aug. 3, 2008

Aug. 3, 2008

chourmovs wrote: > I'd like to participate to wine improvement instead of > always requesting for new features > > ... xinput support lack for new games and its > implementation is maybe not the hardest thing to do Please start by writing conformance tests. See http://www.winehq.org/site/docs/winedev-guide/testing - Dan

3 2

Re: ntdll: import dll from dir of referring dll if not found instandard locations
by Dmitry Timoshkov Aug. 3, 2008

Aug. 3, 2008

"Hongbo Ni" <hongbo(a)njstar.com> wrote: > This patch fixes bug 14699. It should fix all failed applications > which try to load a dll from specific folder, and the dll is link > another dll in the same folder. Please add a test case for this behaviour to confirm that your patch is doing a correct thing. -- Dmitry.

2 1

Re: [2/2] mlang/tests: add test for fnIMLangFontLink_GetCharCodePages
by Dmitry Timoshkov Aug. 3, 2008

Aug. 3, 2008

"Vitaly Perov" <vitperov(a)etersoft.ru> wrote: > + /* Tests for GetCharCodePages */ > + /* Latin 1 */ > + ok(IMLangFontLink_GetCharCodePages(iMLFL, 'd', &dwCodePages) == S_OK, > + "IMLangFontLink_GetCharCodePages failed\n"); > + ok(dwCodePages == 2032127, "Incorrect CodePages returned (%i)\n", dwCodePages); > + > + /* Cyrillic (Japanese, Simplified Chinese and Korean are also > + include these symbols) */ > + ok(IMLangFontLink_GetCharCodePages(iMLFL, 0x0436, &dwCodePages) == S_OK, > + "IMLangFontLink_GetCharCodePages failed\n"); > + ok(dwCodePages == 917508, "Incorrect CodePages returned (%i)\n", dwCodePages); > + > + /* Japanese */ > + ok(IMLangFontLink_GetCharCodePages(iMLFL, 0xff6f, &dwCodePages) == S_OK, > + "IMLangFontLink_GetCharCodePages failed\n"); > + ok(dwCodePages == 131072, "Incorrect CodePages returned (%i)\n", dwCodePages); Please use symbolic names for code pages bit field. -- Dmitry.

1 0

rsaenh: Test and correct the maximum allowable salt length
by Louis. Lenders Aug. 2, 2008

Aug. 2, 2008

Usually i don't feel the need to respond to messages on wine-devel, but now i do: > What in the hell does this patch do? Why is it needed? What does it > fix/implement? Doees this change affect any Bugzilla issues? Where is > the Changelog? > This is what I have been trying to get you to do. I have no idea what > you are up to and I have NO access to IRC or other alternate forms of > messaging/communications other than this mailing list. I haven't got a clue what the patch is all about either, but if i'd wanted to know i would just drop a friendly note, asking some more info. As long as i've followed wine's development i've seen Juan as very helpful and main contributor to wine, so i'm a bit surprised about your unfriendly reaction to this patch.... __________________________________________________________ Not happy with your email address?. Get the one you really want - millions of new email addresses available now at Yahoo! http://uk.docs.yahoo.com/ymail/new.html

1 0

World of Warcraft's Current Perforamnce Rating
by Jarred Sumner Aug. 2, 2008

Aug. 2, 2008

Dear Wine Dev's, It seems that as of wine 1.1.0 and later, Almost Every Game's performance that I play on linux has vastly improved. Those games are: - World of Warcraft - City of Heroes - Command & Conquer 3 Tiberium Wars World of Warcraft's Performance has reached higher levels than Windows XP Professional Service Pack 3. It runs 85 FPS whereas on Windows it runs 75fps averagely City of Heroes runs the same on Windows as on Linux Command & Conquer 3 Tiberium Wars Runs a little better due to the fact that there is no anti-aliasing (With the patches provided on the appdb) Great Job with this wine development team! I have tested these games on the following distrobutions: Arch CORE Ubuntu 8.04.1 & 8.04 Slackware 12.1 Thank You for making gaming on Linux Playable! Sincerely, Jarrhed

1 0

Re: rsaenh: Test and correct the maximum allowable salt length
by James McKenzie Aug. 2, 2008

Aug. 2, 2008

Juan Lang wrote: > Inspired by a patch by Karsten Elfenbein. > Who is this and why is this so important? > --Juan > Per: http://winehq.org/site/sending_patches What in the hell does this patch do? Why is it needed? What does it fix/implement? Doees this change affect any Bugzilla issues? Where is the Changelog? This is what I have been trying to get you to do. I have no idea what you are up to and I have NO access to IRC or other alternate forms of messaging/communications other than this mailing list. Let's try to do things better in the future. James McKenzie

2 1

Re: kernal32: change if...if to if...'else if' in get_module_path_end()
by Jacek Caban Aug. 2, 2008

Aug. 2, 2008

Hongbo Ni wrote: > If '\\' is found, there is no point to find '/'. > There is, think about path like c:\dir1\dir2/file.dll Jacek

1 0

DLL loading prolem when injecting into another process
by Hongbo Ni Aug. 2, 2008

Aug. 2, 2008

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 Aug. 2, 2008

Aug. 2, 2008

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 Aug. 2, 2008

Aug. 2, 2008

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 Aug. 2, 2008

Aug. 2, 2008

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 Aug. 2, 2008

Aug. 2, 2008

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 Aug. 1, 2008

Aug. 1, 2008

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 Aug. 1, 2008

Aug. 1, 2008

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 Aug. 1, 2008

Aug. 1, 2008

> 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 Aug. 1, 2008

Aug. 1, 2008

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 Aug. 1, 2008

Aug. 1, 2008

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