- wine-devel - winehq.org

Re: [9/10] WineD3D: Test formats for surface support
by H. Verbeet 04 Aug '08

04 Aug '08

2008/8/4 Stefan Dösinger <stefan(a)codeweavers.com>: > + if(CheckDepthStencilCapability(Adapter, AdapterFormat, CheckFormat)) return TRUE; This is redundant, the depthstencil formats should already be caught by the CheckTextureCapability() call. I think you should set this up the same way as WINED3DRTYPE_TEXTURE, if only for maintainability.

1 0

Re: d3dx9: Implementation of D3DXMatrixDecompose and tests
by H. Verbeet 04 Aug '08

04 Aug '08

2008/8/4 Luis Busquets <luis.busquets(a)ilidium.com>: > +#include "d3d9.h" ... > +#define module(vx,vy,vz) sqrt((vx)*(vx)+(vy)*(vy)+(vz)*(vz)) ... > +#include "stdio.h" You don't really need those.

1 0

RE: [3/3] wined3d: Handle CTXUSAGE_BLIT with offscreen targets and FBO ORM
by Stefan Dösinger 04 Aug '08

04 Aug '08

> This is mostly for correctness, in practice we should always be able to > avoid using CTXUSAGE_BLIT for offscreen targets when FBO ORM is used. Not always actually. With my upcoming patches to perform YUV conversion in Blt I'll have to avoid the fbo_blit codepath in some situations even if fbo_blit is available and fbos are used

2 1

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

04 Aug '08

Aric Stewart wrote: > > It is mapped with the keyboard mapping to the resulting character. so > the key 'A' is DIK_A nomatter what its scancode or vkey would be. This > is relevent to Japanese keymapping where the '@' key is in the '[' > location the scancode for both is 0x22 but dinput generates DIK_AT in > japanese and DIK_LBRACKET in us_qwerty > > reworked to remove the giant case statement and hopefully be more clear. > remove japan specific stuff as with the proper keyboard scancodes it > works out. I'm still not clear why do you need to translate the v_key into char? This involves a round trip to the X server for each key press. Besides this will depend on the state of the num-lock, shift, etc. Which should not be the case for dinput. It should always return the same code for the key regardless of anything else. Vitaliy.

4 12

problem loading wine test projects windows vista
by Hongbo Ni 04 Aug '08

04 Aug '08

Hi, I want to build and test wine test suite on window, I did ./tools/winapi/msvcmaker --no-wine that is ok, but when I try to open the fille winetest.dsw, 1. with Developer Studio 6.0, it compaints that all *.dsp files (such as dlls\advapi32\tests\advapi32_test.dsp) have been modified and can not be loaded as Developer Studio Project. 2. with Developer Studio 2008, half of the *.dsp files (such as dlls\user32\tests\user32_test.dsp) was reported corrupted after been converted into the current Visual C++ project format. Does anyone know what is the problem? Please help me. I really need to compile and run existing tests on window before I can write any test case for wine. Regards Hongbo Ni _________________________________________________________________ It's simple! Sell your car for just $40 at CarPoint.com.au http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Fsecure%2Dau%2Eimrworldwide%…

2 3

RE: [wined3d] Remove arb_tex_npot for NV FX series in fixup_extensions
by Stefan Dösinger 04 Aug '08

04 Aug '08

> this patch fixes performance regressions in Max Payne 2, Morrowind and > HL2 on nVidia GeforceFx based hardware. > It has been approved by Stefan Dösinger and verified by test > application (see source). Just to add this here as well, I think this patch is fine. I could not find any way to use the NP2 emulation for conditional NP2 textures like on ATI cards

1 0

Patch checking robot coming
by Dan Kegel 04 Aug '08

04 Aug '08

After some discussion with Jeremy and Alexandre about how nice it would be to have some automated way to check patches before Alexandre commits them, I decided to have a go at creating one. What I have so far is a script that watches wine-patches and applies each patch to current git, then builds, and sends email with a subject line saying whether it worked, and a body containing a short "I'm a build robot" note, the patch, and the build log. You can see the code at http://code.google.com/p/winezeug/source/browse/#svn/trunk/patchwatcher Its main failing is that it doesn't understand patch series yet, but I should be able to get that going by rewriting get-next-patch.pl to take a bit more context into account. Right now it only emails the results to me, but it's probably nearly good enough to show results to other people. Question: where should the results go? I could put them up on a web site and/or email them to the patch's author and/or email them to a dedicated mailing list (e.g. wine-patches-buildlogs(a)winehq.org?) and/or email them to wine-devel. - Dan

4 5

re: [PATCH] AcceptEx Impelementation
by Dan Kegel 04 Aug '08

04 Aug '08

Hi Scott! Three suggestions: 1) send one patch per email; use 1/2 and 2/2 in the subject line to make it clear they're related 2) port some existing accept() conformance tests from ws2_32/tests/sock.c to use AcceptEx(), add a bit to check the special new features, and make sure they pass on Windows. 3) Submit the acceptance tests first as a separate patch Thanks, Dan

1 0

Re: [9/9] WineD3D: Advertise D3DFMT_A16B16G16R16 support
by Alexandre Julliard 04 Aug '08

04 Aug '08

Stefan Dösinger <stefan(a)codeweavers.com> writes: > I don't see a reason not to do this It doesn't work here: ../../../tools/runtest -q -P wine -M d3d9.dll -T ../../.. -p d3d9_test.exe.so visual.c && touch visual.ok visual.c:8469: Tests skipped: D3DFMT_G16R16F textures not supported visual.c:8469: Tests skipped: D3DFMT_G32R32F textures not supported visual.c:3155: Test failed: quad 1 has color 00000000, expected 0x00FFFF00 visual.c:3159: Test failed: quad 3 has color 00000000, expected 0x0000FF00 visual.c:3242: Test failed: quad 1 has color 00000000, expected 0x00FF0000 visual.c:3249: Test failed: quad 4 has color 00000000, expected 0x0033cc00 visual.c:7453: Tests skipped: Card has unconditional pow2 support, skipping conditional NP2 tests visual.c:8330: Tests skipped: Only 1 simultaneous render target supported, skipping MRT test make: *** [visual.ok] Error 4 -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [1/2] mlang: Add implementation of fnIMLangFontLink_GetCharCodePages
by Dmitry Timoshkov 04 Aug '08

04 Aug '08

