- wine-devel - winehq.org

msi/automation tests on win9x
by Paul Vriens 27 Aug '08

27 Aug '08

Hi, Every time these tests run I get a message box on win9x stating that the service can't be created. Makes sense as we don't have services on win9x. Can we skip all tests if we are on win9x (check for OpenSCManager being not implemented)? -- Cheers, Paul.

2 1

Re: [2/2] user32/tests: Test case for "Fixed bug in loading .cur files"
by Paul Vriens 27 Aug '08

27 Aug '08

JIM CAMERON wrote: > The patch for cursor loading caused some existing > tests to succeed inside todo blocks. This patch > removes those todo and adds a regression test for CreateIconFromResource(). > > > ------------------------------------------------------------------------ > > Hi, That means the tests on Wine will 'fail' without this patch. You should add the removal of the todo_wine's to the first patch. -- Cheers, Paul.

1 0

Re: [ntdll/tests] Fix the SystemHandleInformation tests
by Alexandre Julliard 27 Aug '08

27 Aug '08

Paul Vriens <paul.vriens.wine(a)gmail.com> writes: > The last changes introduced an error on anything but Vista and skipped > the test for the number of handles on all platforms. This is breaking it on Vista again: info.c:411: Test failed: Unexpected ReturnLength : 32 info.c:424: Test failed: Expected STATUS_SUCCESS, got c0000004 -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: regedit: Fix concat handling for ANSI files (try2)
by Alexandre Julliard 27 Aug '08

27 Aug '08

Alexander Nicolaysen Sørnes <alex(a)thehandofagony.com> writes: > + if(c == EOF) > fprintf(stderr,"%s: ERROR - invalid continuation.\n", > getAppName()); > + > + *s = c; > + s++; It's better, but I don't think you want to store EOF in the result string... -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: taskmgr [try 6] [1/2]: Converted some functions and variables to Unicode
by Alexandre Julliard 27 Aug '08

27 Aug '08

Vladimir Pankratov <scriptkid(a)mail.ru> writes: > @@ -93,7 +100,7 @@ > ULONG Idx, Idx2; > HANDLE hProcess; > HANDLE hProcessToken; > - TCHAR szTemp[MAX_PATH]; > + WCHAR wszTemp[256]; > DWORD dwSize; > SYSTEM_PERFORMANCE_INFORMATION SysPerfInfo; > SYSTEM_TIME_INFORMATION SysTimeInfo; > @@ -290,22 +297,10 @@ > if (hProcess) { > if (OpenProcessToken(hProcess, TOKEN_QUERY|TOKEN_DUPLICATE|TOKEN_IMPERSONATE, &hProcessToken)) { > ImpersonateLoggedOnUser(hProcessToken); > - memset(szTemp, 0, sizeof(TCHAR[MAX_PATH])); > + memset(wszTemp, 0, sizeof(wszTemp)/sizeof(WCHAR)); > dwSize = MAX_PATH; You are introducing at least two bugs here. Please don't change things that don't need changing. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: rpcrt4: Fix format specifier warning in NdrAllocate when size_t is typedef'd to unsigned long.
by Alexandre Julliard 27 Aug '08

27 Aug '08

"Rob Shearman" <robertshearman(a)gmail.com> writes: > @@ -373,7 +373,8 @@ void * WINAPI NdrAllocate(MIDL_STUB_MESSAGE *pStubMsg, size_t len) > /* check for overflow */ > if (adjusted_len < len) > { > - ERR("overflow of adjusted_len %d, len %d\n", adjusted_len, len); > + ERR("overflow of adjusted_len %lu, len %lu\n", (long)adjusted_len, > + (long)len); A better fix would be to avoid size_t completely, we should use SIZE_T instead. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [3/3] mshtml: Add IHTMLBodyElement test
by Jacek Caban 27 Aug '08

27 Aug '08

Hi Alistair, Alistair Leslie-Hughes wrote: > Hi, > > Changelog: > mshtml: Add IHTMLBodyElement test > These tests should go to script.c. Also take a look at elem_type_infos table. It would help you to avoid a mistake in previous patch. Jacek

1 0

advapi32:service failing tests
by James Hawkins 27 Aug '08

27 Aug '08

Hi Paul, Tests you added in the following commit cause failures in NT4, 2000, and Vista. Can you have a look please? commit 0539b463e65b386f4aa4c4235bf83d7f1d003e48 Author: Paul Vriens <paul.vriens.wine(a)gmail.com> Date: Thu Aug 21 16:14:45 2008 +0200 advapi32/tests: Add tests for EnumServicesStatusA. http://test.winehq.org/data/5f727cb2afbfafc3b396cf4902e55ca95dbc69d5/ Thanks, James Hawkins

2 1

Header file locations
by chengas123 27 Aug '08

27 Aug '08

Hi, I'm new to WINE and a bit rusty with C, so forgive me if my questions are a bit basic. I'm having trouble finding header files. For example, take a look at http://source.winehq.org/source/dlls/secur32/schannel.c There's a line that says '#include "schannel.h"', but I'm not sure where that file is. Thanks, Ben -- View this message in context: http://www.nabble.com/Header-file-locations-tp19174580p19174580.html Sent from the Wine - Devel mailing list archive at Nabble.com.

2 1

Re: (resend)systray: keep systray hidden when requested by moving itoff screen
by Dmitry Timoshkov 27 Aug '08

27 Aug '08

"Aric Stewart" <aric(a)codeweavers.com> wrote: > diff --git a/programs/explorer/systray.c b/programs/explorer/systray.c > index 8b82d9a..4a7e57e 100644 > --- a/programs/explorer/systray.c > +++ b/programs/explorer/systray.c > @@ -437,6 +437,19 @@ static LRESULT WINAPI tray_wndproc( HWND hwnd, UINT msg, WPARAM wparam, LPARAM l > case WM_COPYDATA: > return handle_incoming((HWND)wparam, (COPYDATASTRUCT *)lparam); > > + case WM_DISPLAYCHANGE: > + if (hide_systray) > + { > + int offscreen; > + SIZE size; > + size = get_window_size(); > + offscreen = GetSystemMetrics(SM_XVIRTUALSCREEN); > + offscreen += GetSystemMetrics(SM_CXVIRTUALSCREEN); > + offscreen += 20; > + MoveWindow(tray_window, offscreen, -500, size.cx, size.cy, TRUE); > + } > + break; > + > case WM_TIMER: > cleanup_destroyed_windows(); > break; > @@ -568,5 +581,15 @@ void initialize_systray(void) > WINE_ERR("Could not create tray window\n"); > return; > } > + > + if (hide_systray) > + { > + int offscreen; > + offscreen = GetSystemMetrics(SM_XVIRTUALSCREEN); > + offscreen += GetSystemMetrics(SM_CXVIRTUALSCREEN); > + offscreen += 20; > + MoveWindow(tray_window, offscreen, -500, size.cx, size.cy, TRUE); > + } > + > SetTimer( tray_window, 1, 2000, NULL ); > } Why not add a function do_hide_systray() and call it unconditionally from both places? do_hide_systray() { if (!hide_systray) return; [hide systray] } That would help keeping the code coherent if somebody changes one of places later. -- Dmitry.

1 0

Re: kernel32/winerr: Add Russian translation
by Dmitry Timoshkov 27 Aug '08

27 Aug '08

"Vladimir Pankratov" <scriptkid(a)mail.ru> wrote: > Added Russian translation. > > Changed files: > dlls/kernel32/nls/winerr_rus.mc > dlls/kernel32/kernel.rc > dlls/kernel32/Makefile.in No one of my concerns have been addressed in this version of the patch. -- Dmitry.

1 0

WWN 351
by Zachary Goldberg 27 Aug '08

27 Aug '08

This one is pretty big so I wanted to send it to wine-devel first for some review. Usually I ask on IRC and give people a link but I am unable to provide such a link this time. Attached is both the patch for those who have a local copy of winehq and a tar file of the html for those who don't. If I don't get any comments by about this time tomorrow I'll send to wine-patches. --Zach

1 0

Re: [Take 2] winex11.drv: Fix buffer overflow bug in X11DRV_KeyEvent()and X11DRV_ToUnicodeEx()
by Dmitry Timoshkov 27 Aug '08

27 Aug '08

"Muneyuki Noguchi" <nogu.dev(a)gmail.com> wrote: > Changes from the previous patch: > - Add a new variable STRSIZE. A define would be better IMO, or just use 64 directly, 2 places don't justify the introduction of it. > - Use HeapAlloc() and HeapFree() instead of malloc() and free(). I'd suggest to have an initial buffer of 64 bytes allocated on the stack, and allocate a larger buffer only if required. That improves performance. > - Return from a function when (re)allocation failed. You have to call wine_tsx11_unlock() when needed on exit. -- Dmitry.

2 2

Re: Opengl32: add a WGL_ARB_create_context / OpenGL 3.0 test
by Chris Robinson 26 Aug '08

26 Aug '08

On Tuesday 26 August 2008 01:17:18 pm Roderick Colenbrander wrote: > + int attribs[] = {WGL_CONTEXT_MAJOR_VERSION_ARB, 3, > WGL_CONTEXT_MINOR_VERSION_ARB, 0, 0}; > + HGLRC gl3Ctx = > pwglCreateContextAttribsARB(hdc, 0, attribs); > + ok(gl3Ctx != NULL, > "Creation of an OpenGL 3.0 context failed!\n"); I'm not sure it should be considered a test failure if GL3 isn't supported..

1 0

Re: [10/10] WineX11: add a run-total fps counter to the fps debug channel
by Detlef Riekenberg 26 Aug '08

26 Aug '08

On Mo, 2008-08-25 at 09:32 -0500, Stefan Dösinger wrote: > @@ -3486,15 +3486,19 @@ BOOL X11DRV_SwapBuffers(X11DRV_PDEVICE > *physDev) > /* FPS support */ > if (TRACE_ON(fps)) > { > - static long prev_time, frames; > + static long prev_time, start_time; > + static unsigned long frames, frames_total; > > DWORD time = GetTickCount(); > frames++; > + frames_total++; > /* every 1.5 seconds */ > if (time - prev_time > 1500) { > - TRACE_(fps)("@ approx %.2ffps\n", 1000.0*frames/(time - > prev_time)); > + TRACE_(fps)("@ approx %.2ffps, total %.2ffps\n", > + 1000.0*frames/(time - prev_time), > 1000.0*frames_total/(time - start_time)); > prev_time = time; > frames = 0; > + if(start_time == 0) start_time = time; The first fps report is not correct (0 as prev_time is not the time, when the device was created) Much more Important is the last fps report. Thiat can be from the actual frame up to 1.5 seconds old. When a DirectX test run ~10 sec, the last fps line is one second old. Any change in the Driver, that increase or decrease the needed test-time between 9 sec and 10.5 sec is not detected. You need to make the counters globals (or move it in X11DRV_PDEVICE) and dump a last fps report, when the device is destroyed. I suggest to rename the variable "time", to make clear what it is and to avoid a mix-up with time(). Example: "last_swapbuffers_time" -- By by ... Detlef

2 1

Re: shlwapi/tests: test UrlUnEscape inplace behavior (1/2) (try 2)
by Alexandre Julliard 26 Aug '08

26 Aug '08

"Dan Kegel" <dank(a)kegel.com> writes: > Add test showing UrlUnEscape should convert the url in place > when URL_UNESCAPE_INPLACE is set, even if the output buffer is NULL. > Passes on XP. > > Changes since originally posted by Louis Lenders as > http://www.winehq.org/pipermail/wine-patches/2008-August/059567.html > 1) added todo_wine around parts that fail in Wine > 2) he has requested that somebody else take it over, > so I am raising my hand. If you are resending a patch written by someone else you need to include a From: line with the complete attribution. Alternatively if you have made significant changes you need to add a "Based on a patch by" note in the log message. -- Alexandre Julliard julliard(a)winehq.org

2 3

Re: imagehlp(1/2): Add tests for ImageGetDigestStream
by Detlef Riekenberg 26 Aug '08

26 Aug '08

On Mo, 2008-08-18 at 09:00 -0700, Juan Lang wrote: > dlls/imagehlp/tests/Makefile.in | 13 + > dlls/imagehlp/tests/main.c | 1222 > +++++++++++++++++++++++++++++++++++++++ > 2 files changed, 1235 insertions(+), 0 deletions(-) > +/* "Minimal" executable from compiling "int main(void) { return 0; }" > */ > +static const BYTE bin[] = { The Patch is really large. TCC creates smaller Images: http://bellard.org/tcc/ (But I did not test your Patch with that binary) -- By by ... Detlef

1 0

Re: Add TRACEs to NtCreateFile returns (second try)
by James Hawkins 26 Aug '08

26 Aug '08

2008/8/24 Markus Hitter <mah(a)jump-ing.de>: > + if (!attr || !attr->ObjectName) + { + TRACE("returning STATUS_INVALID_PARAMETER\n"); + return STATUS_INVALID_PARAMETER; + } These are all very useless TRACES, except for possibly the returned handle value. You should be able to look at the traced parameters and see if there is an invalid parameter. As a side note of something I just noticed, the check for NULL attr will never be true because we'll crash in the TRACE when we dereference attr. -- James Hawkins

4 8

Re: [crypt32/tests] Use CryptAcquireContextA instead of CryptAcquireContextW
by Detlef Riekenberg 26 Aug '08

26 Aug '08

On Mo, 2008-08-25 at 22:16 +0200, Paul Vriens wrote: > static BOOL (WINAPI * pCryptAcquireContextA) > (HCRYPTPROV *, LPCSTR, LPCSTR, DWORD, DWORD); > -static BOOL (WINAPI * pCryptAcquireContextW) > - (HCRYPTPROV *, LPCWSTR, LPCWSTR, DWORD, > DWORD); > @@ -47,7 +45,6 @@ static void init_function_pointers(void) > trace("GetProcAddress(%s) failed\n", #func); > > GET_PROC(hAdvapi32, CryptAcquireContextA) > - GET_PROC(hAdvapi32, CryptAcquireContextW) > @@ -2799,10 +2794,10 @@ static BOOL detect_nt(void) > signer.pCertInfo = &certInfo; > signer.HashAlgorithm.pszObjId = oid_rsa_md5; > > - ret = pCryptAcquireContextW(&signer.hCryptProv, cspNameW, NULL, > + ret = pCryptAcquireContextA(&signer.hCryptProv, cspNameA, NULL, > PROV_RSA_FULL, CRYPT_NEWKEYSET); > - ret = pCryptAcquireContextW(&signer.hCryptProv, cspNameW, > NULL, > + ret = pCryptAcquireContextA(&signer.hCryptProv, cspNameA, > NULL, > PROV_RSA_FULL, 0); > } > > @@ -2810,7 +2805,7 @@ static BOOL detect_nt(void) > > /* cleanup */ > CryptReleaseContext(signer.hCryptProv, 0); > - pCryptAcquireContextW(&signer.hCryptProv, cspNameW, NULL, > PROV_RSA_FULL, > + pCryptAcquireContextA(&signer.hCryptProv, cspNameA, NULL, > PROV_RSA_FULL, > CRYPT_DELETEKEYSET); This changes are wrong. Please compare your change with the name of the last Function. The code is expected to Fail on Win9x. This should work as first code in detect_nt(): + if (!pCryptAcquireContextW) return FALSE; Thanks -- By by ... Detlef

2 1

Re: regedit: Fix concat handling for ANSI files
by Alexandre Julliard 26 Aug '08

26 Aug '08

Alexander Nicolaysen Sørnes <alex(a)thehandofagony.com> writes: > + do > + { > + *s = fgetc(in); > + } while(*s == ' ' || *s == '\t'); > + > + if(*s == EOF) > fprintf(stderr,"%s: ERROR - invalid continuation.\n", > getAppName()); You can't do that, EOF is an int not a char. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: shlwapi: [PATCH 3/4] Fix results for UrlApplyScheme
by Dmitry Timoshkov 26 Aug '08

26 Aug '08

"Detlef Riekenberg" <wine.dev(a)web.de> wrote: > Subject: [PATCH 2/4] shlwapi: Fix results for UrlApplyScheme This subject doesn't match the e-mail subject line, and may confuse things. > in = HeapAlloc(GetProcessHeap(), 0, > - (2*INTERNET_MAX_URL_LENGTH) * sizeof(WCHAR)); > + (2*INTERNET_MAX_URL_LENGTH) * sizeof(WCHAR)); > out = in + INTERNET_MAX_URL_LENGTH; > > - MultiByteToWideChar(0, 0, pszIn, -1, in, INTERNET_MAX_URL_LENGTH); > + MultiByteToWideChar(CP_ACP, 0, pszIn, -1, in, INTERNET_MAX_URL_LENGTH); It would simplify things to allocate the buffer on the stack, since the buffer is small and its size is known. > +/************************************************************************* > + */ > + > static HRESULT URL_GuessScheme(LPCWSTR pszIn, LPWSTR pszOut, LPDWORD pcchOut) > { It's a usual convention to not leave an empty line after the API/function description comment, and adding an empty comment is not useful at all. -- Dmitry.

1 0

Re: comdlg32: Update Japanese translation
by Alexandre Julliard 26 Aug '08

26 Aug '08

"Muneyuki Noguchi" <nogu.dev(a)gmail.com> writes: > +/****************************************************************/ > +/* Japanese neutral resources > +/****************************************************************/ > + > +LANGUAGE LANG_JAPANESE, SUBLANG_NEUTRAL You shouldn't need neutral resources for Japanese, there's only one sublanguage. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [2/3] d3dx9: Add d3dx9effect.h
by Alexandre Julliard 26 Aug '08

26 Aug '08

Busquets Pérez Luis C. <luiscar2001(a)yahoo.es> writes: > + /*** ID3DXEffect ***/ > + STDMETHOD(GetPool)(THIS_ LPD3DXEFFECTPOOL* ppPool) PURE; > + STDMETHOD(SetTechnique)(THIS_ D3DXHANDLE hTechnique) PURE; > + STDMETHOD_(D3DXHANDLE, GetCurrentTechnique)(THIS) PURE; > + STDMETHOD(ValidateTechnique)(THIS_ D3DXHANDLE hTechnique) PURE; > + STDMETHOD(FindNextValidTechnique)(THIS_ D3DXHANDLE hTechnique, D3DXHANDLE *pTechnique) PURE; > + STDMETHOD_(BOOL, IsParameterUsed)(THIS_ D3DXHANDLE hParameter, D3DXHANDLE hTechnique) PURE; > + STDMETHOD(Begin)(THIS_ UINT *pPasses, DWORD Flags) PURE; > + STDMETHOD(Pass)(THIS_ UINT Pass) PURE; > + STDMETHOD(End)(THIS) PURE; > + STDMETHOD(GetDevice)(THIS_ LPDIRECT3DDEVICE9* ppDevice) PURE; > + STDMETHOD(OnLostDevice)(THIS) PURE; > + STDMETHOD(OnResetDevice)(THIS) PURE; > + STDMETHOD(CloneEffect)(THIS_ LPDIRECT3DDEVICE9 pDevice, LPD3DXEFFECT* ppEffect) PURE; This doesn't match the headers I have. Is the interface different between d3dx9 versions? -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: How should I name the Traditional Chinese resource file ?
by Alexandre Julliard 26 Aug '08

26 Aug '08

Hongbo Ni <hongbo(a)njstar.com> writes: > 1. name it Zh_tw.rc, (but Alexandre seems not like it) > 2. name it Tw.rc > 3. rename all Zh.rc to Cn.rc, then name traditional as Zh.rc > 4. just put both simplified and traditional Chinese in Zh.rc > (not good as they are different encoding). > > My question is how should I name it ? The best solution is 4, we try to use a single file per language. If encoding is an issue you can convert the file to utf-8. -- Alexandre Julliard julliard(a)winehq.org

2 2

Patchwatcher status: regenerates configure, notifies authors on failure, filtered patches mailing list
by Dan Kegel 26 Aug '08

26 Aug '08

Patchwatcher now regenerates configure and makefiles after each patch, so it can handle patches that change configure.ac. I have enabled email notification to authors of patches that don't build. The script now forwards patches that pass all tests to the mailing list http://groups.google.com/group/wine-patches-filtered so potentially Alexandre could start looking only at that list (though it probably only has two nines of reliability at this point, as patchwatcher doesn't handle every case yet, e.g. it doesn't handle partial resends of patch series).

10 19

winetricks: add ie6 verb
by Steven Edwards 26 Aug '08

26 Aug '08

This might be of use to someone wanting to compare Wine IE gecko rendering to IE6 without having to use a bigger hack like ies4linux. I am sending here rather than privately to Dan as I don't expect it to be merged to winetricks mainline Changelog: Add ie6 verb and support IE6 <rant> I doubt Dan will merge it (no disrespect intended, I am not trying to single him out) because it might be viewed as 'lacking sense taste' whatever that is supposed to mean, see http://www.winehq.org/pipermail/wine-devel/2008-July/067109.html regarding a script for Media player and codecs. I don't see what could be poor taste if Wine is going to have to reimplement this stuff anyway, to provide support for it in winetricks so developers can compare native verses builtin. All the better if some users find it of use too. I would see something like Office being added as crossing the line Dan has drawn for winetricks being a developer tool rather than a user tool but that is not really my point in any case. We've been accused in private by other that Bordeaux will not, or does not contribut back to Wine, leeches off of Winehq in a Transgaming like style, etc. Even though 90% of my patches and ideas (however small they are) have been rejected and even with IE being a nice part of the revenue stream, I've decide to give the hack back in all of its glory. We are committed to maintain NO "proprietary advantages" and seeing everything that runs on Bordeaux work out of the box on the next Wine stable release. We don't have the development staff or funding yet to fully ramp up and be as active as we would like to be but here is another token of our commitment. </rant> -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo

2 2

ddraw error in Tibia (wine told me to post here)
by Michael Reiley 26 Aug '08

26 Aug '08

There's some progress on the MMORPG Tibia since the last wine version, but now there's a new error. before you tell me "This list is for discussions regarding Wine development. It is not for bug reports or user support questions", I'd like to tell you "err:ddraw:IDirectDrawImpl_QueryInterface (0x13b5d0) You may want to contact wine-devel for help" Assuming wine knows what it's talking about, I'm going to post the error log here and see what all of you have to say. fuzzypig@fp-ubuntu-laptop:~/.wine/drive_c/Program Files/Tibia$ wine Tibia.exe engine 0 fixme:win:EnumDisplayDevicesW ((null),0,0x32e468,0x00000000), stub! err:ddraw:IDirectDrawImpl_QueryInterface (0x13b5d0) The App is requesting a D3D device, but a non-OpenGL surface type was choosen. Prepare for trouble! err:ddraw:IDirectDrawImpl_QueryInterface (0x13b5d0) You may want to contact wine-devel for help err:ddraw:IDirectDrawSurfaceImpl_QueryInterface No interface fixme:d3d:WineD3D_ChoosePixelFormat Add OpenGL context recreation support to SetDepthStencilSurface fixme:d3d:CreateContext >>>>>>>>>>>>>>>>> GL_INVALID_OPERATION (0x502) from glClearColor @ context.c / 514 fixme:d3d_shader:state_texfactor_arbfp >>>>>>>>>>>>>>>>> GL_INVALID_ENUM (0x500) from glProgramEnvParameter4fvARB(GL_FRAGMENT_PROGRAM_ARB, ARB_FFP_CONST_TFACTOR, col) @ arb_program_shader.c / 2327 fixme:d3d_shader:set_bumpmat_arbfp >>>>>>>>>>>>>>>>> GL_INVALID_ENUM (0x500) from glProgramEnvParameter4fvARB(GL_FRAGMENT_PROGRAM_ARB, ARB_FFP_CONST_BUMPMAT(stage), &mat[0][0]) @ arb_program_shader.c / 2361 fixme:d3d_shader:set_bumpmat_arbfp >>>>>>>>>>>>>>>>> GL_INVALID_ENUM (0x500) from glProgramEnvParameter4fvARB(GL_FRAGMENT_PROGRAM_ARB, ARB_FFP_CONST_BUMPMAT(stage), &mat[0][0]) @ arb_program_shader.c / 2361 fixme:d3d_shader:set_bumpmat_arbfp >>>>>>>>>>>>>>>>> GL_INVALID_ENUM (0x500) from glProgramEnvParameter4fvARB(GL_FRAGMENT_PROGRAM_ARB, ARB_FFP_CONST_BUMPMAT(stage), &mat[0][0]) @ arb_program_shader.c / 2361 fixme:d3d_shader:set_bumpmat_arbfp >>>>>>>>>>>>>>>>> GL_INVALID_ENUM (0x500) from glProgramEnvParameter4fvARB(GL_FRAGMENT_PROGRAM_ARB, ARB_FFP_CONST_BUMPMAT(stage), &mat[0][0]) @ arb_program_shader.c / 2361 fixme:d3d_shader:set_bumpmat_arbfp >>>>>>>>>>>>>>>>> GL_INVALID_ENUM (0x500) from glProgramEnvParameter4fvARB(GL_FRAGMENT_PROGRAM_ARB, ARB_FFP_CONST_BUMPMAT(stage), &mat[0][0]) @ arb_program_shader.c / 2361 Happy trails! ~Michael Reiley

1 0

Re: winex11.drv: Fix buffer overflow bug in X11DRV_KeyEvent() andX11DRV_ToUnicodeEx()
by Dmitry Timoshkov 25 Aug '08

25 Aug '08

"Muneyuki Noguchi" <nogu.dev(a)gmail.com> wrote: > winex11.drv: Fix buffer overflow bug in X11DRV_KeyEvent() and > X11DRV_ToUnicodeEx() > + Str = (char *)malloc(64); > + if (Str == NULL) > + ERR("Failed to allocate memory!\n"); Please don't use malloc() in Wine, use win32 Heap*** APIs instead. Also, you need to properly handle memory allocation errors, not just print an ERR. -- Dmitry.

2 1

Using wine directdraw dll on windows?
by Joseph Garvin 25 Aug '08

25 Aug '08

Intel's windows vista graphics drivers are pretty terrible, and some older directdraw games won't run at all with them. I know that there was talk before about using wine's opengl-based direct3d implementation on windows, so I was curious if it was at all possible to do the same with directdraw. Ironically Worms Armageddon runs better on my laptop under wine than it does on my gf's under Vista. Thanks, Joe

3 3

New steam survey statistics?
by Scott Ritchie 25 Aug '08

25 Aug '08

When we last heard from Valve a year ago, Wine had about a .4% share of the steam user base. It would be interesting to see how this has changed since then - in that time, we've both released Wine 1.0 and likely seen Linux adoption increase a great deal. Linux had doubled its desktop marketshare the year preceding the last survey, I wouldn't be surprised to see Wine usage at around 1% on steam now. Thanks, Scott Ritchie

4 5

Re: cryptnet: Sign-compare warning fix (try 2)
by Juan Lang 25 Aug '08

25 Aug '08

Hi Andy, + LONG last_error; ret = CryptGetObjectUrl(URL_OID_CERTIFICATE_CRL_DIST_POINT, rgpvContext[i], 0, NULL, &cbUrlArray, NULL, NULL, NULL); - if (!ret && GetLastError() == CRYPT_E_NOT_FOUND) + last_error = GetLastError(); + if (!ret && last_error == CRYPT_E_NOT_FOUND) I don't get it. How does using a temporary LONG rather than GetLastError directly remove the warning? Either the compiler was wrong about the first warning, or it's wrong about not warning about this form. I don't see the utility of this patch. Furthermore, any patches that remove warnings due to sign mismatches between GetLastError and an error in winerror.h reflect an error on Microsoft's part, not on Wine's, so I don't see the point of removing them. --Juan

2 4

Re: [3/3] d3dx9: Begin Implementation of ID3DXEffect and D3DXCreateEffectEx
by tony.wasserka＠freenet.de 25 Aug '08

25 Aug '08

Hi, > +HRESULT WINAPI D3DXCreateEffectEx(LPDIRECT3DDEVICE9 pdevice, LPCVOID psrcdata, UINT srcdatalen, D3DXMACRO *pdefines, > + LPD3DXINCLUDE pinclude, LPCSTR pskipconstants, DWORD flags, LPD3DXEFFECTPOOL ppool, LPD3DXEFFECT * ppeffect, > + LPD3DXBUFFER * ppcompilationerrors) > +{ > + ID3DXEffectImpl *This; > + This=(ID3DXEffectImpl *)malloc(sizeof(ID3DXEffectImpl)); > + This->lpVtbl=&ID3DXEffect_Vtbl; > + This->device=pdevice; > + return D3D_OK; > +} > + Don't use malloc for windows functions, use HeapAlloc for that. Also, you should do some error checking to make sure that the memory was allocated successfully, or this code will segfault. You forgot to assign the ppeffect pointer to This, i.e. *ppeffect=This. you'll need to check that ppeffect isn't NULL first, of course. At least ID3DXBaseEffectImpl_AddRef/Release/QueryInterface (well, actually only Release) need to be implemented in the same patch as the interface leaks memory otherwise (one more unnecessary valgrind error). Last thing, you need to AddRef the device when creating another reference to it, and Release it on ID3DXBaseEffectImpl_Release. (Though a device pointer isn't even neccessary yet, so you could also leave it away) Best regards, Tony Heute schon ge"freeMail"t? Jetzt kostenlose E-Mail-Adresse sichern! http://email.freenet.de/dienste/emailoffice/produktuebersicht/basic/mail/in…

1 0

RE: [try 3][1/2]wined3d: Support clipplanes with GLSL shaders
by Stefan Dösinger 25 Aug '08

25 Aug '08

+ if(gl_info->max_glsl_varyings > 32) + gl_info->max_glsl_varyings -= 4; + if(!apple && gl_info->gl_vendor == VENDOR_ATI && gl_info->max_glsl_varyings == 40) { + WARN("Hardcoded 32 varyings instead of 44 to avoid crashing the ATI driver\n"); + gl_info->max_glsl_varyings -= 4; + } This will give you 36 varyings, not 32. Is this intentional? > -----Original Message----- > From: wine-patches-bounces(a)winehq.org [mailto:wine-patches- > bounces(a)winehq.org] On Behalf Of Fabian Bieler > Sent: Monday, August 25, 2008 6:25 AM > To: wine-patches(a)winehq.org > Subject: [try 3][1/2]wined3d: Support clipplanes with GLSL shaders >

1 0

Re: d3dx9: Add stubs for D3DXCreateEffectxx and D3DXCreateEffectFromFilexx
by tony.wasserka＠freenet.de 24 Aug '08

24 Aug '08

Hi, There were quite a number of minor issues in you code: In Makefile.in: > C_SRCS = \ > d3dx9_36_main.c \ >+ effect.c \ > font.c \ Use tabs here, please, as the intendation switches here on other computers. In effect.c: + * modify it under the terms of the GNU Lesser General Public + GetCurre* License as published by the Free Software Foundation; either + * version 2.1 of the License, or (at your option) any later version. I guess that was a paste at the wrong position ;-) > +HRESULT D3DXCreateEffectEx( You missed the WINAPI for that one. In d3dx9effect.h: I haven't looked too much into the whole effect stuff, but this thing looks like Unicode isn't supported here (only LPCSTRs are used). Are you sure about that? >+#endif //__D3DX9EFFECT_H__ This is C code, use /* */, please. As David already said, you should split the patch into smaller chunks. Also, you need to convert a D3DXCreateEffect call into a D3DXCreateEffectEx call, look at font.c to see how it's done for D3DXCreateFont. This applies to the D3DXCreateEffectFromFile calls, too. Best regards, Tony Unbegrenzter Speicher, Top-Spamschutz, 120 SMS und eigene E-MailDomain inkl. http://office.freenet.de/dienste/emailoffice/produktuebersicht/power/mail/i…

1 0

Re: d3dx9: Add stubs for D3DXCreateEffectxx and D3DXCreateEffectFromFilexx
by Henri Verbeet 24 Aug '08

24 Aug '08

2008/8/24 Busquets Pérez Luis C. <luiscar2001(a)yahoo.es>: > Why are you adding stubs for these? I don't think having a stub implementation is useful here.

1 0

Re: d3dx9: Add stubs for D3DXCreateEffectxx and D3DXCreateEffectFromFilexx
by David Adam 24 Aug '08

24 Aug '08

Hello, A few remarks: 1) this patch is too huge You need to split it in several patches. I advice you to do a patch for - d3dx9effect.h -an another one for d3dx9shader.h -an another one for D3DXCreateEffect -an another one for D3DXCreateEffectExW and D3DXCreateEffectExW 2) for the patch D3DXCreateEffect you need to stub not only this function but also, all the methods coming with this function David

1 0

Re: [10/10] WineD3D: Sort out some limit confusion
by Henri Verbeet 24 Aug '08

24 Aug '08

2008/8/22 Stefan Dösinger <stefan(a)codeweavers.com>: > + glGetIntegerv(GL_MAX_TEXTURE_COORDS, &gl_max); > + gl_info->max_texture_coords = min(MAX_TEXTURES, gl_max); > + TRACE_(d3d_caps)("Max texture coords: %d\n", gl_info->max_texture_coords); I don't know if this is intentional or not, but did you mean to use gl_info->max_textures here? > @@ -3172,7 +3172,7 @@ static void loadTexCoords(IWineD3DStateBlockImpl *stateblock, WineDirect3DVertex > return; > } > > - for (textureNo = 0; textureNo < GL_LIMITS(texture_stages); ++textureNo) { > + for (textureNo = 0; textureNo < GL_LIMITS(texture_coords); ++textureNo) { > int coordIdx = stateblock->textureState[textureNo][WINED3DTSS_TEXCOORDINDEX]; > > mapped_stage = stateblock->wineD3DDevice->texUnitMap[textureNo]; Shouldn't that be testing mapped_stage against GL_LIMITS(texture_coords) instead? > - if (GL_SUPPORT(NV_REGISTER_COMBINERS)) { > - /* The number of the mapped stages increases monotonically, so it's fine to use the last used one */ > - for (textureNo = mapped_stage + 1; textureNo < GL_LIMITS(textures); ++textureNo) { > - GL_EXTCALL(glMultiTexCoord4fARB(GL_TEXTURE0_ARB + textureNo, 0, 0, 0, 1)); > - } > - } I'm probably missing something here, but why is it safe to remove that? > @@ -420,7 +420,7 @@ static void drawStridedSlow(IWineD3DDevice *iface, WineDirect3DVertexStridedData > } > > /* Texture coords --------------------------- */ > - for (textureNo = 0; textureNo < GL_LIMITS(texture_stages); ++textureNo) { > + for (textureNo = 0; textureNo < GL_LIMITS(texture_coords); ++textureNo) { > > if (!GL_SUPPORT(ARB_MULTITEXTURE) && textureNo > 0) { > FIXME("Program using multiple concurrent textures which this opengl implementation doesn't support\n"); Similar to above, shouldn't this test texture_idx against GL_LIMITS(texture_coords) instead of textureNo? In the bigger picture, these various limits are pretty tricky to get right, I wonder if it might make more sense to handle most of this stuff in the tex unit map instead. That way we could be sure that if a stage is mapped to a sampler that sampler is safe to use.

3 7

d3dx9: Effects
by Busquets Pérez Luis C. 24 Aug '08

24 Aug '08

What is wrong with the attached patch? __________________________________________________ Correo Yahoo! Espacio para todos tus mensajes, antivirus y antispam ¡gratis! Regístrate ya - http://correo.yahoo.es

1 0

Re: [try 2][2/2]wined3d: Support first clipplane with ARB shaders
by Henri Verbeet 24 Aug '08

24 Aug '08

2008/8/24 Fabian Bieler <der.fabe(a)gmx.net>: > + if (use_vs(stateblock->wineD3DDevice) && (enable ^ supported_by_shader_backend) & enable) { Did you mean to write if (use_vs(stateblock->wineD3DDevice) && (enable & ~supported_by_shader_backend)) { there?

1 0

ddraw_test crashes on windows xp sp3 (blue screen)
by Rico Schüller 24 Aug '08

24 Aug '08

Hi, the attached patch solves a hard crash on my ati mobility 9600/9700 card. The code behind the c style comments let the application crash. The code between /* */ crash the hole system. Probably there have to be another check for supported cards/extensions. Cheers Rico diff --git a/dlls/ddraw/tests/d3d.c b/dlls/ddraw/tests/d3d.c index 221a95b..436a49c 100644 --- a/dlls/ddraw/tests/d3d.c +++ b/dlls/ddraw/tests/d3d.c @@ -2089,9 +2089,9 @@ static void DeviceLoadTest() ddsd.ddsCaps.dwCaps2 = DDSCAPS2_CUBEMAP | DDSCAPS2_CUBEMAP_POSITIVEX; ddsd.dwWidth = 128; ddsd.dwHeight = 128; - hr = IDirectDraw7_CreateSurface(lpDD, &ddsd, &cube_face_levels[0][0][0], NULL); - ok(hr==DD_OK,"CreateSurface returned: %x\n",hr); - if (FAILED(hr)) goto out; +// hr = IDirectDraw7_CreateSurface(lpDD, &ddsd, &cube_face_levels[0][0][0], NULL); +// ok(hr==DD_OK,"CreateSurface returned: %x\n",hr); +// if (FAILED(hr)) goto out; memset(&ddsd, 0, sizeof(DDSURFACEDESC2)); ddsd.dwSize = sizeof(ddsd); @@ -2100,13 +2100,13 @@ static void DeviceLoadTest() ddsd.ddsCaps.dwCaps2 = DDSCAPS2_CUBEMAP | DDSCAPS2_CUBEMAP_POSITIVEX | DDSCAPS2_CUBEMAP_POSITIVEY; ddsd.dwWidth = 128; ddsd.dwHeight = 128; - hr = IDirectDraw7_CreateSurface(lpDD, &ddsd, &cube_face_levels[1][0][0], NULL); - ok(hr==DD_OK,"CreateSurface returned: %x\n",hr); - if (FAILED(hr)) goto out; +// hr = IDirectDraw7_CreateSurface(lpDD, &ddsd, &cube_face_levels[1][0][0], NULL); +// ok(hr==DD_OK,"CreateSurface returned: %x\n",hr); +// if (FAILED(hr)) goto out; /* INVALIDPARAMS tests currently would fail because wine doesn't support partial cube faces (the above created cubemaps will have all faces. */ - hr = IDirect3DDevice7_Load(lpD3DDevice, cube_face_levels[0][0][0], NULL, cube_face_levels[1][0][0], NULL, +/* hr = IDirect3DDevice7_Load(lpD3DDevice, cube_face_levels[0][0][0], NULL, cube_face_levels[1][0][0], NULL, DDSCAPS2_CUBEMAP_ALLFACES); todo_wine ok(hr==DDERR_INVALIDPARAMS, "IDirect3DDevice7_Load returned: %x\n",hr); @@ -2132,6 +2132,7 @@ static void DeviceLoadTest() IDirectDrawSurface7_Release(cube_face_levels[0][0][0]); IDirectDrawSurface7_Release(cube_face_levels[1][0][0]); +*/ memset(cube_face_levels, 0, sizeof(cube_face_levels)); }

2 1

Re: d3dx8: Implementation of D3DXGetFVFVertexSize with tests try 2
by David Adam 24 Aug '08

24 Aug '08

Hello, could you keep the style of the file, please? For instance for (.....) { xxxxxxxx } instead of for (.....) { xxxxxxxx } The same for the if condition and the switch condition? David

1 0

Re: Unbreak dlls/winhttp on FreeBSD (and likely other BSDs/Darwin)
by Hans Leidekker 24 Aug '08

24 Aug '08

On Wednesday 20 August 2008 20:34:43 Gerald Pfeifer wrote: > This minor change on top of Hans' contributions in the recent days > unbreaks the build on FreeBSD (and likely other BSDs and possibly > Darwin/MacOS). Thanks. I didn't want to copy all of the ifdef blocks from wininet because I can't verify which ones are actually needed. So I'm counting on people like you to fix this up, and I'm sure I'll need your help again :) -Hans

2 1

How should I name the Traditional Chinese resource file ?
by Hongbo Ni 24 Aug '08

24 Aug '08

Hi, For Chinese language, there are simplified Chinese (zh_CN) and traditional Chinese (zh_TW) sublanguage. Currently all the dlls have Chinese resource named with xxx_Cn.rc for simplified, and xxx_Zh.rc for traditional Chinese. For all the programs such as notepage, simplified Chinese resource is named Zh.rc (while it should be named Cn.rc inline with dlls), and there is no traditional Chinese resource. I want to add traditional Chinese resources for all programs. I have those options: 1. name it Zh_tw.rc, (but Alexandre seems not like it) 2. name it Tw.rc 3. rename all Zh.rc to Cn.rc, then name traditional as Zh.rc 4. just put both simplified and traditional Chinese in Zh.rc (not good as they are different encoding). My question is how should I name it ? Hongbo Ni

1 0

Re: kernel32/winerr: Add Russian translation
by Dmitry Timoshkov 24 Aug '08

24 Aug '08

"Vladimir Pankratov" <scriptkid(a)mail.ru> wrote: > Added Russian translation. > > Changed files: > dlls/kernel32/nls/winerr_rus.mc > dlls/kernel32/kernel.rc > dlls/kernel32/Makefile.in Is there a reason you've used cp866 encoding instead of cp1251? Also, this doesn't look like a translation, messages don't match their english counterparts, how did you do that? -- Dmitry.

1 0

About patchwatcher
by Nikolay Sivov 23 Aug '08

23 Aug '08

Dan, am I right that Patchwatcher now runs a whole test suite for every patch? I know that this situation is rather rare but still I think it make sense to run only tests changed by patch if this patch contains only test changes. I could save some time without any side effect. Since all test stored in 'tests' directory for each module it's very easy to determine that a patch brings changes only to this directory without affecting module itself. What you think about this?

2 1

Re: [1/2] wined3d: Support clipplanes with GLSL shaders
by Henri Verbeet 23 Aug '08

23 Aug '08

> @@ -248,11 +248,12 @@ typedef struct { > void (*shader_generate_vshader)(IWineD3DVertexShader *iface, SHADER_BUFFER *buffer); > void (*shader_get_caps)(WINED3DDEVTYPE devtype, WineD3D_GL_Info *gl_info, struct shader_caps *caps); > BOOL (*shader_conv_supported)(WINED3DFORMAT conv); > + DWORD shader_supported_clipplanes; /* bitmask of supported clipplanes */ > } shader_backend_t; You shouldn't abuse the call table like that, you should store that flag in the private data instead.

1 0

Fwd: Patchwatcher: failed regression tests: d3dx8: replace loops with explicit computations to make them faster [PATCH] d3dx8: replace loops by explicit computations
by Dan Kegel 23 Aug '08

23 Aug '08

Patchwatcher notes that the conformance test fails here: ../../../tools/runtest -q -P wine -M d3dx8.dll -T ../../.. -p d3dx8_test.exe.so math.c && touch math.ok math.c:442: Test failed: Expected matrix= (-0.214800,1.311600,0.475200,0.000000 0.950400,-0.883600,0.924400,0.000000 1.021200,0.193600,-1.358800,0.000000 18.298500,-29.624001,15.683499,1.000000 ) Got matrix= (-0.214800,1.311600,0.475200,0.000000 0.950401,-0.883601,0.924400,0.000000 1.021204,0.193593,-1.358803,0.000000 18.298538,-29.624159,15.683425,1.000000) Looks like rounding errors, but one way or another, you have to take care of that. Also: did you benchmark this change to verify it actually made things faster? Unrolling loops is no longer as sure-fire a win as it used to be. I'm inclined to prefer the more compact, clear loop unless there's hard evidence it's > 1% slower. - Dan ---------- Forwarded message ---------- From: <patchwatcher(a)kegel.com> Date: Fri, Aug 22, 2008 at 8:35 PM Subject: Patchwatcher: failed regression tests: d3dx8: replace loops with explicit computations to make them faster [PATCH] d3dx8: replace loops by explicit computations To: dank(a)kegel.com Hi! This is the experimental automated wine patchwatcher thingy. The latest git sources were built and tested with your patch "d3dx8: replace loops with explicit computations to make them faster [PATCH] d3dx8: replace loops by explicit computations" Result: the patch failed regression tests. You can retrieve the full build results at http://kegel.com/wine/patchwatcher/results/264.log and see the patch as parsed at http://kegel.com/wine/patchwatcher/results/264.txt See http://kegel.com/wine/patchwatcher/results for more info.

2 2

Re: wined3d/d3d9: Set the initial scissor rect to the window size
by H. Verbeet 23 Aug '08

23 Aug '08

2008/8/21 Rico Schüller <kgbricola(a)web.de>: > + /* Set the scissor rect values */ > + scissor.left=0; > + scissor.right=ThisDevice->ddraw_width; > + scissor.top=0; > + scissor.bottom=ThisDevice->ddraw_height; > + IWineD3DDevice_SetScissorRect(device, &scissor); > + Are you sure you shouldn't be using the primary swapchain's backbuffer dimensions?

4 8

re: [Patch] 0001-Support-for-winscard.dll.patch
by Dan Kegel 23 Aug '08

23 Aug '08

Heiko wrote: > This is my first patch using git and also for wine. > > Please check it and let me know which things can be made better. Hi! Welcome to Wine! You probably need to include a better description, and some conformance tests would help, too. (They should do basic error checking at least, and should skip checks that really need hardware if the required hardware isn't present.) Also, your patch failed to apply; see http://kegel.com/wine/patchwatcher/results/ You can avoid the particular problem by not including a diff for 'configure' in the patch; the diff for configure.ac suffices. We have lots of pages (way too many) of advice for how to send patches at winehq.org, but that bit of advice doesn't seem to be in any of them yet :-( http://www.winehq.org/site/sending_patches http://wiki.winehq.org/DeveloperFaq http://winehq.org/site/docs/winedev-guide/codingpractice It does show up in http://wiki.jswindle.com/index.php/Coding_Hints:Using_Diff - Dan

2 4

New winetricks 20080823: add non-activex-plugin for flash, work around indeo installer bug; updated divx, liberation, kdewin, directx9, ffdshow.
by Dan Kegel 23 Aug '08

23 Aug '08

Just a bunch of little updates and fixes. Thanks to everyone who pointed out the issues. Online as always at http://kegel.com/wine/winetricks or http://winezeug.googlecode.com Changes since 20080710: r164: divx updated, change path and sha1sum to match. Thanks to Graham Inggs for the nudge. r163: Update liberation to 1.04. Thanks to Graham Inggs for the nudge. Uses the probably-gnu-specific --strip option to tar to get the fonts in the right place... but everybody's using gnu tar 1.15 or later, right? r162: Update kdewin to 0.9.3-1. Thanks to Graham Inggs for the nudge. r161: Register indeo codec harder; thanks to 414N for the tip. r112: Update directx9 to june 2008 release; thanks to Paul Drain for the tip. r111: Add non-activex flash plugin r110: Update ffdshow. Update version. r107: Add a little error checking, and missing quotes in one spot.

1 0

Crosstest building question
by Nikolay Sivov 23 Aug '08

23 Aug '08

I have a problem building crosstest for GDI+ call GdipFillClosedCurve2. I've got the following: graphics.cross.o: In function `func_graphics':/home/mrlarch/wine/dlls/gdiplus/tests/graphics.c:593: undefined reference to `_GdipFillClosedCurve2@24' collect2: ld returned 1 exit status make[2]: *** [gdiplus_crosstest.exe] Error 1 make[2]: Leaving directory `/home/mrlarch/wine/dlls/gdiplus/tests' make[1]: *** [gdiplus/tests/__crosstest__] Error 2 make[1]: Leaving directory `/home/mrlarch/wine/dlls' make: *** [dlls/__crosstest__] Error 2 This never happened with other calls yet. Before this I've done 'make && make install' for library and make clean for 'tests' directory. Actually in definition file I have now -- GdipFillClosedCurve2@20 @216. I'm able to build ordinary (not cross) tests without any errors. I think the question is why reference name differs from .def file?

2 2

Patchwatcher status
by Dan Kegel 22 Aug '08

22 Aug '08

I think I fixed the charset munging, so patches of non-english stretches of code should work now. That was the last big source of false failure reports, so I'm going to enable email notification to people whose patches fail. I'll probably clear the results page tonight to get rid of all the bogus failure notices caused by the charset conversion bug.

1 0

RE: Spore patch to fix UI and Part descriptions
by Stefan Dösinger 22 Aug '08

22 Aug '08

> + rect.right = 0; > + rect.top = NULL; > + rect.left = NULL; > + rect.bottom= 0; NULL is (void *) 0, so this test is the same as the one above, except that the compiler may warn about an implicit cast from pointer to integer. Otherwise, this goes into the right direction. > -----Original Message----- > From: wine-patches-bounces(a)winehq.org [mailto:wine-patches- > bounces(a)winehq.org] On Behalf Of Andrew Fenn > Sent: Friday, August 22, 2008 2:52 AM > To: H. Verbeet; Stefan Dösinger > Cc: wine-patches(a)winehq.org > Subject: Re: Spore patch to fix UI and Part descriptions > > I made a new patch this time including a test. > > I put in some extra checking in SetScissorRect making sure that if rect > was null or it was an invalid rectangle that it was returned as invalid > as it should be. > > I'm not able to do a test on windows so if anyone does one please let > me know if there are any problems. Also please tell me if you spot any > problems with this patch. > > Thanks, > Andrew

1 0

Re: regedit 1/2: Convert key creation to unicode
by Michael Stefaniuc 22 Aug '08

22 Aug '08

Alexander Nicolaysen Sørnes wrote: > regedit 1/2: Convert key creation to unicode Why do you add extra TCHARs then? You replace one or two with WCHAR and then add a lot more TCHARs. > From 2f56e158d55011ac4294d113f844c32fb998a2c2 Mon Sep 17 00:00:00 2001 > From: =?utf-8?q?Alexander=20Nicolaysen=20S=C3=B8rnes?= <alex(a)thehandofagony.com> > Date: Thu, 21 Aug 2008 23:49:34 +0200 > Subject: [PATCH] regedit: Convert key creation to unicode > > --- > programs/regedit/edit.c | 14 +++++++------- > programs/regedit/framewnd.c | 13 +++++++++---- > programs/regedit/main.h | 4 ++-- > programs/regedit/treeview.c | 14 +++++++++----- > 4 files changed, 27 insertions(+), 18 deletions(-) bye michael

2 1

Re: appwiz: fix some typos in the french resources
by Alexandre Julliard 22 Aug '08

22 Aug '08

"David Adam" <david.adam.cnrs(a)gmail.com> writes: > - CONTROL "Ce logiciel peut �tre automatiquement d�sinstaller. Pour supprimer un programme ou modifier ses composants, s�lectionner le dans la liste, et cliquer sur Ajouter/Supprimer.", 1002, "STATIC", SS_LEFT | WS_CHILD | WS_VISIBLE | WS_GROUP, 40, 57, 270, 30 > + CONTROL "Ces logiciels peuvent �tre automatiquement d�sinstaller. Pour supprimer un programme ou modifier ses composants, s�lectionner le dans la liste, et cliquer sur Ajouter/Supprimer.", 1002, "STATIC", SS_LEFT | WS_CHILD | WS_VISIBLE | WS_GROUP, 40, 57, 270, 30 While you're at it you should fix the grammar too... -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [PATCH] shell32 - handle WM_CLOSE in the Control Panel window (fixed)
by James Mckenzie 22 Aug '08

22 Aug '08

Vincent Povirk <madewokherd+8cd9(a)gmail.com> at Aug 21, 2008 8:49 PM (MST) wrote about [PATCH] shell32 - handle WM_CLOSE in the Control Panel window (fixed) > >WM_CLOSE is already handled by the default window procedure, >DefWindowProcW, which calls DestroyWindow. It's only necessary to >override the default for WM_CLOSE if you want to prevent the window >from being destroyed. > So what is the use of this case? Is it to prevent DestroyWindow from being called or is it to insert additional code before DestroyWindow is called. I'll have to git the current source and examine it further. Thank you for advising of the original case, which I had not assumed was what happened on a WM_CLOSE message. James McKenzie

1 0

Regression with d3d: Remove IWineD3DDevice::SetHwnd.
by Maxime Bellengé 22 Aug '08

22 Aug '08

Hi This patch is causing a regression in the game Return to mysterious Island. When the game start it crashes displaying the trace I added at the end of the mail. I'm not an expert at all with ddraw but as it crashes on a NULL pointer, maybe there is an inconsistency between This->dest_window and This->ddraw_window ith this patch. Here is a link to the appdb page which contains a link to the demo of the game. http://appdb.winehq.org/objectManager.php?sClass=version&iId=3361 Thanks Maxime 34b37fe2411d83f1a6f3e11a7a1e4d28bd9b36ba is first bad commit commit 34b37fe2411d83f1a6f3e11a7a1e4d28bd9b36ba Author: Stefan Dösinger <stefan(a)codeweavers.com> Date: Tue Aug 5 14:24:10 2008 -0500 d3d: Remove IWineD3DDevice::SetHwnd. :040000 040000 70726cbb30d4e915779d7f0897cd44227f549e3e afda0b9ddba310280afcbe82a78ae4e2212f1801 M dlls :040000 040000 405e4687c093ec5c082507ce0195a7958799b4bf fc8ba10a277dc8b364967673fb81eb08f0844897 M include err:wgl:internal_SetPixelFormat Invalid operation on root_window err:d3d:CreateContext SetPixelFormat failed on HDC=0x2e8 for iPixelFormat=3 err:d3d:IWineD3DDeviceImpl_CreateAdditionalSwapChain Failed to create a new context fixme:ddraw:D3D7CB_CreateAdditionalSwapChain (0x19e2890) call to IWineD3DDevice_CreateAdditionalSwapChain failed wine: Unhandled page fault on read access to 0x00000014 at address 0x6113c944 (thread 0009), starting debugger... Unhandled exception: page fault on read access to 0x00000014 in 32-bit code (0x6113c944). fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_cmp (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_mul_low (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_pow (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_mul_high (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_sub_high (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_cmp (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_mul_low (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_pow (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_mul_high (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_sub_high (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_cmp (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_mul_low (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_pow (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_mul_high (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_sub_high (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_cmp (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_mul_low (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_pow (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_mul_high (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_sub_high (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_cmp (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_mul_low (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_pow (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_mul_high (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_sub_high (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_cmp (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_mul_low (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_pow (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_mul_high (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_sub_high (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_cmp (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_mul_low (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_pow (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_mul_high (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_sub_high (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_cmp (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_mul_low (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_pow (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_mul_high (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_sub_high (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_cmp (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_mul_low (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_pow (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_mul_high (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_sub_high (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_cmp (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_mul_low (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_pow (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_mul_high (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_sub_high (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_cmp (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_mul_low (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_pow (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_mul_high (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_sub_high (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_cmp (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_mul_low (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_pow (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_mul_high (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_sub_high (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_cmp (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_mul_low (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_pow (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_mul_high (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_sub_high (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_cmp (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_mul_low (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_pow (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_mul_high (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_sub_high (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_cmp (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_mul_low (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_pow (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_mul_high (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_sub_high (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_cmp (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_mul_low (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_pow (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_mul_high (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_sub_high (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_cmp (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_mul_low (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_pow (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_mul_high (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_sub_high (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_cmp (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_mul_low (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_pow (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_mul_high (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_sub_high (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_cmp (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_mul_low (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_pow (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_mul_high (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_sub_high (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_cmp (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_mul_low (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_pow (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_mul_high (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_sub_high (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_cmp (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_mul_low (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_pow (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_mul_high (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_sub_high (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_cmp (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_mul_low (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_pow (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_mul_high (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_sub_high (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_cmp (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_mul_low (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_pow (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_mul_high (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_sub_high (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_cmp (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_mul_low (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_pow (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_mul_high (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_sub_high (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_cmp (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_mul_low (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_pow (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_mul_high (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_sub_high (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_cmp (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_mul_low (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_pow (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_mul_high (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_sub_high (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_cmp (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_mul_low (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_pow (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_mul_high (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_sub_high (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_cmp (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_mul_low (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_pow (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_mul_high (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_sub_high (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_cmp (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_mul_low (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_pow (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_mul_high (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_sub_high (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_cmp (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_mul_low (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_pow (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_mul_high (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_sub_high (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_cmp (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_mul_low (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_pow (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_mul_high (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_sub_high (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_cmp (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_mul_low (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_pow (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_mul_high (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_sub_high (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_cmp (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_mul_low (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_pow (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_mul_high (a) fixme:dbghelp_dwarf:dwarf2_parse_variable Unsupported form for const value srgb_sub_high (a) Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0063 GS:006b EIP:6113c944 ESP:0032ee38 EBP:0032ee50 EFLAGS:00210202( - 00 - -RI1) EAX:6113c9a0 EBX:61232e98 ECX:00110048 EDX:00000002 ESI:00000000 EDI:001379f8 Stack dump: 0x0032ee38: 00000000 6113c9a0 61233b70 61232e98 0x0032ee48: 001379f8 00000000 0032ef10 61165c7e 0x0032ee58: 001379f8 00000008 00000004 00000000 0x0032ee68: 7b88ef10 60721040 00000040 7bc63de1 0x0032ee78: 00000005 0032eeb8 0032eeb4 0032eeb0 0x0032ee88: 0032eeac 0032eea4 0032eea8 0032eea0 Backtrace: =>1 0x6113c944 arbfp_free+0x34(iface=0x1379f8) [/home/max/wine/wine/dlls/wined3d/arb_program_shader.c:2255] in wined3d (0x0032ee50) 2 0x61165c7e IWineD3DDeviceImpl_Init3D+0x25e(iface=<register ESI not in topmost frame>, pPresentationParameters=0x32f068, D3DCB_CreateAdditionalSwapChain=0x60987840) [/home/max/wine/wine/dlls/wined3d/device.c:2258] in wined3d (0x0032ef10) 3 0x60989057 IDirectDrawImpl_CreateSurface+0xc47(iface=0x19e2890, DDSD=0x32f12c, Surf=0xa11614, UnkOuter=(nil)) [/home/max/wine/wine/dlls/ddraw/ddraw.c:3292] in ddraw (0x0032f0c0) 4 0x6098b29e IDirectDraw4Impl_CreateSurface+0x3e(This=<register ESI not in topmost frame>, pSDesc=0x32f12c, ppSurface=<register EDI not in topmost frame>, pUnkOuter=(nil)) [/home/max/wine/wine/dlls/ddraw/ddraw_thunks.c:500] in ddraw (0x0032f0f0) 5 0x0048c680 in rtmi (+0x8c680) (0x00000400) 6 0x00000000 (0x00000000) 0x6113c944 arbfp_free+0x34 [/home/max/wine/wine/dlls/wined3d/arb_program_shader.c:2255] in wined3d: movl 0x14(%esi),%eax 2255 hash_table_destroy(priv->fragment_shaders, arbfp_free_ffpshader, &This->adapter->gl_info); Modules: Module Address Debug info Name (82 modules) PE 330000- 388000 Deferred ijl15 PE 400000- d7c000 Export rtmi PE 400000- d7c000 Export rtmi PE 400000- d7c000 Export rtmi PE 400000- d7c000 Export rtmi PE 400000- d7c000 Export rtmi PE 400000- d7c000 Export rtmi PE 400000- d7c000 Export rtmi PE 400000- d7c000 Export rtmi PE 400000- d7c000 Export rtmi PE 400000- d7c000 Export rtmi PE 400000- d7c000 Export rtmi PE 400000- d7c000 Export rtmi PE 400000- d7c000 Export rtmi PE 400000- d7c000 Export rtmi PE 400000- d7c000 Export rtmi PE 400000- d7c000 Export rtmi PE 400000- d7c000 Export rtmi PE 400000- d7c000 Export rtmi PE 400000- d7c000 Export rtmi PE 400000- d7c000 Export rtmi PE 400000- d7c000 Export rtmi PE 400000- d7c000 Export rtmi PE 10000000-1008f000 Deferred spr ELF 6001f000-60155000 Deferred libwine.so.1 ELF 60156000-6016b000 Deferred libresolv.so.2 ELF 60322000-6032e000 Deferred libnss_files.so.2 ELF 60612000-6075b000 Deferred user32<elf> \-PE 60630000-6075b000 \ user32 ELF 6075b000-607f8000 Deferred gdi32<elf> \-PE 60770000-607f8000 \ gdi32 ELF 607f8000-60849000 Deferred advapi32<elf> \-PE 60800000-60849000 \ advapi32 ELF 60849000-608eb000 Deferred ole32<elf> \-PE 60860000-608eb000 \ ole32 ELF 608eb000-60950000 Deferred rpcrt4<elf> \-PE 60900000-60950000 \ rpcrt4 ELF 60950000-6096f000 Deferred iphlpapi<elf> \-PE 60960000-6096f000 \ iphlpapi ELF 6096f000-609c8000 Dwarf ddraw<elf> \-PE 60980000-609c8000 \ ddraw ELF 609c8000-60a00000 Deferred dinput<elf> \-PE 609d0000-60a00000 \ dinput ELF 60a00000-60a4a000 Deferred dsound<elf> \-PE 60a10000-60a4a000 \ dsound ELF 60a4a000-60adc000 Deferred winmm<elf> \-PE 60a50000-60adc000 \ winmm ELF 60adc000-60af5000 Deferred version<elf> \-PE 60ae0000-60af5000 \ version ELF 60af5000-60b09000 Deferred lz32<elf> \-PE 60b00000-60b09000 \ lz32 ELF 60b09000-60b3e000 Deferred winspool<elf> \-PE 60b10000-60b3e000 \ winspool ELF 60c65000-60cfe000 Deferred winex11<elf> \-PE 60c70000-60cfe000 \ winex11 ELF 60d0a000-60d18000 Deferred libgcc_s.so.1 ELF 60d18000-60d1a000 Deferred libnvidia-tls.so.1 ELF 60e52000-60e72000 Deferred imm32<elf> \-PE 60e60000-60e72000 \ imm32 ELF 60e75000-60e7a000 Deferred libxxf86vm.so.1 ELF 60e9c000-60ed1000 Deferred winealsa<elf> \-PE 60ea0000-60ed1000 \ winealsa ELF 60ed1000-60ee9000 Deferred msacm32<elf> \-PE 60ee0000-60ee9000 \ msacm32 ELF 60eed000-60fcd000 Deferred libasound.so.2 ELF 60fcd000-60ff4000 Deferred msacm32<elf> \-PE 60fd0000-60ff4000 \ msacm32 ELF 60ff4000-61008000 Deferred midimap<elf> \-PE 61000000-61008000 \ midimap ELF 61119000-61235000 Dwarf wined3d<elf> \-PE 61130000-61235000 \ wined3d ELF 6125d000-612dd000 Deferred opengl32<elf> \-PE 61270000-612dd000 \ opengl32 ELF 612f9000-6139e000 Deferred libgl.so.1 ELF 6139e000-620de000 Deferred libglcore.so.1 ELF 62aed000-62b13000 Deferred dmusic<elf> \-PE 62af0000-62b13000 \ dmusic ELF 7b800000-7b930000 Deferred kernel32<elf> \-PE 7b820000-7b930000 \ kernel32 ELF 7bc00000-7bca5000 Deferred ntdll<elf> \-PE 7bc10000-7bca5000 \ ntdll ELF 7bf00000-7bf03000 Deferred <wine-loader> Threads: process tid prio (all id:s are in hex) 00000008 (D) C:\Program Files\The Adventure Company\Retour sur l'�le myst�rieuse\RtMI.exe 00000028 15 00000023 0 00000009 0 <== 0000000c 0000001d 0 00000013 0 00000012 0 0000000e 0 0000000d 0 0000000f 00000015 0 00000014 0 00000011 0 00000010 0 00000016 00000017 0 Backtrace: =>1 0x6113c944 arbfp_free+0x34(iface=0x1379f8) [/home/max/wine/wine/dlls/wined3d/arb_program_shader.c:2255] in wined3d (0x0032ee50) 2 0x61165c7e IWineD3DDeviceImpl_Init3D+0x25e(iface=<register ESI not in topmost frame>, pPresentationParameters=0x32f068, D3DCB_CreateAdditionalSwapChain=0x60987840) [/home/max/wine/wine/dlls/wined3d/device.c:2258] in wined3d (0x0032ef10) 3 0x60989057 IDirectDrawImpl_CreateSurface+0xc47(iface=0x19e2890, DDSD=0x32f12c, Surf=0xa11614, UnkOuter=(nil)) [/home/max/wine/wine/dlls/ddraw/ddraw.c:3292] in ddraw (0x0032f0c0) 4 0x6098b29e IDirectDraw4Impl_CreateSurface+0x3e(This=<register ESI not in topmost frame>, pSDesc=0x32f12c, ppSurface=<register EDI not in topmost frame>, pUnkOuter=(nil)) [/home/max/wine/wine/dlls/ddraw/ddraw_thunks.c:500] in ddraw (0x0032f0f0) 5 0x0048c680 in rtmi (+0x8c680) (0x00000400) 6 0x00000000 (0x00000000)

1 0

Re: user32: fix error setting in FindWindow (try 2)
by Louis. Lenders 22 Aug '08

22 Aug '08

----- Original Message ---- From: Alexandre Julliard <julliard(a)winehq.org> To: Louis. Lenders <xerox_xerox2000(a)yahoo.co.uk> Cc: wine-devel(a)winehq.org Sent: Friday, 22 August, 2008 4:54:49 AM Subject: Re: user32: fix error setting in FindWindow (try 2) "Louis. Lenders" <xerox_xerox2000(a)yahoo.co.uk> writes: > diff --git a/dlls/user32/tests/win.c b/dlls/user32/tests/win.c > index 1964e88..246347f 100644 > --- a/dlls/user32/tests/win.c > +++ b/dlls/user32/tests/win.c > @@ -4789,14 +4789,20 @@ static void test_hwnd_message(void) > SetLastError(0xdeadbeef); > found = FindWindowExA( GetDesktopWindow(), 0, 0, "message window" ); > ok( found == 0, "found message window %p/%p\n", found, hwnd ); > - todo_wine > - ok(GetLastError() == ERROR_FILE_NOT_FOUND, "ERROR_FILE_NOT_FOUND, got %d\n", GetLastError()); > + ok(GetLastError() == ERROR_FILE_NOT_FOUND, "ERROR_FILE_NOT_FOUND, got %d\n", GetLastError()); >Have you tried your test on Windows? According to the test results >there isn't any Windows version that sets last error here. If you're talking about the test above, that was a test written by someone else, i think it was committed on wednesday or so. I only take out the "todo_wine" there; i assumed that test passed on windows, as the patch was committed, but i now see on the test results page that it doesn't. I did run the test on windows yesterday , the whole console got spammed with lots of messages, and i guess i overlooked something then ( i now see on the testpage that the failing test appears in the first lines of the spam, i only overlooked the last part in the console as i expected an eventually failing test there) As FindWindowEx apparently doesn't set an error, I'll have to recheck what FindWindow does on windows Send instant messages to your online friends http://uk.messenger.yahoo.com

1 0

Re: [PATCH 1/2] mstask: Implemented CreateTrigger.
by Roy Shea 22 Aug '08

22 Aug '08

> dlls/mstask/task.c | 4 ++-- > dlls/mstask/tests/task.c | 2 +- > 2 files changed, 3 insertions(+), 3 deletions(-) Please disregard this and the subsequent patch in the set. Patchwatecher found a few incorrect todo_wine statements that I forgot to remove. A revised version of the two patches has been resubmitted. Peace, -Roy

1 0

Re: user32: fix error setting in FindWindow (try 2)
by Alexandre Julliard 22 Aug '08

22 Aug '08

"Louis. Lenders" <xerox_xerox2000(a)yahoo.co.uk> writes: > diff --git a/dlls/user32/tests/win.c b/dlls/user32/tests/win.c > index 1964e88..246347f 100644 > --- a/dlls/user32/tests/win.c > +++ b/dlls/user32/tests/win.c > @@ -4789,14 +4789,20 @@ static void test_hwnd_message(void) > SetLastError(0xdeadbeef); > found = FindWindowExA( GetDesktopWindow(), 0, 0, "message window" ); > ok( found == 0, "found message window %p/%p\n", found, hwnd ); > - todo_wine > - ok(GetLastError() == ERROR_FILE_NOT_FOUND, "ERROR_FILE_NOT_FOUND, got %d\n", GetLastError()); > + ok(GetLastError() == ERROR_FILE_NOT_FOUND, "ERROR_FILE_NOT_FOUND, got %d\n", GetLastError()); Have you tried your test on Windows? According to the test results there isn't any Windows version that sets last error here. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: Spore patch to fix UI and Part descriptions
by Marcus Meissner 22 Aug '08

22 Aug '08

On Fri, Aug 22, 2008 at 02:51:56PM +0700, Andrew Fenn wrote: > I made a new patch this time including a test. > > I put in some extra checking in SetScissorRect making sure that if > rect was null or it was an invalid rectangle that it was returned as > invalid as it should be. > > I'm not able to do a test on windows so if anyone does one please let > me know if there are any problems. Also please tell me if you spot any > problems with this patch. > > --- a/dlls/d3d9/device.c > +++ b/dlls/d3d9/device.c > @@ -746,7 +746,8 @@ static HRESULT WINAPI IDirect3DDevice9Impl_GetDepthStencilSurface(LPDIRECT3DDE > } > } else { > WARN("Call to IWineD3DDevice_GetDepthStencilSurface failed\n"); > - *ppZStencilSurface = NULL; > + /* *ppZStencilSurface = NULL; */ > + return D3DERR_NOTFOUND; > } > LeaveCriticalSection(&d3d9_cs); > return hr; Again, you should likely add a LeaveCriticalSection(&d3d9_cs); to the error return too. Or just set hr = D3DERR_NOTFOUND; and fall through. Ciao, Marcus

1 0

Re: [PATCH] shell32 - handle WM_CLOSE in the Control Panel window (fixed)
by Vincent Povirk 22 Aug '08

22 Aug '08

Why doesn't the WM_DESTROY case handle this properly? At first glance, it appears to have code for stopping the running applets and quitting from the main loop. Calling ExitProcess from WM_CLOSE is anything but graceful. Vincent Povirk On Thu, Aug 21, 2008 at 2:25 PM, Steven Edwards <winehacker(a)gmail.com> wrote: > This time without the TAB/space mixup > > Without this patch, if you have the Control Panel window open along > with an applet and you try to close the Panel window, you get a very > nice crash. This forces an exit with a little grace > > Changelog: > shell32 - handle WM_CLOSE in the Control Panel window > > -- > Steven Edwards > > "There is one thing stronger than all the armies in the world, and > that is an idea whose time has come." - Victor Hugo > > > >

3 6

re: patches
by Dan Kegel 22 Aug '08

22 Aug '08

Louis wrote: > Hi, apparently none of my patches is making it into git, nor did i recieve any response from Alexandre about what's wrong with them. I guess i'm kind of "blacklisted" I don't think so. LOTS of people, me included, have trouble getting patches into git. You just have to have patience, try to figure out what needs improving, and keep at it. Michael Karcher already gave you some good feedback: http://winehq.org/pipermail/wine-devel/2008-August/068280.html I don't think you've followed up on that yet. And when in doubt, it never hurts to rediff and clean up your patch series and resend. Maintainers like Alexandre often get overwhelmed by incoming email. Linus Torvalds even said that he simply deletes his inbox when it gets too full, and that people who are serious about wanting their patches in will resend. This is probably true of Alexandre, especially after he gets back from a two week vacation, as he just did. - Dan

1 0

Re: kernel32: Tiny improvement to the GetVolumePathNameW stub (try 4)
by James Hawkins 21 Aug '08

21 Aug '08

On Mon, Aug 18, 2008 at 4:18 AM, Louis. Lenders <xerox_xerox2000(a)yahoo.co.uk> wrote: > (the return TRUE statement got lost from last patch, thanks Michael for > noticing) > > > Hi, this fixes Adobe Lightroom 2.0 start up bug, mentioned in > http://bugs.winehq.org/show_bug.cgi?id=8224#c4 > > as long wine doesn't handle with volume mount points, it's probably safe to > satisfy most apps. > > (A simple google for > "fixme:volume:GetVolumePathNameW" > revealed only about 3 apps , and "fixme:volume:GetVolumePathNameA" revealed > zero hits, so for now the use of this api seems not really wide-spread, and > no need to touch GetVolumePathNameA i guess) > + /* As long as we don't handle volumemountpoints, and filename is something like "X:\\blabla\\bla", it's probably safe to return "X:\" for + now to keep some applications happy */ + Please get rid of this comment. + if(strlenW(filename)>=3 && filename[1] == ':' && filename[2] == '\\' && buflen >3) + { + lstrcpynW(volumepathname,filename,4); + return TRUE; + } You've handled *a* successful case, but what about the error case? Also, you're copying 4 bytes of filename into volumepathname. I don't think you understand what lstrcpyn does. Imagine this case: volumepathname = "aaaaaaaa" buflen = 8 filename = "C:\\file" After the call to lstrcpyn: volumepathname = "C:\\faaaa" -- James Hawkins

3 3

Re: kernel32: Tiny improvement to the GetVolumePathNameW stub (try 4)
by Louis. Lenders 21 Aug '08

21 Aug '08

----- Original Message ---- From: James Hawkins <truiken(a)gmail.com> To: Louis. Lenders <xerox_xerox2000(a)yahoo.co.uk> Cc: wine-devel(a)winehq.org Sent: Thursday, 21 August, 2008 3:55:07 PM Subject: Re: kernel32: Tiny improvement to the GetVolumePathNameW stub (try 4) >That whole paragraphs reads "hack now, fix later", which is definitely >not acceptable. Well, I would call it a "semi-stub", there's more of them scattered all over the wine-source. But if opinions are it's too hackish, that's fine with me, I was only trying to help a user to get an app running > > + { > + lstrcpynW(volumepathname,filename,4); > + return TRUE; > + } > > >>Also, you're copying 4 bytes of filename into volumepathname. I don't >>think you understand what lstrcpyn does. Imagine this case: > > volumepathname = "aaaaaaaa" > buflen = > 8 > filename = "C:\\file" > > After the call to lstrcpyn: > > volumepathname = "C:\\faaaa" > > > > MSDN says volumepathname was a pointer to an "out" - string, so how would it > become someting > like "aaaaaa", or am i overseeing something? > Yes you are overseeing something. I think it would be a good idea if you read up a bit more on C in your spare time. I get the feeling you don't quite have a grasp on the intricacies of the language, particularly pointers and strings. What I meant is, why would an app set volumepathname to "aaaaaa", as it's the pointer where it expects to find the volumepoint, so on windows this would be filled by kernel32.dll, not by the app. Maybe you mean this could be the case after a second call to GetVolumePathName? Anyway, this is not the place to discuss a C-language course so I'll reread the docs. Thanks for the comments anyway. Send instant messages to your online friends http://uk.messenger.yahoo.com

2 1

re: [6/6][PATCH]Updates WSAIoctl in ws2_32 to return AcceptEx and GetAcceptExSockaddrs
by Dan Kegel 21 Aug '08

21 Aug '08

slindeneau at gmail.com wrote: > This patch will allow the patch [1/6] to successfully complete on wine > and windows. Prior to this patch the conformance tests submitted in > [1/6] of this series will fail on wine. It's exciting to see such progress on AcceptEx! But the wine project likes to have all tests passing after each patch in a series. If patch 1/6 adds tests that fail on Wine, they need to be marked with todo_wine. If patch 6/6 fixes the problem in wine that caused those tests to fail, it should also remove the todo_wine from the test. Following this rule will help make sure your patches don't turn red on http://kegel.com/wine/patchwatcher/results/

2 1

Re:kernel32: Tiny improvement to the GetVolumePathNameW stub (try 4)
by Louis. Lenders 21 Aug '08

21 Aug '08

>You've handled *a* successful case, but what about the error case? As i said already in the mail with the patch, it might be *a* case, but this is the case that most apps will follow as far as i can see. Futhermore, when apps are really crashing into the other cases, it can be added later on i.m.o. For now they will just fall back to the current "implementation", returning "not implmented" then, so there will be no differnce with current behaviour. + { + lstrcpynW(volumepathname,filename,4); + return TRUE; + } >Also, you're copying 4 bytes of filename into volumepathname. I don't >think you understand what lstrcpyn does. Imagine this case: volumepathname = "aaaaaaaa" buflen = 8 filename = "C:\\file" After the call to lstrcpyn: volumepathname = "C:\\faaaa" MSDN says volumepathname was a pointer to an "out" - string, so how would it become someting like "aaaaaa", or am i overseeing something? Send instant messages to your online friends http://uk.messenger.yahoo.com

2 1

Re:shobjidl.idl: add Taskbarlist interface defenitions
by Louis. Lenders 21 Aug '08

21 Aug '08

>The "I'll send the rest later" is a warning light. You should further develop this and send it all later so >we know this is actually going somewhere. The whole patch, that lets Governor of Poker start i have attached to the bug http://bugs.winehq.org/attachment.cgi?id=15297 a few weeks ago. As i said before , it's enough to stub out interface calls like in that patch to let the game start I discovered later I put the headers in the wrong (seperate ) header file, so i thought first to send in the definitions in the correct header. I thought later on send the rest in small pieces thanks again for the review Send instant messages to your online friends http://uk.messenger.yahoo.com

1 0

Re:activeds: add stub for ADsGetLastError
by Louis. Lenders 21 Aug '08

21 Aug '08

Thanks for reviewing the patch James @@ -6,7 +6,7 @@ 8 stub ADsBuildVarArrayInt 9 stdcall ADsOpenObject(wstr wstr wstr long ptr ptr) 12 stub ADsSetLastError -13 stub ADsGetLastError +13 stdcall ADsGetLastError(ptr wstr long wstr long) >Both of those wstr parameters are out pointers so they should be ptr, not wstr. Didn't know that, so that has to be changed for sure /***************************************************** + * ADsGetLastError [ACTIVEDS.13] + */ +HRESULT WINAPI ADsGetLastError(LPDWORD pError, LPWSTR buffer, DWORD buflen, LPWSTR bufname, DWORD bufnamelen) +{ + FIXME("(%p,%p,%d,%p,%d)stub\n", pError, buffer, buflen, bufname, bufnamelen); + return E_POINTER; +} >Returning E_POINTER seems pretty wrong. In the documentation on http://msdn.microsoft.com/en-us/library/aa772183(VS.85).aspx it is listed as one of the possible return values. Of course one could also return E_NOTIMPL or E_FAIL etc, but for a stub this seemed like a good choice to me as well, the application (Dameware) doesn't seem to bother what is returned, it starts up just fine Send instant messages to your online friends http://uk.messenger.yahoo.com

2 1

Re: shobjidl.idl: add Taskbarlist interface defenitions
by James Hawkins 21 Aug '08

21 Aug '08

On Wed, Aug 20, 2008 at 3:24 AM, Louis. Lenders <xerox_xerox2000(a)yahoo.co.uk> wrote: > Hi , this interface is needed to get governor if poker running > (http://bugs.winehq.org/show_bug.cgi?id=14139). these first 3 patches is > only preliminary stuff, the rest of the stuff i'll send later on. > The "I'll send the rest later" is a warning light. You should further develop this and send it all later so we know this is actually going somewhere. -- James Hawkins

1 0

Re: [2/6][PATCH]Fixes an Async bug.
by Alexandre Julliard 21 Aug '08

21 Aug '08

"Scott Lindeneau" <slindeneau(a)gmail.com> writes: > Fixes a bug in the async implementation. When checking for waiting > elements on a queue you need to check to see if ANY element is waiting, > not just the first element. When waking elements up you should ALERT an > element that is not already alerted. All other status messages should be > set. (This compensates for poll events that trigger other poll events > before garbage collection occurs and removes alerted elements from the > queues). This is wrong, it will lead to busy waiting. We very much want the first async to have been handled before we wake up for the next one. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: activeds: add stub for ADsGetLastError
by James Hawkins 21 Aug '08

21 Aug '08

On Tue, Aug 19, 2008 at 4:14 PM, Louis. Lenders <xerox_xerox2000(a)yahoo.co.uk> wrote: > Fixes a crash in Dameware utilities > @@ -6,7 +6,7 @@ 8 stub ADsBuildVarArrayInt 9 stdcall ADsOpenObject(wstr wstr wstr long ptr ptr) 12 stub ADsSetLastError -13 stub ADsGetLastError +13 stdcall ADsGetLastError(ptr wstr long wstr long) Both of those wstr parameters are out pointers so they should be ptr, not wstr. /***************************************************** + * ADsGetLastError [ACTIVEDS.13] + */ +HRESULT WINAPI ADsGetLastError(LPDWORD pError, LPWSTR buffer, DWORD buflen, LPWSTR bufname, DWORD bufnamelen) +{ + FIXME("(%p,%p,%d,%p,%d)stub\n", pError, buffer, buflen, bufname, bufnamelen); + return E_POINTER; +} Returning E_POINTER seems pretty wrong. -- James Hawkins

1 0

patches
by Louis. Lenders 21 Aug '08

21 Aug '08

Hi, apparently none of my patches is making it into git, nor did i recieve any response from Alexandre about what's wrong with them. I guess i'm kind of "blacklisted" because of my dxdiag patch from a few months ago, where i took some code from a directX tutorial ( i thought tutorials were free code, well they aren't apparently). Anyway, there are i think some patches that contain useful things to fix some bugs, so if anyone would like to pick them up, feel free (espesially the fix for the google lively download) (@Alexandre: this is not a request from me to explain why the patches have been rejected. I don't want to be pissed off again by you like in your last mail; I may be a crappy coder, but i've been helping wine-users for a few years now, so i think i deserved a little more respect , than was reflected by that mail) Send instant messages to your online friends http://uk.messenger.yahoo.com

1 0

Re: [1/6][PATCH]AcceptEx Conformance Test
by James Hawkins 21 Aug '08

21 Aug '08

On Thu, Aug 21, 2008 at 12:59 PM, Scott Lindeneau <slindeneau(a)gmail.com> wrote: > Simple overlapped server based on AcceptEx added to the test list > using simple clients. > Tests must always 'pass'. That is, the individual ok tests must all pass, or if they fail you must wrap the failing tests in todo_wine blocks. Since your test was sent before the fixes and there are no todo_wine's, I'm assuming some of these tests fail. -- James Hawkins

1 0

Re: Spore patch to fix UI and Part descriptions
by Marcus Meissner 21 Aug '08

21 Aug '08

> > diff --git a/dlls/d3d9/device.c b/dlls/d3d9/device.c > index ddeaca3..dfbf818 100644 > --- a/dlls/d3d9/device.c > +++ b/dlls/d3d9/device.c > @@ -746,7 +746,8 @@ static HRESULT WINAPI IDirect3DDevice9Impl_GetDepthStencilSurface(LPDIRECT3DDE > } > } else { > WARN("Call to IWineD3DDevice_GetDepthStencilSurface failed\n"); > - *ppZStencilSurface = NULL; > + //*ppZStencilSurface = NULL; > + return D3DERR_INVALIDCALL; > } > LeaveCriticalSection(&d3d9_cs); You might cause a locking problem here, returning with d3d9_cs held. Ciao, Marcus

1 0

LinuxJournal poll: What do you use to run Windows applications on your Linux desktop?
by Dan Kegel 21 Aug '08

21 Aug '08

Don't all go out and vote - we don't want to skew the results - but check out http://www.linuxjournal.com/node/1007221/results What do you use to run Windows applications on your Linux desktop? August 19th, 2008 by LJ Staff Cedega 1% (8 votes) Crossover 4% (38 votes) VirtualBox 22% (195 votes) VMWare 14% (129 votes) Wine 37% (333 votes) Other 2% (21 votes) I don't need or want to run Windows apps 19% (167 votes) Wine comes out on top, but not yet majority. - Dan

1 0

WSAIoctl question.
by Scott Lindeneau 21 Aug '08

21 Aug '08

I noticed a patch that was submitted by John Griffiths on the 13th of July that forwards functions by mwsock.c using the following code: (commit: 2da98052d90591474c65bed853ca75e1da714823) +static void get_fn(SOCKET s, GUID* guid, FARPROC* fn) +{ + FARPROC func; + DWORD len; + if (!WSAIoctl(s, SIO_GET_EXTENSION_FUNCTION_POINTER, guid, sizeof(*guid), + &func, sizeof(func), &len, NULL, NULL)) + *fn = func; +} But wine's WSAIoctl does not support the SIO_GET_EXTENSION_FUNCTION_POINTER. I was wondering how this works and what its for? Is it for using native libraries?

1 0

Re: [PATCH] mstask: Task PersistFile AddRef, QueryInterface, and Release.
by Alexandre Julliard 21 Aug '08

21 Aug '08

Roy Shea <royshea(a)gmail.com> writes: > + TaskImpl *This = (TaskImpl*) > + ((char*)(iface) - offsetof(TaskImpl, persistVtbl)); Please define an inline function for this like many other interfaces do. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: dpnet: Add stubbed DirectPlay8Peer interface (try2)
by Alexandre Julliard 21 Aug '08

21 Aug '08

Alexander Nicolaysen Sørnes <alex(a)thehandofagony.com> writes: > HRESULT DPNET_CreateDirectPlay8Peer(LPCLASSFACTORY iface, LPUNKNOWN punkOuter, REFIID riid, LPVOID *ppobj) { > - WARN("(%p, %s, %p): stub.\n", punkOuter, debugstr_guid(riid), ppobj); > - return CLASS_E_CLASSNOTAVAILABLE; > + IDirectPlay8PeerImpl* Client; > + > + Client = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY, sizeof(IDirectPlay8PeerImpl)); > + > + if(Client == NULL) > + { > + *ppobj = NULL; > + WARN("Not enough memory\n"); > + return E_OUTOFMEMORY; > + } > + > + Client->lpVtbl = &DirectPlay8Peer_Vtbl; > + return IDirectPlay8PeerImpl_QueryInterface((PDIRECTPLAY8PEER)Client, riid, ppobj); You are leaking the object on error. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: user32: fix error setting in FindWindow
by Dmitry Timoshkov 21 Aug '08

21 Aug '08

"Louis. Lenders" <xerox_xerox2000(a)yahoo.co.uk> wrote: > @@ -1613,6 +1613,7 @@ HWND WINAPI FindWindowExW( HWND parent, HWND child, LPCWSTR className, LPCWSTR t > done: > HeapFree( GetProcessHeap(), 0, list ); > HeapFree( GetProcessHeap(), 0, buffer ); > + if(!retvalue) SetLastError(ERROR_FILE_NOT_FOUND); > return retvalue; > } The prevailing indentation style in this file is to have a space after 'if', i.e. use 'if (!retvalue)'. > HWND WINAPI FindWindowA( LPCSTR className, LPCSTR title ) > { > HWND ret = FindWindowExA( 0, 0, className, title ); > - if (!ret) SetLastError (ERROR_CANNOT_FIND_WND_CLASS); > return ret; > } Changing the whole block to just return FindWindowExA( 0, 0, className, title ); would be more logical. -- Dmitry.

1 0

user32: Fix hook_proc DLL loading using LoadLibraryExW instead of LoadLibraryW
by Hongbo Ni 21 Aug '08

21 Aug '08

> >This patch fixes Bug 14784. > >As requested by Dmitry Timoshkov, I have created a standalone test case >for DLL injection via SetWindowHookEx. It has been attached in Bug 14784 >with MSVC source code and compiled exe and dll. > >With LoadLibraryExW(module, NULL, LOAD_WITH_ALTERED_SEARCH_PATH), the >Wine will search any imported DLL first in the same directory as module, >then in the standard search path. > >LoadLibraryW(module) searches imported DLL(s) in the directory of current >process, which may not be the same process where the module is first >loaded. That is why that LoadLibraryW(module) fails to hook to another >process if the DLL containing the hook_proc links to another DLL(s) in >the same directory. > >--- > dlls/user32/hook.c | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > >diff --git a/dlls/user32/hook.c b/dlls/user32/hook.c >index 4354e05..638a302 100644 >--- a/dlls/user32/hook.c >+++ b/dlls/user32/hook.c >@@ -322,7 +322,7 @@ void *get_hook_proc( void *proc, const WCHAR *module ) > { > TRACE( "loading %s\n", debugstr_w(module) ); > /* FIXME: the library will never be freed */ >- if (!(mod = LoadLibraryW(module))) return NULL; >+ if (!(mod = LoadLibraryExW(module, NULL, LOAD_WITH_ALTERED_SEARCH_PATH))) return NULL; > } > return (char *)mod + (ULONG_PTR)proc; > } >-- Is there any problems with this patch? Hongbo Ni <hongbo(a)njstar.com> +----------------------------------------------------------------+ * NJStar Software Corp., P.O. Box 40, Epping NSW 2121, Australia. * Tel: +61-2-9869-1088 WebSite: http://www.njstar.com * Fax: +61-2-9869-1099 Email: http://njstar.com/contact/ * eFax: +1-253-595-4788 +----------------------------------------------------------------+

1 0

Running a conformance test on windows before submitting to wine-patches.
by Scott Lindeneau 21 Aug '08

21 Aug '08

I would like to submit the following AcceptEx conformance test to wine-patches, but I don't have a windows box (and i haven't got qemu setup(correctly) yet). Would someone run this and let me know how/if it failes (or succeeds... it should succeed). Thanks - Scott

3 2

Re: [PATCH] comctl32: Set listview focus on WM_LBUTTONUP instead of WM_LBUTTONDOWN.
by Lei Zhang 21 Aug '08

21 Aug '08

On Mon, Aug 18, 2008 at 4:08 PM, Lei Zhang <thestig(a)google.com> wrote: > Hi, > > This should fix bug 14908. > Any problems with this patch?

1 0

Re: Alexander Nicolaysen Sørnes : regedit: Convert printing&help to unicode.
by Eric Pouech 20 Aug '08

20 Aug '08

Alexandre Julliard a écrit : > Module: wine > Branch: master > Commit: 5cb8bccf462790338677dac3bfb394df8f4da020 > URL: http://source.winehq.org/git/wine.git/?a=commit;h=5cb8bccf462790338677dac3b… > > Author: Alexander Nicolaysen Sørnes <alex(a)thehandofagony.com> > Date: Sun Aug 10 12:43:06 2008 +0200 > > regedit: Convert printing&help to unicode. > > --- > > programs/regedit/framewnd.c | 25 +++++++++++++++++-------- > 1 files changed, 17 insertions(+), 8 deletions(-) > > @@ -671,8 +671,11 @@ static BOOL _CmdWndProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam) > case ID_REGISTRY_DISCONNECTNETWORKREGISTRY: > break; > case ID_REGISTRY_PRINT: > - PrintRegistryHive(hWnd, _T("")); > + { > + const WCHAR empty = 0; > + PrintRegistryHive(hWnd, empty); > break; > + } > this looks very wrong to me -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)

3 4

AcceptEx patch series notes
by Dan Kegel 20 Aug '08

20 Aug '08

Hi Scott. A few notes about your patch series. There should be no forward references in the patches; you can't have patch 1 depend on patch 2. Also, don't send two versions of tests, one for Wine and one for Windows; the same code has to work in both places. You can't even use an ifdef, since the windows .exe has to pass on wine. You can use a runtime test, perhaps, to skip some tests on Wine, but that's about it.

1 0

Re: Running a conformance test on windows before submitting to wine-patches.
by Scott Lindeneau 20 Aug '08

20 Aug '08

Sorry about not knowing how to cross compile before. Here is the patch(gmail doesn't let me attach exe's... I will look into this). Please try this. Tell me if I am doing something wrong (again). -Scott

3 5

re: d3dx9: Implementation of D3DXGetDeclLength
by dank＠kegel.com 20 Aug '08

20 Aug '08

http://kegel.com/wine/patchwatcher/results/ says you forgot to include the new file include/d3dx9mesh.h this time; you included it in http://www.winehq.org/pipermail/wine-patches/2008-August/059261.html but some how dropped it when you resent?

1 0

Re: Running a conformance test on windows before submitting to wine-patches.
by Scott Lindeneau 20 Aug '08

20 Aug '08

It did. I wrote the test using a different set of patches which let it compile with wine. I will look up how to cross compile it and do that next time. Sorry for the inconvenience. On Thu, Aug 21, 2008 at 2:36 AM, Austin English <austinenglish(a)gmail.com> wrote: > On Wed, Aug 20, 2008 at 12:34 PM, Scott Lindeneau <slindeneau(a)gmail.com> wrote: >> I don't think so? I've never written a conformance test before. I did >> implement AcceptEx in wine, but it shouldn't need that patch to >> compile for windows should it? Or maybe I need to load it into memory >> instead of just calling it first... Terribly sorry. I'm making myself >> a nuisance. I will try writing it using the windows WSAIoctl call to >> load it into memory first. MSDN does say I need that. >> >> -Scott >> >> >> On Thu, Aug 21, 2008 at 2:29 AM, Austin English <austinenglish(a)gmail.com> wrote: >>> On Wed, Aug 20, 2008 at 12:23 PM, Scott Lindeneau <slindeneau(a)gmail.com> wrote: >>>> I would like to submit the following AcceptEx conformance test to >>>> wine-patches, but I don't have a windows box (and i haven't got qemu >>>> setup(correctly) yet). Would someone run this and let me know how/if >>>> it failes (or succeeds... it should succeed). >>>> >>>> Thanks >>>> - Scott >>>> >>>> >>>> >>>> >>> >>> Does it depend on another patch: >>> >>> austin@SERVER1:~/wine-git/dlls/ws2_32/tests$ make crosstest >>> i586-mingw32msvc-gcc protocol.cross.o sock.cross.o >>> testlist.cross.o -o ws2_32_crosstest.exe -L../../../dlls >>> -L../../../dlls/ws2_32 -L../../../dlls/kernel32 -lws2_32 -lkernel32 >>> sock.cross.o: In function >>> `overlapped_server':/home/austin/wine-git/dlls/ws2_32/tests/sock.c:633: >>> undefined reference to `_AcceptEx@32' >>> :/home/austin/wine-git/dlls/ws2_32/tests/sock.c:677: undefined >>> reference to `_GetAcceptExSockaddrs@32' >>> collect2: ld returned 1 exit status >>> make: *** [ws2_32_crosstest.exe] Error 1 >>> >> > > Please bottom post on wine-devel. > > In the future, sending a compiled exe is helpful, saves time. Does it > even past make test for you? > > > austin@SERVER1:~/wine-git/dlls/ws2_32/tests$ make test > ccache gcc -c -I. -I. -I../../../include -I../../../include > -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing > -Wdeclaration-after-statement -Wwrite-strings -Wpointer-arith -g -O2 > -o protocol.o protocol.c > ccache gcc -c -I. -I. -I../../../include -I../../../include > -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing > -Wdeclaration-after-statement -Wwrite-strings -Wpointer-arith -g -O2 > -o sock.o sock.c > sock.c: In function âoverlapped_serverâ: > sock.c:670: warning: pointer targets in passing argument 3 of > âGetOverlappedResultâ differ in signedness > ccache gcc -c -I. -I. -I../../../include -I../../../include > -D_REENTRANT -fPIC -Wall -pipe -fno-strict-aliasing > -Wdeclaration-after-statement -Wwrite-strings -Wpointer-arith -g -O2 > -o testlist.o testlist.c > ../../../tools/winegcc/winegcc -B../../../tools/winebuild -mconsole > protocol.o sock.o testlist.o -o ws2_32_test.exe.so > ../../../libs/port/libwine_port.a -lws2_32 -lkernel32 > sock.o: In function `overlapped_server': > /home/austin/wine-git/dlls/ws2_32/tests/sock.c:633: undefined > reference to `AcceptEx' > /home/austin/wine-git/dlls/ws2_32/tests/sock.c:677: undefined > reference to `GetAcceptExSockaddrs' > collect2: ld returned 1 exit status > winegcc: ccache failed > make: *** [ws2_32_test.exe.so] Error 2 >

1 0

Re: crypt32(4/7): Add tests for CMSG_CMS_SIGNER_INFO_PARAM
by Eric Pouech 20 Aug '08

20 Aug '08

Juan Lang a écrit : > --Juan > ------------------------------------------------------------------------ > > From 7eaf8a741cc4ff2035491f36ba9b8f7c5d650458 Mon Sep 17 00:00:00 2001 > From: Juan Lang <juan.lang(a)gmail.com> > Date: Mon, 18 Aug 2008 13:09:24 -0700 > Subject: [PATCH] Add tests for CMSG_CMS_SIGNER_INFO_PARAM > > --- > dlls/crypt32/tests/msg.c | 135 ++++++++++++++++++++++++++++++++++++++++++++++ > 1 files changed, 135 insertions(+), 0 deletions(-) > > diff --git a/dlls/crypt32/tests/msg.c b/dlls/crypt32/tests/msg.c > index 86ce6b1..ce4affd 100644 > --- a/dlls/crypt32/tests/msg.c > +++ b/dlls/crypt32/tests/msg.c > @@ -2265,9 +2265,56 @@ static void compare_signer_info(const CMSG_SIGNER_INFO *got, > /* FIXME: check more things */ > } > > +static void compare_cms_signer_info(const CMSG_CMS_SIGNER_INFO *got, > + const CMSG_CMS_SIGNER_INFO *expected) > +{ > + ok(got->dwVersion == expected->dwVersion, "Expected version %d, got %d\n", > + expected->dwVersion, got->dwVersion); > + ok(got->SignerId.dwIdChoice == expected->SignerId.dwIdChoice, > + "Expected id choice %d, got %d\n", expected->SignerId.dwIdChoice, > + got->SignerId.dwIdChoice); > + if (got->SignerId.dwIdChoice == expected->SignerId.dwIdChoice) > + { > + if (got->SignerId.dwIdChoice == CERT_ID_ISSUER_SERIAL_NUMBER) > + { > + ok(got->SignerId.IssuerSerialNumber.Issuer.cbData == > + expected->SignerId.IssuerSerialNumber.Issuer.cbData, > + "Expected issuer size %d, got %d\n", > + expected->SignerId.IssuerSerialNumber.Issuer.cbData, > + got->SignerId.IssuerSerialNumber.Issuer.cbData); > + ok(!memcmp(got->SignerId.IssuerSerialNumber.Issuer.pbData, > + got->SignerId.IssuerSerialNumber.Issuer.pbData, shouldn't it be expected->SignerId.IssuerSerialNumber.Issuer.pbData, > + got->SignerId.IssuerSerialNumber.Issuer.cbData), > + "Unexpected issuer\n"); > + ok(got->SignerId.IssuerSerialNumber.SerialNumber.cbData == > + expected->SignerId.IssuerSerialNumber.SerialNumber.cbData, > + "Expected serial number size %d, got %d\n", > + expected->SignerId.IssuerSerialNumber.SerialNumber.cbData, > + got->SignerId.IssuerSerialNumber.SerialNumber.cbData); > + ok(!memcmp(got->SignerId.IssuerSerialNumber.SerialNumber.pbData, > + got->SignerId.IssuerSerialNumber.SerialNumber.pbData, ditto ? > + got->SignerId.IssuerSerialNumber.SerialNumber.cbData), > + "Unexpected serial number\n"); > + } > + else > + { > + ok(got->SignerId.KeyId.cbData == expected->SignerId.KeyId.cbData, > + "expected key id size %d, got %d\n", > + expected->SignerId.KeyId.cbData, got->SignerId.KeyId.cbData); > + ok(!memcmp(expected->SignerId.KeyId.pbData, > + got->SignerId.KeyId.pbData, got->SignerId.KeyId.cbData), > + "unexpected key id\n"); > + } > + } > + /* FIXME: check more things */ > +} > + > static const BYTE signedWithCertAndCrlComputedHash[] = { > 0x08,0xd6,0xc0,0x5a,0x21,0x51,0x2a,0x79,0xa1,0xdf,0xeb,0x9d,0x2a,0x8f,0x26, > 0x2f }; > +static BYTE keyIdIssuer[] = { > +0x30,0x13,0x31,0x11,0x30,0x0f,0x06,0x0a,0x2b,0x06,0x01,0x04,0x01,0x82,0x37, > +0x0a,0x07,0x01,0x04,0x01,0x01 }; > > static void test_decode_msg_get_param(void) > { > @@ -2354,6 +2401,32 @@ static void test_decode_msg_get_param(void) > compare_signer_info((CMSG_SIGNER_INFO *)buf, &signer); > CryptMemFree(buf); > } > + /* Getting the CMS signer info of a PKCS7 message is possible. */ > + size = 0; > + ret = CryptMsgGetParam(msg, CMSG_CMS_SIGNER_INFO_PARAM, 0, NULL, &size); > + todo_wine > + ok(ret, "CryptMsgGetParam failed: %08x\n", GetLastError()); > + if (ret) > + buf = CryptMemAlloc(size); > + else > + buf = NULL; > + if (buf) > + { > + CMSG_CMS_SIGNER_INFO signer = { 0 }; > + > + signer.dwVersion = 1; > + signer.SignerId.dwIdChoice = CERT_ID_ISSUER_SERIAL_NUMBER; > + signer.SignerId.IssuerSerialNumber.Issuer.cbData = > + sizeof(encodedCommonName); > + signer.SignerId.IssuerSerialNumber.Issuer.pbData = encodedCommonName; > + signer.SignerId.IssuerSerialNumber.SerialNumber.cbData = > + sizeof(serialNum); > + signer.SignerId.IssuerSerialNumber.SerialNumber.pbData = serialNum; > + signer.HashAlgorithm.pszObjId = oid_rsa_md5; > + CryptMsgGetParam(msg, CMSG_CMS_SIGNER_INFO_PARAM, 0, buf, &size); > + compare_cms_signer_info((CMSG_CMS_SIGNER_INFO *)buf, &signer); > + CryptMemFree(buf); > + } > /* index is ignored when getting signer count */ > size = sizeof(value); > ret = CryptMsgGetParam(msg, CMSG_SIGNER_COUNT_PARAM, 1, &value, &size); > @@ -2383,6 +2456,68 @@ static void test_decode_msg_get_param(void) > CMSG_COMPUTED_HASH_PARAM, signedWithCertAndCrlComputedHash, > sizeof(signedWithCertAndCrlComputedHash)); > CryptMsgClose(msg); > + > + msg = CryptMsgOpenToDecode(PKCS_7_ASN_ENCODING, 0, 0, 0, NULL, NULL); > + ret = CryptMsgUpdate(msg, signedKeyIdEmptyContent, > + sizeof(signedKeyIdEmptyContent), TRUE); > + ok(ret, "CryptMsgUpdate failed: %08x\n", GetLastError()); > + size = sizeof(value); > + ret = CryptMsgGetParam(msg, CMSG_SIGNER_COUNT_PARAM, 0, &value, &size); > + ok(ret, "CryptMsgGetParam failed: %08x\n", GetLastError()); > + ok(value == 1, "Expected 1 signer, got %d\n", value); > + /* Getting the regular (non-CMS) signer info from a CMS message is also > + * possible.. > + */ > + size = 0; > + ret = CryptMsgGetParam(msg, CMSG_SIGNER_INFO_PARAM, 0, NULL, &size); > + todo_wine > + ok(ret, "CryptMsgGetParam failed: %08x\n", GetLastError()); > + if (ret) > + buf = CryptMemAlloc(size); > + else > + buf = NULL; > + if (buf) > + { > + CMSG_SIGNER_INFO signer; > + BYTE zero = 0; > + > + /* and here's the little oddity: for a CMS message using the key id > + * variant of a SignerId, retrieving the CMSG_SIGNER_INFO param yields > + * a signer with a zero (not empty) serial number, and whose issuer is > + * an RDN with OID szOID_KEYID_RDN, value type CERT_RDN_OCTET_STRING, > + * and value of the key id. > + */ > + signer.dwVersion = CMSG_SIGNED_DATA_V3; > + signer.Issuer.cbData = sizeof(keyIdIssuer); > + signer.Issuer.pbData = keyIdIssuer; > + signer.SerialNumber.cbData = 1; > + signer.SerialNumber.pbData = &zero; > + CryptMsgGetParam(msg, CMSG_SIGNER_INFO_PARAM, 0, buf, &size); > + compare_signer_info((CMSG_SIGNER_INFO *)buf, &signer); > + CryptMemFree(buf); > + } > + size = 0; > + ret = CryptMsgGetParam(msg, CMSG_CMS_SIGNER_INFO_PARAM, 0, NULL, &size); > + todo_wine > + ok(ret, "CryptMsgGetParam failed: %08x\n", GetLastError()); > + if (ret) > + buf = CryptMemAlloc(size); > + else > + buf = NULL; > + if (buf) > + { > + CMSG_CMS_SIGNER_INFO signer = { 0 }; > + > + signer.dwVersion = CMSG_SIGNED_DATA_V3; > + signer.SignerId.dwIdChoice = CERT_ID_KEY_IDENTIFIER; > + signer.SignerId.KeyId.cbData = sizeof(serialNum); > + signer.SignerId.KeyId.pbData = (BYTE *)serialNum; > + signer.HashAlgorithm.pszObjId = oid_rsa_md5; > + CryptMsgGetParam(msg, CMSG_CMS_SIGNER_INFO_PARAM, 0, buf, &size); > + compare_cms_signer_info((CMSG_CMS_SIGNER_INFO *)buf, &signer); > + CryptMemFree(buf); > + } > + CryptMsgClose(msg); > } > > static void test_decode_msg(void) > -- 1.5.2.2 > ------------------------------------------------------------------------ > > -- 1.5.2.2 ------------------------------------------------------------------------ -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)

2 1

Re: [PATCH] AcceptEx Impelementation
by Kai Blin 20 Aug '08

20 Aug '08

Hi Scott, I didn't see a reply to your AcceptEx patches yet, sorry if I missed it and you get this again. Please submit one patch per email only. I admittedly don't know much about the wineserver stuff, but I've noticed a couple of style issues in the winsock code: The indentation common in socket.c is either a two-space indent or a four-space indent. Please don't add new code with an eight-space indent. Also, the common convention for ifs is if (cond) { and not if(cond){ Apart from those minor nitpicks, the code looks good. 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.

5 9

Re: [9/10] WineD3D: Update the overlay when the destination was drawn to
by Alexandre Julliard 20 Aug '08

20 Aug '08

Stefan Dösinger <stefan(a)codeweavers.com> writes: > @@ -4550,13 +4558,22 @@ static WINED3DSURFTYPE WINAPI IWineD3DSurfaceImpl_GetImplType(IWineD3DSurface *i > static HRESULT WINAPI IWineD3DSurfaceImpl_DrawOverlay(IWineD3DSurface *iface) { > IWineD3DSurfaceImpl *This = (IWineD3DSurfaceImpl *) iface; > HRESULT hr; > + static BOOL recursive = FALSE; That static looks very suspicious. It should either be stored in the object or use some sort of locking. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: 1/3 dpnet: Add basic DirectPlay8Peer implementation
by Alexandre Julliard 20 Aug '08

20 Aug '08

Alexander Nicolaysen Sørnes <alex(a)thehandofagony.com> writes: > +static HRESULT WINAPI IDirectPlay8PeerImpl_Initialize(PDIRECTPLAY8PEER iface, PVOID CONST pvUserContext, CONST PFNDPNMESSAGEHANDLER pfn, CONST DWORD dwFlags) > +{ > + FIXME("(%p)->(%p,%p,%x): stub\n", iface, pvUserContext, pfn, dwFlags); > + > + return DPN_OK; > +} > + > +static HRESULT WINAPI IDirectPlay8PeerImpl_EnumServiceProviders(PDIRECTPLAY8PEER iface, CONST GUID *CONST pguidServiceProvider, CONST GUID *CONST pguidApplication, DPN_SERVICE_PROVIDER_INFO *CONST pSPInfoBuffer, DWORD *CONST pcbEnumData, DWORD *CONST pcReturned, CONST DWORD dwFlags) > +{ > + FIXME("(%p)->(%p,%p,%p,%p,%p,%x): stub\n", iface, pguidServiceProvider, pguidApplication, pSPInfoBuffer, pcbEnumData, pcReturned, dwFlags); > + return DPN_OK; > +} Returning OK from stubs is usually not a good idea. > +static const IDirectPlay8PeerVtbl DirectPlay8Peer_Vtbl = > +{ > + IDirectPlay8PeerImpl_QueryInterface, > + IDirectPlay8PeerImpl_AddRef, > + IDirectPlay8PeerImpl_Release, > + IDirectPlay8PeerImpl_Initialize, > + IDirectPlay8PeerImpl_EnumServiceProviders > +}; You can't initialize a vtbl partially, you need to stub all the functions. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: gdi32/tests/bitmap: Fix win9x detection
by Alexandre Julliard 20 Aug '08

20 Aug '08

Michael Karcher <wine(a)mkarcher.dialup.fu-berlin.de> writes: > In commit 48bb687dfb00b00f789b688459ad5d0ec77a617b, win9x detection was > changed to use the desktop window instead of a private EDIT window as > target for GetWindowLongW. GetWindowLongW(GetDesktopWindow(),GWLP_WNDPROC) > fails on wine (and probably on WinNT as well, as the counts on > test.winehq.org indicate). > > I am unsure about this patch, as I don't know whether is_win9x now > gets true if one has a Windows 98 system with the Microsoft Layer > for Unicode installed. The right way is to get rid of the check, especially since the GetWindowLongW behavior is irrelevant to what the test is doing. It should be using something like broken() instead. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: msxml3: Add ISAXContentHandler_endPrefix event (1/9) [try2]
by Alexandre Julliard 20 Aug '08

20 Aug '08

Piotr Caban <piotr.caban(a)gmail.com> writes: > @@ -117,6 +120,29 @@ static inline saxattributes *impl_from_ISAXAttributes( ISAXAttributes *iface ) > } > > > +static HRESULT namespacePush(saxlocator *locator, int ns) > +{ > + if(locator->nsStackLast>=locator->nsStackSize) > + { > + int *new_stack; > + > + locator->nsStackSize *= 2; > + new_stack = HeapReAlloc(GetProcessHeap(), 0, > + locator->nsStack, locator->nsStackSize); > + if(!new_stack) return E_OUTOFMEMORY; > + locator->nsStack = new_stack; You need to preserve nsStackSize on error too. -- Alexandre Julliard julliard(a)winehq.org

1 0

Avoiding charset corruption when sending patches
by Dan Kegel 20 Aug '08

20 Aug '08

Short story: Patches that touch non-Latin1 .rc files might need to be sent as attached non-text files rather than inline or as .txt files, to avoid charset corruption. Some examples: http://winehq.org/pipermail/wine-patches/2008-August/059095.html might suffer corruption (I can't tell offhand). http://winehq.org/pipermail/wine-patches/2008-August/059405.html looks safe, though. Long story: Patchwatcher was converting patches to utf-8, causing the patch [1/3] wined3d: Move creating a texture id from PreLoad to BindTexture to not apply. Thanks to Henri Verbeet for diagnosing the problem. The patchwatcher web page may need some surgery to deal with this. Currently it uses a single .txt file for the email message and the patch, which probably tempts the web server and browser to do charset conversions. I will probably switch the suffix to .bin to discourage this. Even longer story: So, what character set is the Wine source tree encoded with? It looks like a mixture: 1. in general, .c and .h files are encoded in Latin-1 aka iso8859-1. 2. include/*.h are encoded in ASCII and are not allowed to have non-ascii chars; see http://bugs.winehq.org/show_bug.cgi?id=5420 3. *_XX.rc (or XX.rc) are in the character set that Windows defaults to for language XX, unless changed by a #pragma code_page... in the .rc file. http://wiki.winehq.org/Developers-Hints#head-ef42a958e4f633dbd4a0ae42649fa0… Which brings us to the question: since email clients love changing charsets of text messages, how can we avoid corrupting patches when sending them via email? It kind of looks like patches to .rc files must be attached rather than inline, and should be attached as .patch, .diff, or .bin files so they are marked with the mime type application/octet-stream which should inhibit all charset conversions. (Attaching as .txt might tempt mail clients to perform charset conversions on them.) - Dan

2 1

Re: [PATCH 2/5] mstask: Implemented (Set|Get)ApplicationName. (Revision)
by Alexandre Julliard 20 Aug '08

20 Aug '08

Roy Shea <royshea(a)gmail.com> writes: > @@ -323,16 +324,62 @@ static HRESULT WINAPI MSTASK_ITask_SetApplicationName( > ITask* iface, > LPCWSTR pwszApplicationName) > { > - FIXME("(%p, %s): stub\n", iface, debugstr_w(pwszApplicationName)); > - return E_NOTIMPL; > + DWORD n; > + TaskImpl *This = (TaskImpl *)iface; > + > + TRACE("(%p, %s)\n", iface, debugstr_w(pwszApplicationName)); > + > + HeapFree(GetProcessHeap(), 0, This->applicationName); > + This->applicationName = NULL; You need to preserve the previous value on error. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [NJS#80611] re: msvcmaker: fix project file generation under MinGW32
by Hongbo Ni 20 Aug '08

20 Aug '08

At 03:25 AM 2008-08-20, Dan Kegel wrote: >Hongbo, it looks like your patch failed to apply because you did not >preserve whitespace exactly. Your patch uses all spaces >for the context, but the file contains tabs, so it does not match, >and patch fails. Thank you Dan, and thanks to Patchwatcher. I will fix it and resubmit. Hongbo Ni Hongbo Ni <hongbo(a)njstar.com> +----------------------------------------------------------------+ * NJStar Software Corp., P.O. Box 40, Epping NSW 2121, Australia. * Tel: +61-2-9869-1088 WebSite: http://www.njstar.com * Fax: +61-2-9869-1099 Email: http://njstar.com/contact/ * eFax: +1-253-595-4788 +----------------------------------------------------------------+

1 0

Incidental patch cleaning?
by Andrew Talbot 19 Aug '08

19 Aug '08

Hi, Is it possible to sneak in a bit of patch cleaning within the new software? It would be useful to incidentally remove any trailing white space that happens to exist within the scope of a patch. -- Andy.

3 2

RE: dinput: Add mouse warp override config option (resend)
by Stefan Dösinger 19 Aug '08

19 Aug '08

Just for the record, I think we really want this patch. XInput 2 is currently under development, so we cannot fix the issue properly right now. Even if we have XI2, there will still be old X servers around for ages. > -----Original Message----- > From: wine-patches-bounces(a)winehq.org [mailto:wine-patches- > bounces(a)winehq.org] On Behalf Of Vitaliy Margolen > Sent: Monday, August 18, 2008 8:18 PM > To: wine-patches(a)winehq.org > Subject: dinput: Add mouse warp override config option (resend) > > > Set [HKCU\Software\Wine\DirectInput] (or application specific key) > "MouseWarpOverride" to: > "force" - always warp > "disable" - newer warp > "anything else" - warp when needed - current behavior (default) > --- > dlls/dinput/mouse.c | 39 ++++++++++++++++++++++++++++++++++----- > 1 files changed, 34 insertions(+), 5 deletions(-)

3 5

Translating kernel32/nls/winerr_eng
by Alexander Nicolaysen Sørnes 19 Aug '08

19 Aug '08

Hello, I'm translating the winerr messages to Norwegian, but I'm not completely sure about the LanguageNames line. Should the code be the same as the language ID (0x414)? LanguageNames=(NOR=0x414:winerr) This seems to be the case for English, but not French & German. Alexander N. Sørnes

1 0

Re: winmm: Test opening the same device twice
by Eric Pouech 19 Aug '08

19 Aug '08

Maarten Lankhorst a écrit : > Behavioral test to show that wine winmm needs fixing. > --- > ------------------------------------------------------------------------ > > this likely is going to fail on old boxes there's no requirement on MS side that a PCM renderer has to be opened twice so having it as a test is wrong some old cards with OSS as a driver forbid the card to be opened twice (especially in different processes). IIRC, there was a bit of support in the OSS driver (not sure about the ALSA one) to allow > 1 opening in the same process (and also opening one handle for sound capture and another one for sound rendering). but this didn't provide support for mixing the output from the two different handles, which is likely what part of what you're trying to do assumes (especially for dsound plus standard winmm output) the only way out is to have the Linux (or Unix) driver handle several opening including the mixing of the two streams if the driver doesn't provide this flexibility, I don't see a point of implementing it in Wine A+ -- Eric Pouech "The problem with designing something completely foolproof is to underestimate the ingenuity of a complete idiot." (Douglas Adams)

2 1

patchwatcher and changes to configure.h.in [was: re: ntdll/file: Add sub-second resolution to NtQueryInformationFile]
by Dan Kegel 19 Aug '08

19 Aug '08

>> Btw, how does patchwatcher handle that? >> Does it detect that in the case of changing config.h.in, >> dlls/Makefile.in, server/protocol.def it needs >> to regenerate the files by running autoconf, >> tools/make_requests, or tools/make_makefiles? > > Not at all. Patches gratefully accepted. Status: - posted note about two bugs in patch series handling, will fix tomorrow - "time baseline_tests" doesn't work (limitation of time cmd), need to fix borkage there. Sloppy. - Austin sent in a patch to install gecko - I'm close to having valgrind integration, but haven't looked at how to make it fast enough yet. - user32:monitor.c:262: Test failed: Failed to reset default resolution is happening lately; should probably restart X server between runs

2 2

re: msvcmaker: fix project file generation under MinGW32
by Dan Kegel 19 Aug '08

19 Aug '08

Hi Hongbo, it looks like your patch failed to apply because you did not preserve whitespace exactly. Your patch uses all spaces for the context, but the file contains tabs, so it does not match, and patch fails. - Dan ---------- Forwarded message ---------- From: <patchwatcher(a)kegel.com> Date: Tue, Aug 19, 2008 at 10:16 AM Subject: Patchwatcher: failed to apply: msvcmaker: fix project file generation under MinGW32 To: dank(a)kegel.com Hi! This is the experimental automated wine patchwatcher thingy. The latest git sources were built and tested with your patch "msvcmaker: fix project file generation under MinGW32" Result: the patch failed to apply. You can retrieve the full build results at http://kegel.com/wine/patchwatcher/results/3.log and see the patch as parsed at http://kegel.com/wine/patchwatcher/results/3.txt See http://kegel.com/wine/patchwatcher/results for more info.

1 0

Patchwatcher status
by Dan Kegel 19 Aug '08

19 Aug '08

Patchwatcher falsely complained that [2/17] richedit: Removed assumption about the order of rtf indent didn't apply because the regexp I used to detect the end of a patch series falsely matched the first patch in a series of 1x patches. Here's the fix: --- patchwatcher.sh (revision 150) +++ patchwatcher.sh (working copy) @@ -283,7 +283,7 @@ cat $PATCHES/$NEXT.log fi # Use a regexp with a back reference to detect last patch in a series and break out - if egrep -q 'Subject:.*[0-9]+/[0-9]+' $PATCHES/$NEXT.txt && ! egrep -q 'Subject:.*([0-9]+)/\1' $PATCHES/$NEXT.txt + if egrep -q 'Subject:.*[0-9]+/[0-9]+' $PATCHES/$NEXT.txt && ! egrep -q 'Subject:.*([0-9]+)/\1[^0-9]' $PATCHES/$NEXT.txt then echo In middle of patch series, not wiping tree NEXT=`expr $NEXT + 1` And it falsely complained that various of adam(a)tpetaccia.com's patches failed because it didn't handle the case of multiple patch series sent by the same author back to back and mixed together by email delays. Here's a fix: --- get-patches.pl (revision 150) +++ get-patches.pl (working copy) @@ -147,7 +147,7 @@ $series_num_patches = $num_patches; } - if ($series_sender ne $sender) { + if ($series_sender ne $sender || $series_num_patches != $num_patches) { #print "Ignoring series for now, will try later; sender $sender, num_patches $num_patches, subject ".$header->get('Subject')."\n"; # can't handle multiple series at once just yet, let it sit return; That still won't handle the case of two patch series of the same length being sent back to back by the same author, but that's ambiguous enough that even humans might be confused, so it should tide us over until I rewrite the patch series detector to handle incomplete series better. I'm on vacation so I can't apply these patches to the running instance, I'll do it on tuesday. - Dan

2 3

New kernel development guide might be good model for Wine...
by Dan Kegel 19 Aug '08

19 Aug '08

This guide seems rather well written: http://ldn.linuxfoundation.org/how-participate-linux-community Wine could probably use something similar.

6 10

Re: Raising exception for SC_RPC_HANDLE being NULL
by Rob Shearman 19 Aug '08

19 Aug '08

2008/8/18 Michael Martin <martinmnet(a)hotmail.com>: > > In widl code generated for services an > exception is raised for null string with RPC_X_NULL_REF_POINTER > In windows calls made to for example CreateService with all NULL's > checks are made on the handle being null and its checked first before null strings. > > Windows documentation on RPC_X_ exceptions say that > RPC_X_SS_IN_NULL_CONTEXT is raised for null handles. > > suggested patch > > Index: widl/client.c > =================================================================== > --- widl/client.c (trunk) > +++ widl/client.c (working copy) > @@ -67,6 +67,15 @@ > indent--; > print_client("}\n\n"); > } > + else if ((var->type->name) && (strncmp(var->type->name,"SC_RPC_HANDLE", 13)==0)) How on earth do you think it is the right fix to hard-code a services type into widl? Did you not notice that SC_RPC_LOCK also needs the right treatment and that renaming SC_RPC_HANDLE to XXXFOOBAR shouldn't make any difference to the generated code? The correct fix is to check for context handles and the output the below code. > + { > + print_client("if (!%s)\n",var->name); > + print_client("{\n"); > + indent++; > + print_client("RpcRaiseException(RPC_X_SS_IN_NULL_CONTEXT);\n"); > + indent--; > + print_client("}\n\n"); > + } > } > } -- Rob Shearman

1 0

Re: ole32 [2/2] (msi [9.5/13]): Storage sharing should be implemented inole32, not the lower-level file API
by Dmitry Timoshkov 19 Aug '08

19 Aug '08

"James Hawkins" <jhawkins(a)codeweavers.com> wrote: > - { FALSE, ERROR_SHARING_VIOLATION, FALSE }, > - { TRUE, ERROR_SUCCESS, TRUE } > + { TRUE, ERROR_SUCCESS }, > + { TRUE, ERROR_SUCCESS }, > + { TRUE, ERROR_SUCCESS }, > + { TRUE, ERROR_SUCCESS }, > + { FALSE, ERROR_SHARING_VIOLATION }, > + { FALSE, ERROR_SHARING_VIOLATION }, > + { FALSE, ERROR_SHARING_VIOLATION }, > + { TRUE, ERROR_SUCCESS }, > + { FALSE, ERROR_SHARING_VIOLATION }, > + { FALSE, ERROR_SHARING_VIOLATION }, > + { FALSE, ERROR_SHARING_VIOLATION }, > + { TRUE, ERROR_SUCCESS }, > + { FALSE, ERROR_SHARING_VIOLATION }, > + { FALSE, ERROR_SHARING_VIOLATION }, > + { FALSE, ERROR_SHARING_VIOLATION }, > + { TRUE, ERROR_SUCCESS } > }; You forgot to remove 'BOOL todo;' from struct access_res definition. Also making the arrays of structures 'static const' while you are at it won't hurt (same for other similar tests). -- Dmitry.

1 0

Re: kernel32: Test the file access and share modes of CreateFile
by Dmitry Timoshkov 19 Aug '08

19 Aug '08

"James Hawkins" <jhawkins(a)codeweavers.com> wrote: > Changelog: > * Test the file access and share modes of CreateFile. Of course, the more tests - the better, but isn't that a duplicate of existing test_file_sharing()? Besides win9x will require fixing it all over the place... -- Dmitry.

2 1

[TRY4]user32/tests: add tests for creating subclassed builtin-class windows
by Hongbo Ni 19 Aug '08

19 Aug '08

Hello All, I am adding tests to test the unicodeness of builtin class window created after the class is globally subclassed. http://www.winehq.org/pipermail/wine-patches/2008-August/059354.html It tests the following builtin classes: Edit, Button, Static, ComboBox, ComboLBox, ListBox, #32770 (dialog), ScrollBar, Message, #32768 (menu), #32769 (desktop), #32772 (icon title), DDEMLEvent, #32771 (task switch) For classes that have text, wine behave different when the class is subclassed using a Unicode procudure. Todo_wine has been added. Thanks to Dmitry Timoshkov, I also added some tests before the builin class is subclassed. It turns out CreateWindowExW can not create window for class DDEMLEvent and #32771. Marked with todo_wine. The test passed for me on Windows XP, Vista and one Wine. Dmitry Timoshkov also confirmed pass on Windows XP and Vista. How can I improve those tests ? 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%…

1 0

Re: [TRY3]user32/tests: add tests for creating subclassedbuiltin-class windows
by Dmitry Timoshkov 19 Aug '08

19 Aug '08

"Hongbo Ni" <hongbo(a)njstar.com> wrote: > Changes since TRY2 - thanks to Dmitry Timoshkov for advice. > > 1. adds extra bulitin classes: ScrollBar,Message,DDEMLEvent & all #327xx; > 2. make sure created hwnd is valid; > 3. more tests for unicodeness of built-in-class window before subclassing; > 4. add more todo_wine for those extra classes without subclassing. > > Tested on Windows Vista SP1, XP SP3. > +#include "windows.h" Please avoid windows.h (include everything) inclusion, find an appropriate set of smaller include files instead, winnls.h in this case. The test looks good to me. it passes for me under XP SP3 (32 bit), and Vista SP1 x64 (native 64-bit and emulated 32-bit modes), although in order to pass in 64-bit mode I had to apply the following patch -#define IS_WNDPROC_HANDLE(x) (((ULONG_PTR)(x) >> 16) == (~((ULONG_PTR)0) >> 16)) +#define IS_WNDPROC_HANDLE(x) (((ULONG_PTR)(x) >> 16) == ((~(ULONG)0) >> 16)) but that's not your fault. -- Dmitry.

2 1

Re: shlwapi: add some more tests for UrlUnEscape
by Michael Karcher 18 Aug '08

18 Aug '08

Am Montag, den 18.08.2008, 08:46 +0000 schrieb Louis. Lenders: > hi, tests show that UrlUnEscape still converts the url-string if the > bufferpointer is set to NULL, and the > URL_UNESCAPE_INPLACE is set. Test passes fine with native shlwapi, and > in wine after applying the previous sent patch : > http://www.winehq.org/pipermail/wine-patches/attachments/20080814/d5feb31b/… Please resend the patch including the testcase, instead of sending a testcase alone. This puts test & fix into the same entry in git history, so that a later review of the changes is eased by having the appropriate testcase directly at hand. Patches including testcases also have a higher chance of getting committed. Regards, Michael Karcher

1 1

Re: Add TRACEs to NtCreateFile returns
by Michael Karcher 18 Aug '08

18 Aug '08

Another review. Am Sonntag, den 20.07.2008, 22:42 +0200 schrieb Markus Hitter: > Similar to NtReadFile and NtWriteFile, NtCreateFile should trace > return values on request. Providing the file handle allows to map > read/write requests to the corresponding file name. Seems very sensible. Your implementation looks OK, except for me not being sure whether status codes are usually printed decimal or hexadecimal. Please check. > Additionally, wrap a overly long line. Please don't put a style change and a functionality change that are independent into the same patch. Usual convention is to leave style of code parts one does not touch alone. If you really feel like that line should be changed, submit it as seperate patch. Regards, Michael Karcher

2 1

Re: Better reflect the current state of DrawIconEx
by Michael Karcher 18 Aug '08

18 Aug '08

You indirectly asked for review of your patches. The comments below might be reasons your patch did not get accepted. Best way to handle ignored patches is to look over the patch again, and if one does not see something that can be improved, just ask on wine-devel or (even better) the IRC channel whether anyone can see something wrong with that patch. Am Montag, den 21.07.2008, 21:17 +0200 schrieb Markus Hitter: > diff --git a/dlls/user32/cursoricon.c b/dlls/user32/cursoricon.c > index a1ba570..eca9bfb 100644 > --- a/dlls/user32/cursoricon.c > +++ b/dlls/user32/cursoricon.c > @@ -1979,7 +1979,9 @@ BOOL WINAPI DrawIconEx( HDC hdc, INT x0, INT > y0, HICON hIcon, > if (istep) > FIXME_(icon)("Ignoring istep=%d\n", istep); > if (flags & DI_COMPAT) > - FIXME_(icon)("Ignoring flag DI_COMPAT\n"); > + FIXME_(icon)("DI_COMPAT flag unimplemented (before NT4.0)\n"); As this flag is ignored on newer windows versions, you might think about removing that check altogether instead of just changing the message. > + if (flags & DI_NOMIRROR) > + FIXME_(icon)("DI_NOMIRROR flag unimplemented (XP or later)\n"); As a wine user, I don't care which windows versions implement this flag. What I do care about is whether the program requested some functionality from wine it can't handle. So I would just show a message that says "DI_NOMIRROR flag unimplemented", and skip the version information. Regards, Michael Karcher

1 0

Re: [Gdiplus 8/9] Implement GdipGetFontHeight
by Nikolay Sivov 18 Aug '08

18 Aug '08

Adam Petaccia wrote: > --- > dlls/gdiplus/font.c | 18 ++++++++++++++++++ > dlls/gdiplus/gdiplus.spec | 2 +- > include/gdiplusflat.h | 2 ++ > 3 files changed, 21 insertions(+), 1 deletions(-) > > diff --git a/dlls/gdiplus/font.c b/dlls/gdiplus/font.c > index 0c78bd5..5e1a14e 100644 > --- a/dlls/gdiplus/font.c > +++ b/dlls/gdiplus/font.c > @@ -387,6 +387,24 @@ GpStatus WINGDIPAPI GdipCloneFont(GpFont *font, GpFont **cloneFont) > } > > /******************************************************************************* > + * GdipGetFontHeight [GDIPLUS.@] > + */ > +GpStatus WINGDIPAPI GdipGetFontHeight(GDIPCONST GpFont *font, > + GDIPCONST GpGraphics *graphics, REAL *height) > +{ > + REAL dpi; > + GpStatus stat; > + > + TRACE("%p %p %p\n", font, graphics, height); > + > + stat = GdipGetDpiX(graphics, &dpi); > Is it normal that you use GdipGetDpiX and not GdipGetDpiY? I'm not much familiar with fonts so treat it like a question. It seems to me that height is measured using another axis. > + if (stat != Ok) > + return stat; > + > + return GdipGetFontHeightGivenDPI(font, dpi, height); > +} > + > +/******************************************************************************* > * GdipGetFontHeightGivenDPI [GDIPLUS.@] > * PARAMS > * font [I] Font to retrieve DPI from > diff --git a/dlls/gdiplus/gdiplus.spec b/dlls/gdiplus/gdiplus.spec > index f1ad0d4..e37eeec 100644 > --- a/dlls/gdiplus/gdiplus.spec > +++ b/dlls/gdiplus/gdiplus.spec > @@ -267,7 +267,7 @@ > @ stdcall GdipGetFamilyName(ptr ptr long) > @ stdcall GdipGetFontCollectionFamilyCount(ptr ptr) > @ stdcall GdipGetFontCollectionFamilyList(ptr long ptr ptr) > -@ stub GdipGetFontHeight > +@ stdcall GdipGetFontHeight(ptr ptr ptr) > @ stdcall GdipGetFontHeightGivenDPI(ptr long ptr) > @ stdcall GdipGetFontSize(ptr ptr) > @ stdcall GdipGetFontStyle(ptr ptr) > diff --git a/include/gdiplusflat.h b/include/gdiplusflat.h > index 17fae9c..f650e24 100644 > --- a/include/gdiplusflat.h > +++ b/include/gdiplusflat.h > @@ -425,6 +425,8 @@ GpStatus WINGDIPAPI GdipGetFamily(GpFont*, GpFontFamily**); > GpStatus WINGDIPAPI GdipGetFontUnit(GpFont*, Unit*); > GpStatus WINGDIPAPI GdipGetFontSize(GpFont*, REAL*); > GpStatus WINGDIPAPI GdipGetFontStyle(GpFont*, INT*); > +GpStatus WINGDIPAPI GdipGetFontHeight(GDIPCONST GpFont*, GDIPCONST GpGraphics*, > + REAL*); > GpStatus WINGDIPAPI GdipGetFontHeightGivenDPI(GDIPCONST GpFont*, REAL, REAL*); > > GpStatus WINGDIPAPI GdipCreateFontFamilyFromName(GDIPCONST WCHAR*, >

1 0

Re: [Gdiplus] Implement GdipCloneImage
by Huw Davies 18 Aug '08

18 Aug '08

On Sat, Aug 16, 2008 at 11:26:42PM -0400, Adam Petaccia wrote: > This seems like the right thing to do, but OleLoadImage fails. > Comments welcome. > --- > dlls/gdiplus/image.c | 42 ++++++++++++++++++++++++++++++++++++++++-- > dlls/gdiplus/tests/image.c | 2 +- > 2 files changed, 41 insertions(+), 3 deletions(-) > > diff --git a/dlls/gdiplus/image.c b/dlls/gdiplus/image.c > index 197665d..a74003f 100644 > --- a/dlls/gdiplus/image.c > +++ b/dlls/gdiplus/image.c > @@ -242,11 +242,49 @@ GpStatus WINGDIPAPI GdipBitmapUnlockBits(GpBitmap* bitmap, > > GpStatus WINGDIPAPI GdipCloneImage(GpImage *image, GpImage **cloneImage) > { > + hr = OleLoadPicture(stream, size, FALSE, &IID_IPicture, > + (LPVOID*)(*cloneImage)->picture); This can't be right. You need to pass the address of the interface ptr. Huw. -- Huw Davies huw(a)codeweavers.com

1 0

Re: [Gdiplus 1/5] Tests for PrivateFontCollection
by Nikolay Sivov 18 Aug '08

18 Aug '08

Adam Petaccia wrote: > --- > dlls/gdiplus/tests/font.c | 81 +++++++++++++++++++++++++++++++++++++++++++++ > 1 files changed, 81 insertions(+), 0 deletions(-) > > diff --git a/dlls/gdiplus/tests/font.c b/dlls/gdiplus/tests/font.c > index 3d30a86..b19f0aa 100644 > --- a/dlls/gdiplus/tests/font.c > +++ b/dlls/gdiplus/tests/font.c > @@ -28,6 +28,7 @@ static const WCHAR arial[] = {'A','r','i','a','l','\0'}; > static const WCHAR nonexistent[] = {'T','h','i','s','F','o','n','t','s','h','o','u','l','d','N','o','t','E','x','i','s','t','\0'}; > static const WCHAR MSSansSerif[] = {'M','S',' ','S','a','n','s',' ','S','e','r','i','f','\0'}; > static const WCHAR MicrosoftSansSerif[] = {'M','i','c','r','o','s','o','f','t',' ','S','a','n','s',' ','S','e','r','i','f','\0'}; > +static const WCHAR Tahoma[] = {'T','a','h','o','m','a','\0'}; > static const WCHAR TimesNewRoman[] = {'T','i','m','e','s',' ','N','e','w',' ','R','o','m','a','n','\0'}; > static const WCHAR CourierNew[] = {'C','o','u','r','i','e','r',' ','N','e','w','\0'}; > > @@ -333,6 +334,85 @@ monospace: > expect (Ok, stat); > } > > +static void test_fontcollections(void) > +{ > + const static WCHAR tahomafilename[] = {'C',':','\\','W','I','N','D','O','W','S','\\','F','o','n','t','s','\\','T','a','h','o','m','a','.','t','t','f','\0'}; > + const static WCHAR timesNRfilename[] = {'C',':','\\','W','I','N','D','O','W','S','\\','F','o','n','t','s','\\','T','i','m','e','s','.','t','t','f','\0'}; > + const static WCHAR badFileName[] = {'C',':','\\','W','I','N','D','O','W','S','\\','F','o','n','t','s','\\','S','h','o','u','l','d','n','o','t','e','x','i','s','t','.','t','t','f','\0'}; > + > + static WCHAR familyName[LF_FACESIZE]; > + GpStatus stat; > + GpFontCollection* PrivateFontCollection; > + GpFontFamily** fontFamily; > + INT expected = 0, count = 0, i; > + BOOL hastahoma, hastimesnr; > + > + stat = GdipNewPrivateFontCollection(&PrivateFontCollection); > +todo_wine > + expect(Ok, stat); > + stat = GdipPrivateAddFontFile(PrivateFontCollection, NULL); > + expect(InvalidParameter, stat); > +todo_wine{ > + stat = GdipPrivateAddFontFile(PrivateFontCollection, badFileName); > + expect(FileNotFound, stat); > + > + stat = GdipPrivateAddFontFile(PrivateFontCollection, tahomafilename); > + if (stat == Ok) > + { > + expected++; > + hastahoma = TRUE; > + } > + > + stat = GdipPrivateAddFontFile(PrivateFontCollection, timesNRfilename); > + if (stat == Ok) > + { > + expected++; > + hastimesnr = TRUE; > + } > + > + stat = GdipGetFontCollectionFamilyCount(PrivateFontCollection, &count); > + expect(Ok, stat); > + expect(expected, count); > + > + expected = count; > + > + /* Test retrieving of installed fonts */ > + fontFamily = GdipAlloc(sizeof(GpFontFamily*) * count); > + stat = GdipGetFontCollectionFamilyList(PrivateFontCollection, count, > + fontFamily, &count); > + expect(Ok, stat); > + expect(expected, count); > + if (stat == Ok) > + { > + i = 0; > + if (hastahoma) > + { > + GdipGetFamilyName(fontFamily[i], familyName, LANG_NEUTRAL); > + ok(lstrcmpiW(familyName, Tahoma) == 0, "Expected Tahoma, got %s\n", > + debugstr_w(familyName)); > + i++; > + } > + > + if (hastimesnr) > + { > + GdipGetFamilyName(fontFamily[i], familyName, LANG_NEUTRAL); > + ok(lstrcmpiW(familyName, TimesNewRoman) == 0, "Expected Times New " > + "Roman, got %s\n", debugstr_w(familyName)); > + i++; > This i++ is redundant, isn't it? > + } > + } > + > + for (i = 0; i < count; i++) > + { > + stat = GdipDeleteFontFamily(fontFamily[i]); > + expect(Ok, stat); > + } > +} > + > + stat = GdipDeletePrivateFontCollection(&PrivateFontCollection); > + expect(Ok, stat); > +} > + > START_TEST(font) > { > struct GdiplusStartupInput gdiplusStartupInput; > @@ -350,6 +430,7 @@ START_TEST(font) > test_fontfamily(); > test_fontfamily_properties(); > test_getgenerics(); > + test_fontcollections(); > > GdiplusShutdown(gdiplusToken); > } >

1 0

Re: rpcrt4: Remove unreachable code in EmbeddedComplexSize.
by James McKenzie 18 Aug '08

18 Aug '08

Rob Shearman wrote: > RPC_FC_ERROR_STATUS_T has a value of 0x10 and therefore isn't a > possible value of "flags_type & 0xf" in the switch statement. > Rob: This may be a really stupid question, but is it possible to generate this condition? James McKenzie

3 3

How to use wine to load windows dll files ?
by Gregory Hosler 18 Aug '08

18 Aug '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi All, I'm a developer of an open source project that needs to load some windows dlls for conversion routines. Specifically, I'm the lead developer of GyachI https://sourceforge.net/projects/gyachi/ a Yahoo Messenger client. In GyachI, in order to support speech in chat rooms, we make use of the window dll codec files (supplied by the end user) to do the necessary codec compression/decompression. At the present moment, we copied mplayer's method of loading the dll files. That is to say that we have some very old wine code in our source tree. It works, but as and when a user runs GyachI on a box with wine installed, then GyachI will run against the installed wine libraries instead of the inbuilt wine code (not sure how, but this seems to be the case, from several reports). Since the code that we're using is all wine code, and in fact it is in the wine libraries, I would like to purge the wine code out of our project tree, and just compile/link against the necessary wine header files / wine libraries. To that extent, I have been able to remove the wine code from a build tree, and using the wine header files, I can get my code to compile. However, when I go to link, I get a number of undefined symbols. Some of the undefined symbols (at link time) are: undefined reference to `CloseDriver' undefined reference to `CodecAlloc' undefined reference to `CodecRelease' undefined reference to `export_names' undefined reference to `GetProcAddress' undefined reference to `HeapAlloc' undefined reference to `HeapFree' undefined reference to `OpenDriverA' undefined reference to `SendDriverMessage' undefined reference to `__vprintf' Upon investigation, I've discovered that many of the routines that I'm linking against are not in libwine.so, but instead, they are in other libraries. e.g. /usr/lib/wine/user32.dll.so, /usr/lib/wine/winmm.dll.so, and a few others. I would like to know how to link to and make use of these routines in the respective wine libraries. I'm willing to write any stub code that might need to be written, but I cannot find any documentation of what needs to be done. Any suggestions, pointers, links, urls, etc., would be most appreciated. Code samples (e.g. from other projects doing what I'm trying to do) would also be much appreciated. :) Many thanks, and best rgds, - -Greg - -- +---------------------------------------------------------------------+ Please also check the log file at "/dev/null" for additional information. (from /var/log/Xorg.setup.log) | Greg Hosler ghosler(a)redhat.com | +---------------------------------------------------------------------+ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFIqQJ6404fl/0CV/QRAivBAJ0c66W7ePiItK8ZvNnZ/1nLErSWKwCfRRD7 PbePRptt6e8mEEefwRx2YsE= =euK4 -----END PGP SIGNATURE-----

2 1

(no subject)
by Hongbo Ni 18 Aug '08

18 Aug '08

Sorry my previous email got wrong format. "Dan Kegel" wrote: > This guide seems rather well written: > http://ldn.linuxfoundation.org/how-participate-linux-community > Wine could probably use something similar. YES, the Wine development speed can be greatly improved if similar development process is adepted, specially the 'Chain of Commands'. I am sure that Alexandre has done a great job as the Wine maintainer, but he may be stressed out when he comes back from his holiday as there are pile of patches awaiting him to review and commit. Hongbo Ni _________________________________________________________________ Win a Nokia E51 with mobile Hotmail SMS alerts http://www.livelife.ninemsn.com.au/compIntro.aspx?compId=4589

1 0

.NET program crashes involving stubbed functions
by Adam Petaccia 17 Aug '08

17 Aug '08

Its customary to make a function return NotImplemented in Gdiplus, if its just a dummy function that does nothing and returns. But .NET seems to check for this and throw an exception, crashing the program anyway. See bug http://bugs.winehq.org/show_bug.cgi?id=12951 for details, but originally a program crashed because GdipNewPrivateFontCollection was just a stub. After the function was created, it still crashes because it returns "NotImplemented", rather than "Ok". IIRC, we return "NotImplemented" for some debugging reason, but if the goal of Wine is to run Windows applications, should we just go ahead and return "Ok" so that .NET apps don't freak out? Of course in a perfect world, we wouldn't have to fake a return code, but until that time comes do people have opinions one way or another?

3 3

Patchwatcher status
by Dan Kegel 17 Aug '08

17 Aug '08

Patchwatcher is online and giving reasonably good feedback on the patch stream. The bug that caused every patch to be marked 'failed tests' is fixed, and the blacklist is expanded enough that false regressions seem to be rare. There are still bugs: 1. the dashboard shows no status column for http://kegel.com/wine/patchwatcher/results/32.txt even though http://kegel.com/wine/patchwatcher/results/32.log exists and shows that there was some strange problem in applying the patch. 2. The most recent patch shows up as 'queued' but the link to the patch doesn't work. Results are at http://kegel.com/wine/patchwatcher/results/ and source code is at http://winezeug.googlecode.com Next steps: - add timeout to handle hanging tests (every day or two I have to kill some test or other). There's no portable way to do this from wine/test.h that works in Win9x, so I'll probably set WINETEST_WRAPPER to run the tests via a wrapper that implements the timeout. - distribute across multiple machines by splitting into master (which watches the patch stream) and slaves (which execute tests). I will probably use http and ftp for this so the slaves can be remote. - support multiple architectures (anybody want to run the slaves on MacOSX for me?) - improve the web page to have error counts and perhaps separate links to the build and test logs - merge the chroot support (though this will need porting to run on MacOSX) - add valgrind as the next step after running tests - improve the web page generator to show current status (e.g. show the results from "make test" before starting valgrind)

4 5

Re: kernel32: Tiny improvement to the GetVolumePathNameW stub (try 3)
by Michael Karcher 17 Aug '08

17 Aug '08

Am Samstag, den 16.08.2008, 23:56 +0000 schrieb Louis. Lenders: > Hi Michael, thanks again for the comment, i moved the check for the > stringlength to the front, and removed the wrong check for the > bufferlength (oops). Looks quite good now, but somehow the "return TRUE;" line got lost. Regards, Michael Karcher

1 0

re: kernel32: Tiny improvement to the GetVolumePathNameW stub (try 2)
by Dan Kegel 16 Aug '08

16 Aug '08

"Louis. Lenders" <xerox_xerox2000(a)yahoo.co.uk> wrote: > i'm sure that if this function ever gets implemented all these checks and tests are needed, but as i said, a bit of google for fixme:GetVolumePath shows the common way (the very few) apps call this function is with filename="c:\blabla\bla", so for now , in my opinion, i don't think it's worth the effort. A simple test would be very easy and would help convince Alexandre to apply your patch. IMHO you should go drink a little bit of the koolaid at http://en.wikipedia.org/wiki/Test-driven_development Check it out; It even *sounds* like Wine development philosophy: ... > By focusing on writing only the code necessary to pass tests, designs can be cleaner and clearer than is often achieved by other methods[3]. In Test-Driven Development by Example Kent Beck also suggests the principle "Fake it, till you make it". - Dan

1 0

Re: kernel32: Tiny improvement to the GetVolumePathNameW stub (try 2)
by Michael Karcher 16 Aug '08

16 Aug '08

Am Samstag, den 16.08.2008, 19:09 +0000 schrieb Louis. Lenders: > Hi Michael, thanks for your comments. I've added some simple sanity > checks from your first suggestions. It looks much better now, but you still access filename[1] before you even know that filename is not an empty string. In that case, filename[1] is past the end of the array, and you must not access it. Your check for strlenW comes too late. The minimal fix would be to put the strlenW call before the character comparisons, but it would be even smarter to either a) check that filename[0] is not 0, and check the next characters in order. So if any of these characters, short circuit evaluation prevents access of later characters, or b) just implement the special case for the empty string and catch this case before you access filename[1] and filename[2]. Please think about what "sizeof(volumepathname)" will return. The condition "sizeof(volumepathname) > 3" is *always* true. You should check buflen at that point. > As for the other suggestions, i'm sure that if this function ever gets > implemented all these checks and tests are needed, but as i said, a > bit of google for fixme:GetVolumePath shows the common way (the very > few) apps call this function is with filename="c:\blabla\bla", so for > now , in my opinion, i don't think it's worth the effort. As long as there are no junctions in wine, your implementation is correct for paths it can handle. So I would suggest to make the FIXME a TRACE and add a FIXME("Can't handle path %s\n",debugstr_w(filename)); below the case you handle. While googling for GetVolumeFileNameW, I stumbled across http://www.winehq.org/pipermail/wine-patches/2006-June/027228.html This patch obviously has not been applied. That is not really surprising, as it contains an extra hunk on an unrelated include file at the end, and also ignores buflen, but it does contain the correct logic for testing whether filename is a fully qualified local part, it contains the GetVolumeFileNameA implementation that forwards to GetVolumeFileNameW and contains at least one basic test. I would suggest to polish that patch a bit and submit the extra goodies from it also (you might use your GetPathNameW implementation after fixing the points raised above; these implementations are mostly equivalent). With polishing, I mean the following changes: - Test buflen in GetVolumeFileNameW (important) - The test "!filename[2]" is redundant (should be removed) (or just use your fixed version instead of the last two) - In the test: There is no need to allocate volumepath on the heap. char volumepath[16] (too bad you can't use constants in C for array dimensions!) would also do. Also, an ok(ret,"Error...") should precede the if(ret) block, the else part killed. If you expect something, always test it with an ok statement; do not sprinkle ok(FALSE) later in the code. Regards, Michael Karcher

1 0

Re: [winmm] Implement stub for midiConnect and midiDisconnect.
by Nikolay Sivov 16 Aug '08

16 Aug '08

Christian Costa wrote: > Hi, > > This fixes bug 11142 & 11182. > > Bye, > Christian > > Changelog: > Implement stub for midiConnect and midiDisconnect. > Usually some error code returned for plain stubs like these. Does it block these bugs?

2 1

Re: kernel32: Tiny improvement to the GetVolumePathNameW stub
by Michael Karcher 16 Aug '08

16 Aug '08

Am Samstag, den 16.08.2008, 17:12 +0000 schrieb Louis. Lenders: > Hi, this fixes Adobe Lightroom 2.0 start up bug, mentioned in > http://bugs.winehq.org/show_bug.cgi?id=8224#c4 > > as long wine doesn't handle with volume mount points, it's probably > safe to satisfy most apps. The idea of your patch looks right to me. But (1) please don't use memcmp to compare wide characters, especially, don't use memcmp with a count of one, as it only compares one half the the wide character. use filename[1] == ':' && filename[2] == '\\' instead. (2) Please check that filename really has at least 3 characters before accessing it. (3)Please check the size of the output buffer before copying anything into it. Finally, the chance of getting this patch accepted raises if you accompany the implementation with an API test. Another point to increase the chances of getting that patch committed is to implement the corner cases (at least the empty string) explained on MSDN, also backed up by an API test. Please also note the documented behaviour for the case of the output buffer being short by one byte. Regards, Michael Karcher

1 0

re: winmm: remove misleading message
by Dan Kegel 16 Aug '08

16 Aug '08

Jeff wrote: > Remove a message suggesting that Wine should be pointed at a windows installation. > > - FIXME("Couldn't load driver for type %s.\n" > - "If you don't have a windows installation accessible from Wine,\n" > - "you perhaps forgot to create a [mci] section in system.ini\n", > + FIXME("Couldn't load driver for type %s.\n", The [mci] section in system.ini advice is still valid and usful, I think. You probably just want to remove the middle line. - Dan

1 0

Re: [1/2] mshtml: Changed get_typeinfo to help support IDispatch
by leslie_alistair＠hotmail.com 16 Aug '08

16 Aug '08

-------------------------------------------------- From: "Jacek Caban" <jacek(a)codeweavers.com> Sent: Saturday, August 16, 2008 8:18 PM To: <wine-devel(a)winehq.org> Cc: "Alistair Leslie-Hughes" <leslie_alistair(a)hotmail.com> Subject: Re: [1/2] mshtml: Changed get_typeinfo to help support IDispatch > Alistair Leslie-Hughes wrote: >> Hi, >> >> Changelog: >> mshtml: Changed get_typeinfo to help support IDispatch > > Subject: [PATCH] Changed get_typeinfo to AddRef the COM pointer > > > get_typeinfo is an internal function so it's fine to not AddRef as long as > we guarantee that we hold the reference (and we do) so there is no point > to add unneeded AddRef here. > I based the msxml get_typeinfo on the mshtml implementation, and it was initial rejected due to the missing AddRef's. So before I started Implementing more of the IDispatch functions, I thought this was the right thing todo. Best Regards Alistair Leslie-Hughes

1 0

Re: [2/2] mshtml: Implement IDispatch for IHTMLElement
by Jacek Caban 16 Aug '08

16 Aug '08

Alistair Leslie-Hughes wrote: > Hi, > > Changelog: > mshtml: Implement IDispatch for IHTMLElement You should forward these calls to IDispatchEx implementation. See htmlselect.c for example. Jacek

1 0

Re: [1/2] mshtml: Changed get_typeinfo to help support IDispatch
by Jacek Caban 16 Aug '08

16 Aug '08

Alistair Leslie-Hughes wrote: > Hi, > > Changelog: > mshtml: Changed get_typeinfo to help support IDispatch > Subject: [PATCH] Changed get_typeinfo to AddRef the COM pointer get_typeinfo is an internal function so it's fine to not AddRef as long as we guarantee that we hold the reference (and we do) so there is no point to add unneeded AddRef here. Jacek

1 0

re: Unwanted WM_CTLCOLORSTATIC notification
by Dan Kegel 15 Aug '08

15 Aug '08

Matt wrote: > I've been trying to debug a problem with Adobe Indesign CS where the > application crashes while creating the file open dialog box. Now I believe > (not 100% sure) I have tracked down the problem to a spurious > WM_CTLCOLORSTATIC notification. Thanks for looking into this. This is a key app needed by many schools and companies, but we haven't had enough time to give it the attention it deserves. Please file a bug report at http://bugs.winehq.org including all the info needed to reproduce the bug (ideally with a trial version; you can find download URLs at http://wiki.winehq.org/AdobeIndesign And attach your test case source there. If you want to go a little further, rewrite your test case in plain C instead of C++ (should be easy). And if you want to go even further, integrate it into our existing message tests, http://source.winehq.org/source/dlls/user32/tests/msg.c which already do have some tests for WM_CTLCOLORSTATIC. One note of caution: the user32/msg.c tests don't all pass on Wine, see http://wiki.winehq.org/MakeTestFailures and http://test.winehq.org/data/520ab5c261706f6118a85a82ba84213932ba76e7/#group… - Dan

2 1

Re: .NET program crashes involving stubbed functions
by James Mckenzie 15 Aug '08

15 Aug '08

Reece Dunn <msclrhd(a)googlemail.com> on Aug 13, 2008 11:32 AM wrote about .NET program crashes involving stubbed functions > >2008/8/13 Adam Petaccia <adam(a)tpetaccia.com>: >> Its customary to make a function return NotImplemented in Gdiplus, if >> its just a dummy function that does nothing and returns. But .NET seems >> to check for this and throw an exception, crashing the program anyway. >> >> See bug http://bugs.winehq.org/show_bug.cgi?id=12951 for details, but >> originally a program crashed because GdipNewPrivateFontCollection was >> just a stub. After the function was created, it still crashes because it >> returns "NotImplemented", rather than "Ok". IIRC, we return >> "NotImplemented" for some debugging reason, but if the goal of Wine is >> to run Windows applications, should we just go ahead and return "Ok" so >> that .NET apps don't freak out? >> >> Of course in a perfect world, we wouldn't have to fake a return code, >> but until that time comes do people have opinions one way or another? > >The problem with returning Ok is that it implies that the function >succeeded in what it is intended to do. As a result, the application >will continue and in this case expect to be able to use the private >font collection. To prevent the application crashing, it is likely >that several functions will need to be implemented. > >Also note that the reporter of the bug mentions that they installed >mono. This means that using MS.NET may lead to different behaviour. It >also means that it should be possible to see how the >GdipNewPrivateFontCollection call is being used by mono and the data >that it returns. Is there a method of resolving this using functions provided by Mono or will this require additional tools? > >So to summarise, I suspect this will require more than simply returning Ok. > I agree. There should be more responses than just OK. James McKenzie

1 0

Re: #1 winhttp: Add a handle management implementation.
by H. Verbeet 15 Aug '08

15 Aug '08

2008/8/15 Hans Leidekker <hans(a)meelstraat.net>: > > +HINTERNET alloc_handle( object_header_t *hdr ) > +{ > + object_header_t **p; > + ULONG_PTR handle = 0, num; > + > + list_init( &hdr->children ); > + > + EnterCriticalSection( &handle_cs ); > + if (!max_handles) > + { > + num = HANDLE_CHUNK_SIZE; > + if (!(p = heap_alloc_zero( sizeof(ULONG_PTR) * num ))) goto end; > + handles = p; > + max_handles = num; > + } > + if (max_handles == next_handle) > + { > + num = max_handles + HANDLE_CHUNK_SIZE; > + if (!(p = heap_realloc_zero( handles, sizeof(ULONG_PTR) * num ))) goto end; > + handles = p; > + max_handles = num; > + } > + handle = next_handle; > + if (handles[handle]) ERR("handle isn't free but should be\n"); > + > + handles[handle] = addref_object( hdr ); > + while (handles[next_handle] && (next_handle < max_handles)) next_handle++; > + > +end: > + LeaveCriticalSection( &handle_cs ); > + return hdr->handle = (HINTERNET)(handle + 1); > +} Not necessarily wrong, but the common way to implement tables like this is to grow the table by some percentage of the original size, and keep a list of free handles.

2 1

Re: #1 winhttp: Add a handle management implementation.
by Hans Leidekker 15 Aug '08

15 Aug '08

On Friday 15 August 2008 14:41:36 Hans Leidekker wrote: Sorry for the From address confusion. The CodeWeavers mail server accused me of relaying but I found out now that it's because I forgot to enable authenticated SMTP. -Hans

1 0

Unwanted WM_CTLCOLORSTATIC notification
by Matt J 15 Aug '08

15 Aug '08

Hi, I've been trying to debug a problem with Adobe Indesign CS where the application crashes while creating the file open dialog box. Now I believe (not 100% sure) I have tracked down the problem to a spurious WM_CTLCOLORSTATIC notification. This notification is generated when the application invokes WM_SETTEXT to change the caption of a 'group box' control control in the dialog box. To verify this I coded up a small test case, which I have attached to the email. This basically creates a new dialog box and when it receives it WM_INITDIALOG notification it calls SendDlgItemMessage to send a WM_SETTEXT message to set the text of a 'group box' control on the dialog. As it runs it logs the notifications that it receives. On windows we see the following: Message: 0x00000030 (48) Message: 0x00000110 (272) WM INITDIALOG Message: 0x00000127 (295) Message: 0x00000128 (296) Message: 0x00000018 (24) Message: 0x00000046 (70) ... Under wine we see: Message: 0x00000030 (48) Message: 0x00000110 (272) WM INITDIALOG Message: 0x00000138 (312) Message: 0x00000018 (24) Message: 0x00000046 (70) ... Of primary interest to me here is the WM_CTLCOLORSTATIC notification (0x00000138) that is generated only under wine. Also of interest is that WM_CHANGEUISTATE (0x00000127) and WM_UPDATEUISTATE (0x00000128) notifications are received under windows but not wine. This is my first foray into debugging wine, so I may be totally off track here, but I do believe that the WM_CTLCOLORSTATIC notification is what is causing InDesign to crash. So, I am wondering if someone with more experience here can give some advice about rectifying this problem. If I can provide any more info about the problem, please let me know. Regards, Matt

1 0

Re: wininet: default to keep-alive when the server is HTTP/1.1, not when it isn't
by Huw Davies 15 Aug '08

15 Aug '08

Vincent Povirk wrote: > This is a fix to a problem I introduced in > fd5b97bc4d12adc69085b739061c56e9107f8d1f. The expression that checked > the HTTP version was true for HTTP/1.0 servers, and I treated it as if > it were true for HTTP/1.1 servers. That means we defaulted to keep-alive > for HTTP/1.0 servers only, the exact opposite of what we want. This was a problem with the old code too, but what happens when we get HTTP > 1.1 ? Huw.

2 1

Flaky tests are starting to get real annoying...
by Dan Kegel 14 Aug '08

14 Aug '08

So, one of the things one learns when writing a patch robot is that flaky tests are very annoying. Each time it gets a new git tree, the robot does five baseline "make -k test" runs, remembers the tests that fail, and doesn't penalize patches for failing any of those tests. See http://code.google.com/p/winezeug/source/browse/trunk/patchwatcher/patchwat… Annoyingly, that's not enough. Some tests stubbornly refuse to fail during the baseline test runs. So I added a second, manual blacklist for those tests; see http://code.google.com/p/winezeug/source/browse/trunk/patchwatcher/patchwat… The list is currently user32:msg.c user32:input.c d3d9:visual.c ddraw:visual.c urlmon:protocol.c kernel32:thread.c and will continue growing as I keep plugging away at getting the patch robot happy. Is anybody else seeing this kind of flakiness? (If you're not, try running patchwatcher for a while :-) FWIW, I'm running the tests on hardy with a fresh metacity (as described in http://wiki.winehq.org/MakeTestFailures ).

4 6

Re: user32: test what FindWindow when window isn't found
by Dmitry Timoshkov 14 Aug '08

14 Aug '08

"Austin English" <austinenglish(a)gmail.com> wrote: > - /* test FindWindow behavior */ > + SetLastError(0xdeadbeef); > + HWND hWnd = FindWindow("SomeWindowThatDoesNotExist", NULL); > + if(hWnd) { > + printf("hWnd not NULL"); > + } > + else { > + > + todo_wine > + ok(GetLastError() == ERROR_FILE_NOT_FOUND, "ERROR_FILE_NOT_FOUND, got %d\n", GetLastError()); > + } Why did you remove the comment? Introducing 'hWnd' variable is not needed, there is one already called 'found', besides declaring variables in the code is not allowed in Wine. It would be much simpler to add the last error test to 2 existing FindWindowExA calls instead of introducing something looking as foreign code (in indentation, braces usage and spaces). -- Dmitry.

3 3

Storesonline, Ecommerce hosting solution - how to avoid mistakes that put your business at risk
by Mister Nice Guy 14 Aug '08

14 Aug '08

*Storesonline, Ecommerce hosting solution - how to avoid mistakes that put your business at risk* Building an e-business inevitably requires a dedicated ecommerce hosting solution that can support the infrastructures. There are plenty of areas to take care of. Depending on your business types, you will need to consider the technical areas that support the e-business transactions. Then * Storesonline* is the right fit for you. You also need to have strong customer support from the website provider. Reputation and security are critical factors which sustain your business. In order to avoid pitfalls due to an inferior host, this article reveals the mentioned areas and helps you determine the steps to proceed further. *Storesonline* does avoid these pitfalls and it's working really well. Unlike hosting an ordinary website, running an ecommerce website such as an online store can demand a high technical focus. For instance, you may need a shopping cart and a payment processor. Other than these, you may also wish to have regular backup service, site monitoring or digital certificates that can protect your valuable business. If so, you have to choose an ecommerce web site hosting plan that fits your needs. But it is really dependent on the business size. If you sell a few products, a simple ecommerce web hosting will be sufficient. *Storesonline* can handle the smallest mom and pop site to the biggest on the planet. However, for a business site of much larger scale, you need to consider the server usage and bandwidth. In such case, a fast and stable server with bigger memories may be necessary.

2 1

re: [appwiz.cpl]New Korean Resource
by Dan Kegel 14 Aug '08

14 Aug '08

Hi Hwang, Thank you for helping localize Wine in Korean! According to our automated patch checker, http://kegel.com/wine/patchwatcher/results/ your patches did not apply easily. You should probably repost them with all filenames as if you were one level above the wine tree. e.g. instead of --- dlls/appwiz.cpl/appwiz.rc 2008-07-26 09:24:56.000000000 +0900 +++ appwiz.rc 2008-07-28 09:48:00.000000000 +0900 you'd want --- a/dlls/appwiz.cpl/appwiz.rc 2008-07-26 09:24:56.000000000 +0900 +++ b/dlls/appwiz.cpl/appwiz.rc 2008-07-28 09:48:00.000000000 +0900 and instead of --- /dev/null 2008-07-28 09:27:06.210506864 +0900 +++ Ko.rc 2008-07-28 09:48:00.000000000 +0900 you'd want --- /dev/null 2008-07-28 09:27:06.210506864 +0900 +++ b/dlls/appwiz.cpl/Ko.rc 2008-07-28 09:48:00.000000000 +0900 The best way to generate patches is by using something like git diff or git format-patch as described at http://www.winehq.org/site/sending_patches as that always gets the directories right. Can you regenerate your patches properly, verify that your patches apply cleanly when in the top level of wine using the -p1 flag, e.g. cd ~/wine-git patch -p1 < ~/foo.patch and then resend the fixed patches? Thanks, Dan

1 0

Re: [TRY 4] Add tests for checking the parent notification for editcontrol
by Dmitry Timoshkov 13 Aug '08

13 Aug '08

"Ilya Shpigor" <shpigor(a)etersoft.ru> wrote: > Best regards > Ilya Shpigor. This version of the patch hasn't changed anything since my previous comments. -- Dmitry.

1 0

No GIT changes since 7 days?
by thacrazze 13 Aug '08

13 Aug '08

Hello, why are no GIT changes since 7 days? Exists a right problem with Microsoft? And what's with the planned 1.1.3? Best regards, thacrazze

3 2

dplayx tests hanging
by Dan Kegel 12 Aug '08

12 Aug '08

Hi Ismael, have a look at http://test.winehq.org/data/tests/dplayx:dplayx.html Since your commits on the 4th of Aug, the dplayx tests have been hanging. This is getting in the way of my regression testing. Can you have a look? Thanks, Dan

4 10

Patchwatcher online
by Dan Kegel 12 Aug '08

12 Aug '08

For the moment, the results only go to a web page, http://kegel.com/wine/patchwatcher/results/ Most of the results there right now are just test messages so you can see how it will look when real patches with various problems are received. The scripts are a bit ugly, so expect problems to linger for the next week or so while I work out the kinks.

8 26

patchwatcher online
by celticht32＠aol.com 12 Aug '08

12 Aug '08

couldn't you instead when the patchwatcher takes the patch it assigns it a patch # and require if there is a patch dependency? that the person put into a comment REQ_PATCH: 123456,15456, etc.. ? That way when a diff is done for the patch it would appear in the patch diff? Then patchwatcher would make sure thats in the tree if its accepted and if that req. patch was not accepted then the new patch is automatically rejected? Chris

3 3

Re: [advapi32] - Add stub for ConvertToAutoInheritPrivateObjectSecurity
by Dmitry Timoshkov 12 Aug '08

12 Aug '08

"Vijay Kiran Kamuju" <infyquest(a)gmail.com> wrote: > +BOOL WINAPI ConvertToAutoInheritPrivateObjectSecurity( > + PSECURITY_DESCRIPTOR ParentDescriptor, > + PSECURITY_DESCRIPTOR CreatorDescriptor, > + PSECURITY_DESCRIPTOR* NewDescriptor, > + GUID* ObjectType, > + BOOL IsDirectoryObject, > + PGENERIC_MAPPING GenericMapping ) > +{ > + FIXME("%p %p %p %p %d %p - stub\n", ParentDescriptor, CreatorDescriptor, > + NewDescriptor, ObjectType, IsDirectoryObject, GenericMapping); > + > + return FALSE; > +} It would be better to not copy variable names from MSDN/PSDK and come up with your own naming. Say, (parent, creator, new, type, is_directory, mapping) would work. > --- a/include/winbase.h > +++ b/include/winbase.h > @@ -1373,6 +1373,7 @@ WINBASEAPI HANDLE WINAPI CreateNamedPipeW(LPCWSTR,DWORD,DWORD,DWORD,DWORD,D > #define CreateNamedPipe WINELIB_NAME_AW(CreateNamedPipe) > WINBASEAPI BOOL WINAPI CreatePipe(PHANDLE,PHANDLE,LPSECURITY_ATTRIBUTES,DWORD); > WINADVAPI BOOL WINAPI > CreatePrivateObjectSecurity(PSECURITY_DESCRIPTOR,PSECURITY_DESCRIPTOR,PSECURITY_DESCRIPTOR*,BOOL,HANDLE,PGENERIC_MAPPING); > +WINADVAPI BOOL WINAPI > ConvertToAutoInheritPrivateObjectSecurity(PSECURITY_DESCRIPTOR,PSECURITY_DESCRIPTOR,PSECURITY_DESCRIPTOR*,GUID*,BOOL,PGENERIC_MAPPING); > WINBASEAPI BOOL WINAPI > CreateProcessA(LPCSTR,LPSTR,LPSECURITY_ATTRIBUTES,LPSECURITY_ATTRIBUTES,BOOL,DWORD,LPVOID,LPCSTR,LPSTARTUPINFOA,LPPROCESS_INFORMATION); > WINBASEAPI BOOL WINAPI > CreateProcessW(LPCWSTR,LPWSTR,LPSECURITY_ATTRIBUTES,LPSECURITY_ATTRIBUTES,BOOL,DWORD,LPVOID,LPCWSTR,LPSTARTUPINFOW,LPPROCESS_INFORMATION); > #define CreateProcess WINELIB_NAME_AW(CreateProcess) Please keep the entries alphabetically sorted. -- Dmitry.

2 1

Re: [TRY 3] Add tests for checking the parent notification for editcontrol
by Dmitry Timoshkov 12 Aug '08

12 Aug '08

"Ilya Shpigor" <shpigor(a)etersoft.ru> wrote: What is the difference between wpParent1 and wpParent2 besides slightly different indentation and 1 superfluous 'break' statement? > > - /* why do we notify to es->hwndParent, and we send this one to GetParent()? */ > > + /* All notifies are send to es->hwndParent > > + * except the WM_CTLCOLORSTATIC and WM_CTLCOLOREDIT. > > + * Its are send to the current parent. > > + */ > > hbrush = (HBRUSH)SendMessageW(GetParent(es->hwndSelf), msg, (WPARAM)hdc, (LPARAM)es->hwndSelf); > > if (!hbrush) > > hbrush = (HBRUSH)DefWindowProcW(GetParent(es->hwndSelf), msg, (WPARAM)hdc, (LPARAM)es->hwndSelf); > > This tests confirming my statement in the comment. If we change > GetParent(es->hwndSelf) to es->hwndParent the tests will be failed. I don't see the tests confirming the comment. Why are you adding the whole new message handling code to edit.c (which complicates things a lot, and makes it less clear what you are trying to do) while msg.c already has everything required, and it already contains the edit message tests? -- Dmitry.

1 0

Re: [TRY 2] Add tests for checking the parent notification for editcontrol
by Dmitry Timoshkov 12 Aug '08

12 Aug '08

"Ilya Shpigor" <shpigor(a)etersoft.ru> wrote: > - /* why do we notify to es->hwndParent, and we send this one to GetParent()? */ > + /* All notifies are send to es->hwndParent > + * except the WM_CTLCOLORSTATIC and WM_CTLCOLOREDIT. > + * Its are send to the current parent. > + */ > hbrush = (HBRUSH)SendMessageW(GetParent(es->hwndSelf), msg, (WPARAM)hdc, (LPARAM)es->hwndSelf); > if (!hbrush) > hbrush = (HBRUSH)DefWindowProcW(GetParent(es->hwndSelf), msg, (WPARAM)hdc, (LPARAM)es->hwndSelf); My question regarding this part left unanswered. Are there the tests confirming your statement in the comment? Also, please avoid adding not related message tests. If you are trying to show which parent receives the notification you need to create your own parent window procs or somehow tell an existing one to mark the notifications, so that it would be easy to distinguish the source of a notification. -- Dmitry.

1 0

Patch formatting question: how picky should the robot be?
by Dan Kegel 12 Aug '08

12 Aug '08

So, git generates patches like this: diff --git a/dlls/ddraw/tests/dsurface.c b/dlls/ddraw/tests/dsurface.c index da66e2e..4569997 100644 --- a/dlls/ddraw/tests/dsurface.c +++ b/dlls/ddraw/tests/dsurface.c and that's the way we like it. And sometimes people generate patches with cvs, like http://winehq.org/pipermail/wine-patches/2008-August/059403.html diff -u -3 -p -r1.57 vga.c --- dlls/winedos/vga.c 14 Jul 2008 10:57:58 -0000 1.57 +++ dlls/winedos/vga.c 27 Jul 2008 23:13:08 -0000 (That even used to be the way we liked it.) That's ok, too, isn't it? If so, I'll make sure my patch robot can handle it. But what about patches like http://winehq.org/pipermail/wine-patches/2008-August/059404.html --- dlls/appwiz.cpl/appwiz.rc 2008-07-26 09:24:56.000000000 +0900 +++ appwiz.rc 2008-07-28 09:48:00.000000000 +0900 ... --- /dev/null 2008-07-28 09:27:06.210506864 +0900 +++ Ko.rc 2008-07-28 09:48:00.000000000 +0900 The patch robot should probably complain about those, right? - Dan

3 3

Crashing tests for WinHttp
by Zac Brown 11 Aug '08

11 Aug '08

Hi all, Dan Kegel pointed out to me a couple of tests for WinHttp were reported as crashing in Wine, build 520ab5c26170 (the latest). Would the owners of machines "2000 wine-1.1.2" and "XP th" please shoot me an email. I'd like to see if I can reproduce the crash in wine. For better reference, its the machines in the first and last column on this page: http://test.winehq.org/data/520ab5c261706f6118a85a82ba84213932ba76e7/#group… Thanks, Zac

1 0

Is Wine portable to ARM arch?
by Tomasz Czapiewski 11 Aug '08

11 Aug '08

I wonder if someone has done successfull port of Wine for mobile/PDA Linux distributions on hardware with ARM processors. Is it possible? If no then are there any plans for multiplatform code in Wine? There are many Linux users of such hardware (like Neo FreeRunner etc.) which would like to use Windows applications on their portable ARM-based devices. Kind Regards, Tom

4 3

RE: [PATCH 04/10] ddraw/dsurface_thunks: Add typesafe inline conversion functions.
by Stefan Dösinger 11 Aug '08

11 Aug '08

> Do you see a chance to get such a change committed? It's hard to tell; I think you should ask Alexandre once he's back from vacation

1 0

Re: rpcrt4: Dynamically load iphlpapi
by Rob Shearman 11 Aug '08

11 Aug '08

2008/8/5 Juan Lang <juan.lang(a)gmail.com>: > This has a similar motivation to the last patch I sent. In rpcrt4's > case, iphlpapi is needed at most once per process, so dynamically load > it rather than keeping it around all the time. > @@ -304,18 +304,23 @@ #define ADDRESS_BYTES_NEEDED 6 > > static RPC_STATUS RPC_UuidGetNodeAddress(BYTE *address) > { > + static const WCHAR iphlpapi[] = { 'i','p','h','l','p','a','p','i',0 }; > int i; > DWORD status = RPC_S_OK; > > ULONG buflen = sizeof(IP_ADAPTER_INFO); > PIP_ADAPTER_INFO adapter = HeapAlloc(GetProcessHeap(), 0, buflen); > + HMODULE lib = LoadLibraryW(iphlpapi); > + DWORD (WINAPI *pGetAdaptersInfo)(PIP_ADAPTER_INFO, PULONG) = NULL; Hi Juan, Why manually load iphlpapi here instead of using the automatic delayed import mechanism like you used for ws2_32? I assume it was because you reasoned that a hard dependency was unnecessary because the code has a fallback path, but I think you needed to make this clear in the changelog. -- Rob Shearman

2 2

RE: [PATCH 04/10] ddraw/dsurface_thunks: Add typesafe inline conversion functions.
by Stefan Dösinger 11 Aug '08

11 Aug '08

I think it is better to replace the whole macros in ddcomimpl.h with inline functions. This is also what Alexandre asked for some time ago, but I was too lazy to implement it > -----Original Message----- > From: wine-patches-bounces(a)winehq.org [mailto:wine-patches- > bounces(a)winehq.org] On Behalf Of Michael Karcher > Sent: Sunday, August 10, 2008 4:20 PM > To: wine-patches(a)winehq.org > Subject: [PATCH 04/10] ddraw/dsurface_thunks: Add typesafe inline > conversion functions. > > These are going to replace the CONVERT/CONVERT_REV macros. > --- > dlls/ddraw/surface_thunks.c | 54 > +++++++++++++++++++++++++++++++++++++++++++ > 1 files changed, 54 insertions(+), 0 deletions(-)

1 0

RE: [PATCH 03/10] ddraw/surface: Made IDirectDrawSurfaceImpl methods non-static.
by Stefan Dösinger 11 Aug '08

11 Aug '08

I think you should put the things from surface_impl.h into ddraw_private.h > -----Original Message----- > From: wine-patches-bounces(a)winehq.org [mailto:wine-patches- > bounces(a)winehq.org] On Behalf Of Michael Karcher > Sent: Sunday, August 10, 2008 4:20 PM > To: wine-patches(a)winehq.org > Subject: [PATCH 03/10] ddraw/surface: Made IDirectDrawSurfaceImpl > methods non-static. > > This allows direct calls from surface_thunks.c. IMHO there is no point > in letting the call from the thunk to the implementation go through the > vtable again, unless we are going to use dynamic vtables. > --- > dlls/ddraw/surface.c | 85 +++++++++--------- > dlls/ddraw/surface_impl.h | 207 > +++++++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 250 insertions(+), 42 deletions(-) create mode > 100644 dlls/ddraw/surface_impl.h

1 0

Re: [AppDB] db_filter_ui: Use first filter option as default
by Winandy Hubert 11 Aug '08

11 Aug '08

Alexander Nicolaysen Sørnes schrieb: > Should be a little more user-friendly. > > > Alexander N. Sørnes > > > > __________ NOD32 3344 (20080810) Information __________ > > Diese E-Mail wurde vom NOD32 antivirus system geprüft > http://www.nod32.com > > ------------------------------------------------------------------------ > > Kann Anhang nicht öffnen Danke Winandy Hubert > > > > __________ NOD32 3344 (20080810) Information __________ > > Diese E-Mail wurde vom NOD32 antivirus system geprüft > http://www.nod32.com

1 0

Re: [Bug 14810] WinHttp needs to be implemented
by James Hawkins 11 Aug '08

11 Aug '08

On Sun, Aug 10, 2008 at 6:43 PM, <wine-bugs(a)winehq.org> wrote: > http://bugs.winehq.org/show_bug.cgi?id=14810 > > > --- Comment #4 from Erich Hoover <ehoover(a)mines.edu> 2008-08-10 18:43:16 --- > This whole DLL has a total of 27 functions, 14 of which are currently exposed, > and only 1 is "implemented". I put some work into implementing enough of the > DLL to get RA3 to authenticate and found that it needs 9 of the functions to > operate properly. I think it is reasonable to say that implementing the rest > of the functions for WinHttp would not be too difficult. I do not think that > this particular issue is anywhere close to a broad-spectrum "Win32 API needs to > be implemented". > Of course it's not the same scale as all of the Win32 API. It was an analogy illustrating why the bug is superfluous. On the other hand, you're vastly underestimating the amount of work needed to properly implement winhttp. You might want to chat with Zac Brown who is working on implementing winhttp right now. Also, please don't post in closed bugs. -- James Hawkins

4 9

Re: rpcrt4: [1/2] Improve stub for I_RpcBindingInqTransportType, with test
by Dmitry Timoshkov 10 Aug '08

10 Aug '08

Detlef Riekenberg <wine.dev(a)web.de> wrote: > @@ -848,6 +848,10 @@ RPC_STATUS WINAPI I_RpcBindingInqTransportType( RPC_BINDING_HANDLE Binding, unsi > { > > FIXME( "(%p,%p): stub\n", Binding, Type); > + > + /* NT: RPC_S_NO_CONTEXT_AVAILABLE, 9x: RPC_S_NO_CALL_ACTIVE */ > + if (!Binding) return RPC_S_NO_CONTEXT_AVAILABLE; According to your test this should be if (!Binding || !Type) return RPC_S_NO_CONTEXT_AVAILABLE; Also the comment doesn't belong here, it's ok to have in the test though. -- Dmitry.

2 1

Re: dplayx tests hanging
by Dan Kegel 10 Aug '08

10 Aug '08

On Sun, Aug 10, 2008 at 11:42 AM, Ismael Barros <razielmine(a)gmail.com> wrote: > You probably have installed in your wine prefix a windows native > dpwsockx.dll, and dplay gets that one instead of wine's builtin > dpwsockx. Seems to be (perhaps I did winetricks directx9). Removing ~/.wine seems to have helped. Don't know if that explains the two timeout reports on wine at test.winehq.org, but it seems likely. Sorry for not trying a clean .wine before writing. - Dan

1 0

Re: [6/11] ole32 : basic inprocess handler implentation
by Rob Shearman 10 Aug '08

10 Aug '08

2008/8/7 <f.dorin(a)free.fr>: > diff --git a/dlls/ole32/proxystub_obj.c b/dlls/ole32/proxystub_obj.c > new file mode 100644 > index 0000000..c229ad2 > --- /dev/null > +++ b/dlls/ole32/proxystub_obj.c > ... > +HRESULT __RPC_STUB IStorage_OpenStream_Stub( > + IStorage* This, > + LPCOLESTR pwcsName, > + unsigned long cbReserved1, > + byte *reserved1, > + DWORD grfMode, > + DWORD reserved2, > + IStream **ppstm) > +{ > + TRACE("(%p)->(%s, %d, %p, %x, %x, %p)\n", This, debugstr_w(pwcsName), (int)cbReserved1, reserved1, grfMode, reserved2, ppstm); > + return IStorage_OpenStream(This, pwcsName, reserved1, grfMode, reserved2, ppstm); > +} These should go into usrmarshal.c. However, Dan Hipschman as already done some work in this area so you might want to search for his patches on generating proxy/stub code for oleidl.idl and objidl.idl so that you don't do any more work than you have to. -- Rob Shearman

2 1

Re: [1/11] ole32 : basic inprocess handler implentation
by Rob Shearman 10 Aug '08

10 Aug '08

Hi François, I appreciate the work you've put into this and the other patches. However, I have a few comments: 2008/8/7 <f.dorin(a)free.fr>: > @@ -78,4 +83,11 @@ ole2nls.spec.o: ole2nls.spec version16.res > version16.res: version16.rc > $(LDPATH) $(RC16) $(RC16FLAGS) -fo$@ $(SRCDIR)/version16.rc > > +objidl_p.c: ../../include/objidl.idl > + $(WIDL) -p ../../include/objidl.idl > + > +oleidl_p.c: ../../include/oleidl.idl > + $(WIDL) -p ../../include/oleidl.idl > + sed -i '14i#include "winuser.h"' oleidl_p.c > + Custom make rules, such as these, are discouraged as they are a pain to maintain because they need to be changed all over the source tree instead of just in Make.rules.in. In this case they should be unnecessary as you can simply create IDL files in the ole32 directory (c.f. dlls/oleaut32/oleaut32_oaidl.idl) that include each of these (and in the second case, add the necessary include file). Also, it's a moot point but I don't think "sed -i" is portable. -- Rob Shearman

1 0

Re: Question: Why are EM_FORMATRANGE Tests 'To Do'
by James Mckenzie 10 Aug '08

10 Aug '08

Juan Lang <juan.lang(a)gmail.com> on Aug 9, 2008 8:27 PM (PNT) wrote additionally in reply to Question: Why are EM_FORMATRANGE Tests 'To Do' > >> Thank you for the clarification. Thus, I can run the pre-built executable on WindowsXP and there should be no richedit errors, correct? > >That's the theory :) The test don't run without error on my XP system, so YMMV. Then I should end up with errors on my WindowsXP system that match yours. I don't have time tonight to do so, but my find time tomorrow to run them. James McKenzie

2 1

Re: Question: Why are EM_FORMATRANGE Tests 'To Do'
by James Mckenzie 10 Aug '08

10 Aug '08

Juan Lang <juan.lang(a)gmail.com> on Aug 9, 2008 6:41 PM wrote about Question: Why are EM_FORMATRANGE Tests 'To Do' in reply to James McKenzie's question on this subject. > >Hi James, > >> Title states it all. I would like to compile tests to run against WindowsXP to see if the test will function. Could I un'to-do' this test and compile it with MinGW? > >todo_wine tests are always run, whether or not the todo_wine flag is >there. The only difference is how the results are interpreted: if >running on Wine (which the standalone tests assume they are not), the >test is assumed to fail, and an error reported if the test does not >fail as expected on Wine. If not running on Wine, they run as normal. Thank you for the clarification. Thus, I can run the pre-built executable on WindowsXP and there should be no richedit errors, correct? James McKenzie

2 1

Question: Why are EM_FORMATRANGE Tests 'To Do'
by James Mckenzie 10 Aug '08

10 Aug '08

Title states it all. I would like to compile tests to run against WindowsXP to see if the test will function. Could I un'to-do' this test and compile it with MinGW? Thank you. James McKenzie

2 1

Networking problems with IDU Verwaltung software
by Werner LEMBERG 09 Aug '08

09 Aug '08

[wine 1.1.2] [openSuSE 10.2, kernel 2.6.21-rc6] Folks, I try to make run a German software bundle called `IDU Verwaltung'. It seems to work, however, I can't make it to connect to a PostgreSQL database. I have enabled PostgreSQL access in my firewall. Interestingly, I couldn't find information how to debug networking problems with wine. Any links? Whatever, here my problem report. I tried on wine-users first, but the responses weren't really encouraging. I've executed WINEDEBUG=warn+all wine Idu_Verwaltung.exe 2> ~/winelog.warnall [within a fresh .wine, not installing any vcredist_x86.exe bundle -- doing this doesn't solve the `actctx' problem which is listed below, BTW] Doing cat winelog.warnall \ | grep -v 'c000003[45]' \ | grep -v 'not found' \ | grep -v 'case-insensitive' \ | grep -i -v 'failed to load' \ | grep -v 'cannot open' \ | grep -v 'no-exec' \ | grep -v 'Invalid handle' \ | grep -v 'font' \ | grep -v 'vkey' \ | grep -v 'keysyms' \ | grep -v 'Heap' \ | grep -v 'Bitmap' \ | grep -v 'GetDC' gives warn:sync:SetNamedPipeHandleState stub: 0x24 0x7edca5a8/2 (nil) (nil) warn:msvcrt:msvcrt_init_console :Console handle Initialisation FAILED! warn:class:CLASS_RegisterClass Win extra bytes 44 is > 40 warn:class:CLASS_RegisterClass Win extra bytes 44 is > 40 warn:winspool:WINSPOOL_GetDWORDFromReg Got ret = 2 on name dnsTimeout warn:winspool:WINSPOOL_GetDWORDFromReg Got ret = 2 on name txTimeout warn:winspool:WINSPOOL_GetDWORDFromReg Got ret = 2 on name dnsTimeout warn:winspool:WINSPOOL_GetDWORDFromReg Got ret = 2 on name txTimeout warn:mixer:getcomponenttype Unknown mixer name Capture Mux, probably harmless warn:mixer:getcomponenttype Unknown mixer name Capture Mux, probably harmless warn:class:CLASS_RegisterClass Win extra bytes 44 is > 40 warn:actctx:lookup_manifest_file no matching file for L"x86_Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_8.0.*.*_*.manife fixme:actctx:parse_depend_manifests Could not find dependent assembly L"Microsoft.VC80.CRT" warn:module:process_attach Initialization of L"MSVCR80.dll" failed warn:combo:ComboWndProc_common unknown msg WM_USER+ba10 wp=460001 lp=00030046 warn:file:CreateFileW Unable to create file L"\\\\.\\Z:" (status c0000022) warn:combo:ComboWndProc_common unknown msg WM_USER+ba10 wp=420001 lp=00060042 warn:combo:ComboWndProc_common unknown msg WM_USER+ba10 wp=4c0001 lp=0009004c warn:driver:CloseDriver Failed to close driver warn:driver:CloseDriver Failed to close driver warn:driver:CloseDriver Failed to close driver warn:driver:CloseDriver Failed to close driver warn:driver:CloseDriver Failed to close driver warn:profile:PROFILE_FlushFile No current profile! The only messages related to networking are those winspool things which doesn't say anything to me. Any idea how to proceed? Werner PS: In case you still have any FreeType issues in Wine, ask me :-)

7 13

Re: Make RegisterDeviceNotificationW behave likeRegisterDeviceNotificationA
by Martin Profittlich 09 Aug '08

09 Aug '08

Dmitry Timoshkov wrote: >"Zachary Goldberg" <zgold550 at gmail.com> wrote: > >> Your patch is more likely to be accepted if it comes with a test which >> works on windows, didnt pass in wine before but passes now and >> demonstrates why the new behavior is correct. > > There is no need for a test since that's not really an implementation > but just a better stub which follows existing code. So is there anything I should do now? Or just wait to see what happens? As for writing a test, I don't think that's possible. The affected apps don't crash inside that function but shortly afterwards. It's just that the crash is affected by the result of RegisterDeviceNotificationW. Wouldn't it also be more consistent, if *A and *W did the same thing? Martin -- GMX Kostenlose Spiele: Einfach online spielen und Spaß haben mit Pastry Passion! http://games.entertainment.gmx.net/de/entertainment/games/free/puzzle/61691…

2 1

Re: [1/11] ole32 : basic inprocess handler implentation
by Detlef Riekenberg 09 Aug '08

09 Aug '08

On Do, 2008-08-07 at 15:45 +0200, f.dorin(a)free.fr wrote: > This patch modifies the Makefile.in file to include some new file to be compile - You must use your real name - Wine must compile after every Patch. You need to add the changes for Makefile.in, when you add a file - Why do you need to use sed for winuser.h? When the input for widl is correct and the output of widl is wrong, then widl must be fixed instead. - You forgot the License-Header in the new files. Wine is LGPL. -- quote -- 2.1 of the License, or (at your option) any later version. -- quote -- - The subject is not very precise. You should use the description, that is already in your Mail. Example for [4/11]: "Main core file for inprocess handler implementation" - Some Patches are large, please try to split it. - Some lines in your Patches are very long, please try to split them. - Do not use C++ style comments - Wine is using 4 Space for indention. The only exception is to stay with the indention of File, when you touch that File - No Idea, if the change in 8/11 is acceptable, but you should a comment in the code, when you make such a change. - A Hack, to workaround a bug in widl will not be accepted. Widl must be fixed instead. - Unrelated to the fact, that the Hack in 10/11 will not be accepted, you must make sure, not add spaces at the end of a Line. - When you change the imlementation, that fix a test, then both changes must be in the same Patch Thanks for helping Wine -- By by ... Detlef

1 0

Re: taskmgr [try 4]: Converted some functions and variables to Unicode [1/7]
by Nikolay Sivov 09 Aug '08

09 Aug '08

Vladimir Pankratov wrote: > static void TaskManager_OnMenuSelect(HWND hWnd, UINT nItemID, UINT nFlags, HMENU hSysMenu) > { > - TCHAR str[100]; > + WCHAR wstr[256]; > + WCHAR wszEmptyStr[] = {' ',0}; > > - _tcscpy(str, TEXT("")); > - if (LoadString(hInst, nItemID, str, 100)) { > - /* load appropriate string */ > - LPTSTR lpsz = str; > - /* first newline terminates actual string */ > - lpsz = _tcschr(lpsz, '\n'); > - if (lpsz != NULL) > - *lpsz = '\0'; > - } > - SendMessage(hStatusWnd, SB_SETTEXT, 0, (LPARAM)str); > + strcpyW(wstr, wszEmptyStr); > + LoadStringW(hInst, nItemID, wstr, sizeof(wstr)/sizeof(WCHAR)); > + SendMessageW(hStatusWnd, SB_SETTEXTW, 0, (LPARAM)wstr); > } > > static void TaskManager_OnViewUpdateSpeedHigh(void) You really need a single space string passed as message parameter? If not - WCHAR wszEmptyStr[] = {0} - should be enough. And maybe it's better to initialize wstr to empty instead of using another variable.

1 0

Re: Is Wine portable to ARM arch?
by James Mckenzie 08 Aug '08

08 Aug '08

Lei Zhang <thestig(a)google.com> on Aug 8, 2008 10:58 AM (PNT) wrote about Is Wine portable to ARM arch? > >On Fri, Aug 8, 2008 at 10:39 AM, James Mckenzie ><jjmckenzie51(a)earthlink.net> wrote: >> NO! Even MacOSX specific code is not allowed > >grep -rI __APPLE__ wine-git/ | wc -l >returns 68. Correct, there is code that will only be used on when the system is an Apple (Mac). However, Mac specific code, such as ObjC code is not allowed per Alexandre. James McKenzie

4 5

Re: taskmgr [try 3]: Converted some functions and variables to Unicode [1/12]
by Nikolay Sivov 08 Aug '08

08 Aug '08

Vladimir Pankratov wrote: > - GetLastErrorText(strErrorText, 260); > + GetLastErrorText(wstrErrorText, sizeof(wstrErrorText)/sizeof(WCHAR)); The same as of try2. You changed argument type in patch 1/12 but function GetLastErrorText will change later in 12/12. So patches in series aren't not independent now cause after applying first you'll get broken GetLastErrorText call till you applied the last (12th). Changing call and a function should be placed in a single path.

1 0

Re: Is Wine portable to ARM arch?
by James Mckenzie 08 Aug '08

08 Aug '08

Tomasz Czapiewski <xeros(a)irc.pl> on Aug 8, 2008 10:05 AM (PNT) wrote about Is Wine portable to ARM arch? > >I wonder if someone has done successfull port of Wine for >mobile/PDA Linux distributions on hardware with ARM processors. No. >Is it possible? Very likely but you run into the following: 1. Windows programs are written for the x86 processor. Is there an x86 emulator for the ARM arch? 2. Windows programs are mostly written for a minimum of a 640 by 480 pixel display. I know of very few devices that run at that, or higher, resolution. 3. Are the ARM processors 'strong' enough to run both a x86 emulator AND Wine AND provide acceptable performance of many Windows programs. >If no then are there any plans for multiplatform code in Wine? NO! Even MacOSX specific code is not allowed >There are many Linux users of such hardware (like Neo FreeRunner etc.) >which would like to use Windows applications on their portable >ARM-based devices. Don't know. Most functions are provided by other systems. I know that Windows CE (aka Portable Windows) does exist for some handheld devices. The key is to get folks to write software for that platform. My point three above shows why Wine is written, mostly, for x86 devices. It would be nice to see Wine ported to other platforms. Technically, this is possible, however would it provide satisfactory performance as well is key to user satisfaction. James McKenzie

8 7

re: Patch checking robot coming
by Dan Kegel 08 Aug '08

08 Aug '08

Ambroz wrote: > To me, a script that builds just > every patch is a serious security flaw; I suppose it wouldn't > be very hard for someone to send a naughty patch > that would take control of your machine. True. > I suggest you make it build patches in a chroot > as a regular user, and copy over the chroot from a > template every time a new patch is being built. Sounds great. Want to implement that and send it my way? It'll take me a while to get the kinks worked out of the script, it'd be nice to have a hand with the chroot. - Dan

5 10

Re: user32: Add tests and fix for the edit control parent notification
by Dmitry Timoshkov 08 Aug '08

08 Aug '08

"Ilya Shpigor" <shpigor(a)etersoft.ru> wrote: > - /* why do we notify to es->hwndParent, and we send this one to GetParent()? */ > - hbrush = (HBRUSH)SendMessageW(GetParent(es->hwndSelf), msg, (WPARAM)hdc, (LPARAM)es->hwndSelf); > + /* We must send all notifies to es->hwndParent. > + * If es->hwndParent don't response, we call > + * DefWindowProcW of the current parent. > + */ > + > + hbrush = (HBRUSH)SendMessageW(es->hwndParent, msg, (WPARAM)hdc, (LPARAM)es->hwndSelf); > if (!hbrush) > hbrush = (HBRUSH)DefWindowProcW(GetParent(es->hwndSelf), msg, (WPARAM)hdc, (LPARAM)es->hwndSelf); > return hbrush; If you have changed the target in the SendMessage call, shouldn't you do the same for DefWindowProc? > + SendMessage( hwEdit, WM_PAINT, (WPARAM)GetDC( hwEdit ), 0 ); > + syscolor = GetPixel( GetDC( hwEdit ), PIXEL_X, PIXEL_Y ); > + > + SetParent( hwEdit, hwParent2 ); > + DestroyWindow( hwParent1 ); > + > + SendMessage( hwEdit, WM_PAINT, (WPARAM)GetDC( hwEdit ), 0 ); > + editcolor = GetPixel( GetDC( hwEdit ), PIXEL_X, PIXEL_Y ); > + > + ok( editcolor == syscolor, "Child color is wrong, child = %04x\n", editcolor ); > + > + DestroyWindow( hwEdit ); > + DestroyWindow( hwParent2 ); > +} You are leaking a DC in the test. From your fix it looks like you need to test the message sequences instead of the pixel color (which is not reliable). Same applies to your other patch. -- Dmitry.

1 0

Re: user32: DdeClientTransaction should return 0 in the last param forDDE_DATA
by Dmitry Timoshkov 08 Aug '08

08 Aug '08

"Jeff Latimer" <lats(a)yless4u.com.au> wrote: > --- a/dlls/user32/dde_client.c > +++ b/dlls/user32/dde_client.c > @@ -520,6 +520,7 @@ static WDML_QUEUE_STATE WDML_HandleRequestReply(WDML_CONV* pConv, MSG* msg, WDML > case WM_DDE_DATA: > UnpackDDElParam(WM_DDE_DATA, msg->lParam, &uiLo, &uiHi); > TRACE("Got the result (%08lx)\n", uiLo); > + if (ack) *ack = ERROR_SUCCESS; > > hsz = WDML_MakeHszFromAtom(pConv->instance, uiHi); > > diff --git a/dlls/user32/tests/dde.c b/dlls/user32/tests/dde.c > index 8ea0525..debbd20 100644 > --- a/dlls/user32/tests/dde.c > +++ b/dlls/user32/tests/dde.c > @@ -292,10 +292,7 @@ static void test_ddeml_client(void) > hdata = DdeClientTransaction(NULL, 0, conversation, item, CF_TEXT, XTYP_REQUEST, default_timeout, &res); > ret = DdeGetLastError(client_pid); > ok(ret == ERROR_SUCCESS, "Expected ERROR_SUCCESS, got %d\n", ret); > - todo_wine > - { > - ok(res == ERROR_SUCCESS, "Expected ERROR_SUCCESS, got %08x\n", res); > - } > + ok(res == ERROR_SUCCESS, "Expected ERROR_SUCCESS, got %08x\n", res); DdeClientTransaction is not supposed to return ERROR_SUCCESS in res. DDE_FNOTPROCESSED looks like a more appropriate value. Same for DdeGetLastError, DMLERR_NO_ERROR seems more reasonable in this case. Also IMO a more appropriate place to set ack to DDE_FNOTPROCESSED is WDML_HandleReply, so that all types of replies get covered. -- Dmitry.

2 5

Re: advapi32: Implement GetSecurityInfo. [take 3]
by Juan Lang 08 Aug '08

08 Aug '08

Hi Dan, + if (ppSecurityDescriptor) + *ppSecurityDescriptor = sd; + you leak sd in the (implicit) else block here. --Juan

3 6

Re: [TRY2]user32/tests: add tests for creating subclassed builtinclass windows
by Dmitry Timoshkov 08 Aug '08

08 Aug '08

"Hongbo Ni" <hongbo(a)njstar.com> wrote: > +static void test_builtin_class_subclassed(char *classA, WCHAR *classW); It is possible to avoid forward declarations by a proper function rearranging. Also please add 'const' to classA/W. > + > +static void test_all_builtin_classes_subclassed(void) > +{ > + int i, n, len; > + WCHAR classW[80]; 10 should be enough. > + CHAR *BUILTIN_CLASSES[MAX_BUILTIN_CLASSES] = { 'static const CHAR BUILTIN_CLASSES[][10]' as in the existing test would be better IMO. > + "Edit", > + "Button", > + "Static", > + "ComboBox", > + "ComboLBox", > + "ListBox", > + "#32770", /* dialog */ > + }; You forgot "ScrollBar" and some other builtin classes. > + > + for(i = 0; i < MAX_BUILTIN_CLASSES; i++) > + { > + len = strlen(BUILTIN_CLASSES[i]); > + for(n = 0; n < len; n++) classW[n] = BUILTIN_CLASSES[i][n]; > + classW[n] = 0; MultiByteToWideChar would be more appropriate here. > + test_builtin_class_subclassed(BUILTIN_CLASSES[i], classW); > + } > +} > + > +static void test_builtin_class_subclassed(char *classA, WCHAR *classW) > +{ > + HWND hwnd, hwnd2; > + WNDPROC oldproc; > + > + hwnd = CreateWindowExA(0, classA, NULL, WS_OVERLAPPEDWINDOW, CW_USEDEFAULT, > + CW_USEDEFAULT, 680, 260, NULL, NULL, NULL, 0); It would be helpful to actually test whether window has been created, and what type it has (ansi/unicode). Same is true for all similar cases. Otherwise the test looks good, and it passes for me under XP SP3. -- Dmitry.

2 1

Re: [8/11] ole32 : basic inprocess handler implentation
by Alistair Leslie-Hughes 07 Aug '08

07 Aug '08

<f.dorin(a)free.fr> wrote in message news:146439758.2397291218116816278.JavaMail.root@spooler1-g27.priv.proxad.net...> Modify the stub implementation of GetDestCtx, to "emulate" a local machine instead of a remote machine. This trick is needed to allow handle marshalling > + *pdwDestContext = MSHCTX_NOSHAREDMEM; //MSHCTX_DIFFERENTMACHINE;> c++ style comments are discouraged. Best Regards Alistair Leslie-Huges _________________________________________________________________ Shout your Messenger buddies to the movies http://www.livelife.ninemsn.com.au/compIntro.aspx?compId=4590

1 0

Re: Make RegisterDeviceNotificationW behave like RegisterDeviceNotificationA
by Zachary Goldberg 07 Aug '08

07 Aug '08

On 8/6/08, Martin Profittlich <martin.profittlich(a)gmx.de> wrote: > Hello! > > This patch fixes bug 14781 (http://bugs.winehq.org/show_bug.cgi?id=14781). > > Some Native Instruments apps like Kontakt 3 and Kore Player crash on startup, shortly after calling RegisterDeviceNotificationW(). This stub currently returns a 0 for failure. RegisterDeviceNotificationA() otoh returns a fake handle. This patch makes RegisterDeviceNotificationW() do this also. This makes both apps work. > > This is my first submission. Please let me know if the format is wrong or some important information is missing. > > Martin > -- > Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten > Browser-Versionen downloaden: http://www.gmx.net/de/go/browser > > > > > Martin, Your patch is more likely to be accepted if it comes with a test which works on windows, didnt pass in wine before but passes now and demonstrates why the new behavior is correct. --Zach

2 1

Re: taskmgr: Converted some functions and variables to Unicode
by Nikolay Sivov 07 Aug '08

07 Aug '08

Vladimir Pankratov wrote: > - if (DialogBox(hInst, MAKEINTRESOURCE(IDD_COLUMNS_DIALOG), hMainWnd, ColumnsDialogWndProc) == IDOK) > + if (DialogBoxW(hInst, (LPWSTR)MAKEINTRESOURCE(IDD_COLUMNS_DIALOG), hMainWnd, ColumnsDialogWndProc) == IDOK) Why not to use MAKEINTRESOURCEW?

1 0

Re: advapi32: Implement GetSecurityInfo. [take 2]
by Dmitry Timoshkov 07 Aug '08

07 Aug '08

"Dan Hipschman" <dsh(a)linux.ucla.edu> wrote: > +#include <assert.h> ... > DWORD WINAPI GetSecurityInfo( > HANDLE hObject, SE_OBJECT_TYPE ObjectType, > @@ -2718,8 +2735,44 @@ DWORD WINAPI GetSecurityInfo( > PSECURITY_DESCRIPTOR *ppSecurityDescriptor > ) > { > - FIXME("stub!\n"); > - return ERROR_BAD_PROVIDER; > + PSECURITY_DESCRIPTOR sd; > + NTSTATUS status; > + ULONG n1, n2; > + BOOL present, defaulted; > + > + status = NtQuerySecurityObject(hObject, SecurityInfo, NULL, 0, &n1); > + assert(status != STATUS_SUCCESS); > + if (status != STATUS_BUFFER_TOO_SMALL) > + return RtlNtStatusToDosError(status); My previous comments regarding assert() still apply. -- Dmitry.

3 3

RE: winex11.drv: recognize WGL_SWAP_METHOD_ARB wgl pixel format attribute.
by Stefan Dösinger 06 Aug '08

06 Aug '08

> WGL_SWAP_METHOD attribute is not handled. Explicitly skip it in > ConvertAttribWGLtoGLX and always return WGL_SWAP_UNDEFINED_ARB in > X11DRV_wglGetPixelFormatAttribivARB, because buffers are always in > undefined state after swap in GLX. There's GLX_OML_swap_method. It is supported on fglrx, and I think it is supported on the open source drivers as well

2 1

RE: winex11.drv: recognize WGL_SWAP_METHOD_ARB wgl pixel format attribute.
by Stefan Dösinger 06 Aug '08

06 Aug '08

> WGL_SWAP_METHOD attribute is not handled. Explicitly skip it in > ConvertAttribWGLtoGLX and always return WGL_SWAP_UNDEFINED_ARB in > X11DRV_wglGetPixelFormatAttribivARB, because buffers are always in > undefined state after swap in GLX. There's GLX_OML_swap_method. It is supported on fglrx, and I think it is supported on the open source drivers as well

1 0

Re: user32: Add test and fix for the error with edit control whose parentis desktop.
by Dmitry Timoshkov 06 Aug '08

06 Aug '08

"Ilya Shpigor" <shpigor(a)etersoft.ru> wrote: > +static void test_edit_parent_desktop_1(void) > +{ > + HWND hwEdit; > + HDC hdc; > + > + hwEdit = CreateWindowEx( 0, "EDIT", NULL, WS_CHILD | WS_OVERLAPPEDWINDOW | > WS_VISIBLE, 10, 10, 300, 300, GetDesktopWindow(), NULL, hinst, NULL); Formatting of the line above looks pretty much strange. Please try to keep the line length under 80 columns, and use consistent spacing. > + > + hdc = GetDC( hwEdit ); > + SendMessage( hwEdit, WM_PAINT, (WPARAM)GetDC( hwEdit ), 0 ); > + > + ok( GetPixel( hdc, PIXEL_X, PIXEL_Y ) != COLOR_DEF_EDIT, "Get incorrect parent device context handle: brush color > = %04x\n", GetPixel( hdc, PIXEL_X, PIXEL_Y ) ); Same here. > + > + DestroyWindow( hwEdit ); > +} In general this test proves nothing. -- Dmitry.

1 0

Re: d3dx9: Implementation of D3DXGetDeclLength
by H. Verbeet 06 Aug '08

06 Aug '08

2008/8/5 Luis Busquets <luis.busquets(a)ilidium.com>: > +static const D3DVERTEXELEMENT9 lc={0xFF,0,D3DDECLTYPE_UNUSED,0,0,0}; What do you use this for? > + while ((pdecl+i)->Stream!=0xFF) > + { > + i++; You might as well increment pdecl itself. Also keep in mind that Alexandre won't be back before the 18th, so no patches will be applied before that either.

2 1

Re: taskmgr [try 2]: Converted some functions and variables to Unicode [1/12]
by Nikolay Sivov 06 Aug '08

06 Aug '08

Vladimir Pankratov wrote: > - TCHAR strErrorText[260]; > + WCHAR wstrErrorText[0x400]; Why do you use word format for size constant? Btw, is it normal that it's changed 260 -> 1024? > - GetLastErrorText(strErrorText, 260); > + GetLastErrorText(wstrErrorText, sizeof(wstrErrorText)/sizeof(WCHAR)); You've patched GetLastErrorText in your patch 12. But you changed calls to use WCHAR argument before this. That's why previous patches are broken I think. you should change function and all related calls of it in a single patch.

1 0

Re: [PATCH] oleaut32: Fix some corner cases in VarBstrCmp.
by Alexandre Julliard 06 Aug '08

06 Aug '08

"Lei Zhang" <thestig(a)google.com> writes: > diff --git a/dlls/oleaut32/vartype.c b/dlls/oleaut32/vartype.c > index daeac85..713ebae 100644 > --- a/dlls/oleaut32/vartype.c > +++ b/dlls/oleaut32/vartype.c > @@ -6942,7 +6942,24 @@ HRESULT WINAPI VarBstrCmp(BSTR pbstrLeft, BSTR pbstrRight, LCID lcid, DWORD dwFl > if (!pbstrLeft || !*pbstrLeft) > { > if (!pbstrRight || !*pbstrRight) > - return VARCMP_EQ; > + { > + UINT ll; > + UINT lr; > + > + if (lcid) > + { > + ll = SysStringLen(pbstrLeft); > + lr = SysStringLen(pbstrRight); > + } > + else > + { > + ll = SysStringByteLen(pbstrLeft); > + lr = SysStringByteLen(pbstrRight); > + } > + if (ll == lr) > + return VARCMP_EQ; > + return ll < lr ? VARCMP_LT : VARCMP_GT; > + } That's ugly, you shouldn't need such special handling here, you should simply fall through to the normal comparisons which should give the correct results. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: d3dx9: Implementation of D3DXMatrixDecompose 2/2
by David Adam 05 Aug '08

05 Aug '08

Hi, some remarks + if (((*poutscale).x==0)||((*poutscale).y==0)||((*poutscale).z==0)) should be + if ((poutscale->x==0)||(poutscale->y==0)||(poutscale->z==0)) No need to redefine a module fonction Replace + poutscale->x=module(pM->m[0][0],pM->m[0][1],pM->m[0][2]); by + poutscale->x=D3DXVec3Length(&D3DXVECTOR3((pM->m[0][0],pM->m[0][1],pM->m[0][2])); David 2008/8/5 Luis Busquets <luis.busquets(a)ilidium.com> > Please be aware that this function relies on D3DXQuaternionRotationMatrix > and therefore the bug in the latter has to be corrected. > > --- > dlls/d3dx9_36/d3dx9_36.spec | 2 +- > dlls/d3dx9_36/math.c | 39 ++++++++++++++++++++++++++ > dlls/d3dx9_36/tests/math.c | 64 > +++++++++++++++++++++++++++++++++++++++++++ > include/d3dx9math.h | 1 + > 4 files changed, 105 insertions(+), 1 deletions(-) > > > >

2 1

Vacation
by Alexandre Julliard 05 Aug '08

05 Aug '08

Folks, I'm leaving on vacation, so there won't be any commits for a while. Of course thanks to git that shouldn't prevent you from filling my mailbox with patches... I'll be back on the 18th, and release 1.1.3 will thus be on the 22nd. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: [WineHQ] [4/4] news: Remove the 'Weekly Newsletters' box from the home page.
by Zachary Goldberg 05 Aug '08

05 Aug '08

On Mon, Aug 4, 2008 at 9:28 AM, Francois Gouget <fgouget(a)free.fr> wrote: > --- > > So assuming that all the previous patches were miraculously correct, then, > as discussed on wine-devel, we don't need the 'Weekly Newsletters' box > anymore. > > site | 6 ------ > 1 files changed, 0 insertions(+), 6 deletions(-) > > > > I'm still not 100% convinced removing this box altogether is the right idea. Making the box smaller (via taking out the indicies) might still achieve the same purpose of de-cluttering while still providing a repository of links to recent WWNs. Also, we should add a link in the main menu to http://winehq.org/?issue=back.

3 3

Re: [dplayx 01/12] Tests for CreateGroup
by Paul Vriens 05 Aug '08

05 Aug '08

Ismael Barros wrote: > Tests for CreateGroup > Fixed the implementation of CreateGroup and CreateGroupInGroup so that > it doesn't segfault when the service provider is not initialized > > --- > dlls/dplayx/dplay.c | 10 ++ > dlls/dplayx/tests/dplayx.c | 340 ++++++++++++++++++++++++++++++++++++++++++++ > 2 files changed, 350 insertions(+), 0 deletions(-) > > > ------------------------------------------------------------------------ > > Hi Ismael, On what Windows version are you running your tests for verification? Is there anything particular you are doing to speed up the tests on your box? test.winehq.org already shows timeouts for all boxes that are running W2K or higher. This new patch serie will even add more tests but I'm afaid we will not see any output from it on the mentioned website. -- Cheers, Paul.

2 1

Re: [1/2] user32: Add a test for ToUnicode (try 5)
by Paul Vriens 05 Aug '08

05 Aug '08

Andre Wisplinghoff wrote: > Wrapping was still wrong. Sorry for that. Just using attachments now. > > dlls/user32/tests/input.c | 37 +++++++++++++++++++++++++++++++++++++ > 1 files changed, 37 insertions(+), 0 deletions(-) > > > ------------------------------------------------------------------------ > > Just some things that caught my attention: Could you trim the length for some of the lines somewhat? I also don't think you need all those comments in the first call to ToUnicode. There is a C++ comment in the patch, should be avoided. And as a last one, is it possible to use names instead of magic constants? -- Cheers, Paul.

2 1

Re: [2/2] user32:focus.c Remove unneeded palette messages.
by Dmitry Timoshkov 05 Aug '08

05 Aug '08

"Anatoly Lyutin" <vostok(a)etersoft.ru> wrote: > I run test-cases on 98 and XP and I can not see where this messages have > been posted in tests. In Wine this messages have not processing. > > Does anybody something know about this? Try to run the tests in a paletted (256 color) mode. -- Dmitry.

2 1

Re: msxml3: Add ISAXContentHandler_endPrefix event (1/7)
by Alexandre Julliard 05 Aug '08

05 Aug '08

Piotr Caban <piotr.caban(a)gmail.com> writes: > +static HRESULT namespacePush(saxlocator *locator, int ns) > +{ > + if(locator->nsStackLast+1>locator->nsStackSize) > + { > + locator->nsStackSize += STACKALLOCATIONSIZE; > + locator->nsStack = HeapReAlloc(GetProcessHeap(), 0, > + locator->nsStack, locator->nsStackSize); > + if(!locator->nsStack) return E_FAIL; You should preserve the existing stack on failure. Also the growth should be by a multiple of the current size instead of a constant. -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: d3dx9: Implementation of D3DXMatrixDecompose and tests
by tony.wasserka＠freenet.de 05 Aug '08

05 Aug '08

Hi, 1. The order of + /*The components of the translation transformation vector are straigth in the fourth column of the transformation matrix*/ + (*pouttranslation).x=(*pM).m[3][0]; + (*pouttranslation).y=(*pM).m[3][1]; + (*pouttranslation).z=(*pM).m[3][2]; + + /*Let's calculate rotation now*/ + /*If some of the scale factors is zero, it is impossible to obtain the rotation*/ + if (((*poutscale).x==0)||((*poutscale).y==0)||((*poutscale).z==0)) + { + return D3DERR_INVALIDCALL; + } should be reversed, as we want to return D3DERR_INVALIDCALL as soon as possible (if needed). Also, the whole code can be simplified to: + /*If some of the scale factors is zero, it is impossible to obtain the rotation*/ + if ((poutscale->x==0)||(poutscale->y==0)||(poutscale->z==0)) + return D3DERR_INVALIDCALL; + + /*The components of the translation transformation vector are straigth in the fourth column of the transformation matrix*/ + pouttranslation->x=pM->m[3][0]; + pouttranslation->y=pM->m[3][1]; + pouttranslation->z=pM->m[3][2]; + + /*Let's calculate rotation now*/ (Note the removed {} which saves two lines of code) 2. I haven't tested this, but if you haven't done so yet, you should check the function's behavior if one of the pointers is NULL. If it segfaults with native d3dx9_36, your code is okay, otherwise you'll need an additional check right at the beginning. 3. Also, there were some spelling mistakes: + /*The scale factors are the modules of the three vectors __of that__ lie in __the__ column of the 3x3 submatrix*/ + /*The scale factors are the modules of the three vectors __which__ lie in __each__ column of the 3x3 submatrix*/ + /*If some of the scale factors is zero, it is impossible to obtain the rotation*/ + /*If __any scale factor__ is zero, it is impossible to obtain the rotation*/ + /*Then we go for the biggest component in order to __minimise__ division error as commonly explained in the __literacy__. + We just calculate one component from the diagonal to avoid sign loss of the square root. The first sign is not important + because the rotations (x,y,z,w) and (-x,-y,-z,-w) are equivalent. But if we __calc ulated__ the other two components we would have + to choose and could be wrong.*/ + /*Then we go for the biggest component in order to __minimize__ division error as commonly explained in the __literature__. + We just calculate one component from the diagonal to avoid sign loss of the square root. The first sign is not important + because the rotations (x,y,z,w) and (-x,-y,-z,-w) are equivalent. But if we __calculated__ the other two components we would have + to choose and could be wrong.*/ 4. Regarding the test, you should perhaps explain in a one-line comment what's special about the tested numbers in comparison to the others (other sign? invalid numbers? etc.) 5. It's not bad, but for the future you may want to split the implementation and the test in two patches so that you have a greater chance to get one of them in. Best regards, Tony Unbegrenzter Speicher, Top-Spamschutz, 120 SMS und eigene E-MailDomain inkl. http://office.freenet.de/dienste/emailoffice/produktuebersicht/power/mail/i…

1 0

Re: [NJS#80583] Re: ntdll: import dll from dir of referring dll if not found instandard locations
by Dmitry Timoshkov 05 Aug '08

05 Aug '08

"Hongbo Ni" <hongbo(a)njstar.com> wrote: > I have posted a another patch regarding to windows hook into another > process. > http://www.winehq.org/pipermail/wine-patches/2008-August/059069.html > > Basically it change LoadlibraryW to LoadlibraryExW with Alt-path. > > Could you please let me know what your comment and guide me in coding > such test case? > > Basically the test need to inject 2 dlls into another process (say Notepad) > using SetWindowsHookEx(), and have some way to know if the dlls are > loaded by the target process. > > I can code the dll so it will send a message back to my test window to > inform me that they are loaded into Notepad. > > For those 2 DLLS, I have already made it on windows, How and where > can I add to wine test? > > Do I need submit the source and make file of those 2 dlls for maketest? > I am not sure how maketest create window DLL for auto-testing. Due to some problems there is no way to create an ELF wrapped hook dll using Wine tools. I'd suggest to create maximally stripped down test which works under Windows, and post an url to it with your fix. -- Dmitry.

1 0

Re: advapi32: Implement GetSecurityInfo.
by Dmitry Timoshkov 05 Aug '08

05 Aug '08

"Dan Hipschman" <dsh(a)linux.ucla.edu> wrote: > +#include <assert.h> ... > @@ -2718,8 +2719,38 @@ DWORD WINAPI GetSecurityInfo( > PSECURITY_DESCRIPTOR *ppSecurityDescriptor > ) > { > - FIXME("stub!\n"); > - return ERROR_BAD_PROVIDER; > + SECURITY_DESCRIPTOR *sd; > + NTSTATUS status; > + ULONG n1, n2; > + > + status = NtQuerySecurityObject(hObject, SecurityInfo, NULL, 0, &n1); > + assert(status != STATUS_SUCCESS); > + if (status != STATUS_BUFFER_TOO_SMALL) > + return RtlNtStatusToDosError(status); assert() (or rather ok(0)) would be appropriate in the test case, but not in the implementation IMO. -- Dmitry.

1 0

Re: d3dx9: Implementation of D3DXGetVertexShaderProfile 2/2 try 4
by Ivan Gyurdiev 05 Aug '08

05 Aug '08

Luis Busquets wrote: > + if ((caps.VS20Caps.NumTemps>=13) && > + (caps.VS20Caps.DynamicFlowControlDepth=24) && > + (caps.VS20Caps.Caps&D3DPS20CAPS_PREDICATION)) > + { > + return "vs_2_a"; > + } Please re-check - the second condition is an assignment and always true. - Ivan

1 0

Re: [4/10] WineD3D: Implement overlay position tracking
by H. Verbeet 04 Aug '08

04 Aug '08

2008/8/4 Stefan Dösinger <stefan(a)codeweavers.com>: > and will be done in another patch wave. > About those... could you spread them out a bit? It's quite a bit of code to review, and right now I probably don't look as close as I probably should.

2 1

Re: [1/10] WineD3D: Call glFlush outside the GL lock
by H. Verbeet 04 Aug '08

04 Aug '08

2008/8/4 Stefan Dösinger <stefan(a)codeweavers.com>: > + /* No checkGLcall here to avoid locking the lock just for checking a call that hardly ever > + * fails > + */ I think explaining why there's no ENTER_GL()/LEAVE_GL() is more important there.

2 1

What to do with tests that run for ages (examples dplayx and msi/install)
by Paul Vriens 04 Aug '08

04 Aug '08

Hi, The recent additions to the dplayx tests make these tests run very slow (or there is just a lot tested?). Is there a way to either split up these tests so they don't timeout or better yet find out if we can run them faster. This issue can be seen on W2K upwards. The same can be said about the msi/install tests. This however only seems to be an issue on XP and Vista. -- Cheers, Paul.

5 5

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