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

Re: ddraw fix for incorrect return value from wined3d take 3.
by Roderick Colenbrander Aug. 12, 2006

Aug. 12, 2006

Hi, One small comment regarding your patch make sure that you use the same indentation as the rest of the ddraw code. The ddraw code seems to use 4 spaces for a tab and I think your editor is configured to use tabs. Regards, Roderick Colenbrander > The new test cases crashes under wine but not under > windows. The fix for test cases crash is to initialize > the vertexbuffer to NULL when unsuccessful. > > This patch should be used rather then previous one. > > thx > Index: dlls/ddraw/direct3d.c =================================================================== RCS file: /home/wine/wine/dlls/ddraw/direct3d.c,v retrieving revision 1.9 diff -u -r1.9 direct3d.c --- dlls/ddraw/direct3d.c 9 Aug 2006 11:04:37 -0000 1.9 +++ dlls/ddraw/direct3d.c 11 Aug 2006 22:47:16 -0000 @@ -992,8 +992,11 @@ { ERR("(%p) IWineD3DDevice::CreateVertexBuffer failed with hr=%08lx\n", This, hr); HeapFree(GetProcessHeap(), 0, object); + *VertexBuffer = NULL; if (hr == WINED3DERR_INVALIDCALL) return DDERR_INVALIDPARAMS; + if (hr == WINED3DERR_OUTOFVIDEOMEMORY) + return D3DERR_TOOMANYVERTICES; else return hr; } -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer

1 0

Re: wininet: Support http_proxy environment variable
by Augusto Arcoverde da Rocha Aug. 11, 2006

Aug. 11, 2006

Exists a opened bug report about the problem which this patch is suposed to fix: http://bugs.winehq.org/show_bug.cgi?id=5625 Can someone give some comments for what this pach wasn't applied? Thanks, Augusto Arcoverde da Rocha

5 10

Re: [UPDATE] RFC: XEmbed System Tray Patches
by Juan Lang Aug. 11, 2006

Aug. 11, 2006

Hi James, thanks for taking this up. I'd like to have nice docked system tray icons, too. Some small nits on your patches: + wine_tsx11_lock(); + /* set XEMBED protocol data on the window */ + info[0] = 0; /* protocol version */ + info[1] = 1; /* mapped = true */ + XChangeProperty( display, data->whole_window, + x11drv_atom(_XEMBED_INFO), + x11drv_atom(_XEMBED_INFO), 32, PropModeReplace, + (unsigned char*)info, 2); + + /* send the docking request message */ + ZeroMemory( &ev, sizeof(ev) ); + ev.xclient.type = ClientMessage; + ev.xclient.window = systray_window; + ev.xclient.message_type = x11drv_atom(_NET_SYSTEM_TRAY_OPCODE); + ev.xclient.format = 32; + ev.xclient.data.l[0] = CurrentTime; + ev.xclient.data.l[1] = SYSTEM_TRAY_REQUEST_DOCK; + ev.xclient.data.l[2] = data->whole_window; + ev.xclient.data.l[3] = 0; + ev.xclient.data.l[4] = 0; + XSendEvent( display, systray_window, False, NoEventMask, &ev ); + wine_tsx11_unlock(); You do more with the lock held than you need to. Initializing info and ev could both be down without holding the lock. diff --git a/include/wine/server_protocol.h b/include/wine/server_protocol.h index b8c8a7c..3b4bd08 100644 --- a/include/wine/server_protocol.h +++ b/include/wine/server_protocol.h @@ -2741,6 +2741,7 @@ struct set_window_pos_reply { struct reply_header __header; unsigned int new_style; + unsigned int ex_style; }; This diff should be against server/protocol.def, not against server_protocol.h. diff --git a/dlls/winex11.drv/window.c b/dlls/winex11.drv/window.c index b26e14f..69c32ef 100644 --- a/dlls/winex11.drv/window.c +++ b/dlls/winex11.drv/window.c @@ -400,6 +400,13 @@ static void systray_dock_window( Display ev.xclient.data.l[3] = 0; ev.xclient.data.l[4] = 0; XSendEvent( display, systray_window, False, NoEventMask, &ev ); + + /* This XSync call is needed to properly send the message to the + * systray window and is required to have icon docking work properly. + * Furthermore, an XSync is shown in an example of how to send proper + * docking messages, see the XEmbed system tray spec for more + * information. */ + XSync(display, False); Why not include this in the original patch (0005 in the series?) --Juan __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

3 2

Wine and Photoshop in news
by Vijay Kiran Kamuju Aug. 11, 2006

Aug. 11, 2006

Check this link out Its about Wine and Photoshop compatibility. http://www.manilastandardtoday.com/?page=business05_aug01_2006 Can we also try to improve the photoshop compatibility with wine. Today will download the demo and try it on wine current git.

4 5

Re: [wintrust.h] Added some missing struct variables
by Paul Vriens Aug. 11, 2006

Aug. 11, 2006

On Fri, 2006-08-11 at 16:40 +0200, Paul Vriens wrote: > Hi, > > our struct was missing some variables. > > Changelog > Added some missing struct variables > > Cheers, > > Paul > --- > include/wintrust.h | 2 ++ > 1 files changed, 2 insertions(+), 0 deletions(-) > > diff --git a/include/wintrust.h b/include/wintrust.h > index d490ac9..0230dee 100644 > --- a/include/wintrust.h > +++ b/include/wintrust.h > @@ -254,6 +254,8 @@ typedef struct _CRYPT_PROVIDER_DATA { > HCRYPTMSG hMsg; > DWORD csSigners; > CRYPT_PROVIDER_SGNR *pasSigners; > + DWORD csProvPrivData; > + CRYPT_PROVIDER_PRIVDATA *pasProvPrivData; > DWORD dwSubjectChoice; > union { > struct _PROVDATA_SIP *pPDSip; Hi, please wait with this one. There appears to be some differences in the structure for w2k/winxp (and others?). Cheers, Paul.

1 0

Re: kernel32: redirect GetNativeSystemInfo to GetSystemInfo
by Alexandre Julliard Aug. 11, 2006

Aug. 11, 2006

Robert Reif <reif(a)earthlink.net> writes: > --- dlls/kernel/kernel32.spec 21 Jun 2006 13:03:23 -0000 1.175 > +++ dlls/kernel/kernel32.spec 11 Aug 2006 01:51:02 -0000 > @@ -546,7 +546,7 @@ > @ stdcall GetNamedPipeHandleStateA(long ptr ptr ptr ptr str long) > @ stdcall GetNamedPipeHandleStateW(long ptr ptr ptr ptr wstr long) > @ stdcall GetNamedPipeInfo(long ptr ptr ptr ptr) > -# @ stub GetNativeSystemInfo > +@ stdcall GetNativeSystemInfo(ptr) GetSystemInfo There's a bit more to it than that, so we probably want to print a FIXME for this one. -- Alexandre Julliard julliard(a)winehq.org

1 0

[wintrust.h] Added some missing struct variables
by Paul Vriens Aug. 11, 2006

Aug. 11, 2006

Hi, our struct was missing some variables. Changelog Added some missing struct variables Cheers, Paul --- include/wintrust.h | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/include/wintrust.h b/include/wintrust.h index d490ac9..0230dee 100644 --- a/include/wintrust.h +++ b/include/wintrust.h @@ -254,6 +254,8 @@ typedef struct _CRYPT_PROVIDER_DATA { HCRYPTMSG hMsg; DWORD csSigners; CRYPT_PROVIDER_SGNR *pasSigners; + DWORD csProvPrivData; + CRYPT_PROVIDER_PRIVDATA *pasProvPrivData; DWORD dwSubjectChoice; union { struct _PROVDATA_SIP *pPDSip; -- 1.4.1.1

1 0

Re: winhelp: fix LZ77 decompressor patch: what's wrong?
by HolyLich Aug. 11, 2006

Aug. 11, 2006

В сообщении от Friday 11 August 2006 17:17 вы написали: > 2006/8/11, HolyLich <lich(a)math.spbu.ru>: > > I've sent patch several times, but it has not been applied. > > Why not use memmove() instead? > Heh, this problem was discussed before http://www.winehq.org/pipermail/wine-devel/2006-August/050133.html, http://www.winehq.org/pipermail/wine-devel/2006-August/050139.html http://www.winehq.org/pipermail/wine-devel/2006-August/050141.html. memmove cannot be used because it provides other functionality - it doesn't suit LZ77 memcpy cannot be used because it's too clever (copies INTs instead of BYTEs), so doesn't suit LZ77 Solution: while (len--) *dst++=*src++; // The simplies way of memcpy Any more suggestion of bad patch? --HolyLich

2 1

winhelp: fix LZ77 decompressor patch: what's wrong?
by HolyLich Aug. 11, 2006

Aug. 11, 2006

Hi, I've sent patch several times, but it has not been applied. Patch is reasonable, MIME type is OK. patch -p0 < mbox works ;-) (as recommended at http://winehq.org/site/docs/winedev-guide/style-notes) Please, tell what I must do to this patch to be applied? Thanks a lot -- HolyLich Subject: [RESENDv2] winhelp: fix LZ77 decompressor Date: Thursday 10 August 2006 14:21 From: HolyLich <lich(a)math.spbu.ru> To: wine-patches(a)winehq.org Hi, This patch fixes a bug in LZ77 decompressor which affected only large (>0x1000) compressed embedded files, e.g. images (metafiles). I've never noticed it corrupting small images, but it may. I sent this patch before but messed with MIME. Now it's OK. ChangeLog: winhelp: Fix LZ77 decompressor -------------------------------------------------------

3 2

Rooms for Wineconf - Please act now
by Jeremy White Aug. 11, 2006

Aug. 11, 2006

Hi Folks, I know that Wineconf is still over a month away, but you'll really regret it if you don't make your accomodation selections now. If you paypal (or even arrange to mail a check) to me *now*, you'll get to hang out with all the cool people, on campus, and learn what the "Drink-making facilities on each corridor" really means, all for the low low price of about 40 pounds (okay, so the exchange rate sucks, and that's $75 US, but still...) If you *don't* get me an room request in the next few days, then I'll have to close down our room reservation, and you'll be stuck in some sleazy motel on the edge of town paying outrageous sums of of money. (Okay, they actually all look like nice places to stay, but they will be a ways away, and they all cost more :-/). Again, see this page for more details: http://www.winehq.org/site/wineconf/travel If you can't do Paypal, I can take a check in US currency as well. Cheers, Jeremy

6 9

Re: wldap32: Write-strings warning fix
by Hans Leidekker Aug. 11, 2006

Aug. 11, 2006

On Friday 11 August 2006 00:58, Andrew Talbot wrote: > -INT CDECL ber_printf(BerElement*,PCHAR,...); > +INT CDECL ber_printf(BerElement*,LPCSTR,...); This is an API defined by Microsoft, we can't change its prototype. -Hans

2 1

patch feedback?
by Damjan Jovanovic Aug. 11, 2006

Aug. 11, 2006

Hi I've tried submitting a patch to wine-patches 3 times now in the past 3 weeks, and not only has it not been applied, but I never even got any feedback. Please tell me what I am doing wrong. The latest patch is below. Thank you Damjan --- Damjan Jovanovic <dj015(a)yahoo.com> wrote: > Date: Thu, 3 Aug 2006 23:49:11 -0700 (PDT) > From: Damjan Jovanovic <dj015(a)yahoo.com> > To: wine-patches(a)winehq.org > Subject: setupapi: test+patch for > SetupDiOpenClassRegKeyExW (try 3) > > wine's SetupDiOpenClassRegKeyExW returns FALSE > instead > of INVALID_HANDLE_VALUE in several places, and > doesn't > brace the GUID string like it should. The test > reveals > these problems, and the patch fixes them. > > ChangeLog: > * Fixed returns values, braced GUID string, and > added > a test, for SetupDiOpenClassRegKeyExW. > > Damjan Jovanovic (dj015(a)yahoo.com) > > > a/dlls/setupapi/tests/Makefile.in 2006-07-10 > 18:01:08.000000000 +0200 > +++ b/dlls/setupapi/tests/Makefile.in 2006-08-04 > 16:15:05.000000000 +0200 > @@ -3,7 +3,7 @@ > SRCDIR = @srcdir@ > VPATH = @srcdir@ > TESTDLL = setupapi.dll > -IMPORTS = setupapi kernel32 > +IMPORTS = setupapi kernel32 advapi32 rpcrt4 > > CTESTS = \ > devinst.c \ > --- a/dlls/setupapi/tests/devinst.c 2006-08-03 > 10:07:11.000000000 +0200 > +++ b/dlls/setupapi/tests/devinst.c 2006-08-04 > 17:57:57.000000000 +0200 > @@ -27,6 +27,7 @@ > #include "winuser.h" > #include "winreg.h" > #include "setupapi.h" > +#include "rpc.h" > > #include "wine/test.h" > > @@ -63,7 +64,85 @@ > ok(ret, "SetupDiDestroyDeviceInfoList failed : > %ld\n", error); > } > > +static void test_SetupDiOpenClassRegKeyExW() > +{ > + GUID guid; > + RPC_STATUS rpcStatus; > + HKEY hkey; > + WCHAR *unbracedGuid; > + WCHAR *bracedGuid; > + > + rpcStatus = UuidCreate(&guid); > + if (rpcStatus != RPC_S_OK) > + { > + ok(FALSE, "failed to generate test guid, > error %ld", rpcStatus); > + return; > + } > + > + /* Check return value for non-existant key */ > + hkey = SetupDiOpenClassRegKeyExW(&guid, > KEY_ALL_ACCESS, > + DIOCR_INSTALLER, NULL, NULL); > + ok(hkey == INVALID_HANDLE_VALUE, > + "invalid return value %p from > SetupDiOpenClassRegKeyExW " > + "for non-existant key, expected %p\n", > hkey, INVALID_HANDLE_VALUE); > + > + rpcStatus = UuidToStringW(&guid, > &unbracedGuid); > + if (rpcStatus != RPC_S_OK) > + { > + ok(FALSE, "failed to get string form of > guid, error %ld", rpcStatus); > + return; > + } > + > + bracedGuid = HeapAlloc(GetProcessHeap(), 0, > + (lstrlenW(unbracedGuid) + 3) * > sizeof(WCHAR)); > + if (bracedGuid != NULL) > + { > + HKEY classesKey; > + > + bracedGuid[0] = (WCHAR) '{'; > + memcpy(&bracedGuid[1], unbracedGuid, > + lstrlenW(unbracedGuid) * > sizeof(WCHAR)); > + bracedGuid[1 + lstrlenW(unbracedGuid)] = > (WCHAR) '}'; > + bracedGuid[1 + lstrlenW(unbracedGuid) + 1] > = (WCHAR) 0; > + > + SetLastError(0xdeadbeef); > + classesKey = > SetupDiOpenClassRegKeyExW(NULL, KEY_ALL_ACCESS, > + DIOCR_INSTALLER, NULL, NULL); > + ok(classesKey != INVALID_HANDLE_VALUE, > + "failed to open the device classes > registry key: error %ld\n", > + GetLastError()); > + if (classesKey != INVALID_HANDLE_VALUE) > + { > + DWORD ret; > + HKEY classKey; > + ret = RegCreateKeyW(classesKey, > bracedGuid, &classKey); > + if (ret == ERROR_SUCCESS) > + { > + RegCloseKey(classKey); > + SetLastError(0xdeadbeef); > + classKey = > SetupDiOpenClassRegKeyExW(&guid, KEY_ALL_ACCESS, > + DIOCR_INSTALLER, NULL, NULL); > + /* wine does incorrectly return > FALSE, so ... */ > + ok(classKey != FALSE && classKey != > INVALID_HANDLE_VALUE, > + "failed opening class key, > error %ld\n", GetLastError()); > + RegCloseKey(classKey); > + RegDeleteKeyW(classesKey, > bracedGuid); > + } > + else > + ok(FALSE, "failed creating device > key: error %ld\n", ret); > + RegCloseKey(classesKey); > + } > + > + HeapFree(GetProcessHeap(), 0, bracedGuid); > + } > + else > + ok(FALSE, "failed to allocate memory for > braced guid\n"); > + > + RpcStringFreeW(&unbracedGuid); > +} > + > START_TEST(devinst) > { > test_SetupDiCreateDeviceInfoListEx(); > + test_SetupDiOpenClassRegKeyExW(); > } > --- a/dlls/setupapi/devinst.c 2006-08-03 > 10:07:11.000000000 +0200 > +++ b/dlls/setupapi/devinst.c 2006-08-04 > 18:10:06.000000000 +0200 > @@ -1393,6 +1393,7 @@ > PVOID Reserved) > { > LPWSTR lpGuidString; > + LPWSTR lpBracedGuidString; > HKEY hClassesKey; > HKEY hClassKey; > LPCWSTR lpKeyName; > @@ -1433,21 +1434,37 @@ > if (UuidToStringW((UUID*)ClassGuid, > &lpGuidString) != RPC_S_OK) > { > RegCloseKey(hClassesKey); > - return FALSE; > + return INVALID_HANDLE_VALUE; > + } > + > + lpBracedGuidString = > HeapAlloc(GetProcessHeap(), 0, > + (strlenW(lpGuidString) + 3) * > sizeof(WCHAR)); > + if (lpBracedGuidString == NULL) > + { > + RpcStringFreeW(&lpGuidString); > + RegCloseKey(hClassesKey); > + return INVALID_HANDLE_VALUE; > } > + lpBracedGuidString[0] = (WCHAR) '{'; > + memcpy(&lpBracedGuidString[1], lpGuidString, > + strlenW(lpGuidString) * sizeof(WCHAR)); > + lpBracedGuidString[1 + strlenW(lpGuidString)] = > (WCHAR) '}'; > + lpBracedGuidString[1 + strlenW(lpGuidString) + > 1] = (WCHAR) 0; > + > + RpcStringFreeW(&lpGuidString); > > if (RegOpenKeyExW(hClassesKey, > - lpGuidString, > + lpBracedGuidString, > 0, > KEY_ALL_ACCESS, > &hClassKey)) > { > - RpcStringFreeW(&lpGuidString); > + HeapFree(GetProcessHeap(), 0, lpBracedGuidString); > RegCloseKey(hClassesKey); > - return FALSE; > + return INVALID_HANDLE_VALUE; > } > > - RpcStringFreeW(&lpGuidString); > + HeapFree(GetProcessHeap(), 0, > lpBracedGuidString); > RegCloseKey(hClassesKey); > > return hClassKey; > > > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --- a/dlls/setupapi/tests/Makefile.in 2006-07-10 18:01:08.000000000 +0200 +++ b/dlls/setupapi/tests/Makefile.in 2006-08-04 16:15:05.000000000 +0200 @@ -3,7 +3,7 @@ SRCDIR = @srcdir@ VPATH = @srcdir@ TESTDLL = setupapi.dll -IMPORTS = setupapi kernel32 +IMPORTS = setupapi kernel32 advapi32 rpcrt4 CTESTS = \ devinst.c \ --- a/dlls/setupapi/tests/devinst.c 2006-08-03 10:07:11.000000000 +0200 +++ b/dlls/setupapi/tests/devinst.c 2006-08-04 17:57:57.000000000 +0200 @@ -27,6 +27,7 @@ #include "winuser.h" #include "winreg.h" #include "setupapi.h" +#include "rpc.h" #include "wine/test.h" @@ -63,7 +64,85 @@ ok(ret, "SetupDiDestroyDeviceInfoList failed : %ld\n", error); } +static void test_SetupDiOpenClassRegKeyExW() +{ + GUID guid; + RPC_STATUS rpcStatus; + HKEY hkey; + WCHAR *unbracedGuid; + WCHAR *bracedGuid; + + rpcStatus = UuidCreate(&guid); + if (rpcStatus != RPC_S_OK) + { + ok(FALSE, "failed to generate test guid, error %ld", rpcStatus); + return; + } + + /* Check return value for non-existant key */ + hkey = SetupDiOpenClassRegKeyExW(&guid, KEY_ALL_ACCESS, + DIOCR_INSTALLER, NULL, NULL); + ok(hkey == INVALID_HANDLE_VALUE, + "invalid return value %p from SetupDiOpenClassRegKeyExW " + "for non-existant key, expected %p\n", hkey, INVALID_HANDLE_VALUE); + + rpcStatus = UuidToStringW(&guid, &unbracedGuid); + if (rpcStatus != RPC_S_OK) + { + ok(FALSE, "failed to get string form of guid, error %ld", rpcStatus); + return; + } + + bracedGuid = HeapAlloc(GetProcessHeap(), 0, + (lstrlenW(unbracedGuid) + 3) * sizeof(WCHAR)); + if (bracedGuid != NULL) + { + HKEY classesKey; + + bracedGuid[0] = (WCHAR) '{'; + memcpy(&bracedGuid[1], unbracedGuid, + lstrlenW(unbracedGuid) * sizeof(WCHAR)); + bracedGuid[1 + lstrlenW(unbracedGuid)] = (WCHAR) '}'; + bracedGuid[1 + lstrlenW(unbracedGuid) + 1] = (WCHAR) 0; + + SetLastError(0xdeadbeef); + classesKey = SetupDiOpenClassRegKeyExW(NULL, KEY_ALL_ACCESS, + DIOCR_INSTALLER, NULL, NULL); + ok(classesKey != INVALID_HANDLE_VALUE, + "failed to open the device classes registry key: error %ld\n", + GetLastError()); + if (classesKey != INVALID_HANDLE_VALUE) + { + DWORD ret; + HKEY classKey; + ret = RegCreateKeyW(classesKey, bracedGuid, &classKey); + if (ret == ERROR_SUCCESS) + { + RegCloseKey(classKey); + SetLastError(0xdeadbeef); + classKey = SetupDiOpenClassRegKeyExW(&guid, KEY_ALL_ACCESS, + DIOCR_INSTALLER, NULL, NULL); + /* wine does incorrectly return FALSE, so ... */ + ok(classKey != FALSE && classKey != INVALID_HANDLE_VALUE, + "failed opening class key, error %ld\n", GetLastError()); + RegCloseKey(classKey); + RegDeleteKeyW(classesKey, bracedGuid); + } + else + ok(FALSE, "failed creating device key: error %ld\n", ret); + RegCloseKey(classesKey); + } + + HeapFree(GetProcessHeap(), 0, bracedGuid); + } + else + ok(FALSE, "failed to allocate memory for braced guid\n"); + + RpcStringFreeW(&unbracedGuid); +} + START_TEST(devinst) { test_SetupDiCreateDeviceInfoListEx(); + test_SetupDiOpenClassRegKeyExW(); } --- a/dlls/setupapi/devinst.c 2006-08-03 10:07:11.000000000 +0200 +++ b/dlls/setupapi/devinst.c 2006-08-04 18:10:06.000000000 +0200 @@ -1393,6 +1393,7 @@ PVOID Reserved) { LPWSTR lpGuidString; + LPWSTR lpBracedGuidString; HKEY hClassesKey; HKEY hClassKey; LPCWSTR lpKeyName; @@ -1433,21 +1434,37 @@ if (UuidToStringW((UUID*)ClassGuid, &lpGuidString) != RPC_S_OK) { RegCloseKey(hClassesKey); - return FALSE; + return INVALID_HANDLE_VALUE; + } + + lpBracedGuidString = HeapAlloc(GetProcessHeap(), 0, + (strlenW(lpGuidString) + 3) * sizeof(WCHAR)); + if (lpBracedGuidString == NULL) + { + RpcStringFreeW(&lpGuidString); + RegCloseKey(hClassesKey); + return INVALID_HANDLE_VALUE; } + lpBracedGuidString[0] = (WCHAR) '{'; + memcpy(&lpBracedGuidString[1], lpGuidString, + strlenW(lpGuidString) * sizeof(WCHAR)); + lpBracedGuidString[1 + strlenW(lpGuidString)] = (WCHAR) '}'; + lpBracedGuidString[1 + strlenW(lpGuidString) + 1] = (WCHAR) 0; + + RpcStringFreeW(&lpGuidString); if (RegOpenKeyExW(hClassesKey, - lpGuidString, + lpBracedGuidString, 0, KEY_ALL_ACCESS, &hClassKey)) { - RpcStringFreeW(&lpGuidString); + HeapFree(GetProcessHeap(), 0, lpBracedGuidString); RegCloseKey(hClassesKey); - return FALSE; + return INVALID_HANDLE_VALUE; } - RpcStringFreeW(&lpGuidString); + HeapFree(GetProcessHeap(), 0, lpBracedGuidString); RegCloseKey(hClassesKey); return hClassKey;

2 1

Re: segfaults with last selection repaint patch in riched20
by Phil Krylov Aug. 11, 2006

Aug. 11, 2006

Hi Krzysztof, On 11/08/06, Krzysztof Foltman <wdev(a)foltman.com> wrote: > What are the circumstances? Is it after some delete/insert operation, or > just after document load? Well I have not traced the whole sequence of calls to richedit, but from the display I can suppose the following. I am doing a search operation on some files. When the app finds a match, it fills the richedit with some text including the match, and changes the match's color (supposedly selects the match and calls setcharformat). It works OK. After that I push "Find next" button. After finding another match the app updates richedit text with the new context of the match and (not changed the match's color yet) segfaults. > I'd do an assert(pLastSelStartPara->member.para.nCharOfs <= > pLastSelEndPara->member.para.nCharOfs) or something. That could possibly > shed some light on the issue. When it crashes and falls out to GDB, nCharOfs of the first para is 10, and nCharOfs of the last para is 3. > This git thing is a piece of unreliable unintuitive crap. For sure CVS was simpler, but GIT also has some advantages... I haven't had any problems requiring to git-clone yet, but I still have to hold the GitWine wiki page open in my browser ;) -- Ph.

1 0

segfaults with last selection repaint patch in riched20
by Phil Krylov Aug. 11, 2006

Aug. 11, 2006

Hi Krzysztof, I was getting a segfault in ME_MarkForPainting() after that patch (BTW great work), and started looking through the code. One thing I found was obviously a typo which can be easily fixed (BTW I don't know for sure but I'd also update pLastSelStartPara and pLastSelEndPara here): --- a/dlls/riched20/paint.c +++ b/dlls/riched20/paint.c @@ -529,7 +529,7 @@ ME_InvalidateSelection(ME_TextEditor *ed /* last selection markers aren't always updated, which means they can point past the end of the document */ if (editor->nLastSelStart > len) - editor->nLastSelEnd = len; + editor->nLastSelStart = len; if (editor->nLastSelEnd > len) editor->nLastSelEnd = len; But it did not resolve my problem. I did not have time to find the real reason for the segfault, but here is a quick hack which made the segfault go away and can probably help you in finding the real reason. Sorry, but I can't officially provide you with the failing application (IBM Translation Manager 6.0.9) which is proprietary and only for IBM internal usage. --- a/dlls/riched20/para.c +++ b/dlls/riched20/para.c @@ -94,7 +94,7 @@ void ME_MarkForWrapping(ME_TextEditor *e void ME_MarkForPainting(ME_TextEditor *editor, ME_DisplayItem *first, ME_DisplayItem *last) { - while(first != last) + while(first && first != last) { first->member.para.nFlags |= MEPF_REPAINT; first = first->member.para.next_para; The backtrace of the segfault was: 1 0x7d948cc0 ME_MarkForPainting+0x10(editor=0x11700f8, first=0x11741d8, last=0x1173ac8) [/home/phil/build/wine-git/dlls/riched20/para.c:99] in riched20 (0x7d948cc0) 2 0x7d948816 ME_InvalidateSelection+0x186(editor=0x11700f8) [/home/phil/build/wine-git/dlls/riched20/paint.c:542] in riched20 (0x7d948816) 3 0x7d9442e9 RichEditANSIWndProc+0x22d9(hWnd=0x100b4, msg=0xb1, wParam=0xe, lParam=0x117) [/home/phil/build/wine-git/dlls/riched20/editor.c:1579] in riched20 (0x7d9442e9) 4 0x7d9466aa RichEdit10ANSIWndProc+0x3a(hWnd=0x100b4, msg=0xb1, wParam=0xe, lParam=0x117) [/home/phil/build/wine-git/dlls/riched20/editor.c:2598] in riched20 (0x7d9466aa) ... -- Ph.

2 1

[UPDATE] RFC: XEmbed System Tray Patches
by James Liggett Aug. 10, 2006

Aug. 10, 2006

Attached is a major update to the XEmbed systray patches that I sent earlier this week. After a few days of tweaking and testing the code, I think I have found the solution to the race conditions that have plagued previous versions of this work. While this is a major step forward, I still need some assistance with some issues with these patches: 1. I need people to test this on any window manager they can to see if the results that I get can be reproduced, especially on older GNOME versions (I tested on GNOME 2.14) I was able to run a small test app that I made over 120 times, and each time it docked perfectly, no zombie systray adapter windows like before. 2. In order to accomplish this reliability, I've had to ensure that systray windows are *never* mapped. According to the XEmbed specs and my testing, we can't map systray windows ourselves--the tray has to do it, or we get the race conditions. However, my current solution isn't entirely correct. The problem is that systray windows aren't mapped under *any* circumstances. While this allows the docking to work properly, the icons don't show up at all if there's no tray to dock with. I've been contemplating some solutions to the problem but I'm not sure what the correct way to go about this is. My current idea is to add a function to winex11.drv that checks to see if we have a systray window. If the function finds one, then we don't map tray windows. If it doesn't return one, then we map them. Would adding a function like that to x11drv be a good idea? Any comments/suggestions/test results highly appreciated. If you'd like to test these, apply them in the order that they're numbered (should go from 0001 to 0010.) Thanks again, James Liggett

1 0

A advapi32 patch to Implement GetCurrentHwProfileA() fully I found
by Scott Ritchie Aug. 10, 2006

Aug. 10, 2006

It looks like this patch didn't get into 0.9.19, so I think someone else needs to take ownership of it and figure out what Alexandre wants until it can get in. I'm looking forward to full tilt poker working :) Any volunteers? Thanks, Scott Ritchie ----- Thanks to the AppDB and a little digging, I was able to discover this patch from a long while ago that never got properly forwarded to wine-patches. See here: http://www.winehq.org/pipermail/wine-devel/2006-February/045115.html Apparently, it makes the Full Tilt Poker client work, which is currently broken (see http://appdb.winehq.org/appview.php?iVersionId=2839) Since this patch apparently got lost by the wayside after it showed up on wine-devel, I'm doing the last step for him and sending it on to wine-patches. If this patch does get rejected, I won't be able to fix it, so please post a message on wine-devel so someone else can do it. It would be a shame for this implementation to stay dead for another year. If implemented, this should also close bug 4468: http://bugs.winehq.org/show_bug.cgi?id=4468 Thanks, Scott Ritchie

1 0

Re: wine-ShowCursor-D3D-over-GDI.patch
by Stefan Dösinger Aug. 10, 2006

Aug. 10, 2006

Am Samstag 29 Juli 2006 11:17 schrieb Andrew Riedi: > Well, here is my first patch, feel free to tell me what all is wrong with > it. I noticed a problem in WoW d3d, so I tracked it down and checked out > msdn. It seems that implementing ShowCursor() over GDI is acceptable, at > least according to msdn, and it seems to work great. Anyhow, this patch > fixes the two mouse cursor problem in WoW, and makes wined3d more > compatible with windows, at least msdn. Here goes nothing. I wrote a little testing app, and unfortunately this is not correct. IDirect3DDevice9::ShowCursor has no effect on the gdi cursor. Part one of that tests are in the minor cursor fix I sent yesterday. The cursor visiblity reported by GetCursorInfo does not change with d3d9device::ShowCursor. The real visibility on the screen does not change either, after ShowCursor(FALSE) the gdi cursor is still visible on windows. The other parts are in my not-yet sent visual test case suite, I didn't send it yet because it needs more work on GetFrontBufferData. What I noticed is that the gdi cursor immediately disappears when SetCursorProperties is called - but GetCursorInfo still returns that it is showed, and the cursor handle is the same :-/ There are some other things which hide the cursor which I didn't find yet. A number of old ddraw games have cursor issues too

1 0

Something wrong with this patch ?
by Stefan Siebert Aug. 10, 2006

Aug. 10, 2006

I assume there's something wrong with my patch ? I've did some research lately on how 32 Bit programs interact with 16Bit windows. This patch doesn't help if a SendMessage was sent from a 32Bit application because it gets dispatched from the 16Bit thread. So NtCurrentTeb doesn't work. At least it fixes uncaught WM_USER messages in the current process. >user - EditWndProc_common - Ignore WM_USER messages which are not sent >from a vdm >Hello, >this patch fixes a Notes Client crash when building the server console >tab (administration client). After creating a text control for console >commands it sends uncaught WM_USER messages which get interpreted by >Wine as 16Bit messages and crashes badly due to NULL pointers. >Changelog: user/edit.c - EditWndProc_common - Ignore WM_USER messages >which are not sent from a vdm --- Stefan Siebert diff --git a/dlls/user/edit.c b/dlls/user/edit.c old mode 100644 new mode 100755 index c4f95e4..fd74183 --- a/dlls/user/edit.c +++ b/dlls/user/edit.c @@ -439,6 +439,10 @@ static LRESULT WINAPI EditWndProc_common LRESULT result = 0; TRACE("hwnd=%p msg=%x (%s) wparam=%x lparam=%lx\n", hwnd, msg, SPY_GetMsgName(msg, hwnd), wParam, lParam); + + /* Ignore WM_USER messages which are not sent from a vdm */ + if ((msg >= WM_USER) && (!NtCurrentTeb()->Tib.SubSystemTib)) + return 0; if (!es && msg != WM_NCCREATE) return DefWindowProcT(hwnd, msg, wParam, lParam, unicode);

1 0

static inline wine_get_fs etc
by Tijl Coosemans Aug. 10, 2006

Aug. 10, 2006

I'm looking at include/wine/library.h and was wondering why the wine_get_fs/gs/... are declared extern and not static like many other functions in that file. Is there any particular reason I'm not seeing? Their __asm__ block is also missing __volatile__ I believe.

3 2

Wine is stripping comments from system register
by Augusto Arcoverde da Rocha Aug. 9, 2006

Aug. 9, 2006

Hi all, I'm tring store some marks as comments inside of system register, but when I start some wine process and it finish the comments have disappeared from the register file. Is this the expected behaviour? Many thanks, Augusto Arcoverde da Rocha

2 1

localspl.dll: Implementation-Question
by Detlef Riekenberg Aug. 9, 2006

Aug. 9, 2006

Am Sonntag, den 30.07.2006, 21:41 +0200 schrieb Detlef Riekenberg: > Printmonitors need spoolss.dll,EnumPortsW > > On windows, all work is done in spoolss.dll and winspool.drv is just the > Forwarder (RPC). > We avoid the need for loading spoolss.dll in every App by > doing the work in winspool.drv and use spoolss.dll as relay. > > > Changelog: > - spoolss: add EnumPortsW (by calling winspool.drv) > The Codebase in "dlls/winspool.drv/info.c" get really large and the actual Code-Path is: "winspool.drv -> CUPS/LPR" (with help from GDI). A possible place to split the Code is at the Printmonitor-Level. The Printmonitor for the Standard "Local Ports" in Windows (COM*:, LPT*:, FILE:, Windows-File) was in "localmon.dll" and merged into "localspl.dll" with w2k. On IRC, Alexandre already accepted to handle Wine-Specific Ports ( CUPS:*, LPR:*, Pipe to a unix_app, /unix-File ) together with the Standard Window-Ports in a single Printmonitor: "localspl.dll" The Requirement, that updating the System-Printers in wine must work automatic, need some Attention, when the related code (LoadSystemPrinters) move from "winspool.drv" to "localspl.dll": 1) Changing the Code-Path to "winspool.drv -> localspl.dll -> CUPS/LPR" and using the same Memory-Functions for "localspl.dll" as done in Windows (the Memory-Related Exports from "spoolss.dll"), give us a circular dependency, when we load and call "winspool.drv" from "spoolss.dll". For this reason, using HeapAlloc(GetProcessHeap(), ...) and Friends from "kernel32.dll" is a Possible way to go for "localspl.dll". 2) To let Printing in Wine work as similar as possible as Printing is done in Windows, (but without RPC and without the Spooler-Service) we can change the Code-Path to "winspool.drv -> spoolss.dll -> localspl.dll -> CUPS/LPR" and use the Exports from "spoolss.dll". Since we need the Memory-Exports from "spoolss.dll" also for other Printmonitors and many Names/Prototypes of the other "spoolss.dll" - Exports are Equal to the Functions in "winspool.drv", I prefer Solution "2". (Wine as an EMF-Printing-Backend for samba is only Possible with 2) As a Reference, what windows does, is: winspool.drv --(RPC)--> spoolsv.exe(Spooler Service) --(WINAPI)--> spoolss.dll -> localspl.dll -> Driver for LPT*: / COM*: Any comments please. Thanks -- By By ... ... Detlef

1 0

Re: This patch should fix bug 4863 - Icons in Notes Workspace
by Augusto Arcoverde da Rocha Aug. 9, 2006

Aug. 9, 2006

Hi all, A little time ago I have sent this patch and now I'm asking to the Wine devel community about the correctness of that code. May be a fix for "Icons in Notes" bug would be incorporated in the next Wine release with some peer-review efforts. Regards, Augusto Arcoverde da Rocha On 7/21/06, Augusto Arcoverde da Rocha <agarobr.listas(a)gmail.com> wrote: > Description: > This patch should fix bug 4863 - Icons in Notes Workspace. > > ChangeLog: > Making SetDIBits function compliant with MSDN documentation by > ignoring the device context parameter if DIB parameter is informed as > having a palette (DIB_PAL_COLORS). > > References: > http://msdn.microsoft.com/library/default.asp?url=/library/en-us/gdi/bitmap… > > Author: > Augusto Arcoverde da Rocha <agarobr\at\yahoo.com.br> > > Notes: > Since I wasn't successful learning more about internal representation > of DIB structure, I couldn't make the apropriated test units for this > fix, sorry. > > >

4 4

Re: version/tests: Write-strings warnings fix
by James Hawkins Aug. 9, 2006

Aug. 9, 2006

On 8/9/06, Andrew Talbot <Andrew.Talbot(a)talbotville.com> wrote: > Please note: in install.c, I have preserved a distinction between "regedit" > and "regedit.exe" that was in the original code. If this distinction is > accidental, please inform me, via wine-devel, and I shall send a revised > version of this patch. > ... > > @@ -34,6 +34,9 @@ > char filename[MAX_PATH]; > char outBuf[MAX_PATH]; > char windir[MAX_PATH]; > + static CHAR empty[] = "", > + regedit_a[] = "regedit", > + regedit_b[] = "regedit.exe"; > > memset(appdir, 0, MAX_PATH); > memset(windir, 0, MAX_PATH); > Seems like regedit and regedit_exe might be better names than regedit_a/b. -- James Hawkins

2 1

Re: WineD3D: draw buffers support (patch 2)
by Roderick Colenbrander Aug. 9, 2006

Aug. 9, 2006

This is a slighly updated version of the patch. The code is the same but I changed the comment a little as suggested by Henri as the part about SM3 was wrong. Roderick > Hi, > > This is a second draw buffers / gl_FragColor patch and it depends on the > other patch which was sent earlier today. The previous patch added draw > buffers support and fixed a gl_FragData bug. This patch fixes another case > where we incorrectly use gl_FragData. > > Regards, > Roderick Colenbrander -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer

1 0

wine
by XIAOJING XIN Aug. 9, 2006

Aug. 9, 2006

hi how are you? i am one of wine users , it is a very amazing software i like it very much , and i have a problem here , does wine support other language? i use it to run one of foreign software which is Chinese, but , the wine software can not display the language, so what can i do now , does it only support English software? regard thank you very much

5 6