"Vitaly Perov" <vitperov(a)etersoft.ru> wrote: > @@ -1855,8 +1855,56 @@ static HRESULT WINAPI fnIMLangFontLink_GetCharCodePages( > WCHAR chSrc, > DWORD* pdwCodePages) > { > - FIXME("\n"); > - return E_NOTIMPL; > + /* codepages, supported by Windows */ > + static const unsigned int processCP[] = {1250, 1251, 1252, 1253, 1254, 1255, > + 1256, 1257, 1258, 874, 932, 936, 949, 950, 0}; It doesn't really matter what code pages Windows supports, it does matter though what code pages are valid. You need to use Win32 APIs EnumSystemCodePages/GetCPInfo/MultiByteToWideChar instead of accessing Wine internals directly. -- Dmitry.

2 2

Re: [2/2] wined3d: Use CTXUSAGE_RESOURCELOAD for ActivateContext() in color_fill_fbo()
by Alexander Dorofeyev 04 Aug '08

04 Aug '08

H. Verbeet wrote: > + IWineD3DDeviceImpl_MarkStateDirty(This, STATE_RENDER(WINED3DRS_SCISSORTESTENABLE)); > + > + glDisable(GL_BLEND); > + IWineD3DDeviceImpl_MarkStateDirty(This, STATE_RENDER(WINED3DRS_ALPHABLENDENABLE)); Don't you need to also dirtify STATE_SCISSORRECT there?

2 1

Re: user32/tests: Avoid crash on win9x in win.c
by Dmitry Timoshkov 04 Aug '08

04 Aug '08

"Detlef Riekenberg" <wine.dev(a)web.de> wrote: > @@ -4765,10 +4765,14 @@ static void test_hwnd_message(void) > parent = pGetAncestor(hwnd, GA_PARENT); > ok(parent != 0, "GetAncestor(GA_PARENT) should not return 0 for message windows\n"); > ok(parent != desktop, "GetAncestor(GA_PARENT) should not return desktop for message windows\n"); > - root = pGetAncestor(hwnd, GA_ROOT); > - ok(root == hwnd, "GetAncestor(GA_ROOT) should return hwnd for message windows\n"); > + if (0) { > + /* this crash on win9x */ > + root = pGetAncestor(hwnd, GA_ROOT); > + ok(root == hwnd, "GetAncestor(GA_ROOT) should return hwnd for message windows\n"); > + } HWND_MESSAGE is not supported on win9x, so there is no point in disabling a part of the test which is not supposed to pass a all. Probably CreateWindowEx doesn't fail for some reason, so you need to find a different way to detect that. -- Dmitry.

1 0

Re: [7/9] WineD3D: Always load glFinish and glFlush from opengl32.dll
by H. Verbeet 03 Aug '08

03 Aug '08

2008/8/3 Stefan Dösinger <stefan(a)codeweavers.com>: > +/* glFinish and glFlush are always loaded from opengl32.dll, this the always have > + * __stdcall calling convention > + */ In theory WINAPI could be something else than __stdcall.

2 3

Re: xinput implementation
by chourmovs 03 Aug '08

03 Aug '08

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 03 Aug '08

03 Aug '08

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 03 Aug '08

03 Aug '08

chourmovs(a)gmail.com

1 0

winetest sometimes shows 'crashed' and sometimes 'timeout'
by Paul Vriens 03 Aug '08

03 Aug '08

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 03 Aug '08

03 Aug '08

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 03 Aug '08

03 Aug '08

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 03 Aug '08

03 Aug '08

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 03 Aug '08

03 Aug '08

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 03 Aug '08

03 Aug '08

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 03 Aug '08

03 Aug '08

"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 03 Aug '08

03 Aug '08

"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 02 Aug '08

02 Aug '08

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 02 Aug '08

02 Aug '08

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 02 Aug '08

02 Aug '08

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 02 Aug '08

02 Aug '08

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 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

Re: [Gdiplus] Try harder to get a monospace font
by Vitaly Lipatov 01 Aug '08

01 Aug '08

В сообщении от 1 августа 2008 Adam Petaccia написал(a): > + * If Courier New is not found, the replacement font Liberation Mono is > used. */ Why do not use font replacement rules in the registry? I think it is more common way to subst Liberation fonts instead proprietary one. -- Vitaly Lipatov, ALT Linux Team Russia, Saint-Petersburg, www.etersoft.ru

1 0

Re: crypt32(1/3): Use ReadFile rather than a memory-mapped file to check the type of a file
by Alexandre Julliard 01 Aug '08

01 Aug '08

"Juan Lang" <juan.lang(a)gmail.com> writes: > From 064365f26630c76546a6c8bedc1e99d47b74563d Mon Sep 17 00:00:00 2001 > From: Juan Lang <juan.lang(a)gmail.com> > Date: Thu, 31 Jul 2008 09:08:09 -0700 > Subject: [PATCH] Use ReadFile rather than a memory-mapped file to check the type of a file This doesn't work here: ../../../tools/runtest -q -P wine -M wintrust.dll -T ../../.. -p wintrust_test.exe.so softpub.c && touch softpub.ok softpub.c:449: Test failed: expected TRUST_E_NOSIGNATURE, got 800b0003 make: *** [softpub.ok] Error 1 -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 1/2] shell32: Add a test for FindExecutableA.
by Alexandre Julliard 01 Aug '08

01 Aug '08

"Lei Zhang" <thestig(a)google.com> writes: > + { > + char expand[MAX_PATH]; > + strcpy(command, "foobar"); > + strcpy(filename, "foo.msi"); > + file = CreateFileA(filename, GENERIC_WRITE, 0, NULL, CREATE_ALWAYS, 0, NULL); > + ok(file != INVALID_HANDLE_VALUE, "Failure to open file %s\n", filename); > + CloseHandle(file); > + > + ok(ExpandEnvironmentStringsA("\%systemroot\%\\system32\\msiexec.exe", expand, MAX_PATH) != 0, "ExpandEnvironmentStringsA failed\n"); Again, please don't hardcode system32, use GetSystemDirectory instead. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: d3dx9: Implementation of D3DXGetPixelShaderProfile 1/2 try 3
by Alexandre Julliard 01 Aug '08

01 Aug '08

Luis Busquets <luis.busquets(a)ilidium.com> writes: > + case D3DPS_VERSION(2, 0): > + if ((caps.PS20Caps.NumTemps>=22) && > + (caps.PS20Caps.Caps&D3DPS20CAPS_ARBITRARYSWIZZLE) && > + (caps.PS20Caps.Caps&D3DPS20CAPS_GRADIENTINSTRUCTIONS) && > + (caps.PS20Caps.Caps&D3DPS20CAPS_PREDICATION) && > + (caps.PS20Caps.Caps&D3DPS20CAPS_NODEPENDENTREADLIMIT) && > + (caps.PS20Caps.Caps&D3DPS20CAPS_NOTEXINSTRUCTIONLIMIT)) > + { > + return "ps_2_a"; > + } > + if ((caps.PS20Caps.NumTemps>=32) && > + (caps.PS20Caps.Caps&D3DPS20CAPS_NOTEXINSTRUCTIONLIMIT)) > + { > + return "ps_2_b"; > + } > + return "ps_2_0"; I'm usually tolerant of strange identation styles, but that's not even indentation at all. Can you please fix this to use a more commonly accepted format? -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH] wine.inf: Change Msi.Package actions to have the full msiexec path. (try 2)
by Alexandre Julliard 31 Jul '08

31 Jul '08

"Lei Zhang" <thestig(a)google.com> writes: > @@ -143,9 +143,9 @@ HKCR,lnkfile\CLSID,,2,"{00021401-0000-0000-C000-000000000046}" > HKCR,lnkfile\shellex\IconHandler,,2,"{00021401-0000-0000-C000-000000000046}" > HKCR,lnkfile\shellex\ContextMenuHandlers\{00021401-0000-0000-C000-000000000046},,0x10, > HKCR,Msi.Package\DefaultIcon,,2,"msiexec.exe" > -HKCR,Msi.Package\shell\Open\command,,2,"msiexec /i ""%1""" > -HKCR,Msi.Package\shell\Repair\command,,2,"msiexec /f ""%1""" > -HKCR,Msi.Package\shell\Uninstall\command,,2,"msiexec /x ""%1""" > +HKCR,Msi.Package\shell\Open\command,,0x20000,"""%SystemRoot%\System32\msiexec.exe"" /i ""%1"" %*" > +HKCR,Msi.Package\shell\Repair\command,,0x20000,"""%SystemRoot%\System32\msiexec.exe"" /f ""%1"" %*" > +HKCR,Msi.Package\shell\Uninstall\command,,0x20000,"""%SystemRoot%\System32\msiexec.exe"" /x ""%1"" %*" 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? -- Alexandre Julliard julliard(a)winehq.org

2 3

Hang in mshtml/tests/dom.c
by Dan Kegel 31 Jul '08

31 Jul '08

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? Thanks, Dan

2 2

Re: shdocvw(2/2): rudimentary implementation of CLSID_InternetShortcut (try 3)
by Jacek Caban 31 Jul '08

31 Jul '08

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

1 0

Re: [5/7] WineD3D: Only set D3D caps when GL was loaded successfully
by H. Verbeet 31 Jul '08

31 Jul '08

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?

2 1

Re: [resent] Fix some hackish usages of WideCharToMultiByte
by Alexandre Julliard 31 Jul '08

31 Jul '08

"Colin Finck" <mail(a)colinfinck.de> writes: > @@ -947,7 +947,8 @@ static void convert_PCREDENTIALW_to_PCREDENTIALA(const CREDENTIALW *CredentialW, > if (CredentialW->TargetName) > { > CredentialA->TargetName = buffer; > - string_len = WideCharToMultiByte(CP_ACP, 0, CredentialW->TargetName, -1, CredentialA->TargetName, -1, NULL, NULL); > + /* Buffer is guaranteed to be large enough */ > + string_len = WideCharToMultiByte(CP_ACP, 0, CredentialW->TargetName, -1, CredentialA->TargetName, 0x7FFFFFFF, NULL, NULL); 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. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: [resent] [WideChar conversion improvements - 5/5] Add a lot of WideCharToMultiByte tests
by Jeff Latimer 31 Jul '08

31 Jul '08

Colin Finck wrote: > Add a lot of new tests for the actual WideCharToMultiByte string > conversion as well. Are you planning to move on to MultiByteToWideChar tests? I was planning on adding a few and don't want to get into your way. Jeff

2 1

New valgrind warnings in kernel32/tests/codepage.c
by Dan Kegel 31 Jul '08

31 Jul '08

Hi Colin, your change http://source.winehq.org/git/wine.git/?a=commitdiff;h=c2c1a55f1c08f35ae02b8… seems to have triggered some valgrind warnings, http://kegel.com/wine/valgrind/logs/2008-07-31-07.46/vg-kernel32_codepage-d… e.g. + Use of uninitialised value of size 4 + at wcstombs_sbcs (wctomb.c:186) + by wine_cp_wcstombs (wctomb.c:457) + by WideCharToMultiByte (locale.c:1936) + by test_string_conversion (codepage.c:288) + by func_codepage (codepage.c:351) + by run_test (test.h:488) + by main (test.h:537) + Uninitialised value was created by a stack allocation + at test_string_conversion (codepage.c:216) + Use of uninitialised value of size 4 + at wcstombs_sbcs_slow (wctomb.c:246) + by wine_cp_wcstombs (wctomb.c:453) + by WideCharToMultiByte (locale.c:1936) + by test_string_conversion (codepage.c:288) + by func_codepage (codepage.c:352) + by run_test (test.h:488) + by main (test.h:537) + Uninitialised value was created by a stack allocation + at test_string_conversion (codepage.c:216) Could you have a look?

2 1

Re: [3/7] WineD3D: Beware of the frontbuffer coordinate system difference
by H. Verbeet 31 Jul '08

31 Jul '08

You'll need to modify stretch_rect_fbo() as well.

1 0

xinput implementation
by chourmovs 31 Jul '08

31 Jul '08

hi everyone I'd like to participate to wine improvement instead of always requesting for new features Maybe i'm wrong but i thaught xinput support lack for new games and its implementation is maybe not the hardest thing to do The fact is that i have lack of knowledge in msdn and c coding, maybe i could read interesting documentation on how included wine dll's work By my side, i'm going to read all i can find on website documentation to get familiarized with wine code Maybe someones could guide me through this "Way of the Cross" Vincent -- Utilisant le client e-mail révolutionnaire d'Opera : http://www.opera.com/mail/

2 1

Re: shdocvw(2/2): rudimentary implementation of CLSID_InternetShortcut (try 3)
by Alexandre Julliard 31 Jul '08

31 Jul '08

"Damjan Jovanovic" <damjan.jov(a)gmail.com> writes: > +static HRESULT strdupAtoW(LPCSTR in, LPWSTR *out) > +{ The usual pattern is to return the new pointer, not an HRESULT. The only possible error is E_OUTOFMEMORY anyway. > +static HRESULT WINAPI UniformResourceLocatorA_SetUrl(IUniformResourceLocatorA *url, LPCSTR pcszURL, DWORD dwInFlags) > +{ > + HRESULT hr; > + LPWSTR wideURL; > + InternetShortcut *This = impl_from_IUniformResourceLocatorA(url); > + TRACE("(%p, %s, 0x%x)\n", url, debugstr_a(pcszURL), dwInFlags); > + hr = strdupAtoW(pcszURL, &wideURL); > + if (SUCCEEDED(hr)) > + { > + hr = This->uniformResourceLocatorW.lpVtbl->SetURL(&This->uniformResourceLocatorW, wideURL, dwInFlags); In general you shouldn't access lpVtbl. You should either use the COM macros, or if you know the target function like in this case, call it directly. Here it would be even better to not call anything and simply store the pointer to avoid duplicating the string twice. > +static HRESULT WINAPI UniformResourceLocatorW_SetUrl(IUniformResourceLocatorW *url, LPCWSTR pcszURL, DWORD dwInFlags) > +{ > + InternetShortcut *This = impl_from_IUniformResourceLocatorW(url); > + TRACE("(%p, %s, 0x%x)\n", url, debugstr_w(pcszURL), dwInFlags); > + if (dwInFlags != 0) > + FIXME("ignoring unsupported flags 0x%x\n", dwInFlags); > + This->isDirty = TRUE; > + HeapFree(GetProcessHeap(), 0, This->url); > + if (pcszURL == NULL) > + This->url = NULL; > + else > + { > + This->url = heap_strdupW(pcszURL); > + if (This->url == NULL) > + return E_OUTOFMEMORY; You should preserve the old value on error. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: ole32: don't crash when running the marshal tests on Vista.
by Rob Shearman 31 Jul '08

31 Jul '08

2008/7/30 Reece Dunn <msclrhd(a)googlemail.com>: > When running the ole32:marshal tests on Vista, the call to > CoUnmarshalInterface fails. This results in pProxy being NULL which > then causes the crash on the QueryInterface call. > > This patch makes sure that the pProxy-dependant tests are only called > when pProxy is valid. We need to work out why the test is failing - possibly it requires more implementation of the object we are marshalling than in previous versions of Windows. Also, the typical way of detecting failure in our COM code in Wine is to check the return value rather than whether a output object is NULL or not. -- Rob Shearman

2 1

Re: d3d9: fix device crashing on Vista.
by H. Verbeet 31 Jul '08

31 Jul '08

2008/7/30 Reece Dunn <msclrhd(a)googlemail.com>: > SetMaterial crashes when passed a NULL argument. > If you're going to do that, you might as well remove the entire test. I think this test has caused trouble before.

2 1

RE: ddraw/tests: Skip cubemap tests when cubemap isn't supported.
by Stefan Dösinger 31 Jul '08

31 Jul '08

> skip("No cubemap support\n"); if you return right after that you wouldn't have to change the indention on all the rest of the code Also I think in the case of the surface test, there should be an easier way to tell if cubemaps are supported, without starting a d3d device. In the worst case just abort on a CreateSurface error > -----Original Message----- > From: wine-patches-bounces(a)winehq.org [mailto:wine-patches- > bounces(a)winehq.org] On Behalf Of Alexander Dorofeyev > Sent: Tuesday, July 29, 2008 5:25 PM > To: wine-patches(a)winehq.org > Subject: ddraw/tests: Skip cubemap tests when cubemap isn't supported. > > > Fixes some test failures on systems without cubemap support. > --- > dlls/ddraw/tests/d3d.c | 428 ++++++++++++++++++++++------------ > --------- > dlls/ddraw/tests/dsurface.c | 57 ++++++- > 2 files changed, 275 insertions(+), 210 deletions(-)

5 11

Re: [1/3] WineD3D: Use C bitfields to compact the ffp description (try 2)
by Alexandre Julliard 30 Jul '08

30 Jul '08

Stefan Dösinger <stefan(a)codeweavers.com> writes: > @@ -1785,16 +1785,17 @@ void gen_ffp_op(IWineD3DStateBlockImpl *stateblock, struct ffp_settings *setting > }; > unsigned int i; > DWORD ttff; > + DWORD cop, aop, carg0, carg1, carg2, aarg0, aarg1, aarg2; > > for(i = 0; i < GL_LIMITS(texture_stages); i++) { > IWineD3DBaseTextureImpl *texture; > if(stateblock->textureState[i][WINED3DTSS_COLOROP] == WINED3DTOP_DISABLE) { > settings->op[i].cop = WINED3DTOP_DISABLE; > settings->op[i].aop = WINED3DTOP_DISABLE; > - settings->op[i].carg0 = settings->op[i].carg1 = settings->op[i].carg2 = 0xffffffff; > - settings->op[i].aarg0 = settings->op[i].aarg1 = settings->op[i].aarg2 = 0xffffffff; > + settings->op[i].carg0 = settings->op[i].carg1 = settings->op[i].carg2 = -1; > + settings->op[i].aarg0 = settings->op[i].aarg1 = settings->op[i].aarg2 = -1; It's not very clean to store -1 into unsigned variables, the previous code was better IMO. -- Alexandre Julliard julliard(a)winehq.org

3 3

Re: [2]wined3d: rework surface Blt a bit to only lock the part of the destination surface being drawn to
by H. Verbeet 30 Jul '08

30 Jul '08

2008/7/30 Aric Stewart <aric(a)codeweavers.com>: > --- > dlls/wined3d/surface_base.c | 122 > +++++++++++++++++++++++-------------------- > 1 files changed, 65 insertions(+), 57 deletions(-) > Looks reasonable to me, although you might want to wait for Stefan to look it over as well.

2 1

WWN announcements on WineHQ
by Francois Gouget 30 Jul '08

30 Jul '08

On http://www.winehq.org/ we have the following news items: July 13, 2008: Wine Weekly News Issue 349 WWN Issue 349 was released today. June 18, 2008: Wine Weekly News Issue 348 WWN Issue 348 was released today. That's pretty lame. Should either have a 2 or 3 sentence summary for the WWN releases, or simply reuse the index we show in the 'Weekly Newsletters' box. Actually with the combination of proper news items and the back issues page, that box would be pretty redundant. Maybe we should remove it? -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ The nice thing about meditation is that it makes doing nothing quite respectable -- Paul Dean

4 12

[PATCH] cmd: Use ShellExecuteExW instead of CreateProcess for opening files.
by Kirill K. Smirnov 30 Jul '08

30 Jul '08

Hi, >+ sei.fMask = SEE_MASK_FLAG_DDEWAIT| >+ SEE_MASK_FLAG_NO_UI| >+ SEE_MASK_NO_CONSOLE| >+ SEE_MASK_NOCLOSEPROCESS; Console apps must be executed using exiting console, not a new one. -- Kirill

1 0

Re: wined3d: universal surface convertor function for unsigned integer color formats(5th attempt)
by Victor 30 Jul '08

30 Jul '08

Well, the last attempt (with added big-endian support) was submitted several days ago, and again - no feedback, and patch still isn't accepted. What's wrong with patch now? --- Victor Eremin

4 11

Re: quartz: Add tests for avi splitter
by Paul Vriens 30 Jul '08

30 Jul '08

Hi Maarten, NT4 doesn't have CreateToolhelp32Snapshot so none of the quartz tests will run on NT4 currently. Should I just create a patch that checks for the existence of this function and skip some tests? Or do we have another way to get the number of threads? We could use NtQuerySystemInformation but that's not available on Win9x. We could also have a mix of these two depending on the availability of CreateToolhelp32Snapshot. -- Cheers, Paul.

2 2

[crypt32/tests] Don't crash on win9x
by Juan Lang 30 Jul '08

30 Jul '08

Hi Paul, thanks very much for looking into the crypt32 tests. - /* Weird--bad add disposition leads to an access violation in Windows. - */ (snip) + if (!on_win9x) + { + /* Weird--bad add disposition leads to an access violation in Windows. + * Both tests crash on win9x + */ This suggests to me that the test should just be removed, as it's very unlikely that an application will depend on such behavior. Leaving it around with an if (0) around it seems reasonable too. Any of these tests whose behavior is inconsistent across Windows versions, especially where some Windows versions crash, are good candidates for removal, IMO. --Juan

2 1

Re: [PATCH 1/5] quartz: Add tests for Video Mixing Renderer 9
by Alexandre Julliard 30 Jul '08

30 Jul '08

"Maarten Lankhorst" <m.b.lankhorst(a)gmail.com> writes: > From f3544f718dbebd3dca29d94dbbcbdd071884e5a6 Mon Sep 17 00:00:00 2001 > From: Maarten Lankhorst <m.b.lankhorst(a)gmail.com> > Date: Mon, 28 Jul 2008 18:18:06 -0700 > Subject: [PATCH] quartz: Add tests for Video Mixing Renderer 9 > > --- > dlls/quartz/tests/Makefile.in | 5 +- > dlls/quartz/tests/null.h | 667 +++++++++++++++++++++++++++++ You should put that code in the C file, it doesn't belong in a header, especially since you are not using anywhere else. Building tests stand-alone is a nice to have, but it's not worth the cost of putting half the code in a header. > +#define trace_save trace > + > +/* Don't debug null by default */ > +#define debug(...) do { } while (0) Vararg macros are not portable. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: [PATCH 4/5] quartz: Make the vmr-9 implementation work
by H. Verbeet 30 Jul '08

30 Jul '08

I just looked the patch over quickly since you mentioned d3d9, but here are a few things I noticed: > + hr = IDirect3DSurface9_LockRect(info->lpSurf, &lock, NULL, D3DLOCK_DISCARD); > + assert(hr == S_OK); ... > + hr = IDirect3DDevice9_Clear(This->d3d9_dev, 0, NULL, D3DCLEAR_TARGET, D3DCOLOR_XRGB(0, 0, 0), 1.0f, 0); > + if (hr != S_OK) I realize D3D_OK and S_OK have the same value, but using SUCCEEDED()/FAILED() would probably be more appropriate. Happens in a few other places as well. > +// info.dwFlags = VMR9AllocFlag_TextureSurface; ... > + FIXME("SendMessageW: %08x\n", hr); You'll probably want to remove these.

2 1

Re: [PATCH] wine.inf: Change Msi.Package actions to have the full msiexec path.
by Vitaliy Margolen 30 Jul '08

30 Jul '08

Lei Zhang wrote: > Hi, > > On Windows, the Msi.Package action registry keys have the full path to > msiexec.exe. > ------------------------------------------------------------------------ > > +HKCR,Msi.Package\shell\Open\command,,0x20002,"""%SystemRoot%\System32\msiexec.exe"" /i ""%1"" %*" > +HKCR,Msi.Package\shell\Repair\command,,0x20002,"""%SystemRoot%\System32\msiexec.exe"" /f ""%1"" %*" > +HKCR,Msi.Package\shell\Uninstall\command,,0x20002,"""%SystemRoot%\System32\msiexec.exe"" /x ""%1"" %*" Should those 0x20002 be 0x20000 instead? Why do we need to preserve overrides of something that can be opened with msi only? Vitaliy

2 1

d3dx9: Add stubs for the ID3DXSprite functions
by David Adam 30 Jul '08

30 Jul '08

Since the prototype for D3DXCreateSprite in d3dx9 and d3dx8 are not compatible, it would be worth to do the implementation in parallel (that is in the same patch), instead of duplicating the d3dx9 patch into the d3dx8 one. David

1 0

Re: [1/2] comctl32: support for drawing themed push buttons. [try 3]
by Alexandre Julliard 30 Jul '08

30 Jul '08

"Reece Dunn" <msclrhd(a)googlemail.com> writes: > -typedef void (*pfThemedPaint)(HTHEME theme, HWND hwnd, HDC hdc); > +/* These are indices into a states array to determine the theme state for a given theme part. */ > +#define STATE_NORMAL 0 > +#define STATE_DISABLED 1 > +#define STATE_HOT 2 > +#define STATE_PRESSED 3 > +#define STATE_DEFAULTED 4 An enum would be nicer. > +static void PB_draw(HTHEME theme, HWND hwnd, HDC hDC, int drawState, UINT dtFlags) > +{ > + static const int states[] = { PBS_NORMAL, PBS_DISABLED, PBS_HOT, PBS_PRESSED, PBS_DEFAULTED }; > + > + RECT bgRect, textRect; > + HFONT font = (HFONT)SendMessageW(hwnd, WM_GETFONT, 0, 0); > + HFONT hPrevFont = font ? SelectObject(hDC, font) : NULL; > + int state = states[ drawState ]; > + WCHAR text[MAX_PATH]; > + int len = MAX_PATH; MAX_PATH is not appropriate for a button text, this has nothing to do with a path. You should define your own constant, though dynamic allocation would of course be preferable. -- Alexandre Julliard julliard(a)winehq.org

1 0

user32: Add a test for ToUnicode - Win9x behaviour
by Andre Wisplinghoff 30 Jul '08

30 Jul '08

Hello, I think my patch [1] shouldn't be applied, because I didn't think about older versions of Windows. According to MSDN, ToUnicode has NT 3.1 as a minimum, meaning we should test if the function is unimplemented and skip the test in this case (Win9x Systems). Unfortunately I don't have a Win9x system ready for testing at the moment. Is adding the following after the first call to ToUnicode enough to handle this issue? if (GetLastError() == ERROR_CALL_NOT_IMPLEMENTED) { trace("Skipping the ToUnicode test on a Win9x platform\n"); return; } Best Regards -- Andre Wisplinghoff [1] http://www.winehq.org/pipermail/wine-patches/2008-July/058745.html

3 5

Re: d3dx8: Implement D3DXBoxBoundProbe
by H. Verbeet 30 Jul '08

30 Jul '08

2008/7/30 David Adam <david.adam.cnrs(a)gmail.com>: > I forgot to add a change recommended by Henri. > Now, everything should be fine. > Oops, missed that myself as well :-)

1 0

Re: d3dx8: Implement D3DXBoxBoundProbe
by H. Verbeet 30 Jul '08

30 Jul '08

Looks ok to me.

1 0

Re: [PATCH] relay: Avoid reading stack memory on unprotected side of stack pointer
by Alexandre Julliard 30 Jul '08

30 Jul '08

John Reiser <jreiser(a)BitWagon.com> writes: > Thus it seems to me that both the offset and the segment are OK > in the patched code, including when the stack is in a 16-bit segment. > If this analysis has errors, then I wish to learn. You cannot assume that the context you have to restore is identical to what call_from_32_regs has saved. So yes, call_from_32_regs will always be running in 32-bit mode and will save a 32-bit context; but the restore part needs to be able to restore any arbitrary context, including one with a 16-bit stack and separate %ds,%es,%ss selectors. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: d3dx8: Implement D3DXBoxBoundProbe
by H. Verbeet 30 Jul '08

30 Jul '08

Looks good in principle, but I've still got a few comments: > + if ( praydirection->x >= 0.0f ) > + { > + tmin = ( pmin->x - prayposition->x ) / praydirection->x; > + tmax = ( pmax->x - prayposition->x ) / praydirection->x; > + } ... > + if ( tmax < 0.0f ) return FALSE; This will break if praydirection->x is -0.0, because in that case you'll end up with -INF for positive values of tmin and tmax, and INF for negative values. One way to solve this is to do the division before the if. Ie: float div; ... div = 1.0 / praydirection->x; if (div >= 0.0f) { tmin = (pmin->x - prayposition->x) * div; tmax = (pmax->x - prayposition->x) * div; } ... That way you'll test against INF or -INF rather than 0.0 or -0.0 (which are considered equal). I don't think this one is right: > + if ( tymax > tmax ) tmax = tymax; if ( tymax < tmax ) tmax = tymax; would work better I think. > + if ( tzmin > tmin ) tmin = tzmin; > + if ( tzmax > tmax ) tmax = tzmax; These are redundant. Although the code looks pretty clear to me, in general it might make sense to briefly describe the algorithm. Something along the lines of "Consider the box as the intersection of three slabs. Clip the ray against each slab, if there's anything left of the ray after we're done we've got an intersection of the ray with the box."

1 0

Re: [PATCH 1/3] mstask/test: NewWorkItem conformance test
by Dan Hipschman 30 Jul '08

30 Jul '08

Hey Roy, On Tue, Jul 29, 2008 at 04:44:45PM -0700, Roy Shea wrote: > +static BOOL setup_task_scheduler() > +{ > + HRESULT hres; > + > + hres = CoCreateInstance(&CLSID_CTaskScheduler, NULL, CLSCTX_INPROC_SERVER, > + &IID_ITaskScheduler, (void **) &test_task_scheduler); > + return hres == S_OK; > +} You should do an "ok" check on this so that if it fails, the tests fail, since this is part of the module you're testing. > +static void test_NewWorkItem() > +{ > + HRESULT hres; > + ITask *task; > + const WCHAR task_name[] = {'T', 'e', 's', 't', 'i', 'n', 'g', 0}; > + const GUID invalid_id = {0x00000000, 0x0000, 0x0000, > + {0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00}}; You can use GUID_NULL and eliminate this local. > + if (!setup_task_scheduler()) > + { > + skip("Failed to create task scheduler. Skipping tests.\n"); > + goto out; > + } Why goto-return when you can just return? I thought we hated gotos. ;)

2 1

Re: [PATCH 2/3] mstask: Task stub with AddRef, QueryInterface, and Release
by Dan Hipschman 30 Jul '08

30 Jul '08

On Tue, Jul 29, 2008 at 04:45:31PM -0700, Roy Shea wrote: > +static HRESULT WINAPI MSTASK_ITask_GetTriggerString( > + ITask* iface, > + WORD iTrigger, > + LPWSTR *ppwszTrigger) > +{ > + FIXME("(%p, %d, %p): stub\n", iface, iTrigger, ppwszTrigger); > + FIXME("Not implemented\n"); > + return E_NOTIMPL; > +} Forgot to remove the original FIXME.

1 0

Re: [PATCH] shell32: autocomplete: there is no need for separate IAutoComplete and IAutoComplete2 vtbls
by Juan Lang 29 Jul '08

29 Jul '08

Hi Mikolaj, + if (IsEqualIID(riid, &IID_IUnknown) || + IsEqualIID(riid, &IID_IAutoComplete) || + IsEqualIID(riid, &IID_IAutoComplete)) Perhaps you mean IID_IAutoComplete2 for one of these? --Juan

1 0

Re: Missed patches concerning valgrind-detected issues
by Kirill K. Smirnov 29 Jul '08

29 Jul '08

В сообщении от 29 июля 2008 Alexandre Julliard написал(a): > "Kirill K. Smirnov" <lich(a)math.spbu.ru> writes: > > Hello, Alexandre, > > > > dsound: check error status of waveOutGetVolume() function before using > > retrieved values (found by valgrind) > > http://www.winehq.org/pipermail/wine-patches/2008-July/058124.html > > You should most likely propagate the errors instead of assuming default > values. It seems that it is a bigger problem than I expected (just because OSS works OK here). Please, ignore this patch. > > cmd: Do not deceive CompareString() passing more characters then we > > really have (found by valgrind) > > http://www.winehq.org/pipermail/wine-patches/2008-July/058504.html > > There shouldn't be any need to pass an explicit length here, the code is > confused. Hmm... We are just trying to perform strncmpi() here - so we obligated to pass an explicit length. Unfortunately there is not such simple function a-la lstrncmpi() in WinAPI (I've double checked this!) I believe strncmpiW() function from winelib is more suitable - but I'm not sure that it will not introduce new bugs and any unexpected behaviour (diacritic weights, etc). Thanks -- Kirill

1 0

Re: [WideChar conversion improvements - 1/5] Add a new check for 'dstlen < 0' to WideCharToMultiByte
by Alexandre Julliard 29 Jul '08

29 Jul '08

"Colin Finck" <mail(a)colinfinck.de> writes: > @@ -1893,7 +1893,7 @@ INT WINAPI WideCharToMultiByte( UINT page, DWORD flags, LPCWSTR src, INT srclen, > const union cptable *table; > int ret, used_tmp; > > - if (!src || (!dst && dstlen)) > + if (!src || (!dst && dstlen) || dstlen < 0) There are places in Wine that use a negative dstlen, you have to fix them first. -- Alexandre Julliard julliard(a)winehq.org

2 1

Hang in user32/tests/dde.c:test_msg_client()
by Dan Kegel 29 Jul '08

29 Jul '08

I'm running the tests on a slowish uniprocessor (Athlon XP 2100+, not dual as I mistakenly said in last post), and I'm running into a hang in user32/tests/dde.c. This is a two process test. One process is hung in 8 test_ddeml_server+0x1ad(hproc=0x4c) [dlls/user32/tests/dde.c:797] in user32_test (0x7f21fc68) in a reasonable looking "wait for requests", and the other is hung in 5 X11DRV_MsgWaitForMultipleObjectsEx+0x77(count=0x1, handles=0x7f22fa0c, timeout=0xffffffff, mask=0x40, flags=0x0) [dlls/winex11.drv/event.c:402] in winex11 (0x7f22f968) 6 wait_message_reply+0x11f(flags=0x0) [dlls/user32/message.c:2274] in user32 (0x7f22fa28) 7 send_inter_thread_message+0xf9(info=0x7f22faec, res_ptr=0x7f22fab0) dlls/user32/message.c:2418] in user32 (0x7f22fa78) 8 send_message+0x252(info=0x7f22faec, res_ptr=0x0, unicode=0x0) [dlls/user32/message.c:2480] in user32 (0x7f22fac8) 9 SendMessageTimeoutA+0x52(hwnd=0x84002c, msg=0x3e0, wparam=0xb005c, lparam=0xc09fc09c, flags=0x0, timeout=0x0, res_ptr=0x0) [dlls/user32/message.c:2567] in user32 (0x7f22fb18) 10 broadcast_message_callback+0xfa(hwnd=0x84002c, lparam=0x7f22fc08) [dlls/user32/message.c:363] in user32 (0x7f22fb68) 11 EnumWindows+0x7d(lpEnumFunc=0x4b3d5ba, lParam=0x7f22fc08) [dlls/user32/win.c:2979] in user32 (0x7f22fb98) 12 send_message+0x3b(info=0x7f22fc08, res_ptr=0x7f22fc34, unicode=0x0) [dls/user32/message.c:2450] in user32 (0x7f22fbe8) 13 SendMessageA+0x5b(hwnd=0xffff, msg=0x3e0, wparam=0xb005c, lparam=0xc09fc09c) [dlls/user32/message.c:2609] in user32 (0x7f22fc38) 14 test_msg_client+0x111() [dlls/user32/tests/dde.c:1026] in user32_test (0x7f22fc68) That last frame is on the line SendMessageA(HWND_BROADCAST, WM_DDE_INITIATE, (WPARAM)client_hwnd, MAKELONG(server, topic)); Looking at the code, it seems the client is spawned before the server is started. What happens if the client gets all the way to that SendMessageA(... WM_DDE_INITIATE...) before the server is active? Would that cause the observed hang? The code in question seems to have been added back in October by: commit 9cf7f8c3e21931b52e3da6c5feb701aa9ba4a1f8 Author: James Hawkins <truiken(a)gmail.com> Date: Mon Oct 8 04:06:45 2007 -0500 user32: Test the ddeml server interface. - Dan

1 0

Missed patches concerning valgrind-detected issues
by Kirill K. Smirnov 29 Jul '08

29 Jul '08

Hello, Alexandre, Is there anything wrong with this couple of patches: dsound: check error status of waveOutGetVolume() function before using retrieved values (found by valgrind) http://www.winehq.org/pipermail/wine-patches/2008-July/058124.html and cmd: Do not deceive CompareString() passing more characters then we really have (found by valgrind) http://www.winehq.org/pipermail/wine-patches/2008-July/058504.html Thanks -- Kirill

2 1

Re: wined3d: Call apply_fbo_state() from inside ActivateContext()
by Alexandre Julliard 29 Jul '08

29 Jul '08

"H. Verbeet" <hverbeet(a)gmail.com> writes: > This should prevent setting an incorrect draw buffer when an FBO is active. It doesn't work here: ../../../tools/runtest -q -P wine -M d3d9.dll -T ../../.. -p d3d9_test.exe.so visual.c && touch visual.ok visual.c:8465: Tests skipped: D3DFMT_G16R16F textures not supported visual.c:8465: Tests skipped: D3DFMT_G32R32F textures not supported visual.c:7449: Tests skipped: Card has unconditional pow2 support, skipping conditional NP2 tests visual.c:8326: Tests skipped: Only 1 simultaneous render target supported, skipping MRT test visual.c:5476: Test failed: vs_3_0 returned color 0x0000ff00, expected 0x00193366 visual.c:5479: Test failed: vs_1_1 returned color 0x00ff0000, expected 0x004c0066 visual.c:5482: Test failed: vs_2_0 returned color 0x0000ff00, expected 0x004c0066 make[2]: *** [visual.ok] Error 3 -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: [PATCH] relay: Avoid reading stack memory on unprotected side of stack pointer
by Alexandre Julliard 29 Jul '08

29 Jul '08

John Reiser <jreiser(a)BitWagon.com> writes: > + output( "\tmovl %d(%%ecx),%%edx; movl %%edx,%%es:0*4(%%eax)\n", CONTEXTOFFSET(Eax) ); > + output( "\tmovl %d(%%ecx),%%edx; movl %%edx,%%es:1*4(%%eax)\n", CONTEXTOFFSET(Ecx) ); > + output( "\tmovl %d(%%ecx),%%edx; movl %%edx,%%es:2*4(%%eax)\n", CONTEXTOFFSET(SegDs) ); > + output( "\tmovl %d(%%ecx),%%edx; movl %%edx,%%es:3*4(%%eax)\n", CONTEXTOFFSET(Eip) ); > + output( "\tmovl %d(%%ecx),%%edx; movl %%edx,%%es:4*4(%%eax)\n", CONTEXTOFFSET(SegCs) ); > + output( "\tmovl %d(%%ecx),%%edx; movl %%edx,%%es:5*4(%%eax)\n", CONTEXTOFFSET(EFlags) ); This won't work if the stack is 16-bit, you'd need to truncate the address to 16-bit too. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: wined3d: Call apply_fbo_state() from inside ActivateContext()
by Vitaliy Margolen 29 Jul '08

29 Jul '08

H. Verbeet wrote: > This should prevent setting an incorrect draw buffer when an FBO is active. > This patch breaks Psychonauts and possibly other multi-threaded games with OffscreenRendering=FBO on Nvidia hardware. Vitaliy.

2 1

Re: rsaenh: Test and correct the maximum allowable salt length
by James Hawkins 29 Jul '08

29 Jul '08

On Mon, Jul 28, 2008 at 9:58 PM, Juan Lang <juan.lang(a)gmail.com> wrote: > Inspired by a patch by Karsten Elfenbein. + /* What sizes salt can I set? */ + salt.pbData = pbData; + for (i=0; i<24; i++) + { + salt.cbData = i; + result = CryptSetKeyParam(hKey, KP_SALT_EX, (BYTE *)&salt, 0); + ok(result, "setting salt failed for size %d: %08x\n", i, GetLastError()); + } + salt.cbData = 25; + SetLastError(0xdeadbeef); + result = CryptSetKeyParam(hKey, KP_SALT_EX, (BYTE *)&salt, 0); + ok(!result && GetLastError() == NTE_BAD_DATA, "%08x\n", GetLastError()); + + /* What sizes salt can I set? */ + salt.pbData = pbData; + for (i=0; i<24; i++) + { + salt.cbData = i; + result = CryptSetKeyParam(hKey, KP_SALT_EX, (BYTE *)&salt, 0); + ok(result, "setting salt failed for size %d: %08x\n", i, GetLastError()); + } + salt.cbData = 25; + SetLastError(0xdeadbeef); + result = CryptSetKeyParam(hKey, KP_SALT_EX, (BYTE *)&salt, 0); + ok(!result && GetLastError() == NTE_BAD_DATA, "%08x\n", GetLastError()); + Did you mean to test that block twice? -- James Hawkins

2 1

Re: [PATCH] ntdll: use symbols, add documentation for i386 page faulterror code
by Dmitry Timoshkov 29 Jul '08

29 Jul '08

"John Reiser" <jreiser(a)BitWagon.com> wrote: >> These changes are not compatible with PSDK. >> > > Which "PSDK" is that, and what are the error messages? I'm using Software Development Kit Update for Windows Vista. > The numerical values are identical, > and the new names are the ones used by the hardware documentation. The problem is that you are introducing things not existing in PSDK. -- Dmitry.

1 0

RE: Convert 565 to 0888
by Stefan Dösinger 29 Jul '08

29 Jul '08

This patch collides with Victor Eremin's general convertor I think. We may still want both, because the special function is faster than code that attempts to handle all potential formats. > -----Original Message----- > From: wine-patches-bounces(a)winehq.org [mailto:wine-patches- > bounces(a)winehq.org] On Behalf Of Austin English > Sent: Wednesday, July 23, 2008 9:34 AM > To: wine-patches(a)winehq.org > Subject: Fwd: Convert 565 to 0888 > > ---------- Forwarded message ---------- > From: Einars <einars(a)gmail.com> > Date: Jul 22, 2008 11:22 PM > Subject: Convert 565 to 0888 > To: wine-devel(a)winehq.org > > > I had graphical problems with an online game called Angels Online, when > just a black screen was visible, and complaints about missing converter > from WINED3DFMT_R5G6B5 to WINED3DFMT_X8R8G8B8, so I added a converter > for this format, and the game runs flawlessly now on wine, the 1.1.1 > release as well as git version (at least for me). I hope this was the > right way to fix it. > > Kind regards, > > Einars Lielmanis

3 9

Richedit: fix bug 14280, EM_SETTEXTTEX obeys ST_SELECTION with RTF inputs
by Dustin Brody 29 Jul '08

29 Jul '08

I sent the patch at http://www.winehq.org/pipermail/wine-patches/2008-July/058460.html but got neither it applied nor any other comment. As far as I can tell, I complied with all the guidelines at http://www.winehq.org/site/sending_patches. Is it the editing of comments not strictly part of the new test (but, I'd claim, valuable for the future expansion of those test cases to cover the remaining flag option combinations)? The introduction of a new buffer in the test handler? That the test handler maybe should be a patch in itself (although the standard practise seems to be to bundle them)? The code in the new test-cases? That the editor.c patch should adopt a different approach? That aside from my own patch to DC++ (discussed in the numbered bug report) I haven't looked for or found a real-world program using this (in which case, should I first get the DC++ patch in, then point to that as an example of such a real-world program; I have been avoiding that precisely because I primarily use WINE and don't want to break things for myself in the indeterminately long period after such an application to the main DC++ tree)? Something else? Aside from the test cases, this is literally a one-bit change from 0 to 1 and it's been a weeks and a resend and I have no idea what the status is, how likely it is ever to be committed, or how I might have screwed up. Feedback would be appreciated. -Dustin Brody

2 2

Re: [PATCH] gdiplus: Detect integer overflow in GdipCreateBitmapFromScan0. (try 2)
by Lei Zhang 28 Jul '08

28 Jul '08

On Mon, Jul 21, 2008 at 5:59 PM, Lei Zhang <thestig(a)google.com> wrote: > Hi, > > This patch does a better job of detecting integer overflow. > > The tests added reproduce the behavior in bug 14536, which this patch fixes. > Anything wrong with this patch?

1 0

RE: [1/3] WineD3D: Use C bitfields to compact the ffp description
by Stefan Dösinger 28 Jul '08

28 Jul '08

Don't apply the patches yet, they break the d3d7 visual tests > -----Original Message----- > From: wine-patches-bounces(a)winehq.org [mailto:wine-patches- > bounces(a)winehq.org] On Behalf Of Stefan Dösinger > Sent: Monday, July 28, 2008 11:44 AM > To: wine-patches(a)winehq.org > Subject: [1/3] WineD3D: Use C bitfields to compact the ffp description >

1 0

Re: d3dx8: [patch 2/2] Implement D3DXBoxBoundProbe
by H. Verbeet 28 Jul '08

28 Jul '08

2008/7/28 David Adam <david.adam.cnrs(a)gmail.com>: > + ortho = D3DXVec3Dot(praydirection, &normal[i]); > + if ( ortho && D3DXVec3Subtract(&difference, &point, prayposition) ) > + { > + t = D3DXVec3Dot(&difference, &normal[i]) / ortho; While correct, due to the fact that the box is axis-aligned, this just turns into an expensive way to calculate t = (point->x - prayposition->x) / praydirection->x t = (point->y - prayposition->y) / praydirection->y t = (point->z - prayposition->x) / praydirection->z depending on the face you're testing against. I think performance wise it makes more sense to just write it out for each face, and get rid of the for-loop and normal. > + if ( number_intersection == 2 ) return TRUE; This implies that eg. a ray that starts inside the box doesn't intersect it. Is that intentional? Otherwise you could return early as soon as you find an intersection, and skip testing the other faces. Also note that at least in theory the ray can intersect all six faces of the box if it goes through two opposing corners.

1 0

Re: wined3d: in surface Blt when source and destination are not the same only lock the part of the destination surface that is requested to copy to.
by H. Verbeet 28 Jul '08

28 Jul '08

2008/7/28 Aric Stewart <aric(a)codeweavers.com>: > + if (Src != This) > + { > + xdst.top = 0; > + xdst.bottom = DestRect->bottom - DestRect->top; > + xdst.left = 0; > + xdst.right = DestRect->right - DestRect->left; > + } This will still break the rectangle bounds check further down (around line 940), and anything else that depends on the position of the rectangle within the surface. Come to think of it, the rectangle bounds check should probably be done before trying to lock the surface. Something else I just thought of is that LockRect() probably won't handle mirrored or flipped destination rectangles very well.

2 2

Re: ole32: fix offsets managment
by f.dorin＠free.fr 28 Jul '08

28 Jul '08

>Thank you for your first contribution, but first of all the subject >isn't correct as the patch is to rpcrt4 instead of ole32. Oups, sorry. My apologies for this mistake. But I'm currently working on ole32 and I forgot this file belongs to rpcrt4. I will pay attention next time. >Second of >all, the patch is not correct as it is widl that is generating the >wrong format string here: > >http://www.winehq.org/pipermail/wine-patches/2008-June/056332.html >http://www.winehq.org/pipermail/wine-devel/2008-June/066587.html Thanks for the links. I didn't think one moment it can be a widl bug. I believed it was a rpcrt4 one. François DORIN

1 0

Re: [PATCH] ntdll: use symbols, add documentation for i386 page faulterror code
by Dmitry Timoshkov 28 Jul '08

28 Jul '08

"John Reiser" <jreiser(a)BitWagon.com> wrote: > diff --git a/include/winnt.h b/include/winnt.h > index e8a37f5..ad2f674 100644 > --- a/include/winnt.h > +++ b/include/winnt.h > @@ -812,9 +812,24 @@ typedef struct _CONTEXT86 > > typedef CONTEXT86 CONTEXT; > > -#define EXCEPTION_READ_FAULT 0 > -#define EXCEPTION_WRITE_FAULT 1 > -#define EXCEPTION_EXECUTE_FAULT 8 > +/* Page Fault Error Code. > + * Intel 64 and IA-32 Architectures Software Developer's Manual, Volume 3A: > + * System Programming Guide, Part 1; Figure 5-9, Page-Fault Error Code, p.5-55. > + * http://www.intel.com/design/processor/manuals/253668.pdf > + * linux/arch/x86/mm/fault.c do_page_fault() > + */ > +/* This hardware bit is ignored by shifting it off the bottom. > + *#define EXCEPTION_PAGE_NOT_P (0<<0) > + *#define EXCEPTION_PROT_VIOL (1<<0) > + * > + * Hardware delivers these bits [below] one position to the left. > + */ > +#define EXCEPTION_READ_FAULT (0<<0) > +#define EXCEPTION_WRITE_FAULT (1<<0) /* 1 */ > +#define EXCEPTION_KERNEL_MODE (0<<1) > +#define EXCEPTION_USER_MODE (1<<1) /* 2 */ > +#define EXCEPTION_RSV_PAGETAB (1<<2) /* 4 */ > +#define EXCEPTION_EXECUTE_FAULT (1<<3) /* 8 */ These changes are not compatible with PSDK. -- Dmitry.

1 0

Re: wined3d: universal surface convertor function for unsigned integer color formats(5th attempt)
by Stefan Dösinger 28 Jul '08

28 Jul '08

> Well, the last attempt (with added big-endian support) was submitted several > days ago, and again - no feedback, and patch still isn't accepted. > What's wrong with patch now? Sorry, I must have missed this on Wine-patches again :-( It look ok to me. The endianess #ifdefs look strange, but I don't know how that's supposed to be handled. PS: Sorry, I lost the original mail. I don't know how to supply a reference ID to outlook, so I broke the thread appart

1 0

Re: [WideChar conversion improvements - 5/5] Add a lot of WideCharToMultiByte tests
by Vitaliy Margolen 28 Jul '08

28 Jul '08

Colin Finck wrote: > Remove todo_wine from two tests, which now pass under Wine after the > changes in my previous patches. You have to do that in the patch that fixes the test. Each patch have to be autonomous and have all tests pass before and after it. Vitaliy.

2 2

Re: [3/5] WineD3D: Optimize the fragment processing description
by H. Verbeet 28 Jul '08

28 Jul '08

Is there any particular reason you're not simply using the compiler's support for bit-fields?

3 4

Re: [10/10] [try 5] appwiz.cpl: Gather extra information for SupportInfo dialog
by Owen Rudge 28 Jul '08

28 Jul '08

> 3 files changed, 86 insertions(+), 0 deletions(-) I'm just wondering if there's a reason this patch wasn't committed with the other appwiz patches? The patch applies cleanly to the current git master. If there's anything obviously wrong with it that I've not spotted, please do let me know so I can fix it. Cheers, -- Owen Rudge http://www.owenrudge.net/

2 1

IWineD3DDeviceImpl_SetRenderState
by Chris Ahrendt 28 Jul '08

28 Jul '08

Attached to this note is a patch I have been working on for the past few days to finish out the above function. What I did was use MSDN for the definition : /***** * Get / Set Render States * TODO: Verify against dx9 definitions * Direct X 9 Definition: Parameters State [in] Device state variable that is being modified. This parameter can be any member of the D3DRENDERSTATETYPE enumerated type. Value[in] New value for the device render state to be set. The meaning of this parameter is dependent on the value specified for State. For example, if State were D3DRS_SHADEMODE, the second parameter would be one member of the D3DSHADEMODE enumerated type. Return Values If the method succeeds, the return value is D3D_OK. D3DERR_INVALIDCALL is returned if one of the arguments is invalid. Requirements Header: Declared in D3D9.h should I open a bug and then post this to the patches list... Please let me know what you think. The Following States have no rules for their valid values associated with them as far as I can find. WINED3DRS_BLENDOPALPHA: WINED3DRS_DEPTHBIAS: WINED3DRS_SRGBWRITEENABLE: WINED3DRS_BLENDFACTOR: WINED3DRS_COLORWRITEENABLE1: WINED3DRS_COLORWRITEENABLE2: WINED3DRS_COLORWRITEENABLE3: WINED3DRS_ADAPTIVETESS_X: WINED3DRS_ADAPTIVETESS_Y: WINED3DRS_ADAPTIVETESS_Z: WINED3DRS_ADAPTIVETESS_W: WINED3DRS_SLOPESCALEDEPTHBIAS: WINED3DRS_TWEENFACTOR: WINED3DRS_COLORWRITEENABLE: WINED3DRS_POINTSIZE_MAX: WINED3DRS_WRAP0: WINED3DRS_WRAP1: WINED3DRS_WRAP2: WINED3DRS_WRAP3: WINED3DRS_WRAP4: WINED3DRS_WRAP5: WINED3DRS_WRAP6: WINED3DRS_WRAP7: WINED3DRS_WRAP8: WINED3DRS_WRAP9: WINED3DRS_WRAP10: WINED3DRS_WRAP11: WINED3DRS_WRAP12: WINED3DRS_WRAP13: WINED3DRS_WRAP14: WINED3DRS_WRAP15: WINED3DRS_STENCILREF: WINED3DRS_FOGSTART: WINED3DRS_FOGEND: WINED3DRS_FOGDENSITY: WINED3DRS_CLIPPLANEENABLE: WINED3DRS_POINTSIZE: WINED3DRS_POINTSIZE_MIN: WINED3DRS_POINTSCALE_A: WINED3DRS_POINTSCALE_B: WINED3DRS_POINTSCALE_C: Chris --- device_old.c 2008-07-25 11:42:25.000000000 -0400 +++ device.c 2008-07-26 21:07:45.000000000 -0400 @@ -34,6 +34,11 @@ WINE_DEFAULT_DEBUG_CHANNEL(d3d); #define GLINFO_LOCATION This->adapter->gl_info +#define D3DBLEND_INVSRCCOLOR 4 +#define WINED3DDMT_ENABLE 0 +#define WINED3DDMT_DISABLE 1 +#define WINED3DBLEND_INVSRCCOLOR2 17 +#define WINED3DBLEND_SRCCOLOR2 16 /* Define the default light parameters as specified by MSDN */ const WINED3DLIGHT WINED3D_default_light = { @@ -3249,14 +3254,280 @@ /***** * Get / Set Render States * TODO: Verify against dx9 definitions - *****/ + * + + Direct X 9 Definition: + Parameters + State + [in] Device state variable that is being modified. This parameter + can be any member of the D3DRENDERSTATETYPE enumerated type. + Value[in] New value for the device render state to be set. + The meaning of this parameter is dependent on the value specified + for State. For example, if State were D3DRS_SHADEMODE, the second + parameter would be one member of the D3DSHADEMODE enumerated type. + + Return Values + + If the method succeeds, the return value is D3D_OK. D3DERR_INVALIDCALL is returned if one of the arguments is invalid. +Requirements + +Header: Declared in D3D9.h + + ****/ static HRESULT WINAPI IWineD3DDeviceImpl_SetRenderState(IWineD3DDevice *iface, WINED3DRENDERSTATETYPE State, DWORD Value) { IWineD3DDeviceImpl *This = (IWineD3DDeviceImpl *)iface; DWORD oldValue = This->stateBlock->renderState[State]; TRACE("(%p)->state = %s(%d), value = %d\n", This, debug_d3drenderstate(State), State, Value); + + switch(State) + { + case WINED3DRS_SEPARATEALPHABLENDENABLE: + WINED3DRS_TWOSIDEDSTENCILMODE: + WINED3DRS_ENABLEADAPTIVETESSELLATION: + WINED3DRS_ANTIALIASEDLINEENABLE: + WINED3DRS_SCISSORTESTENABLE: + WINED3DRS_INDEXEDVERTEXBLENDENABLE: + WINED3DRS_MULTISAMPLEANTIALIAS: + WINED3DRS_POINTSPRITEENABLE: + WINED3DRS_POINTSCALEENABLE: + WINED3DRS_NORMALIZENORMALS: + WINED3DRS_LOCALVIEWER: + WINED3DRS_COLORVERTEX: + WINED3DRS_CLIPPING: + WINED3DRS_ZENABLE: + WINED3DRS_STENCILENABLE: + WINED3DRS_RANGEFOGENABLE: + WINED3DRS_ALPHABLENDENABLE: + WINED3DRS_DITHERENABLE: + WINED3DRS_ZWRITEENABLE: + WINED3DRS_ALPHATESTENABLE: + WINED3DRS_FOGENABLE: + WINED3DRS_SPECULARENABLE: + WINED3DRS_LIGHTING: + WINED3DRS_LASTPIXEL: + if ((Value == TRUE) || + (Value == FALSE)) break; + return WINED3DERR_INVALIDCALL; + break; + + case WINED3DRS_FILLMODE: + if ((Value == WINED3DFILL_POINT) || + (Value == WINED3DFILL_WIREFRAME) || + (Value == WINED3DFILL_SOLID)) break; + return WINED3DERR_INVALIDCALL; + break; + + case WINED3DRS_SHADEMODE: + if ((Value == WINED3DSHADE_FLAT) || + (Value == WINED3DSHADE_GOURAUD) || + (Value == WINED3DSHADE_PHONG)) break; + return WINED3DERR_INVALIDCALL; + break; + + case WINED3DRS_SRCBLENDALPHA: + case WINED3DRS_DESTBLENDALPHA: + case WINED3DRS_DESTBLEND: + case WINED3DRS_SRCBLEND: + if ((Value == WINED3DBLEND_ZERO) || + (Value == WINED3DBLEND_ONE) || + (Value == WINED3DBLEND_SRCCOLOR) || + (Value == WINED3DBLEND_INVSRCCOLOR) || + (Value == WINED3DBLEND_SRCALPHA) || + (Value == WINED3DBLEND_INVSRCALPHA) || + (Value == WINED3DBLEND_DESTALPHA) || + (Value == WINED3DBLEND_INVDESTALPHA) || + (Value == WINED3DBLEND_DESTCOLOR) || + (Value == WINED3DBLEND_INVDESTCOLOR) || + (Value == WINED3DBLEND_SRCALPHASAT) || + (Value == WINED3DBLEND_BOTHSRCALPHA) || + (Value == WINED3DBLEND_BOTHINVSRCALPHA) || + (Value == WINED3DBLEND_BLENDFACTOR) || + (Value == WINED3DBLEND_INVBLENDFACTOR) || + (Value == WINED3DBLEND_SRCCOLOR2) || + (Value == WINED3DBLEND_INVSRCCOLOR2)) break; + return WINED3DERR_INVALIDCALL; + break; + + case WINED3DRS_CULLMODE: + if ((Value == WINED3DCULL_NONE) || + (Value == WINED3DCULL_CW) || + (Value == WINED3DCULL_CCW)) break; + return WINED3DERR_INVALIDCALL; + break; + + case WINED3DRS_CCW_STENCILFUNC: + WINED3DRS_STENCILFUNC: + WINED3DRS_ALPHAFUNC: + WINED3DRS_ZFUNC: + if ((Value == WINED3DCMP_NEVER) || + (Value == WINED3DCMP_LESS) || + (Value == WINED3DCMP_EQUAL) || + (Value == WINED3DCMP_LESSEQUAL) || + (Value == WINED3DCMP_GREATER) || + (Value == WINED3DCMP_NOTEQUAL) || + (Value == WINED3DCMP_GREATEREQUAL) || + (Value == WINED3DCMP_ALWAYS)) break; + return WINED3DERR_INVALIDCALL; + break; + + case WINED3DRS_ALPHAREF: + /* Valid values are between 0 and FF */ + if ((Value >= 0) || + (Value <= 0xFF)) break; + return WINED3DERR_INVALIDCALL; + break; + + case WINED3DRS_FOGCOLOR: + /* Valid Values are between 0 and FFFF (4 bytes alpha, red, green, and blue)) */ + if ((Value >= 0) || + (Value <= 0xFFFF)) break; + return WINED3DERR_INVALIDCALL; + break; + + case WINED3DRS_FOGVERTEXMODE: + WINED3DRS_FOGTABLEMODE: + if ((Value == WINED3DFOG_NONE) || + (Value == WINED3DFOG_EXP) || + (Value == WINED3DFOG_EXP2) || + (Value == WINED3DFOG_LINEAR)) break; + return WINED3DERR_INVALIDCALL; + break; + + case WINED3DRS_CCW_STENCILFAIL: + WINED3DRS_CCW_STENCILZFAIL: + WINED3DRS_CCW_STENCILPASS: + WINED3DRS_STENCILPASS: + WINED3DRS_STENCILZFAIL: + WINED3DRS_STENCILFAIL: + if ((Value == WINED3DSTENCILOP_KEEP) || + (Value == WINED3DSTENCILOP_ZERO) || + (Value == WINED3DSTENCILOP_REPLACE) || + (Value == WINED3DSTENCILOP_INCRSAT) || + (Value == WINED3DSTENCILOP_DECRSAT) || + (Value == WINED3DSTENCILOP_INVERT) || + (Value == WINED3DSTENCILOP_INCR) || + (Value == WINED3DSTENCILOP_DECR)) break; + return WINED3DERR_INVALIDCALL; + break; + + case WINED3DRS_MULTISAMPLEMASK: + WINED3DRS_AMBIENT: + WINED3DRS_TEXTUREFACTOR: + WINED3DRS_STENCILWRITEMASK: + WINED3DRS_STENCILMASK: + if ((Value >= 0) || + (Value <=0xFFFFFFFF)) break; + return WINED3DERR_INVALIDCALL; + break; + + case WINED3DRS_SPECULARMATERIALSOURCE: + WINED3DRS_AMBIENTMATERIALSOURCE: + WINED3DRS_EMISSIVEMATERIALSOURCE: + WINED3DRS_DIFFUSEMATERIALSOURCE: + if ((Value == WINED3DMCS_MATERIAL) || + (Value == WINED3DMCS_COLOR1) || + (Value == WINED3DMCS_COLOR2)) break; + return WINED3DERR_INVALIDCALL; + break; + + case WINED3DRS_VERTEXBLEND: + if ((Value == WINED3DVBF_DISABLE) || + (Value == WINED3DVBF_1WEIGHTS) || + (Value == WINED3DVBF_2WEIGHTS) || + (Value == WINED3DVBF_3WEIGHTS) || + (Value == WINED3DVBF_TWEENING) || + (Value == WINED3DVBF_0WEIGHTS)) break; + return WINED3DERR_INVALIDCALL; + break; + + case WINED3DRS_PATCHEDGESTYLE: + if ((Value == WINED3DPATCHEDGE_DISCRETE) || + (Value == WINED3DPATCHEDGE_CONTINUOUS)) break; + return WINED3DERR_INVALIDCALL; + break; + + case WINED3DRS_DEBUGMONITORTOKEN: + if ((Value == WINED3DDMT_ENABLE) || + (Value == WINED3DDMT_DISABLE)) break; + return WINED3DERR_INVALIDCALL; + break; + + case WINED3DRS_BLENDOP: + if ((Value == WINED3DBLENDOP_ADD) || + (Value == WINED3DBLENDOP_SUBTRACT) || + (Value == WINED3DBLENDOP_REVSUBTRACT) || + (Value == WINED3DBLENDOP_MIN) || + (Value == WINED3DBLENDOP_MAX)) break; + return WINED3DERR_INVALIDCALL; + break; + + case WINED3DRS_NORMALDEGREE: + WINED3DRS_POSITIONDEGREE: + if ((Value == WINED3DDEGREE_LINEAR) || + (Value == WINED3DDEGREE_QUADRATIC) || + (Value == WINED3DDEGREE_CUBIC) || + (Value == WINED3DDEGREE_QUINTIC)) break; + return WINED3DERR_INVALIDCALL; + break; + + case WINED3DRS_MINTESSELLATIONLEVEL: + WINED3DRS_MAXTESSELLATIONLEVEL: + if ((Value == WINED3DDEGREE_LINEAR) || + (Value == WINED3DDEGREE_QUADRATIC) || + (Value == WINED3DDEGREE_CUBIC) || + (Value == WINED3DDEGREE_QUINTIC)) break; + return WINED3DERR_INVALIDCALL; + break; + + case WINED3DRS_BLENDOPALPHA: + WINED3DRS_DEPTHBIAS: + WINED3DRS_SRGBWRITEENABLE: + WINED3DRS_BLENDFACTOR: + WINED3DRS_COLORWRITEENABLE1: + WINED3DRS_COLORWRITEENABLE2: + WINED3DRS_COLORWRITEENABLE3: + WINED3DRS_ADAPTIVETESS_X: + WINED3DRS_ADAPTIVETESS_Y: + WINED3DRS_ADAPTIVETESS_Z: + WINED3DRS_ADAPTIVETESS_W: + WINED3DRS_SLOPESCALEDEPTHBIAS: + WINED3DRS_TWEENFACTOR: + WINED3DRS_COLORWRITEENABLE: + WINED3DRS_POINTSIZE_MAX: + WINED3DRS_WRAP0: + WINED3DRS_WRAP1: + WINED3DRS_WRAP2: + WINED3DRS_WRAP3: + WINED3DRS_WRAP4: + WINED3DRS_WRAP5: + WINED3DRS_WRAP6: + WINED3DRS_WRAP7: + WINED3DRS_WRAP8: + WINED3DRS_WRAP9: + WINED3DRS_WRAP10: + WINED3DRS_WRAP11: + WINED3DRS_WRAP12: + WINED3DRS_WRAP13: + WINED3DRS_WRAP14: + WINED3DRS_WRAP15: + WINED3DRS_STENCILREF: + WINED3DRS_FOGSTART: + WINED3DRS_FOGEND: + WINED3DRS_FOGDENSITY: + WINED3DRS_CLIPPLANEENABLE: + WINED3DRS_POINTSIZE: + WINED3DRS_POINTSIZE_MIN: + WINED3DRS_POINTSCALE_A: + WINED3DRS_POINTSCALE_B: + WINED3DRS_POINTSCALE_C: + break; + Default: + return WINED3DERR_INVALIDCALL; + } + This->updateStateBlock->changed.renderState[State] = TRUE; This->updateStateBlock->renderState[State] = Value;

6 19

Re: dpnet: #3 Add stubbed DirectPlay8Peer:Close
by Alexandre Julliard 28 Jul '08

28 Jul '08

Alexander Nicolaysen Sørnes <alex(a)thehandofagony.com> writes: > + > static const IDirectPlay8PeerVtbl DirectPlay8Peer_Vtbl = > { > IDirectPlay8PeerImpl_QueryInterface, > IDirectPlay8PeerImpl_AddRef, > IDirectPlay8PeerImpl_Release, > IDirectPlay8PeerImpl_Initialize, > - IDirectPlay8PeerImpl_EnumServiceProviders > + IDirectPlay8PeerImpl_EnumServiceProviders, > + NULL, > + NULL, > + NULL, > + NULL, > + NULL, > + NULL, > + NULL, > + NULL, > + NULL, > + NULL, > + NULL, > + NULL, > + NULL, > + NULL, > + NULL, > + NULL, > + NULL, > + NULL, > + NULL, > + IDirectPlay8PeerImpl_Close Don't do that, partial vtables lead to hard to find crashes. The vtable should be completely initialized from the start with stub functions. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: shdocvw: rudimentary implementation of CLSID_InternetShortcut
by Alexandre Julliard 28 Jul '08

28 Jul '08

"Damjan Jovanovic" <damjan.jov(a)gmail.com> writes: > +#define IMPL(class, member, pointer) ((class*) (((char*) pointer) - offsetof(class, member))) Please don't invent yet another macro for this. Use inline functions instead. > +typedef struct > +{ > + IUnknown unknown; > + IUniformResourceLocatorA uniformResourceLocatorA; > + IUniformResourceLocatorW uniformResourceLocatorW; > + IPersistFile persistFile; There's no need for an explicit IUnknown vtable. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: dlls/winedos/vxd.c
by Francois Gouget 28 Jul '08

28 Jul '08

On Mon, 28 Jul 2008, Gerald Pfeifer wrote: > Seems like I'm losing the argument on the GCC side, so we'll really > need to address those six or so warnings in our codebase by adding > return statements I guess. Hopefully they won't add a check complaining that this is an unreachale statement next. Are all the other cases unreachable too? static DWORD CALLBACK timer_thread( void *arg ) { DWORD *system_time = arg; for (;;) { *system_time = GetTickCount(); Sleep( 55 ); } return 0; } -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ The software said it requires Win95 or better, so I installed Linux.

1 0

Re: d3dx8: patch1: Implement D3DXBoxBoundProbe
by H. Verbeet 28 Jul '08

28 Jul '08

2008/7/27 David Adam <david.adam.cnrs(a)gmail.com>: > + ortho = D3DXVec3Dot(praydirection, &normal[i]); > + if ( ortho ) > + { > + t = D3DXVec3Dot(praydirection, &normal[i]) / ortho; This doesn't make much sense, t will always be close to zero this way. > + rayposition.x = -3.0f; rayposition.y = 1.0f; rayposition.z = -2.0f; > + result = D3DXBoxBoundProbe(&bottom_point, &top_point, &rayposition, &raydirection); > + ok(result == TRUE, "expected TRUE, received FALSE\n"); This succeeds because rayposition lies on one of the faces of the box. I think it would be useful to also add a test where rayposition lies outside the box but where the ray still intersects the box. In general, also note that the fact that the box is always axis-aligned means the normal is always 0 in two of the three directions. This simplifies the equations a bit.

1 1

Re: [WideChar conversion improvements - 2/5] Implement new versions ofwctomb and wcstombs
by Dmitry Timoshkov 28 Jul '08

28 Jul '08

"Colin Finck" <mail(a)colinfinck.de> wrote: > -INT CDECL MSVCRT_wctomb( char *dst, MSVCRT_wchar_t ch ) > +INT CDECL MSVCRT_wctomb(char *mbchar, MSVCRT_wchar_t wchar) What's the point of the above change? > { > - return WideCharToMultiByte( CP_ACP, 0, &ch, 1, dst, 6, NULL, NULL ); > + BOOL bUsedDefaultChar; > + char chMultiByte[MSVCRT_MB_LEN_MAX]; > + int nBytes; Please don't use ugly mixed case variable names. Same for other tests. > + > + /* At least one parameter needs to be given, the length of a null character cannot be queried (verified by tests > under WinXP SP2) */ > + if(!mbchar && !wchar) > + return 0; Please keep line length close to 80 columns limit. What are you calling a "null character" here? A NULL pointer is not a NUL character. What happens in the code below if mbchar is not NULL but wchar is? > + > + /* Use WideCharToMultiByte for doing the conversion using the codepage currently set with setlocale() */ > + nBytes = WideCharToMultiByte(MSVCRT___lc_codepage, 0, &wchar, 1, chMultiByte, MSVCRT_MB_LEN_MAX, NULL, > &bUsedDefaultChar); -- Dmitry.

3 3

Re: [5/5] WineD3D: Implement an ARB_fragmen_program fixed function pipeline
by H. Verbeet 28 Jul '08

28 Jul '08

2008/7/27 Stefan Dösinger <stefan(a)codeweavers.com>: > Unfortunately, even despite the preparations in the last patches, this patch > is still kinda huge because I have to replace all the fragment processing at > once. > This enables the replacement pretty much unconditionally... do we want that? It also might make sense to give this its own file.

2 2

Re: winhttp: tests/winhttp.c: Add test for WinHttpSendRequest
by Hans Leidekker 28 Jul '08

28 Jul '08

On Friday 25 July 2008 22:13:18 Zac Brown wrote: > +#include <wchar.h> > > #include <windef.h> > #include <winbase.h> > +#include <windows.h> You shouldn't need these. -Hans

2 1

Re: crypt32: Add test showing only file header is checked for cabinet files
by Detlef Riekenberg 27 Jul '08

27 Jul '08

On Fr, 2008-07-25 at 11:28 -0700, Juan Lang wrote: > + /* Create a file with just the .cab header 'MSCF' */ > + file = CreateFileW( CreateFileW is not supported on win9x. (returned NULL with ERROR_CALL_NOT_IMPLEMENTED) I have a Patch ready for the other use of CreateFileW in dlls/crypt32/tests/sip.c -- By by ... Detlef

1 0

Re: wined3d: universal surface convertor function for unsigned integer color formats(5th attempt)
by Philip Nilsson 27 Jul '08

27 Jul '08

On Thu, Jul 24, 2008 at 08:14:40PM +0400, Victor Eremin wrote: > Supports conversion between most of "unsigned color" argb/xrgb > surface formats (D3DFMT_A8R8G8B8, D3DFMT_A8R3G3B2, etc), and > "luminosity" color formats (D3DFMT_L8, etc), > excluding D3DFMT_A16R16G16B16, D3DFMT_A8P8, D3DFMT_P8 and D3DFMT_A1. > luminosity to argb/xrgb (and vice versa) conversions are not supported > dlls/wined3d/surface_base.c | 218 ++++++++++++++++++++++++++++++++++++++- I think it would be a better idea to put most of the functions in utils.c, as they are utilities, and may have utility in other places (for example argb_to_fmt does something similar, although I'm not sure if more format conversion is neccessary.) > +inline BYTE getMaskShift(DWORD mask){ Most functions here do not use camelCase. > +void mask_erase(DWORD dstMask, BYTE pixelSize, I'd make all functions static that have no use outside their file to get nicer warnings (function unused) and smaller binaries. I wonder how static and inline interacts... > +/* > + * Warning: this won't convert all formats > + */ The FIXMEs should be enough. > struct d3dfmt_convertor_desc convertors[] = { > - {WINED3DFMT_R32F, WINED3DFMT_R16F, convert_r32f_r16f}, > + {WINED3DFMT_R32F, WINED3DFMT_R16F, convert_r32f_r16f} > }; I think my neckbeard just caught fire! A lot of tests would be nice (although I guess most of the functionality is already tested.) I hope this is somewhat helpful.

1 0

Bizarre idea: creating our own extension to msi for cross-platform installers
by Scott Ritchie 27 Jul '08

27 Jul '08

Just a crazy thought, but... What if we created a standard for passing some sort of wine-specific metadata in an MSI file? Windows would ignore it, but application developers could use it to include some helpful Linux-specific Wine instructions like what windows version to use, a custom .desktop file, or even instructions to install into a completely independent Wine prefix. This way, a single .msi file could be a true universal installer for both Windows machines and Linux machines. Moreover, there'd be less of a need to create custom Wine packages for applications like Picassa since a lot of that functionality would be abstracted into Wine itself. Thoughts? Thanks, Scott Ritchie

4 4

Re: ole32: fix a bad return value for DefaultHandler_SetExtent
by Rob Shearman 27 Jul '08

27 Jul '08

2008/7/26 <f.dorin(a)free.fr>: > fix a bad return value for DefaultHandler_SetExtent implemented in defaulthandler.c > > ChangeLog entry: > * real name : François DORIN > * email : f.dorin(a)free.fr > * description : when the server is running, the return value must be the value of the delegating method and not OLE_E_NOTRUNNING. Good spot. Your patch looks good to me. -- Rob Shearman

1 0

Re: ole32: fix offsets managment
by Rob Shearman 27 Jul '08

27 Jul '08

2008/7/26 <f.dorin(a)free.fr>: > It's my first patch. So, if something is wrong, don't hesitate to notify me ! > > ChangeLog entry : > * real name : François DORIN > * email : f.dorin(a)free.fr > * description : offsets can be negative. It is necessary to treat them as signed numbers to avoid unexpected behaviors. Thank you for your first contribution, but first of all the subject isn't correct as the patch is to rpcrt4 instead of ole32. Second of all, the patch is not correct as it is widl that is generating the wrong format string here: http://www.winehq.org/pipermail/wine-patches/2008-June/056332.html http://www.winehq.org/pipermail/wine-devel/2008-June/066587.html -- Rob Shearman

1 0

re: ole32: fix offsets managment
by Dan Kegel 27 Jul '08

27 Jul '08

f.dorin at free.fr wrote: > It's my first patch. So, if something is wrong, don't hesitate to notify me ! > ... > + if (*(const WORD*)pFormat) pointer_desc = pFormat + *(const SHORT*)pFormat; Hi François! A few quick notes: 1) it's helpful if you can say what app each patch fixes, and what the symptom was 2) it's very helpful if you can include a conformance test with each patch. It can probably be just a few lines added to an existing conformance test. 3) In this patch, it looks kind of funny to use WORD and SHORT for same type, may as well change the type in the conditional, too. - Dan

1 0

Re: GL_INVALID_ENUM errors with FBO
by Vitaliy Margolen 27 Jul '08

27 Jul '08

H. Verbeet wrote: > 2008/7/24 Vitaliy Margolen <wine-devel(a)kievinfo.com>: >>>> side affects. But the full version of Psychonauts crashes after initial >>>> videos. Same as it did when we had problems with multi-threaded games. >>>> >>> Is that a regression introduced by the patch? >> Yes. Without the patch everything works. With the patch it crashes. > It's a bit unfortunate that it only happens in the full version. Have > you got any idea which part of that patch is causing the crash? Is it > the Clear call again? In the original case it was pretty clear that > calling apply_fbo_state() without activating the context for the > current thread caused issues, but as far as I can see that part should > still work correctly with my patch. It's this part: diff --git a/dlls/wined3d/drawprim.c b/dlls/wined3d/drawprim.c index 9a47f8b..f2ab699 100644 --- a/dlls/wined3d/drawprim.c +++ b/dlls/wined3d/drawprim.c @@ -974,6 +974,7 @@ void drawPrimitive(IWineD3DDevice *iface, /* Signals other modules that a drawing is in progress and the stateblock finalized */ This->isInDraw = TRUE; + ActivateContext(This, This->render_targets[0], CTXUSAGE_DRAWPRIM); /* Ok, we will be updating the screen from here onwards so grab the lock */ @@ -983,7 +984,6 @@ void drawPrimitive(IWineD3DDevice *iface, LEAVE_GL(); } - ActivateContext(This, This->render_targets[0], CTXUSAGE_DRAWPRIM); ENTER_GL(); if (This->stencilBufferTarget) {

3 10

Path reset on wine update
by Massimo Del Fedele 26 Jul '08

26 Jul '08

Maybe that's an already asked question, but.... why does wine reset path on each wine update ? That's becoming annoying... I mus reedit registry on each update to make my apps work again. Ciao Max

3 5

iTunes ipod support
by Mathias Karwath 26 Jul '08

26 Jul '08

Hi, im from Germany and i would use iTunes with the iPod Touch. I saw a Post on the Mailing list that its possible to Sync the Touch over iTunes using wine, but its not implemented yet. Is it possible to get the Patches? Im suck of using iTunes in a VM with Windows on my System. So i would like to test the Patches. Please! :) regards Mathias Karwath

3 2

Signature checking in Wine
by Juan Lang 26 Jul '08

26 Jul '08

Folks, now that there's a bit more code in Wine that "verifies" file signatures, I wanted to make sure everyone understands its current limitations. 1. It's only implemented for PE files and .cab files. Windows supports more formats, of course, notably MSI files (see bug 11759, http://bugs.winehq.org/show_bug.cgi?id=11759 ) 2. Wine doesn't actually verify that the signature in the file matches the file being checked. Any valid certificate could be put into a file, and Wine would accept it. I don't consider this a serious security flaw, because I think the concept of a signature validating anything useful about a binary is flawed. Hence I'm not terribly motivated to fix it. Flame away, --Juan

4 5

Midterm evaluations for summer of code students
by Maarten Lankhorst 25 Jul '08

25 Jul '08

Hi students, As you might know it's time for midterm evaluations. Unfortunately for some students I haven't seen the progress they made, and I highly encourage all students to send their patches early and often, even if it's not yet finished. Also, I would like to hear from all students now a reflection. What went well, and what didn't, and what did you accomplish so far? :-) Cheers, Maarten.

7 6

Re: [try 4] gdi32/tests: Add tests for GdiGetCodePage.
by Alexandre Julliard 25 Jul '08

25 Jul '08

"Huang, Zhangrong" <hzhrong(a)gmail.com> writes: > This patch add tests for GdiGetCodePage, all failed stuff has been > marked as todo_wine. It doesn't work here: ../../../tools/runtest -q -P wine -M gdi32.dll -T ../../.. -p gdi32_test.exe.so font.c && touch font.ok font.c:850: Test succeeded inside todo block: data index 2: expected font codepage 1252, got 1252 font.c:853: Test succeeded inside todo block: data index 2: GdiGetCodePage should have returned 1252, got 1252 font.c:850: Test succeeded inside todo block: data index 3: expected font codepage 1252, got 1252 font.c:853: Test succeeded inside todo block: data index 3: GdiGetCodePage should have returned 1252, got 1252 font.c:850: Test succeeded inside todo block: data index 15: expected font codepage 1253, got 1253 font.c:853: Test succeeded inside todo block: data index 15: GdiGetCodePage should have returned 1253, got 1253 font.c:850: Test succeeded inside todo block: data index 16: expected font codepage 1251, got 1251 font.c:853: Test succeeded inside todo block: data index 16: GdiGetCodePage should have returned 1251, got 1251 font.c:1579: Tests skipped: Symbol or Wingdings is not installed font.c:1595: Tests skipped: Symbol or Wingdings is not installed font.c:1749: Tests skipped: Symbol is not installed font.c:2557: Tests skipped: Arial Black or Symbol/Wingdings is not installed font.c:1975: Tests skipped: Font DejaVu Sans doesn't contain 'x', skipping the test font.c:1975: Tests skipped: Font DejaVu Sans Condensed doesn't contain 'x', skipping the test font.c:1975: Tests skipped: Font OpenSymbol doesn't contain 'x', skipping the test make[2]: *** [font.ok] Error 8 -- Alexandre Julliard julliard(a)winehq.org

3 2

DSurface optimization, comments requested
by Aric Stewart 25 Jul '08

25 Jul '08

Hi there, I was playing with a older Japanese side scrolling shooter benchmark and was getting 4.3 frames per second. Some digging revealed that the game made extensive use of Blt on gdi surfaces and it looks like the current implementation of Blt actually locks the entire destination surface to blt to it. This then causes the Unlock to copy the entire screen out. This means that every time any sprite moved the entire screen redrew. I threw together this patch, which seems far to simple to be at all correct, and suddenly i was getting 28.8 frames per second. I know it is not fully correct because a a portion of the game (drawn by FastBlt it looks like) stopped rendering correctly with this patch. But I thought it may get someone who knows that area better thinking about it. If we can optimize this then a number of the scrolling shooter games will become playable. I am told that these style games are still very popular here. And if said people in the know where to busy, maybe they could give me some pointers on if I have the right approach or not. If anyone is interested I can provide an archive with the benchmark program in it. -aric diff --git a/dlls/wined3d/surface_base.c b/dlls/wined3d/surface_base.c index 57809e1..2ec3a52 100644 --- a/dlls/wined3d/surface_base.c +++ b/dlls/wined3d/surface_base.c @@ -852,7 +852,7 @@ IWineD3DBaseSurfaceImpl_Blt(IWineD3DSurface *iface, if (Src == This) { - IWineD3DSurface_LockRect(iface, &dlock, NULL, 0); + IWineD3DSurface_LockRect(iface, &dlock, DestRect, 0); dfmt = This->resource.format; slock = dlock; sfmt = dfmt; @@ -877,20 +877,26 @@ IWineD3DBaseSurfaceImpl_Blt(IWineD3DSurface *iface, sfmt = Src->resource.format; } sEntry = getFormatDescEntry(sfmt, NULL, NULL); - IWineD3DSurface_LockRect(iface, &dlock,NULL,0); + IWineD3DSurface_LockRect(iface, &dlock, DestRect,0); } if (!DDBltFx || !(DDBltFx->dwDDFX)) Flags &= ~WINEDDBLT_DDFX; if (sEntry->isFourcc && dEntry->isFourcc) - { - memcpy(dlock.pBits, slock.pBits, This->resource.size); - goto release; + { + if (!DestRect) + { + memcpy(dlock.pBits, slock.pBits, This->resource.size); + goto release; + } } if (DestRect) { - xdst = *DestRect; + xdst.top = 0; + xdst.bottom = DestRect->bottom - DestRect->top; + xdst.left = 0; + xdst.right = DestRect->right - DestRect->left; } else {

3 2

Re: CUDA wrapper
by Mind Matter 25 Jul '08

25 Jul '08

Sorry if I posted this wrong, I'm new to mailing lists. *You could use oprofile to find out where the CPU time is spent - this *behavior can be caused by a lot of issues. *Does the Cuda client work now? If so, it would be cool if we could include *the wrapper in Wine, or get it into a shape to make it easilly *redistributable and installable next to Wine. I have been testing this out with Seth. Yes the wrapper is up and running. I have been able to run the folding@home GPU client for about a week now with comparable performance to the same hardware running under Windows. The main problem as stated before is that both cores (dual core system) are running at 100% and the system is not usable until the client is killed. In Windows this client only uses about 20% or less of a single core to feed the GPU leaving the second core free. I ran oprofile (first time, never heard of it before) while the client was running. 213932 54.7876 wine-preloader CPU_CLK_UNHALT...| samples| %| ------------------ 1970113 88.9871 libcuda.so.177.13 160796 7.2629 FahCore_11.exe 30056 1.3576 libc-2.7.so 10169 0.4593 libpthread-2.7.so 9143 0.4130 libcudart.so.2.0 8473 0.3827 libfreetype.so.6.3.16 5065 0.2288 kernel32.dll.so 4726 0.2135 ntdll.dll.so 3578 0.1616 [vdso] (tgid:19882 range:0xffffe000-0xfffff000) 3458 0.1562 cudart.dll.so I have attached the full output. I assume this says that libcuda is using 88% of the CPU and FahCore_11.exe is using 7%. When I watch the processes in the KDE system monitor it shows FahCore_11.exe using ~50% (one full core) and Xorg using ~50% (second core). I don't see from oprofile how and why xorg is using a whole core.

2 1

re: EverQuest2.exe and context.c
by Dan Kegel 25 Jul '08

25 Jul '08

Chris Ahrendt wrote: > Again on the goto's I was following what the site > suggested was a good task to start with Where does it say that? I looked, but I couldn't find it. Please let me know so I can go make sure it's accurate. Wine code is a bit like kernel code, it has slightly different conventions than most people are used to. Chris, you should focus on one thing at a time, and code cleanup probably shouldn't be something you focus on until you are more in tune with Wine. - Dan p.s. Also, everybody, please trim your quotes...

2 1

question
by Adi mmx 25 Jul '08

25 Jul '08

Hallo, i have a question to wine developers, how do i get parallel port access tru dlportio.sys, and dlportio.dll , becose im getting an error while loading driver. Thanks.

3 2

Re: kernel32 [1/4]: Add tests for GetPrivateProfileString [RESEND]
by Paul Vriens 25 Jul '08

25 Jul '08

James Hawkins wrote: > Hi, > > Anything wrong with these patches? > > Changelog: > * Add tests for GetPrivateProfileString. > > dlls/kernel32/tests/profile.c | 272 +++++++++++++++++++++++++++++++++++++++++ > 1 files changed, 272 insertions(+), 0 deletions(-) > There are lots of test crashes because of this patch (tested on W2K, XP-SP3, W2K3 and Vista). It looks like all tests with 'lpAppName is empty' and 'lpKeyName is empty' fail (haven't checked others). Marking them with an if(0) does seem overkill. Any idea? -- Cheers, Paul.

1 0

Re: crypt32/tests: check Vista error codes for the msg tests. [resend]
by Alexandre Julliard 25 Jul '08

25 Jul '08

"Reece Dunn" <msclrhd(a)googlemail.com> writes: > @@ -383,9 +383,10 @@ static void test_data_msg_update(void) > /* Can't update a message with no data */ > SetLastError(0xdeadbeef); > ret = CryptMsgUpdate(msg, NULL, 0, TRUE); > - /* NT: E_INVALIDARG, 9x: unchanged */ > - ok(!ret && (GetLastError() == E_INVALIDARG || GetLastError() == 0xdeadbeef), > - "Expected E_INVALIDARG or 0xdeadbeef, got 0x%x\n", GetLastError()); > + /* last error -- NT: E_INVALIDARG, 9x/Vista: unchanged */ > + /* ret is FALSE on XP and earlier but TRUE on Vista, therefore it cannot be tested for */ > + ok((GetLastError() == E_INVALIDARG || GetLastError() == 0xdeadbeef), > + "Expected E_INVALIDARG or 0xdeadbeef, 0x%x\n", GetLastError()); It doesn't make sense to test last error if the function succeeds. Also if it sometimes succeeds and sometimes fails the whole test is useless. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: EverQuest2.exe and context.c
by Vitaliy Margolen 25 Jul '08

25 Jul '08

Chris Ahrendt wrote: > Vitaliy Margolen wrote: >> Chris Ahrendt wrote: >>> Vitaliy Margolen wrote: >>>> Chris Ahrendt wrote: >>>>> Ok I ran make test and got the failure without running >>>>> Everquest2.exe let me attach the output of maketest. I guess thats >>>>> a start eh? >>>>> >>>> You getting off-topic too far here. Make test have nothing to do >>>> with your game. Especially that you attached complete output of >>>> everything. >>>> >>>> However this lines tell the whole story: >>>>> libGL error: drmMap of framebuffer failed (Cannot allocate memory) >>>>> libGL error: reverting to (slow) indirect rendering >>>> >>>> You have broken driver. And I'm afraid your configuration can not be >>>> supported. You could try and read the faq about how to try and fix >>>> it. But that still won't fix broken driver. >>>> >>>> Vitaliy >>>> >>>> PS: >>>> Please do not attach big files to mailing list. If you are asked for >>>> them - send to that person directly or attach to the bug report. >>>> >>>> PPS: >>>> Please take this discussion to the bug report. It's not a general >>>> case but a game specific. It belongs there not in the developer's >>>> mailing list. Since you are not a developer yourself and just add an >>>> extra noise to the mailing list. >>> Actually Vialiy it is a discussion that belongs here... not in bug fix.. >>> I have had that gl error and its not what we are working on... the >>> problem we are working on was first found in EverQuest2.exe but I was >>> able to reproduce it without everquest. so its not a game related issue. >>> Second point.. I was told to bring this sort of discussion over here to >>> discuss as the patch list is not for general discussion. >>> >> >> I'm talking about bugzilla. What's the bug number you are referring too? >> >> >> Vitaliy. > There are a couple 14072 is one of them... > Did you noticed that your patch has nothing to do with what you talking about here? The bug related to this topic is 14000. And please don't mix and match multiple things. Reading this thread you talking about: 1. Changing gotos with something 2. Not liking the code 3. PixelFormat. 4. make test failures (not even related to d3d at all) 5. dxdiag crash This is all on top of broken configuration (did you disable fast tls?) and known bad drivers and particular bad video card. Please stay on topic of pixelformat related problem or you won't get anywhere trying to fix everything at the same time. For the main topic - you will need to wait for Roderic to chime in on the reasons behind his code. This area is really fragile and should not be changed to fix a particular program. Vitaliy.

3 4

Re: d3dx9: Implement D3DXPlaneTransformArray.
by Vitaliy Margolen 24 Jul '08

24 Jul '08

Philip Nilsson wrote: > Thanks to joaopa for pointing out that I forgot this function. > > +D3DXPLANE* WINAPI D3DXPlaneTransformArray( > + D3DXPLANE* out, UINT outstride, CONST D3DXPLANE* in, UINT instride, > + CONST D3DXMATRIX* matrix, UINT elements) > +{ > + unsigned int i; > + TRACE("\n"); > + for (i = 0; i < elements; ++i) { Please don't mix and match win types and C types. If it says "UINT" in the function declaration then make the iterator "UINT i" as well. Vitaliy.

1 0

Re: [PATCH] cryptnet/tests: Make the tests usable on win9x
by Juan Lang 24 Jul '08

24 Jul '08

Hi Detlef, overall your patch looks good to me. One minor suggestion: + /* only newer versions of cryptnet do the cleanup */ + if(!ret && GetLastError() != CRYPT_E_ASN1_BADTAG && + GetLastError() != OSS_DATA_ERROR) { + ok(crl == NULL, "Expected CRL to be NULL\n"); + } Rather than only checking crl when a newer version of cryptnet is available, why not use the broken() macro? We really do expect crl to get cleaned up. --Juan

1 0

GL_INVALID_ENUM errors with FBO
by Vitaliy Margolen 24 Jul '08

24 Jul '08

I've been trying to track some of the errors that I get with different games. To do that I've added some extra traces and this is what I see: fixme:d3d_surface:read_from_framebuffer_texture glReadBuffer(0x405) was 0x8ce0 >>>>>>>>>>>>>>>>> GL_INVALID_ENUM (0x500) @ ../../../wine.git/dlls/wined3d/surface.c / 918 0x405 is GL_BACK and 0x8ce0 is GL_COLOR_ATTACHMENT0_EXT. Also when this happens I have an inverted image of the entire screen in the left bottom corner. Is this an indication that we are reading from the wrong surface? Or writing into the wrong surface? Attached is the patch that produces the above output. BTW if it looks fine to you guys (that extra TRACE()/FIXME() call overhead) then I can send it to wine-patches as well. Vitaliy.

3 5

Re: [PATCH] wined3d: Fix the OpenGL driver version for Mac OS X NVIDIA driver.
by Michael Karcher 24 Jul '08

24 Jul '08

Am Donnerstag, den 24.07.2008, 00:55 +0800 schrieb Huang, Zhangrong: > Hi, > I tried run World of Warcraft on Mac OS X with X11 and NVIDIA card, > got the following error messages: > > err:d3d_caps:IWineD3DImpl_FillGLCaps Invalid nVidia version string: > "1.5 NVIDIA-1.5.24" > err:d3d_caps:IWineD3DImpl_FillGLCaps Invalid nVidia version string: > "1.5 NVIDIA-1.5.24" > > This patch fixed this problem. > + gl_string_cursor = gl_string; > + major = atoi(gl_string_cursor); > + while (*gl_string_cursor <= '9' && *gl_string_cursor >= '0') { > + ++gl_string_cursor; > + } What is the advantage of that compared to major = strtol(gl_string, &gl_string_cursor,10); ? Or even replace the whole scanning code by if(sscanf(gl_string, "%d.%d", &major, &minor) != 2) ERR_(d3d_caps)(...) Regards, Michael Karcher

2 1

Re: [5/5] WineD3D: Make the MAC ARBvp implementation happy about ARL
by Ivan Gyurdiev 24 Jul '08

24 Jul '08

> Unfortunately we can't make it a different function in the shader instruction table because the difference between MOV and ARL is decided with the dest register. Sure you can, it seems that this MOV/MOVA specific stuff all belongs in vshader_hw_mov (both sides of the MOV if statement can be moved). There should also be a comment explaining what this ARL block is doing, and why (as part of "wined3d: Relative addressing offsets are limited to [-64; 63] in arb."). Ivan

2 1

Re: general question..
by James Hawkins 24 Jul '08

24 Jul '08

On Mon, Jul 21, 2008 at 9:24 PM, Chris Ahrendt <celticht32(a)aol.com> wrote: > > Well here is my list so far : > > device.c - filled with goto's if you need the routines I can supply them... > they can be moved to a routine and called... > wine$ find . -name "device.c" ./dlls/ddraw/device.c ./dlls/dinput/tests/device.c ./dlls/dinput/device.c ./dlls/wined3d/device.c ./dlls/d3d8/tests/device.c ./dlls/d3d8/device.c ./dlls/mountmgr.sys/device.c ./dlls/d3d9/tests/device.c ./dlls/d3d9/device.c ./programs/winedevice/device.c ./server/device.c > context.c - same except in this case its just a return with noting else.. > why do a goto why not just do the return? > This is probably ok to change. I can only imagine that the original author thought there might be cleanup needed at some later point. > directx.c - same... this can be moved to a routine and simplified.. > this is in routine WineD3D_CreateFakeGLContext which I was tracing down some > stuff... > cleanup usually does not warrant a new function. This is exactly what we use goto for. > pixelshader.c - this has a recompile goto.. again why not make this into a > routine? > > provider.c - same > This function is ugly, but not because it uses goto. The function is 144 lines long, which is too long. I'm not familiar with this code, but I'm pretty sure some factorization is in order. The level of indentation could be reduced by breaking on failure instead of proceeding on success. Assuming this previous change is made, the use of the goto would be that much more appealing. > > These are just the ones I have run accross so far.. > Why do you say that... or is the idea.. hack and get it done... one of the > problems with goto's is it makes finding and putting in patches a pain in > the ass.. and thats putting it bluntly.. > Complete sentences go a long way towards effective communication :-) The use of goto's cannot possibly be considered as a hack. I also don't see how you find goto's a problem when patching the code. > Of course.. Do you have a suggestion on how I should word the RFC? > No, just send in a patch to wine-devel stating why you think the change is correct. P.S. Make sure you reply-all to cc wine-devel. We're an open project and we communicate openly so everyone can be a part of the discussion. -- James Hawkins

6 15

Re: [1/10] [try 5] appwiz.cpl: Add skeleton Add/Remove Programs control panel
by Alexandre Julliard 24 Jul '08

24 Jul '08

Owen Rudge <owen(a)owenrudge.net> writes: > +#include "En.rc" > + > +LANGUAGE LANG_NEUTRAL, SUBLANG_NEUTRAL > + > +ICO_MAIN ICON "../../programs/uninstaller/uninstaller.ico" > +ICO_SETUP ICON "../../programs/msiexec/msiexec.ico" > +ICO_BIN ICON "../shell32/trash_file.ico" You can't depend on files belonging to other dlls. You should load the icons from the corresponding dlls at run-time, or if absolutely necessary duplicate the files. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [Gdiplus try4 1/6] Implement GdipCreateRegion and mark the tests todo_wine instead of skipping over them all.
by Alexandre Julliard 24 Jul '08

24 Jul '08

Adam Petaccia <adam(a)tpetaccia.com> writes: > diff --git a/dlls/gdiplus/tests/region.c b/dlls/gdiplus/tests/region.c > index 6b1c5f0..ef5ab28 100644 > --- a/dlls/gdiplus/tests/region.c > +++ b/dlls/gdiplus/tests/region.c > @@ -62,50 +62,60 @@ static void test_getregiondata(void) > GpRect rect; > GpPath *path; > > + ZeroMemory(buf, sizeof(buf)); > + > status = GdipCreateRegion(&region); > -todo_wine > ok(status == Ok, "status %08x\n", status); > > - if(status != Ok) return; > - > +todo_wine > +{ > status = GdipGetRegionDataSize(region, &needed); > ok(status == Ok, "status %08x\n", status); > - ok(needed == 20, "got %d\n", needed); > + expect(20, needed); > status = GdipGetRegionData(region, (BYTE*)buf, sizeof(buf), &needed); > ok(status == Ok, "status %08x\n", status); > - ok(needed == 20, "got %d\n", needed); > + expect(20, needed); > expect_dword(buf, 12); > trace("buf[1] = %08x\n", buf[1]); > expect_magic((DWORD*)(buf + 2)); > +} > expect_dword(buf + 3, 0); > +todo_wine > +{ If you want to test that the buffer contains zero you should initialize it with something else, this will avoid having the test succeed even though Wine doesn't yet put anything in the buffer. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: advapi32[2/2]: remove access checks from advapi32 (makes KEY_WOW64_* work)
by Paul Vriens 24 Jul '08

24 Jul '08

Mikołaj Zalewski wrote: > + hkey1 = NULL; + ret = RegCreateKeyExA(HKEY_LOCAL_MACHINE, "Software", 0, NULL, 0, KEY_READ|KEY_WOW64_32KEY, NULL, &hkey1, NULL); + ok(ret == ERROR_SUCCESS && hkey1 != NULL, "RegOpenKeyEx with KEY_WOW64_64KEY failed (err=%u)\n", ret); + RegCloseKey(hkey1); } The call to RegCreateKeyExA uses the KEY_WOW64_32KEY flag. -- Cheers, Paul.

1 0

Re: oleaut32: fix the SafeArrayGetVartype tests on Vista and use that behaviour. [try 4]
by Alexandre Julliard 24 Jul '08

24 Jul '08

"Reece Dunn" <msclrhd(a)googlemail.com> writes: > This includes Rob Shearman's suggestion of marking the old behaviour > as broken() as it is clearly a bug, and also updated the > SafeArrayGetVartype implementation to return the correct value in this > case. > > The tests pass on Vista and on Wine. Not for me: ../../../tools/runtest -q -P wine -M oleaut32.dll -T ../../.. -p oleaut32_test.exe.so safearray.c && touch safearray.ok safearray.c:628: Test failed: SAGVT of array with vt 9 returned 13 make[2]: *** [safearray.ok] Error 1 -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: advapi32[2/2]: allow generic rights in registry functions
by Alexandre Julliard 24 Jul '08

24 Jul '08

Mikołaj Zalewski <mikolaj(a)zalewski.pl> writes: > The GENERIC_* flags were also missing I'd suggest to simply kill that access mask check, there's no reason to second-guess the server checks anyway. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: wined3d: universal surface convertor function for unsigned integer color formats(4th attempt)
by Alexandre Julliard 24 Jul '08

24 Jul '08

Victor Eremin <ErV2005(a)rambler.ru> writes: > +void mask_copy(DWORD srcMask, BYTE srcPixelSize, > + DWORD dstMask, BYTE dstPixelSize, > + BYTE *src, BYTE* dst, DWORD src_pitch, DWORD dst_pitch, > + unsigned int w, unsigned int h){ > + unsigned int x, y; > + BYTE i; > + BYTE *dstp, *srcp, *dstmaskp, *srcmaskp, *channelValuePtr; > + DWORD channelValue; > + BYTE upShift, downShift; > + dstmaskp = (BYTE*)&dstMask; > + srcmaskp = (BYTE*)&srcMask; > + channelValuePtr = (BYTE*)&channelValue; You can't access DWORDs as bytes, that will break on big-endian platforms. -- Alexandre Julliard julliard(a)winehq.org

1 0

Request For Testing: Can you check this crypt32/protectdata test fix on Win2000.
by Reece Dunn 24 Jul '08

24 Jul '08

Hi, I want to verify that the "if (!protected) ..." are correct. That is, on non-Win2000 platforms, we can't verify LastError == ERROR_SUCCESS, so I have removed those as per Juan's request. However, there are two places where Win2000 is returning a different error code. So the question is, is this the correct way to do this (and because I have changed the condition for the first test that I have changed I want to verify it stll works on Win2000). Thanks, - Reece

1 0

Re: d3dx8 [try 2]: Implement D3DXSphereBoundProbe
by H. Verbeet 24 Jul '08

24 Jul '08

2008/7/23 David Adam <david.adam.cnrs(a)gmail.com>: > +#include <stdio.h> > +#include <stdlib.h> > +#include <stdarg.h> > +#include <assert.h> > + > +#define NONAMELESSUNION ... > +#include <assert.h> I don't think you need those. (I should've noticed this in the first patch, sorry for that.)

1 0

RE: wined3d: universal surface convertor function for unsigned integer color formats(3rd attempt)
by Stefan Dösinger 23 Jul '08

23 Jul '08

The patch looks reasonably, just one small thing: There is a count_bits function implemented in utils.c, which as far as I can see does the same as getMaskSize. Can you check if you can reuse it? > -----Original Message----- > From: wine-patches-bounces(a)winehq.org [mailto:wine-patches- > bounces(a)winehq.org] On Behalf Of Victor Eremin > Sent: Wednesday, July 23, 2008 10:25 AM > To: wine-patches(a)winehq.org > Subject: wined3d: universal surface convertor function for unsigned > integer color formats(3rd attempt) > > > Supports conversion between most of "unsigned color" argb/xrgb surface > formats (D3DFMT_A8R8G8B8, D3DFMT_A8R3G3B2, etc), and "luminosity" color > formats (D3DFMT_L8, etc), excluding D3DFMT_A16R16G16B16, D3DFMT_A8P8, > D3DFMT_P8 and D3DFMT_A1. > luminosity to argb/xrgb (and vice versa) conversions are not supported > > Removes "Cannot find coverter" FIXMEs from "Ancient Evil" and "Stranded > 2" games. > > Fixes water glitches in "Stranded 2" game. > --- > dlls/wined3d/surface_base.c | 202 > ++++++++++++++++++++++++++++++++++++++- > dlls/wined3d/utils.c | 126 +++++++++++++------------- > dlls/wined3d/wined3d_private.h | 2 +- > 3 files changed, 260 insertions(+), 70 deletions(-)

3 4

Re: crypt32/tests: check Vista error codes for the protectdata tests.
by Juan Lang 23 Jul '08

23 Jul '08

Hi Reece, > (Vista does not set the last error on success for the functions used > in protectdata). In that case, it seems to me we should just remove those tests, as it's unlikely an app can depend on the last error being set on success. --Juan

1 0

RE: wined3d: universal surface convertor function for unsigned integer color formats(3rd attempt)
by Stefan Dösinger 23 Jul '08

23 Jul '08

Actually, one more idea: It will be extra-slow, but we could implement a general all-to-all format by converting the source format to A32R32G32B32F(float values), and then write code to convert this format to all possible destination formats. The from->to table lookup could be replaced by code that can combine multiple conversions to find a conversion strategy(e.g. R5G6B5->ARGB32F->R8G8B8). I am not sure if it is a good idea, but it is worth a consideration

2 1

valgrind warning in wineconsole
by Dan Kegel 23 Jul '08

23 Jul '08

Here's a warning that seems to pop up if you type or mouse or something during the kernel32/console test. I first saw it last year, but it popped up again once last month and again today: http://kegel.com/wine/valgrind/logs/2008-07-23-07.18/vg-kernel32_console.txt Syscall param writev(vector[...]) points to uninitialised byte(s) at (within /lib/ld-2.7.so) by send_request (server.c:246) by wine_server_call (server.c:327) by wine_server_call_err (server.h:61) by WriteConsoleInputW (console.c:429) by WCUSER_GenerateKeyInputRecord (user.c:1059) by WCUSER_Proc (user.c:1118) by ??? (library.h:163) by call_window_proc (winproc.c:457) by WINPROC_call_window (winproc.c:2198) by DispatchMessageW (message.c:3125) by WCUSER_MainLoop (user.c:1381) by WinMain (wineconsole.c:869) by main (exe_main.c:48) Address 0x7f22f8a6 is on thread 1's stack Uninitialised value was created by a stack allocation at WCUSER_GenerateKeyInputRecord (user.c:1019) That user.c is in programs/wineconsole. This might just be a matter of INPUT_RECORD being holey, I haven't checked.

1 0

Valgrind warnings in new msxml3 saxreader code?
by Dan Kegel 23 Jul '08

23 Jul '08

Hi Piotr, I see a lot of new valgrind warnings today that seem to be triggered by your new msxml3 code. I don't know offhand if they're bugs in libxml2 or in your code, could you have a look? Thanks! See http://kegel.com/wine/valgrind/logs/2008-07-21-07.56/vg-msxml3_saxreader-di… Here are the first two: Conditional jump or move depends on uninitialised value(s) at xmlStrlen (in /usr/lib/libxml2.so.2.6.31) by xmlSetupParserForBuffer (in /usr/lib/libxml2.so.2.6.31) by isaxxmlreader_parse (saxreader.c:1077) by test_saxreader (saxreader.c:502) by func_saxreader (saxreader.c:518) by run_test (test.h:488) by main (test.h:537) Uninitialised value was created by a client request at mark_block_uninitialized (heap.c:164) by RtlAllocateHeap (heap.c:1236) by SAFEARRAY_Malloc (safearray.c:94) by SafeArrayAllocData (safearray.c:536) by SAFEARRAY_Create (safearray.c:231) by SafeArrayCreate (safearray.c:576) by test_saxreader (saxreader.c:494) by func_saxreader (saxreader.c:518) by run_test (test.h:488) by main (test.h:537) Conditional jump or move depends on uninitialised value(s) at get_length_mbs_utf8 (utf8.c:286) by wine_utf8_mbstowcs (utf8.c:312) by MultiByteToWideChar (locale.c:1838) by bstr_from_xmlChar (node.c:284) by libxmlCharacters (saxreader.c:249) by xmlParseCharData (in /usr/lib/libxml2.so.2.6.31) by xmlParseContent (in /usr/lib/libxml2.so.2.6.31) by xmlParseElement (in /usr/lib/libxml2.so.2.6.31) by xmlParseDocument (in /usr/lib/libxml2.so.2.6.31) by isaxxmlreader_parse (saxreader.c:1083) by test_saxreader (saxreader.c:502) by func_saxreader (saxreader.c:518) by run_test (test.h:488) by main (test.h:537) Uninitialised value was created by a client request at mark_block_uninitialized (heap.c:164) by RtlAllocateHeap (heap.c:1236) by SAFEARRAY_Malloc (safearray.c:94) by SafeArrayAllocData (safearray.c:536) by SAFEARRAY_Create (safearray.c:231) by SafeArrayCreate (safearray.c:576) by test_saxreader (saxreader.c:494) by func_saxreader (saxreader.c:518) by run_test (test.h:488) by main (test.h:537) ...

2 1

Re: [3/4] ntdll: Implement the timer queue thread.
by Rob Shearman 23 Jul '08

23 Jul '08

Hi Dan, 2008/7/23 Dan Hipschman <dsh(a)linux.ucla.edu>: > This isn't the most efficient implementation, but it works, and it should > not be difficult to tweak. Hence, I'd rather get this version in and add > the optimizations one at a time, in little patches. "Get it working first..." Yes, I think you're right. I don't think it will be too hard to change the architecture of this to that of my suggestions. However, I have one minor nit. > +static void WINAPI timer_queue_thread_proc(LPVOID p) > +{ > + struct timer_queue *q = p; > + ULONG timeout_ms; > + BOOL done; > + > + timeout_ms = INFINITE; > + while (!q->quit) > + { > + LARGE_INTEGER timeout; > + DWORD ret = NtWaitForSingleObject(q->event, FALSE, > + get_nt_timeout(&timeout, timeout_ms)); This should be NTSTATUS. > + > + if (ret == STATUS_TIMEOUT) > + queue_timer_expire_next(q); > + > + RtlEnterCriticalSection(&q->cs); > + timeout_ms = timer_queue_update(q); > + RtlLeaveCriticalSection(&q->cs); > + } -- Rob Shearman

2 1

Re: d3dx8: implement D3DXSphereBoundProbe
by H. Verbeet 23 Jul '08

23 Jul '08

2008/7/22 David Adam <david.adam.cnrs(a)gmail.com>: > + b = pow(D3DXVec3Dot(&difference, praydirection), 2); Maybe I'm just bad at math, but shouldn't that just be b = D3DXVec3Dot(&difference, praydirection); (The test case doesn't really help there) > + ok(result == TRUE, "expected FALSE, received TRUE\n"); That's misleading.

1 0

Re: crypt32/tests: check Vista error codes for the msg tests.
by Markus Hitter 23 Jul '08

23 Jul '08

Am 23.07.2008 um 02:25 schrieb Reece Dunn: > > + /* last error -- NT: E_INVALIDARG, 9x/Vista: unchanged */ > + /* ret is FALSE on XP and earlier but TRUE on Vista, therefore > it cannot be tested for */ > + ok((GetLastError() == E_INVALIDARG || GetLastError() == > 0xdeadbeef), > + "Expected E_INVALIDARG or 0xdeadbeef, 0x%x\n", GetLastError > ()); A more general question: Is it Wine's policy to just ignore differences in behaviour between different Windows versions? From my own (naive) standpoint I'd say something like this would be better (pseudo-code): if (WinVer <= XP) { ok((!ret && [...]), "Expected [...]); } else { ok((ret && [...]), "Expected [...]); } Likely a often asked question, but I couldn't find hints about the answer yet. MarKus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/

3 2

Re: libs/wpp/ppy.y signedness fixes
by Alexandre Julliard 23 Jul '08

23 Jul '08

Gerald Pfeifer <gerald(a)pfeifer.com> writes: > In ISO C, operations involving both signed and unsigned types are > using signed. If the case of ui = ui OP si is really ment to make > use of this (despite the result being stored in an unsigned type), > we'd need to handle this via two casts, but I doubt this is really > the intent here. It's supposed to follow the C rules, so yes the result most likely needs to be signed in this case. That doesn't mean using two casts, it means using the correct output type. -- Alexandre Julliard julliard(a)winehq.org

1 0

Add "Wine FAQ" entry to Wine menu?
by Dan Kegel 23 Jul '08

23 Jul '08

Recently, several newbies had trouble finding the FAQ and were surprised to hear that it could be helpful. Perhaps if our packages added a "Wine FAQ" menu item, they'd have less trouble finding it. Here's a patch to add that to the Debian / Ubuntu packages. What do people think? --- /dev/null 2008-05-31 06:33:17.000000000 -0700 +++ debian/wine-faq.desktop 2008-07-22 00:06:29.000000000 -0700 @@ -0,0 +1,8 @@ +[Desktop Entry] +Name=Wine FAQ +Comment=Frequently Asked Questions about Wine (and their answers) +Exec=xdg-open http://wiki.winehq.org/FAQ +Terminal=false +Type=Application +Icon=gnome-help +Categories=Wine; --- debian/rules.orig 2008-07-22 00:11:37.000000000 -0700 +++ debian/rules 2008-07-22 00:12:32.000000000 -0700 @@ -160,6 +160,7 @@ cp -f $(CURDIR)/debian/wine-notepad.desktop $(CURDIR)/debian/tmp/usr/share/applications/ cp -f $(CURDIR)/debian/wine-browsedrive.desktop $(CURDIR)/debian/tmp/usr/share/applications/ cp -f $(CURDIR)/debian/wine-winecfg.desktop $(CURDIR)/debian/tmp/usr/share/applications/ + cp -f $(CURDIR)/debian/wine-faq.desktop $(CURDIR)/debian/tmp/usr/share/applications/ mkdir -p $(CURDIR)/debian/tmp/usr/share/desktop-directories/ cp -f $(CURDIR)/debian/wine-wine.directory $(CURDIR)/debian/tmp/usr/share/desktop-directories/

2 3

Re: [Gdiplus 1/6] Valgrind: Fix a memory leak
by James Hawkins 23 Jul '08

23 Jul '08

On Tue, Jul 22, 2008 at 10:06 PM, Adam Petaccia <adam(a)tpetaccia.com> wrote: > If this patch is rejected, the others will still apply and I will drop this from my tree. > > Technically a leak shouldn't occur here as the call before it is invalid, but because Gdiplus doesn't correctly handle this, we should call delete and expect an InvalidParamter return. > Shouldn't GdipCreateFontFamilyFromName be fixed to free the handle in this error case? Also, if you have a patch in a series that no later patch depends on, please don't add it to the series numbering. -- James Hawkins

1 0

[RFC] crypt32: fixed the base64 tests on Vista.
by Reece Dunn 22 Jul '08

22 Jul '08

This patch fixes the base64 tests on Vista (http://test.winehq.org/data/b3f4091b47e70681a9909bfccd19dee95657fabd/vista_…), however to me this feels wrong. In the call to pCryptStringToBinaryA, Vista is returning TRUE in some cases, and for those is sometimes not setting GetLastError(), and in others is setting it to ERROR_INVALID_DATA (even when it is returning TRUE!). For these cases, it is also not skipping any characters. To me, without understanding this in any more detail, it looks as if Vista is broken here (and thus the Vista return parts should be marked as broken()). However, Vista may be doing the right thing, and thus the behaviour in these cases has changed between XP and Vista. The latter seems more likely, but I do not have any experience in this area, nor understand these tests well enough to say one way or the other. Any ideas? - Reece

3 4

RE: wined3d: universal surface convertor function for unsigned integer color formats(2nd attempt)
by Stefan Dösinger 22 Jul '08

22 Jul '08

How many different conversions do the two games need? One of my concerns is that this generic code is way slower than a separate conversion function for each pair of color formats. On the other hand, one function for each pair gives a whole lot more of code, and if we run into the conversion function during rendering we can kiss the framerate goodbye anyway > -----Original Message----- > From: wine-patches-bounces(a)winehq.org [mailto:wine-patches- > bounces(a)winehq.org] On Behalf Of Victor Eremin > Sent: Thursday, July 17, 2008 11:02 AM > To: wine-patches(a)winehq.org > Subject: wined3d: universal surface convertor function for unsigned > integer color formats(2nd attempt) > > > Supports conversion between most of "unsigned color" argb/xrgb surface > formats (D3DFMT_A8R8G8B8, D3DFMT_A8R3G3B2, etc), and "luminosity" color > formats (D3DFMT_L8, etc), excluding D3DFMT_A16R16G16B16, D3DFMT_A8P8, > D3DFMT_P8 and D3DFMT_A1. > luminosity to argb/xrgb (and vice versa) conversions are not supported > > Removes "Cannot find coverter" FIXMEs from "Ancient Evil" and "Stranded > 2" games. > > Fixes water glitches in "Stranded 2" game. > --- > dlls/wined3d/surface_base.c | 203 > ++++++++++++++++++++++++++++++++++++++-- > dlls/wined3d/utils.c | 126 ++++++++++++------------ > dlls/wined3d/wined3d_private.h | 2 +- > 3 files changed, 260 insertions(+), 71 deletions(-)

2 3

Convert 565 to 0888
by Einars 22 Jul '08

22 Jul '08

I had graphical problems with an online game called Angels Online, when just a black screen was visible, and complaints about missing converter from WINED3DFMT_R5G6B5 to WINED3DFMT_X8R8G8B8, so I added a converter for this format, and the game runs flawlessly now on wine, the 1.1.1 release as well as git version (at least for me). I hope this was the right way to fix it. Kind regards, Einars Lielmanis

1 0

RE: general question..
by Stefan Dösinger 22 Jul '08

22 Jul '08

Can you give some examples of such code? Nobody here is a goto-maniac, but in all cases I know the goto is used for a good reason. Most of the time it is used for error path to avoid ugly if() nesting and/or code duplication when freeing partially allocated objects > -----Original Message----- > From: wine-patches-bounces(a)winehq.org [mailto:wine-patches- > bounces(a)winehq.org] On Behalf Of Chris Ahrendt > Sent: Monday, July 21, 2008 8:42 PM > To: wine-patches(a)winehq.org > Subject: general question.. > > As I have been going through trying to debug the everquest2 issues on > my > machine I have run into a few places where I think the code should be > changed a little ( this alot of times is where there is a GOTO in the > code). My question is in the case where I do find these goto's and I > rewrite the code should I submit the changes here for approval? > I have been doing some code reviews and found a few places where > there are goto's that don't need to be there. I guess I am old school > and really dislike code with goto's (they make debugging and > maintenance > a nightmare (I used to maintain 20 year old cobol code along time ago > =) ) > > > Chris

3 3

Re: [Gdiplus try3 02/16] Implement GdipCreateRegion
by Huw Davies 22 Jul '08

22 Jul '08

Hi Adam, Some comments inlined below: On Tue, Jul 22, 2008 at 01:22:56AM -0400, Adam Petaccia wrote: > diff --git a/dlls/gdiplus/gdiplus_private.h b/dlls/gdiplus/gdiplus_private.h > index e7ca874..9c0246b 100644 > --- a/dlls/gdiplus/gdiplus_private.h > +++ b/dlls/gdiplus/gdiplus_private.h > @@ -196,4 +198,40 @@ struct GpFontFamily{ > WCHAR FamilyName[LF_FACESIZE]; > }; > > +typedef struct RegionElement > +{ > + DWORD type; /* Rectangle, Path, SpecialRectangle, or CombineMode */ > + union > + { > + GpRectF rect; > + struct > + { > + GpPath* path; > + struct > + { > + DWORD size; > + DWORD magic; > + DWORD pointCount; > + DWORD storageFlags; > + } pathHeader; > + } pathData; > + struct > + { > + struct RegionElement *left; /* the original region */ > + struct RegionElement *right; /* what *left was combined with */ > + } combine; > + } elementData; > +} RegionElement; It would be better to avoid the mixed upper/lower case names, since this makes it look like they're win32 api structures. Something like typedef struct region_element region_element is nicer. Same goes for the element names like pathHeader etc. > +struct GpRegion{ > + struct > + { > + DWORD size; > + DWORD checksum; > + DWORD magic; > + DWORD numOps; A better name for numOps would be num_child_nodes. This is the total number of children under the root node (and is equal to twice the number of ops). I should update my comment at the beginning of region.c to reflect this. > + } header; > + RegionElement *node; How about actually embedding the structure here rather than a pointer to it? Since you'll always have a root node there's no need to allocate it explicitly. And let's call it 'root' not 'node'. Something like region_element root > diff --git a/include/gdiplusenums.h b/include/gdiplusenums.h > index 53401bd..f3110c9 100644 > --- a/include/gdiplusenums.h > +++ b/include/gdiplusenums.h > @@ -308,6 +308,15 @@ enum CombineMode > CombineModeComplement > }; > > +enum RegionType > +{ > + RegionDataRect = 0x10000000, > + RegionDataPath = 0x10000001, > + RegionDataEmptyRect = 0x10000002, > + RegionDataInfiniteRect = 0x10000003, > +}; > + > + > enum FlushIntention > { > FlushIntentionFlush = 0, > @@ -353,6 +362,7 @@ typedef enum HotkeyPrefix HotkeyPrefix; > typedef enum PenAlignment GpPenAlignment; > typedef enum ImageCodecFlags ImageCodecFlags; > typedef enum CombineMode CombineMode; > +typedef enum RegionType RegionType; > typedef enum FlushIntention FlushIntention; > typedef enum CoordinateSpace CoordinateSpace; > Are you sure RegionType is in the win32 api? I can't find this is my gdiplusenums.h. If it isn't then it should be put in gdiplus_private.h (or even just in region.c if nothing else uses it) and renamed to enum region_type. Again, I think you'd be better off submitting a couple of patches at a time. Huw. -- Huw Davies huw(a)codeweavers.com

2 2

Re: [3/9] shell32: Load Control Panel title from resources
by Alexandre Julliard 22 Jul '08

22 Jul '08

Owen Rudge <owen(a)owenrudge.net> writes: > --- a/dlls/shell32/shell32_Bg.rc > +++ b/dlls/shell32/shell32_Bg.rc > @@ -219,4 +219,6 @@ STRINGTABLE > IDS_CDBURN_AREA "Local Settings\\Application Data\\Microsoft\\CD Burning" > > IDS_NEWFOLDER "New Folder" > + > + IDS_CPANEL_TITLE "Wine Control Panel" The indentation is wrong, looks like you are using the wrong tab size. -- Alexandre Julliard julliard(a)winehq.org

2 1

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

22 Jul '08

Aric Stewart wrote: > It is mapped with the keyboard mapping to the resulting character. so > the key 'A' is DIK_A nomatter what its scancode or vkey would be. This > is relevent to Japanese keymapping where the '@' key is in the '[' > location the scancode for both is 0x22 but dinput generates DIK_AT in > japanese and DIK_LBRACKET in us_qwerty > Looks good but have few comments: > +static int map_dik_code(DWORD scanCode) > +{ > + DWORD vk = MapVirtualKeyA(scanCode,MAPVK_VSC_TO_VK); There is a vkCode in the KBDLLHOOKSTRUCT struct. You should use that instead of doing the remapping all the time. > + CHAR c = MapVirtualKeyA(vk,MAPVK_VK_TO_CHAR); > + > + switch (c & 0xFF) > + { > + case 32: return DIK_SPACE; > + case 39: return DIK_APOSTROPHE; Magic numbers are always bad. It's better to use vk_code here instead of a char. Vitaliy.

2 1

Re: netapi32: add stub for NetShareGetInfo
by Vitaly Perov 22 Jul '08

22 Jul '08

I am sorry. It was wrong file attached. -- Best wishes, Vitaly Perov Russia, Saint-Petersburg. www.etersoft.ru

1 0

Re: [Gdiplus try3 01/16] Mark the tests todo_wine, instead of skipping over them all.
by Alexandre Julliard 22 Jul '08

22 Jul '08

Adam Petaccia <adam(a)tpetaccia.com> writes: > todo_wine > +{ > ok(status == Ok, "status %08x\n", status); > > - if(status != Ok) return; > - > status = GdipGetRegionDataSize(region, &needed); > ok(status == Ok, "status %08x\n", status); > - ok(needed == 20, "got %d\n", needed); > + expect(20, needed); This will fail randomly since needed isn't set on failure. Skipping the test was better. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: quartz: Add support for the file writer filter
by Alexandre Julliard 22 Jul '08

22 Jul '08

"Maarten Lankhorst" <m.b.lankhorst(a)gmail.com> writes: > This should be in qcap, however it doesn't have the directshow > primitives (wine directshow base classes) that quartz has. If you > reject it for that reason, please let me know.. If it's in qcap on Windows it should clearly be in qcap on Wine. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: oleaut32: fix the SafeArrayGetVartype tests on Vista and use that behaviour. [try 3] [resend]
by Alexandre Julliard 22 Jul '08

22 Jul '08

"Reece Dunn" <msclrhd(a)googlemail.com> writes: > This includes Rob Shearman's suggestion of marking the old behaviour > as broken() as it is clearly a bug, and also updated the > SafeArrayGetVartype implementation to return the correct value in this > case. > > The tests pass on Vista and on Wine. > > Was there anything wrong with this patch? You should simplify the test, there's no need for two separate branches. -- Alexandre Julliard julliard(a)winehq.org

1 0

ntdll/server and unix_fd handling
by Kai Blin 22 Jul '08

22 Jul '08

Hi folks, I'm currently trying to get some integrated Wine/Samba tests working and in order to do so, I'm trying to add Samba socket wrapper support to Wine (i.e. allow Wine to hook into Samba's fake AF_FILE-based networking for testing). The socket wrapper code keeps track of the unix_fds of the sockets it's wrapping, because it can also _not_ wrap other fds. Now, I've been trying to connect this in dlls/ws2_32/socket.c:WSASocketW() by getting the unix_fd of the SOCKET the create_socket wineserver call returns, by calling get_sock_fd(). Now I noticed that every time I call this for the same SOCKET, the unix_fd increases by 1, effectively killing the tracking socket_wrapper does. After some more digging, upstream of the get_sock_fd call, the server_get_unix_fd() call always gets the same fd, either from wineserver or from the cache. wine_server_handle_to_fd() then seems to call dup() on the unix_fd. This seems to be needed because for some reason unix fds are used only temporary, so get_sock_fd is always followed by release_sock_fd(), which calls a close(). Why is this handled this way? Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton.

2 1

Re: general question..
by James Hawkins 22 Jul '08

22 Jul '08

On Mon, Jul 21, 2008 at 8:41 PM, Chris Ahrendt <celticht32(a)aol.com> wrote: > As I have been going through trying to debug the everquest2 issues on my > machine I have run into a few places where I think the code should be > changed a little ( this alot of times is where there is a GOTO in the > code). My question is in the case where I do find these goto's and I > rewrite the code should I submit the changes here for approval? > I have been doing some code reviews and found a few places where > there are goto's that don't need to be there. I guess I am old school > and really dislike code with goto's (they make debugging and maintenance > a nightmare (I used to maintain 20 year old cobol code along time ago =) ) > You're not going to find many in this project that agree with your stance on the use of goto's. That being said, I'm curious to see where you think the use of goto's should be replaced by something else. Feel free to send a RFC to wine-devel. P.S. Please don't send discussion emails to wine-patches. wine-devel is for discussion and wine-patches is for patches only. -- James Hawkins

1 0

Re: one liner patch to stop crash, everquest2.exe
by celticht32＠aol.com 22 Jul '08

22 Jul '08

yes I am looking at the shaders... and am noticing something as well in the traces... some reason when it goes to ask how much memory to use... on my machine it thinks it only has 16mb of texture memory.. when the laptop has 256mb of video ram...? if you look in device.c the pixel shader fails atleast on my firegl5200.? The other curiosity is that when EverQuest2.exe runs it seems to be going through the adapter initialization two times.. once when it loads then it starts loading up sound? and then it looks atleast in my traces? it initializes the adapter again getting an adapter which is the second adapter (I think) used for dual head.... Chris

1 0

Re: rasapi32: the tests need raserror.h to build using MS headers.
by Stefan Leichter 21 Jul '08

21 Jul '08

Am Monday 21 July 2008 21:44 schrieb Reece Dunn: > The error constants (e.g. ERROR_BUFFER_TOO_SMALL) are defined in > raserror.h, which is needed for the tests to build using the Microsoft > headers (checked against the Vista SDK headers). > > - Reece my wine tree does not have the raserror.h header. Therefore the compilation under wine breaks for me. Did you forget to include the header file in the patch? Stefan

2 1

Re: [Gdiplus try2 02/16] Implement GdipCreateRegion
by Huw Davies 21 Jul '08

21 Jul '08

Adam Petaccia wrote: >@@ -226,6 +277,11 @@ GpStatus WINGDIPAPI GdipSetEmpty(GpRegion*region) > > if(!(calls++)) > FIXME("not implemented\n"); >+ TRACE("%p\n", region); >+ >+ GdipDeleteRegion(region); >+ GdipCreateRegion(&region); >+ region->node->type = RegionDataEmptyRect; > > return NotImplemented; > } This is still wrong. You probably don't even want to implement GdipSetEmpty in this patch anyway. In general you may be better off submitting a smaller patch series rather than 16 patches in one go. Huw.

2 1

Re: [PATCH] shell32: Clear a pointer on failure in XDG_UserDirLookup.
by Lei Zhang 21 Jul '08

21 Jul '08

On Wed, Jul 16, 2008 at 12:54 PM, Lei Zhang <thestig(a)google.com> wrote: > Hi, > > We should clear the out pointer on failure, so the caller won't access bad data. > Anything wrong with this patch? Should I check the return value from XDG_UserDirLookup() instead?

1 1

Re: CUDA wrapper
by Seth Shelnutt 21 Jul '08

21 Jul '08

Well at least it compiled, but it isn't working. We are still getting the message that the function isn't implemented. Initializing Nvidia gpu library cudaMalloc CUDAStream::Allocate failed feature is not yet implemented Now both cudamalloc and all four cuda stream's, cudaStreamCreate, Destroy, Query and Synchronize were implemented. I thought maybe it was because in the spec file I had the cudaStream's as pointers (ptr) so I switched them to long but ti didn't make a difference. Originally the argument was "stream" but I can't get any argument but ptr and long to pass the winegcc for spec files. http://shelnutt.twomurs.com/patches/cuda/cuda.dll.spec Does wine need to somehow be made aware of the presence of the cudart.dll.sofile? We tried putting it in both the system32 and the lib folder but it seems also that maybe WINE needs to be made aware of it?

3 10

Failing make crosstest
by Adam Petaccia 21 Jul '08

21 Jul '08

For me make crosstest fails on comctl32, is anyone else seeing this? Or have I missed a secret step? make[2]: Entering directory `/usr/local/src/cvs/wine/dlls/comctl32/tests' i586-mingw32msvc-windres -i rsrc.res -o rsrc.res.cross.o i586-mingw32msvc-windres: rsrc.res: Not a valid WIN32 resource file make[2]: *** [rsrc.res.cross.o] Error 1 make[2]: Leaving directory `/usr/local/src/cvs/wine/dlls/comctl32/tests' make[1]: *** [comctl32/tests/__crosstest__] Error 2 make[1]: Leaving directory `/usr/local/src/cvs/wine/dlls' make: *** [dlls/__crosstest__] Error 2

1 0

gdi32: "StretchDIBits" seems to use the wrong picture offset
by Mathias Kosch 21 Jul '08

21 Jul '08

Currently I'm trying to fix Bug#13344. I figured out that the problems seems to be caused by the function "StretchDIBits" inside "dlls/gdi32/dib.c". When I run "Digital Photo Professional 3.4.1.1" and open images in the editor window in "fit to window" mode all images are shifted to top so that I cannot totally see them. I provided a screenshot as attachment for you to see. The picture was colored to purple to reduce bandwidth. The dimensions of the visible image are 1276 x 850 pixels. The picture is shifted upwards by exactly 174 pixels, so a black bar appears at the bottom. I modified my local copy of "dib.c" (modifications as attachment) to output its parameters. The produced (extract of the) output is attached as "output.txt". The function "StretchDIBits" is called correctly. It shall display a portion of the bitmap at position (0, 40) of dimensions (1276, 850). This function produces two calls to "StretchBlt". (In my case only the second one is called.) The parameters it passes to "StretchBlt" appear to be wrong because (in the second call) "ySrc" is set to 174 which explains the pixel shift. If I adjust "ySrc" to 0 all images are displayed correctly. I looked at the code of "SetDIBits". It seems that it doesn't make any difference between bottom-up or top-down DIBs except that the pixel data is mirrored in y direction. I assume Windows does it the same way, but didn't verify it. However "StretchDIBits" wants to differentiate between the two cases by setting the y offset to "abs(height)-heightSrc-ySrc". I think only "ySrc" should be used as y offset. However since I'm not absolutely sure I would like to ask someone with a little more experience. By the way, I recognized another problem. The code also contains two calls to "SetDIBits" with parameter "height" for "UINT lines". However "height" may be negative. When I'm able to produce a patch for Bug#13344 I will fix this as well. -- Mathias Kosch <info(a)mkosch.de> | http://www.mkosch.de/ RSA Public Key: http://www.mkosch.de/pubkey IT-Nachrichten auf heise online: http://www.heise.de/

2 2

Re: wineesd: Make use of `esd-config --libs` for the configure check. Filter out /usr/lib and /usr/lib64. Also follow the naming convention for the 'xxx-config' variables.
by Alexandre Julliard 21 Jul '08

21 Jul '08

Francois Gouget <fgouget(a)codeweavers.com> writes: > I added code to filter out -L/usr/lib and -L/usr/lib64 because we're > doing it for gphoto2 already, presumably to avoid trouble on 64bit Linux > systems. I'm not sure if that was a gphoto2-specific issue or if it > should be done more systematically. If the latter, then there are other > places that don't do that filtering: libxml-2.0, libxslt, hal and > freetype (but then maybe they don't report the -L settings). If the > filtering is not desired, then I can resubmit. We have only had problems with it with gphoto2 as far as I know. If some other libraries have the same problem then it can be added for them, but I don't see a need to do it systematically. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: kernel32/tests: Fix a failing test in vista
by Dmitry Timoshkov 21 Jul '08

21 Jul '08

"Nicolas Le Cam" <niko.lecam(a)gmail.com> wrote: > Vista introduced new flags for CompareString, as stated in [1]. > The value defined for LINGUISTIC_IGNORECASE is 0x10. So the invalid flag > test don't fail as expected starting from this platform. > > [1] http://msdn.microsoft.com/en-us/library/ms647476.aspx LINGUISTIC_IGNORECASE should be added first instead of using a hex value, and CompareString implementation should handle that flag as well. -- Dmitry.

2 1

ntoskrnl tests - where to write them?
by Jeff Latimer 21 Jul '08

21 Jul '08

I have been looking at writing a couple of tests for ntoskrl functions but I have had difficulty locating a suitable place. It sort of looks like ntdll/tests is the place but it is not clear. Is there a guide for locating this one? Jeff

6 5

Re: [PATCH] ntdll: Use our own implementation of atoi.
by Alexandre Julliard 21 Jul '08

21 Jul '08

"Lei Zhang" <thestig(a)google.com> writes: > diff --git a/dlls/ntdll/string.c b/dlls/ntdll/string.c > index ebfa6fb..6b36364 100644 > --- a/dlls/ntdll/string.c > +++ b/dlls/ntdll/string.c > @@ -466,10 +466,31 @@ ULONG __cdecl NTDLL_strtoul( const char *nptr, char **endptr, int base ) > > /********************************************************************* > * atoi (NTDLL.@) > + * > + * Same implementation as _atoi64. If it's the same then there's no need to duplicate it, just call atoi64. Also what about atol? -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: mlang: A very basic implementation of the IMLangLineBreakConsole interface
by Alexandre Julliard 21 Jul '08

21 Jul '08

> +interface IMLangLineBreakConsole : IUnknown > +{ > + HRESULT BreakLineML( > + [in] IUnknown* pSrcMLStr, /* FIXME: IMLangString */ > + [in] long lSrcPos, > + [in] long lSrcLen, > + [in] long cMinColumns, > + [in] long cMaxColumns, > + [out] long* plLineLen, > + [out] long* plSkipLen); Please add the necessary IMLangString definitions needed for the function to be declared correctly. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH 2/2] gdiplus: Detect integer overflow in GdipCreateBitmapFromScan0.
by Alexandre Julliard 21 Jul '08

21 Jul '08

"Lei Zhang" <thestig(a)google.com> writes: > - datalen = abs(stride * height); > + datalen = stride * height; > size = sizeof(BITMAPFILEHEADER) + sizeof(BITMAPINFOHEADER) + datalen; > + if (datalen <= 0 || size <= 0){ > + GdipFree(*bitmap); > + *bitmap = NULL; > + return InvalidParameter; > + } Testing for overflow is a good idea, but checking for a negative result is not the right way. You can get overflow with a positive result too. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: gphoto2.ds: On Solaris Blastwave's libgphoto2.so needs libintl.so.
by Alexandre Julliard 21 Jul '08

21 Jul '08

Francois Gouget <fgouget(a)codeweavers.com> writes: > Blastwave's 'gphoto2-config --libs' does not say that we need to link > with libintl.so when linking with libgphoto2.so. In a way it's normal as > this dependency does not come from libgphoto2 itself, but from one of > the libraries it links with. I don't think libintl is available > everywhere so I made this patch that first tries to link without it, and > then again with. I think that should be fixed in Blastwave. The whole point of having a config --libs script is to return the necessary paths and dependencies. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: taskmgr: Add full translation [1/2]
by Detlef Riekenberg 20 Jul '08

20 Jul '08

On So, 2008-07-20 at 22:58 +0500, Vladimir Pankratov wrote: First of all, your Idea is great, but your Patch is far to large. Please move only some strings (usual is from one source file) to the resources at once. Then you must keep the resources in sync. That means, when you move one string to the resources, you must add that string to all rc files (most times as english string). Check the patch-size here. It might be useful to split the string-move for one source-file to the resources in more than one patch. The strings in the Menu and Dialogs are already in the resources and translated. You must not remove them. As a hint for your first removed item: grep ID_VIEW_LARGE programs/taskmgr/*.rc > + TCHAR szLoadedString[250]; > + TCHAR szTemp[250]; ... > + LoadStringA(hInst, IDS_UNABLE_TO_ACCESS, szLoadedString, > sizeof(szLoadedString)); > + MessageBox(hMainWnd, strErrorText, szLoadedString, MB_OK| > MB_ICONSTOP); We try to avoid TCHAR and change our Apps to Unicode. When you add code to move the strings to the resources, please use WCHAR and the Unicode functions As a note, switching to unicode later (-DUNICODE -D_UNICODE) breaks with the code from your Patch. When you compare TCHAR, LoadStringA and MessageBox for ANSI and UNICODE, you see, why '#include <tchar.h>' should be forbidden. Thanks for helping Wine. -- By by ... Detlef

1 0

Re: MBCS minor bug fix
by Juan Lang 20 Jul '08

20 Jul '08

Hi Hirofumi, the subject of your patch doesn't tell us very much. Most submissions are in fact bug fixes in fact, so please describe what the bug is at least. A test case showing what's wrong with the existing code, and that shows that your patch fixes it, would be much better. Furthermore, - if (!lpszPath || (iLen = strlen(lpszPath)) >= MAX_PATH) - return NULL; + while(*pch != '\0') + { + pchLast = pch; + pch = CharNext(pch); + } Here you're discarded a test of lpszPath against NULL. That can't be correct, since the existing tests show that Windows returns NULL in this case. (See http://source.winehq.org/source/dlls/shlwapi/tests/path.c#L620 ). You must run 'make test' in the tests directory of the code you're changing (at least), and the tests must pass, in order for your changes to be acceptable. Also, the call to CharNext isn't allowed in Wine's source. (Did you try to compile it? It should have failed to compile.) You must use either CharNextA or CharNextW, whichever is appropriate, instead. + if(MAX_PATH <= lstrlen(lpszPath)) + return NULL; This change seems like an unnecessary style change. The existing test of lpszPath and its length accomplished the same thing, so please leave them alone and concentrate on the fix itself. Finally, if I understand the intent of your patch correctly, the changes to PathAddBackslashW are unnecessary: the W variant doesn't have to deal with MBCS string encodings, so using strlenW to find the end of the string is sufficient. Besides, the following change is simply incorrect, and will produce incorrect results nearly all the time: + if(MAX_PATH <= lstrlen(lpszPath)) Thanks for contributing to Wine. --Juan

1 0

re: Visual Runtime conflicts with the debugger?
by Dan Kegel 20 Jul '08

20 Jul '08

Markus Hitter wrote: >My pet app (Catia) works partially now. That's great! I have a copy, too, but the only thing I did with it was file a bug about the installer... >The thing most missing is, it >can't open a file. As soon as I attempt to do so, the app freezes for >a minute, then a "Visual C++ Runtime Exception" is shown. >[I tried using winedbg to track this down but it doesn't work.] Most of us use log files rather than debuggers to track this kind of thing down. You might want to try WINEDEBUG=+seh,+relay wine catia.exe > log 2>&1 and then get the shortest possible session that reproduces the bug (ideally, noninteractive; does catia take a commandline parameter to open a file?) The trick is to wade through the log file without despairing at how big it is. Tools like grep, head, tail, and in bad cases, perl or sed, are handy for this... - Dan

1 0

Re: [1/2] server: fix async read on mailslot
by Andrey Turkin 20 Jul '08

20 Jul '08

Hi Ambroz, > - > FILE_SYNCHRONOUS_IO_NONALERT ); > + read_timeout ? 0 : > FILE_SYNCHRONOUS_IO_NONALERT ); This looks incorrect. You probably want to compare to -1, not zero. Zero means reads must not block at all, and -1 means read must wait forever (not sure what zero timeout would work as expected with your patch, but it didn't anyway and I think it maybe is broken in another place) Also, please attach patches with disposition inline, not attachment (git can do that) - this make review somehow easier. Regards, Andrey Ambroz Bizjak wrote: > Hi, > > Changelog: > server: fix async read on mailslot > ------------------------------------------------------------------------ > > >

2 2

Visual Runtime conflicts with the debugger?
by Markus Hitter 20 Jul '08

20 Jul '08

Hello all, My pet app (Catia) works partially now. The thing most missing is, it can't open a file. As soon as I attempt to do so, the app freezes for a minute, then a "Visual C++ Runtime Exception" is shown. The shown dialog doesn't feature any meaningful information. So I moved from "wine" at the command line to "winedbg" to get a grip. Unfortunately, this runtime exception doesn't cause the debugger to jump in. All I get is one line: > wine: Unhandled exception 0x80000003 at address 0x7b844351 (thread > 0027), starting debugger... If I force the debugger to pay attention by typing Ctrl-C, I can even get a tiny backtrace: > Backtrace: > =>1 0xffffe40e (0x0033f260) > 2 0x00000800 (0x0033f3a0) > 3 0x7b84ab42 ReadFile+0x264(hFile=0x50, buffer=0x33f448, > bytesToRead=0x800, bytesRead=0x33fcc0, overlapped=0x0) [/home/mah/ > wine/dlls/kernel32/file.c:451] in kernel32 (0x0033f420) > 4 0x0040367b in catstart (+0x367b) (0x0033fc58) Nevertheless, the app continues to run in the GUI as before, making it impossible to check print variables or do stepping. As a third chance, I tried "winedbg --gdb". However, this stops very early: > 00000038:00000013: exception code=0x80000003 > warning: Target reported unsupported offsets: > Text=00110e20;Data=000000be;Bss=00000008 > [New Thread 19] > 0x7b8829fd in DbgBreakPoint () at ../../include/winternl.h:1828 > 1828 static inline void WINAPI DbgBreakPoint(void) { __asm__ > __volatile__("int3"); } > trace: 98 => 80 After showing this, no debugger prompt follows and a Ctrl-C is answered with a quit of both, the debugger and the app. As a last resort I tried to insert printf() statements into the source, finding me unable to repeat the numbers seen in the tiny backtrace above. bytesToRead obviously never has the value 0x800 (= 2048). So my question is: How would I go and debug such an issue? Is it even possible to set breakpoints, to get meaningful backtraces and print() statements and/or to catch Visual Whatever Runtime Exceptions? Thanks, Markus P.S.: This is a current Wine (git) on Ubuntu 64-bit. - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/

1 0

Re: Japanese conversion tests
by Dmitry Timoshkov 20 Jul '08

20 Jul '08

"Aric Stewart" <aric(a)codeweavers.com> wrote: > --- > dlls/mlang/tests/mlang.c | 173 > ++++++++++++++++++++++++++++++++++++++++++++++ > 1 files changed, 173 insertions(+), 0 deletions(-) This behaviour is not mlang specific, and should be added to dlls/kernel32/tests/codepage.c instead. -- Dmitry.

1 0

Interface fonts and locale woes
by Rafał Mużyło 20 Jul '08

20 Jul '08

I wasn't sure if I should post this to the devel or user list. A coin toss decided on this one. First of all, I'd like to praise the author of the patch at http://www.winehq.org/pipermail/wine-patches/2008-July/057033.html for "brilliance of simplicity". As I have all the fonts I needed, it annoyed me a lot that wine was displaying boxes in dialogs, instead of correct glyphs. With that patch, fonts are correctly displayed without any further tweaking. I still probably need to construct a fontconfig rule to tweak it a little bit (mainly antialiasing), but those are just details. Now, for the questions: 1. Do I understand correctly, that this rule should be for Tahoma or should it be another font ? 2. Is there any mechanism to emulate what AppLocale does in a sane way (no, LANG override does not count, it puts whole wine into a different locale, instead of only the app; while that works for most apps, it seems that some make silly assumptions based on locale, like 'what "My Documents" folder is called', also I don't want wine debug messages in a language I can't read fluently) ? Maybe it would be a good idea to expose for the user some of the changes, locale switch makes, so the user could decide which of them are needed, so it could be possible to i.e. run a program with only default ansi charset changed.

1 0

Re: [PATCH] gdi32: Glyph advances should be measured for unrotated characters.
by Dmitry Timoshkov 20 Jul '08

20 Jul '08

"Lei Zhang" <thestig(a)google.com> wrote: > Committish 85c16fc45 broke some text rendering for me. It looks like > when the font has orientation set, adv got the width of the rotated > chars, whereas the comment in struct GM says it's the width of the > unrotated chars. > > Dmitry, can you comment on the patch? It should be possible to add a test case for this. -- Dmitry.

1 0

re: [2/6] winhttp: Allow winhttp to use wininet.h with winhttp.h
by Dan Kegel 20 Jul '08

20 Jul '08

James wrote: > I thought the idea was to implement winhttp and then > implement wininet on top of winhttp. Why are you importing wininet? As of January, Hans was still talking about implementing winhttp on top of wininet ( http://www.winehq.org/pipermail/wine-devel/2008-January/062172.html http://www.winehq.org/pipermail/wine-devel/2007-August/058420.html ) It's not clear one can fully implement either wininet on top of winhttp or vice versa. We will probably need some code duplication or private interfaces eventually. Building winhttp on top of wininet lets us develop on trunk and is probably the fastest path to making a bunch of applications happy, isn't it? That's the way I'm leaning, anyway. - Dan

5 4

Re: [8/11] kernel32: Implement the timer queue thread.
by Rob Shearman 19 Jul '08

19 Jul '08

2008/7/19 Dan Hipschman <dsh(a)linux.ucla.edu>: > > This patch implements the timer thread, running callbacks, cleaning up > timers, and all that good stuff. It should be very efficient, using mostly > atomic operations and one critical section for thread safety. It would be more efficient for queues with large numbers of timers if you used the approach used by server/fd.c of keeping a list of timers sorted by when they next expire to avoid having to search through the entire list every time a timer expires. > I designed > it with thread-safety in mind, and once I got it working the way I wanted, > ran the tests in a loop a few thousand times while I ate lunch. I also did > this with the following patches and never once got a single error, hang or > crash. > > It punts on some integer-wrapping issues. If someone runs their wineserver > for 49 days they may run into that issue. I just thought it would distract > from the main content and wanted to finish everything else before I thought > about it. > > Note that the one todo_wine that got added in the tests wasn't because > something broke, it's just that the function never ran before. > > --- > dlls/kernel32/sync.c | 214 ++++++++++++++++++++++++++++++++++++++++---- > dlls/kernel32/tests/sync.c | 42 +++++++-- > 2 files changed, 231 insertions(+), 25 deletions(-) As mentioned previously, this should be implemented in ntdll. > > diff --git a/dlls/kernel32/sync.c b/dlls/kernel32/sync.c > index 8085077..4df5b44 100644 > --- a/dlls/kernel32/sync.c > +++ b/dlls/kernel32/sync.c > @@ -21,6 +21,7 @@ > #include "config.h" > #include "wine/port.h" > > +#include <assert.h> > #include <string.h> > #ifdef HAVE_UNISTD_H > # include <unistd.h> > @@ -1043,17 +1044,145 @@ BOOL WINAPI CancelWaitableTimer( HANDLE handle ) > } > > > +struct timer_queue; > struct queue_timer > { > + struct timer_queue *q; > struct list entry; > + LONG runcount; /* number of callbacks pending execution */ > + WAITORTIMERCALLBACK callback; > + PVOID param; > + DWORD period; > + ULONG flags; > + DWORD expire; > + BOOL die; /* timer should be deleted; once set, never unset */ "destroy" or "delete" might be a better name for this field. > }; > > struct timer_queue > { > RTL_CRITICAL_SECTION cs; > struct list timers; > + struct queue_timer *next; /* the next timer to expire */ > + BOOL quit; /* queue should be deleted; once set, never unset */ > + DWORD timeout; /* when the next timer expires */ > + HANDLE event; > + HANDLE thread; > }; > > +static void queue_remove_timer(struct timer_queue *q, struct queue_timer *t) > +{ > + /* We MUST hold the queue cs while calling this function. This ensures > + that we cannot queue another callback for this timer. The runcount > + being zero makes sure we don't have any already queued. */ > + assert(t->runcount == 0); > + assert(t->die); > + list_remove(&t->entry); > + if (q->next == t) > + q->next = NULL; > + HeapFree(GetProcessHeap(), 0, t); > +} > + > +static DWORD WINAPI timer_callback_wrapper(LPVOID p) > +{ > + struct queue_timer *t = (struct queue_timer *) p; This cast is unnecessary. > + struct timer_queue *q = t->q; > + > + t->callback(t->param, TRUE); > + > + RtlEnterCriticalSection(&q->cs); > + InterlockedDecrement(&t->runcount); Since you only ever access runcount while inside a critical section then you don't need to use interlocked functions to modify it. > + if (t->die && t->runcount == 0) > + { > + queue_remove_timer(q, t); > + /* Wake up the cleanup loop so it can see if all timers are gone. */ > + if (q->quit) > + SetEvent(q->event); > + } > + RtlLeaveCriticalSection(&q->cs); > + > + return 0; > +} > + > +static void queue_timer_expire(struct queue_timer *t) > +{ > + /* We MUST hold the queue cs while calling this function. */ > + if (!t->die) > + { > + ULONG flags = > + t->flags & (WT_EXECUTEINIOTHREAD | WT_EXECUTEINPERSISTENTTHREAD > + | WT_EXECUTELONGFUNCTION | WT_TRANSFER_IMPERSONATION); > + InterlockedIncrement(&t->runcount); > + QueueUserWorkItem(timer_callback_wrapper, t, flags); You should check the return value and undo the incrementing of t->runcount if it failed. However, you're also calling QueueUserWorkItem inside a critical section so you're imposing a lock ordering on the loader lock. This may cause a deadlock that may or may not exist on Windows if a timer queue function is called from an application's DllMain. > + } > + > + if (t->period) > + { > + /* FIXME: Solve this, here or in timer_queue_update. */ > + DWORD tick = GetTickCount(); > + t->expire = tick + t->period; > + if (t->expire < tick) > + ERR("next expiration wrapped\n"); > + } > + else > + t->die = TRUE; > +} > + > +static void timer_queue_update(struct timer_queue *q) > +{ > + /* We MUST hold the queue cs while calling this function. */ > + struct queue_timer *t, *temp, *next = NULL; > + DWORD tick, time = ~(DWORD) 0; This cast is unnecessary is you use "~0U" instead. > + > + LIST_FOR_EACH_ENTRY_SAFE(t, temp, &q->timers, struct queue_timer, entry) > + if (t->die) > + { > + if (t->runcount == 0) > + queue_remove_timer(q, t); > + } > + else if (t->expire < time) > + { > + time = t->expire; > + next = t; > + } > + > + tick = GetTickCount(); > + q->timeout = next ? (time < tick ? 0 : time - tick) : INFINITE; > + q->next = next; > +} > + > +static DWORD WINAPI timer_queue_thread_proc(LPVOID p) > +{ > + struct timer_queue *q = p; > + BOOL done; > + > + while (!q->quit) > + { > + DWORD ret = WaitForSingleObject(q->event, q->timeout); > + RtlEnterCriticalSection(&q->cs); > + if (ret == WAIT_TIMEOUT && q->next) > + queue_timer_expire(q->next); > + timer_queue_update(q); > + RtlLeaveCriticalSection(&q->cs); > + } > + > + done = FALSE; > + while (!done) > + { > + RtlEnterCriticalSection(&q->cs); > + timer_queue_update(q); > + if (list_count(&q->timers) == 0) > + done = TRUE; > + RtlLeaveCriticalSection(&q->cs); > + if (!done) > + WaitForSingleObject(q->event, INFINITE); > + } > + > + CloseHandle(q->event); > + CloseHandle(q->thread); > + HeapFree(GetProcessHeap(), 0, q); > + return 0; > +} > + > /*********************************************************************** > * CreateTimerQueue (KERNEL32.@) > */ > @@ -1065,15 +1194,27 @@ HANDLE WINAPI CreateTimerQueue(void) > SetLastError(ERROR_NOT_ENOUGH_MEMORY); > return NULL; > } > + > RtlInitializeCriticalSection(&q->cs); > list_init(&q->timers); > - return q; > -} > + q->next = NULL; > + q->quit = FALSE; > + q->timeout = INFINITE; > + q->event = CreateEventW(NULL, FALSE, FALSE, NULL); > + if (!q->event) > + { > + HeapFree(GetProcessHeap(), 0, q); > + return NULL; > + } > + q->thread = CreateThread(NULL, 0, timer_queue_thread_proc, q, 0, NULL); > + if (!q->thread) > + { > + CloseHandle(q->event); > + HeapFree(GetProcessHeap(), 0, q); > + return NULL; > + } It would be better to use a thread pool thread for processing timer queue since it can be reused when the timer queue is destroyed. It might then also be better to only start the timer queue thread when there are timers to process and also release the timer queue thread back to the thread pool when the last timer is removed from the queue. Also, have you thought about using one thread for all timer queues? This might not be appropriate for WT_EXECUTEINTIMERTHREAD timers, but should improve the performance of the process as a whole without affecting other timers. > > -static void queue_remove_timer(struct timer_queue *q, struct queue_timer *t) > -{ > - list_remove(&t->entry); > - HeapFree(GetProcessHeap(), 0, t); > + return q; > } > > /*********************************************************************** > @@ -1085,22 +1226,32 @@ BOOL WINAPI DeleteTimerQueueEx(HANDLE TimerQueue, HANDLE CompletionEvent) > struct queue_timer *t, *temp; > BOOL ret; > > + RtlEnterCriticalSection(&q->cs); > + LIST_FOR_EACH_ENTRY_SAFE(t, temp, &q->timers, struct queue_timer, entry) > + t->die = TRUE; > + q->quit = TRUE; > + RtlLeaveCriticalSection(&q->cs); > + SetEvent(q->event); > + > if (CompletionEvent == INVALID_HANDLE_VALUE) > { > ret = TRUE; > + WaitForSingleObject(q->thread, INFINITE); What if timer_queue_thread_proc exits before you reach here? q->thread will now be invalid (and could be re-used by another thread in the mean time). Another way of looking at it is that you don't own q after the critical section where q->quit is set. > } > else > { > + if (CompletionEvent) > + { > + /* FIXME: This should add the event to a list of events in the > + queue that it will signal when done. */ > + FIXME("returning and signaling events unimplemented; waiting instead\n"); > + WaitForSingleObject(q->thread, INFINITE); > + SetEvent(CompletionEvent); > + } > ret = FALSE; > SetLastError(ERROR_IO_PENDING); > } > > - RtlEnterCriticalSection(&q->cs); > - LIST_FOR_EACH_ENTRY_SAFE(t, temp, &q->timers, struct queue_timer, entry) > - queue_remove_timer(q, t); > - RtlLeaveCriticalSection(&q->cs); > - > - HeapFree(GetProcessHeap(), 0, q); > return ret; > } > > @@ -1123,19 +1274,50 @@ BOOL WINAPI CreateTimerQueueTimer( PHANDLE phNewTimer, HANDLE TimerQueue, > { > struct timer_queue *q = TimerQueue; > struct queue_timer *t = HeapAlloc(GetProcessHeap(), 0, sizeof *t); > + BOOL ret; > + > if (!t) > { > SetLastError(ERROR_NOT_ENOUGH_MEMORY); > return FALSE; > } > - FIXME(": Timer expiration unimplemented\n"); > + t->q = q; > + t->runcount = 0; > + t->callback = Callback; > + t->param = Parameter; > + t->period = Period; > + t->flags = Flags; > + if (Flags & WT_EXECUTEINTIMERTHREAD) > + FIXME("WT_EXECUTEINTIMERTHREAD unimplemented\n"); If you use an expire list in a local variable then you won't need locking when processing the expired timers and so this will be trivial to implement. > + { > + /* FIXME: Solve this, here or in timer_queue_update. */ > + DWORD tick = GetTickCount(); > + t->expire = tick + DueTime; > + if (t->expire < tick) > + ERR("due time wrapped\n"); > + } > + t->die = FALSE; > > + ret = TRUE; > RtlEnterCriticalSection(&q->cs); > - list_add_tail(&q->timers, &t->entry); > + if (q->quit) > + ret = FALSE; > + else > + list_add_tail(&q->timers, &t->entry); > RtlLeaveCriticalSection(&q->cs); > > - *phNewTimer = t; > - return TRUE; > + if (ret) > + { > + SetEvent(q->event); > + *phNewTimer = t; > + } > + else > + { > + SetLastError(ERROR_INVALID_HANDLE); > + HeapFree(GetProcessHeap(), 0, t); > + } > + > + return ret; > } > > /*********************************************************************** Quite a few comments, but the patches are of a good general quality, so well done. -- Rob Shearman

2 1

Re: [Gdiplus 02/15] Implement GdipCreateRegion
by Huw Davies 19 Jul '08

19 Jul '08

Adam Petaccia wrote: > @@ -226,6 +277,11 @@ GpStatus WINGDIPAPI GdipSetEmpty(GpRegion*region) > > if(!(calls++)) > FIXME("not implemented\n"); > + TRACE("%p\n", region); > + > + GdipDeleteRegion(region); > + GdipCreateRegion(&region); > + region->node->type = RegionDataEmptyRect; > > return NotImplemented; > } This can't work. You don't want to free the memory pointed to by region, simply free the nodes underneath it. Huw.

2 1

Re: [5/11] kernel32: Implement Create/DeleteTimerQueue[Ex].
by Rob Shearman 19 Jul '08

19 Jul '08

2008/7/19 Dan Hipschman <dsh(a)linux.ucla.edu>: > --- > dlls/kernel32/sync.c | 40 ++++++++++++++++++++++++++++++++++------ > dlls/kernel32/tests/sync.c | 11 +++-------- > 2 files changed, 37 insertions(+), 14 deletions(-) These functions should be implemented in ntdll instead of kernel32. I would suggest dlls/ntdll/threadpool.c. -- Rob Shearman

1 0

Re: [3/11] kernel32/tests: Add tests for Change/DeleteTimerQueueTimer.
by Rob Shearman 19 Jul '08

19 Jul '08

2008/7/19 Dan Hipschman <dsh(a)linux.ucla.edu>: > +static void CALLBACK timer_queue_cb2(PVOID p, BOOLEAN timedOut) > +{ > + struct timer_queue_data1 *d = (struct timer_queue_data1 *) p; > + ok(timedOut, "Timer callbacks should always time out\n"); > + /* Wait until our own timer handle is set to avoid a pretty much > + impossible race condition (better safe than sorry). */ > + if (d->t) > + if (++d->num_calls == d->max_calls) You could change the above two lines to just "if (d->t && ++d->num_calls == d->max_calls)" and remove a level of indentation. > + { > + BOOL ret; > + SetLastError(0xdeadbeef); > + /* Note, XP SP2 does *not* do any deadlock checking, so passing > + INVALID_HANDLE_VALUE here will just hang. */ > + ret = pDeleteTimerQueueTimer(d->q, d->t, NULL); > + ok(!ret, "DeleteTimerQueueTimer\n"); > + todo_wine > + ok(GetLastError() == ERROR_IO_PENDING, "DeleteTimerQueueTimer\n"); > + } > +} > + > +static void CALLBACK timer_queue_cb3(PVOID p, BOOLEAN timedOut) > +{ > + struct timer_queue_data1 *d = (struct timer_queue_data1 *) p; > + ok(timedOut, "Timer callbacks should always time out\n"); > + /* Wait until our own timer handle is set to avoid a pretty much > + impossible race condition (better safe than sorry). */ > + if (d->t) > + if (++d->num_calls == d->max_calls) Ditto. > + { > + /* Basically kill the timer since it won't have time to run > + again. */ > + BOOL ret = pChangeTimerQueueTimer(d->q, d->t, 10000, 0); > + ok(ret, "ChangeTimerQueueTimer\n"); > + } > +} > + -- Rob Shearman

1 0

Re: oleaut32: fixed the safearray tests for Vista.
by Rob Shearman 19 Jul '08

19 Jul '08

2008/7/18 Reece Dunn <msclrhd(a)googlemail.com>: > Seems like Vista has fixed the bug in the Windows version of > SafeArrayGetVarType, as indicated by > http://test.winehq.org/data/80ee225f23ea8093f57f1e7b29b7fb60e6f6cdda/vista_…, > so update the tests accordingly. How about fixing SafeArrayGetVarType to conform to the new behaviour and marking the old behaviour as broken? > ------=_Part_61560_4553795.1216418064126 > Content-Type: application/octet-stream; > name=0001-oleaut32-fixed-the-safearray-tests-for-Vista.patch > Content-Transfer-Encoding: base64 > X-Attachment-Id: f_fitbsg940 > Content-Disposition: attachment; > filename=0001-oleaut32-fixed-the-safearray-tests-for-Vista.patch Please try to configure your mail client to send the correct content type for .patch files or rename your patches to have a .txt extension. -- Rob Shearman

1 0

Re: [2 of 2] ole32: always return false when asked if NULL is the current clipboard
by Rob Shearman 19 Jul '08

19 Jul '08

2008/7/17 Vincent Povirk <vincent(a)codeweavers.com>: > @@ -583,6 +583,9 @@ HRESULT WINAPI OleIsCurrentClipboard(IDataObject *pDataObject) > if (!theOleClipboard) > return E_OUTOFMEMORY; > > + if (pDataObject == NULL) > + return S_FALSE; > + Functionally, the patch is good, but one small nit about the style - the check before uses the !ptr style whereas the check that you introduce uses the ptr == NULL style. It would be nice if the checks had a consistent style. -- Rob Shearman P.S. Congratulations on your new job :-)

1 0

Re: [PATCH 3/3] mstask: Implement ClassFactory, DllGetClassObject, and DllCanUnloadNow
by Rob Shearman 19 Jul '08

19 Jul '08

2008/7/18 Roy Shea <royshea(a)gmail.com>: > +static HRESULT WINAPI MSTASK_IClassFactory_QueryInterface( > + LPCLASSFACTORY iface, > + REFIID riid, > + LPVOID *ppvObj) > +{ > + ClassFactoryImpl *This = (ClassFactoryImpl *)iface; > + > + TRACE("\n\tIID:\t%s\n",debugstr_guid(riid)); > + if (This == NULL || ppvObj == NULL) > + return E_POINTER; Please don't introduce any more checks for This being NULL. -- Rob Shearman

1 0

Problem compiling wine tests with msvc in standalone mode.
by Reece Dunn 19 Jul '08

19 Jul '08

Hi, I am using VS 2008 (9.0) Express in conjunction with the Vista SDK. When compiling the tests, I get: c:\Users\reece\wine\dlls\comctl32\tests>cl -D_X86_ -DSTANDALONE -I../../../inclu de listview.c Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 15.00.21022.08 for 80x86 Copyright (C) Microsoft Corporation. All rights reserved. listview.c c:\program files\microsoft sdks\windows\v6.0a\include\rpc.h(99) : warning C4005: 'RPCRTAPI' : macro redefinition ../../../include\rpc.h(53) : see previous definition of 'RPCRTAPI' c:\program files\microsoft sdks\windows\v6.0a\include\rpc.h(155) : warning C4005 : 'RpcTryExcept' : macro redefinition ../../../include\rpc.h(81) : see previous definition of 'RpcTryExcept' c:\program files\microsoft sdks\windows\v6.0a\include\rpc.h(162) : warning C4005 : 'RpcExcept' : macro redefinition ../../../include\rpc.h(82) : see previous definition of 'RpcExcept' c:\program files\microsoft sdks\windows\v6.0a\include\rpc.h(171) : warning C4005 : 'RpcTryFinally' : macro redefinition ../../../include\rpc.h(84) : see previous definition of 'RpcTryFinally' c:\program files\microsoft sdks\windows\v6.0a\include\rpc.h(178) : warning C4005 : 'RpcFinally' : macro redefinition ../../../include\rpc.h(85) : see previous definition of 'RpcFinally' c:\program files\microsoft sdks\windows\v6.0a\include\rpc.h(183) : warning C4005 : 'RpcEndFinally' : macro redefinition ../../../include\rpc.h(86) : see previous definition of 'RpcEndFinally' c:\program files\microsoft sdks\windows\v6.0a\include\rpc.h(185) : warning C4005 : 'RpcExceptionCode' : macro redefinition ../../../include\rpc.h(87) : see previous definition of 'RpcExceptionCod e' c:\program files\microsoft sdks\windows\v6.0a\include\rpcndr.h(33) : fatal error C1189: #error : incorrect <rpcndr.h> version. Use the header that matches with the MIDL compiler. Any ideas? Thanks, - Reece

2 2

Re: git inconsistency - cannot fetch latest patchset
by Kirill K. Smirnov 19 Jul '08

19 Jul '08

В сообщении от Saturday 19 July 2008 14:24:40 Nikolay Sivov написал(а): > This 'missed' commit goes to stable branch. > http://source.winehq.org/git/wine.git/?a=shortlog;h=refs/heads/stable Thanks, I almost forgot about branches! Sorry for nuisance. -- Kirill

1 0

git inconsistency - cannot fetch latest patchset
by Kirill K. Smirnov 19 Jul '08

19 Jul '08

Hello, According to wine-cvs mailing list, latest patch is "Vladimir Pankratov : hhctrl.ocx: Update Russian translation.", but it cannot be fetched, after fetch/rebase the following patch is the latest: "Huw Davies : winmm: Only fill in the MIXERLINEA struct if the call to mixerGetLineInfoW succeeds". Web interface to git tree http://source.winehq.org/git/wine.git/, does not contain that patch too. Does anybody observe the same issue? -- Kirill

2 1

Re: [8/11] kernel32: Implement the timer queue thread.
by Hans Leidekker 19 Jul '08

19 Jul '08

On Saturday 19 July 2008 02:19:11 Dan Hipschman wrote: > It punts on some integer-wrapping issues. If someone runs their wineserver > for 49 days they may run into that issue. I just thought it would distract Have you thought about using GetTickCount64 instead of GetTickCount? -Hans

1 0

Re: kernel32/tests: Run the tests again on Win9x (TimerQueue)
by Dan Hipschman 19 Jul '08

19 Jul '08

On Fri, Jul 18, 2008 at 09:27:49PM +0200, Detlef Riekenberg wrote: > Some functions are not present on win98: > CreateTimerQueue > CreateTimerQueueTimer > DeleteTimerQueueEx > > > Changelog: > kernel32/tests: Run the tests again on Win9x (TimerQueue) > > > > ???Dan, when you are finished with your Patchset, please give me a note. > Thanks > (???I saw more to do in this File: merge all GetProcAddress in one place, > use skip, GetLastError is different on win98 in a test.) Please use this one instead: http://www.winehq.org/pipermail/wine-patches/2008-July/058184.html so the other patches in the same set will apply. Thanks.

1 0

Errors on Run of winetricks dotnet11.
by James McKenzie 19 Jul '08

19 Jul '08

It looks like something is crashing when running the .NET 1.1 installer. Is there an existent bug for this problem? If not, would it be worthwhile to create an issue for this? System: MacBook OS Version: 10.5.3 X11: 2.1.1 (I don't think this is what is causing the crash.) XCode is not installed on this system James McKenzie

1 0

valgrind progress: down to 164 errors in 52 tests
by Dan Kegel 18 Jul '08

18 Jul '08

This morning a whole bunch of warnings in directx, dde, gdiplus, and winmm were fixed; see http://kegel.com/wine/valgrind/logs/2008-07-18-07.39-summary.txt This brings us down from yesterday's 187 errors in 67 tests to 164 errors in 52 tests. That's a nice way to start the day.

1 0

Re: Re[2]: advapi32: "RegGetValue" fails with some correct combinations of "dwFlags"
by James Hawkins 18 Jul '08

18 Jul '08

2008/7/18 Mathias Kosch <info(a)mkosch.de>: > Alexandre Julliard wrote: > >> Patches should be generated from the top-level directory. > Sorry for that, I fixed it. Please read [1] to find out how to properly send patches in Wine. You need to send one patch per email. [1] http://www.winehq.org/site/sending_patches -- James Hawkins

1 0

re: ntdll: Remove byte reversed U+3000 (CJK space) from being checked in RtlIsTextUnicode.
by Dan Kegel 18 Jul '08

18 Jul '08

Hang on, if you don't check U+3000 in the big endian case, you probably shouldn't check it in the little endian case, either, right?

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel