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. 12, 2006

Aug. 12, 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

[FreeBSD] locating wine at 0x20000000
by Tijl Coosemans Aug. 9, 2006

Aug. 9, 2006

Hello all, For the past week or so I've been getting to know Wine and trying to improve/fix the FreeBSD version. I've progressed somewhat since then, though there are still quite a few open issues. One of the problems on FreeBSD is that Wine is loaded at 0x7bf00000. FreeBSD's mmap preserves some space for the data segment (about 512Mb by default) and every future call to mmap with NULL for the addr argument maps memory after that. This is the reason that win98 mode doesn't work, since the shared heap at 0x80000000 isn't available and everything that gets dlopen'ed for instance is located beyond the 2G limit which some programs may not like. So I was thinking of moving Wine to 0x20000000. That would be the easiest solution by far, but, are there any potential problems with that?

2 7

Re: [2/2] WINED3D: Fix D3DCOLOR swizzling in shaders.
by Christoph Frick Aug. 9, 2006

Aug. 9, 2006

On Sat, Aug 05, 2006 at 06:15:42PM +0200, H. Verbeet wrote: > This patch fixes those issues by looking at the data types in the > vertex declaration the shader will be used with. To be able to do > that, we have to wait with compiling the shader until the shader is > first used and we have a vertex declaration. I am not sure, if exactly *this* patch fixes the problem - but i assume so: the colors of the cars and lights in Live For Speed are not fixed also. thanks for that! -- cu

1 0

Re: wineconsole: command line option output / default user backend
by Alexandre Julliard Aug. 9, 2006

Aug. 9, 2006

Ekkehard Morgenstern <ekkehard.morgenstern(a)onlinehome.de> writes: > This small patch provides command line option output, a "--help" option > and a default user backend ("--backend=user" is default) to "wineconsole". Your mailer wrapped the patch, please resend it. Also please send separate changes as separate patches, and try to follow the coding conventions of the surrounding code. -- Alexandre Julliard julliard(a)winehq.org

6 14

widl: Error on simple idl file
by Elrond Aug. 9, 2006

Aug. 9, 2006

Hi, The attached idl file gives an error when used with widl -DUSE_TYPEDEF simple.idl I doubt, that it is a syntax error, since adding "-h" creates the header, using "-c" gives the error. The error is: error: Unsupported member type 0x0 Elrond

1 0

Re: ntdll: make shared user data access work
by Alexandre Julliard Aug. 9, 2006

Aug. 9, 2006

Robert Reif <reif(a)earthlink.net> writes: > diff -p -u -r1.66 thread.c > --- dlls/ntdll/thread.c 26 Jul 2006 14:01:20 -0000 1.66 > +++ dlls/ntdll/thread.c 6 Aug 2006 01:15:43 -0000 > @@ -215,7 +215,7 @@ HANDLE thread_init(void) > > addr = (void *)0x7ffe0000; > size = 0x10000; > - NtAllocateVirtualMemory( NtCurrentProcess(), &addr, 0, &size, MEM_RESERVE, PAGE_READONLY ); > + NtAllocateVirtualMemory( NtCurrentProcess(), &addr, 0, &size, MEM_RESERVE | MEM_COMMIT, PAGE_READONLY); This code is only intended to reserve the space at startup. We need to initialize it properly later on before making it accessible. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: wineconsole: command line option output / configurable default backend
by Alexandre Julliard Aug. 9, 2006

Aug. 9, 2006

Ekkehard Morgenstern <ekkehard.morgenstern(a)onlinehome.de> writes: > This patch is akin to the previously posted; however, instead of making > the user backend > the default, I read an environment variable WINECONBACKEND to determine > the default. I don't think that's an improvement, please let's not add more obscure environment variables. You should try to use the user backend when the X display is available and fall back to curses otherwise. -- Alexandre Julliard julliard(a)winehq.org

2 3

Re: oleaut32: Add tmarshal conformance test
by Alexandre Julliard Aug. 9, 2006

Aug. 9, 2006

Dan Hipschman <dsh(a)linux.ucla.edu> writes: > This adds a conformance test written by Rob Shearman. Pretty much all the > code in the four files beginning with "tmarshal" is his. All I did was make > some changes to the Makefiles to be able to test things with IDL components, > and I tweaked his stuff in one or two places where needed. For example, I > wrapped the tests that failed in todo_wine blocks, and I commented out a test > that crashes Wine. All the tests pass on Windows (including the one that > crashes Wine). They don't work on Wine here: ../../../tools/runtest -q -P wine -M oleaut32.dll -T ../../.. -p oleaut32_test.exe.so tmarshal.c && touch tmarshal.ok fixme:ole:ITypeInfo_fnRelease destroy child objects err:ole:marshal_object couldn't get IPSFactory buffer for interface {a028db05-30f0-4b93-b17a-41c72f831d84} err:ole:StdMarshalImpl_MarshalInterface Failed to create ifstub, hres=0x80040155 err:ole:CoMarshalInterface Failed to marshal the interface {a028db05-30f0-4b93-b17a-41c72f831d84}, 80040155 tmarshal.c:139: Test failed: CoMarshalInterface failed with error 0x80040155 err:ole:CoUnmarshalInterface IMarshal::UnmarshalInterface failed, 0x8003001e tmarshal.c:760: Test failed: CoUnmarshalInterface failed with error 0x8003001e wine: Unhandled page fault on write access to 0x00000000 at address 0x15a159 (thread 0009), starting debugger... WineDbg starting on pid 0x8 Unhandled exception: page fault on write access to 0x00000000 in 32-bit code (0x0015a159). Register dump: CS:0073 SS:007b DS:007b ES:007b FS:003b GS:0033 EIP:0015a159 ESP:0033fc88 EBP:0033fd58 EFLAGS:00010246( - 00 -RIZP1) EAX:00159310 EBX:7b8abaa8 ECX:00000000 EDX:00000001 ESI:8003001e EDI:60412be7 Stack dump: 0x0033fc88: 00159310 7b88c87f 00159310 00000001 0x0033fc98: 0015a500 0015a158 00159310 0033ff2c 0x0033fca8: 7b82be98 7b8415c0 7b8abaa8 8003001e 0x0033fcb8: 60412be7 0033fd58 0033fc90 7b88c805 0x0033fcc8: 00000001 00000000 00000000 00000020 0x0033fcd8: 0033fd58 7bc2764f 00110000 7bc77848 fixme:ntdll:RtlNtStatusToDosErrorNoTeb no mapping for c0000119 Backtrace: =>1 0x0015a159 (0x0015a159) fixme:dbghelp:elf_load_debug_info_from_map Alpha-support for Dwarf2 information for oleaut32_test<elf> 2 0x603092f7 func_tmarshal+0x2f7 [/home/julliard/wine/wine/dlls/oleaut32/tests/tmarshal.c:763] in oleaut32_test (0x603092f7) 3 0x6040ee81 run_test+0x121(name=0x1103a9) [/home/julliard/wine/wine/dlls/oleaut32/tests/../../../include/wine/test.h:365] in oleaut32_test (0x6040ee81) 4 0x6040f1a9 __wine_spec_exe_entry+0x99(peb=0x7ffdf000) [/home/julliard/wine/wine/dlls/winecrt0/exe_entry.c:37] in oleaut32_test (0x6040f1a9) fixme:dbghelp:elf_load_debug_info_from_map Alpha-support for Dwarf2 information for kernel32<elf> 5 0x7b87015b start_process+0xeb(arg=0x0) [/home/julliard/wine/wine/dlls/kernel/process.c:822] in kernel32 (0x7b87015b) fixme:dbghelp:elf_load_debug_info_from_map Alpha-support for Dwarf2 information for libwine.so.1 6 0x6001f887 wine_switch_to_stack+0x17 in libwine.so.1 (0x6001f887) 0x0015a159: addb %dl,0x0(%ecx) Wine-dbg> -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: wineconsole: command line option output / configurable default backend
by Vitaliy Margolen Aug. 9, 2006

Aug. 9, 2006

Wednesday, August 9, 2006, 2:33:17 AM, Ekkehard Morgenstern wrote: > This patch is akin to the previously posted; however, instead of making > the user backend > the default, I read an environment variable WINECONBACKEND to determine > the default. > If the value isn't set, "curses" will be the default as in the original > code. You patch wrapped again. Please attach it to the e-mail instead. Vitaliy.

2 1

Re: riched20: new selection invalidation logic
by Vitaliy Margolen Aug. 9, 2006

Aug. 9, 2006

Monday, August 7, 2006, 9:27:16 AM, Krzysztof Foltman wrote: > ChangeLog: > * New, clean, simple selection repaint logic - should fix all > outstanding refresh issues (and bug#5882) > Krzysztof I think this patch takes number of asserts per line to the highest level I've ever seen. Could you explain why you adding asserts everywhere (only 11 in this patch alone!!!)? Instead of using proper error handling? For the past year or more that was the main source of user problems. And if you could how many installers have been broken with this technique, you will probably account for 90% of all the installers that otherwise would work on Wine. Have you even tried your code on purposely broken rtf? How does it handle it? Vitaliy Margolen

3 6

Re: msvcrt: In text mode a ctrl-z signals EOF
by Duane Clark Aug. 8, 2006

Aug. 8, 2006

Duane Clark wrote: > Changelog: In text mode a ctrl-z signals EOF > Spotted by David Hagood with test suggested by Dan Kegel > Howdy David. Any chance you could try out this patch? I added a conformance test, as suggested by Dan, and it looks like any data after a ctrl-z is stripped. Of course, it may be that in the real world there will never be anything other than additional ctrl-z characters, in which case your version would be fine (and more efficient). http://www.winehq.org/pipermail/wine-patches/2006-August/029544.html

1 0

Re: libs/wine/config.c: use execve on FreeBSD
by Alexandre Julliard Aug. 8, 2006

Aug. 8, 2006

Tijl Coosemans <tijl(a)ulyssis.org> writes: > * use execve on FreeBSD Renaming the msvcrt function would really be better. Particularly since "extern char **environ" doesn't work right on all platforms. -- Alexandre Julliard julliard(a)winehq.org

2 2

Re: usp10: Resend - Add funtionality for ScriptStringAnalyse
by Alexandre Julliard Aug. 8, 2006

Aug. 8, 2006

Jeff L <lats(a)yless4u.com.au> writes: > + cMaxItems = 255; /* Pick an abritary size for buffers */ > + analysis = (string_analysis*) pssa; > + if (!*pssa) { /* Clean it out and start again */ > + prtssa(*pssa); > + ScriptStringFree((SCRIPT_STRING_ANALYSIS*)analysis); > + } > + analysis = HeapAlloc( GetProcessHeap(), HEAP_ZERO_MEMORY, > + sizeof(string_analysis)); > + *pssa = (string_analysis*)analysis; I don't follow what you are trying to do here. Why do you print and free a NULL structure? And why do you assign it to analysis and then overwrite it right away with a new allocation? -- Alexandre Julliard julliard(a)winehq.org

1 0

Re: winhelp: bug fix in LZ77 decompressor - prehistory to make things clear
by HolyLich Aug. 8, 2006

Aug. 8, 2006

>> >> Why? >> >> Er, if the memcpy worked (or almost worked) and failed due to overlap >> problems, then memmove will do the trick. Did it ever work at all before? >> Either this code never worked, or you're either seeing a problem that doesn't >> exist/misunderstanding things. >> >> Cheers, Kuba Um, sorry, I didn't understand question. I try to explain why memcpy worked before. It did not worked. As far as I noticed, this bug does not affect small files (<=0x1000) but if file was large enough (>0x1000 byte) - it will appear. In my case it was multi-colour metafile (jwpce.hlp, http://www.physics.ucla.edu/~grosenth/jwpce.html - lots of metafiles). Small pictures are OK, but large are jammed. What is interesting, the bug affected bitmap part of metafile, so no errors while PlayMetaFile, but the result bitmap was jammed a little. --HolyLich

2 1

Re: riched20: modify ME_CharFromPoint to work properly with password controls
by Phil Krylov Aug. 8, 2006

Aug. 8, 2006

Hi Matt, On 07/08/06, Matt Finnicum <mattfinn(a)gmail.com> wrote: > This patch modifies ME_CharFromPoint to work properly with password > controls (the patch i sent in / got committed a couple days ago). Should not the temp string be freed afterwards? -- Ph.

2 2

Re: winhelp: bug fix in LZ77 decompressor
by HolyLich Aug. 8, 2006

Aug. 8, 2006

On Tue, 8 Aug 2006 09:37:09 -0400, Kuba Ober <kuba(a)mareimbrium.org> wrote: >> > > Fix rather unusual bug in LZ77 decompressor. We cannot use >> > > memcpy >> > > with overlapped areas because of unpredictable result. We must >> > > copy byte-by-byte. > >> > Why don't you use memmove instead? The man page for memcpy says: >> > Use memmove(3) if the memory areas do overlap. > >> We cannot use memmove. It provides different functionality. It moves >> blocks, but LZ77 decompress algorithm copies bytes. >> >> Let's suppose: >> 012 >> XYZ >> >> When we say 'memmove(1, 0, 2)' we will get: >> 012 >> XXY >> >> But we (LZ77 algorithm) expect: >> 012 >> XXX (three 'X'). >> >> memcpy is rather clever (it optmizes process by coping INT instead of >> BYTES). This optimization is fatal for LZ77. > > Why? > > Er, if the memcpy worked (or almost worked) and failed due to overlap > problems, then memmove will do the trick. Did it ever work at all before? > Either this code never worked, or you're either seeing a problem that doesn't > exist/misunderstanding things. > > Cheers, Kuba memmove provides OTHER functionality - it GUARANTEES, that if blocks overlaps, then destination area will the same as source area before. LZ77 decompress algorithms needs copiing byte-by-byte - of course, if areas overlap, then dest area WILL NOT match the src area before. It IS correct for LZ77! The simpliest version of memcpy routine, like this: void my_memcpy(char *dst, char *src, int len) { while (len-->0) *dst++=*src++; ) WILL work correctly for LZ77. memcpy provided by gcc is optimized - it NOT copies byte-by-byte from beginning till end. If you mediate over lz77 decompress algo (dlls/kernel/lzexpand.c) the things will be clean.

1 0

Re: winhelp: bug fix in LZ77 decompressor
by HolyLich Aug. 8, 2006

Aug. 8, 2006

> HolyLich wrote: > > ChangeLog: > > Fix rather unusual bug in LZ77 decompressor. We cannot use memcpy > > with overlapped areas because of unpredictable result. We must copy > > byte-by-byte. > Why don't you use memmove instead? The man page for memcpy says: > Use memmove(3) if the memory areas do overlap. We cannot use memmove. It provides different functionality. It moves blocks, but LZ77 decompress algorithm copies bytes. Let's suppose: 012 XYZ When we say 'memmove(1, 0, 2)' we will get: 012 XXY But we (LZ77 algorithm) expect: 012 XXX (three 'X'). memcpy is rather clever (it optmizes process by coping INT instead of BYTES). This optimization is fatal for LZ77. For more information, please, refer to patch. It contains some useful comment. --HolyLich

2 1

Font metrics
by Jeff L Aug. 8, 2006

Aug. 8, 2006

People, I am working on ScriptStringXtoCP etc in usp10. In setting up the tests for this I notice that ABC widths returned ScriptPlace (*/GetCharABCWidthsI) /*is not the same as Windows does. Have tried an couple of fonts and the results are the subtly different. Before I get too carried away with this, are the ABC widths supposed to be the same in Wine and Windows? Jeff Latimer

1 0

dinput & [Get|Set]CursorPos conandrum
by Vitaliy Margolen Aug. 8, 2006

Aug. 8, 2006

Some one few weeks ago mentioned that they needed SetCursorPos to work globally (between processes). Well it seems after all we do need that to fix few lots of things, including most mouse related bugs in dinput. Actually the problem I have is not as much with SetCursorPos as with the fact that with multiple processes only one gets MotionNotify (and other notify) events. This gets cursor position out of sync between two processes and causes interesting side-effects. It's not something major but an annoyance. There are could be more serious problems however. The possible solutions might be: 1. Store cursor_pos in wineserver and call wineserver whenever we need it or need to modify it. Seems straight forward but how expensive it would be? 2. Use shared memory. That means we have to allocate it first (will SharedUserData work for this?). And use mutex for sync. 3. Query X for it's cursor position. Pretty much what we do, except that needs to be fixed: Current dinput has lots of problems with lots of games for number of different reasons (and I'm talking about just mouse). To fix some(all) of them we need to move managing of mouse warping to x11drv - only it has enough information about what programs doing to the cursor. And to make it work all we really need is to make GetCursorPos returned cached cursor position and not the latest from X. Any ideas appreciated. Vitaliy

2 4

Re: winhelp: bug fix in LZ77 decompressor
by Michael Stefaniuc Aug. 8, 2006

Aug. 8, 2006

HolyLich wrote: > ChangeLog: > Fix rather unusual bug in LZ77 decompressor. We cannot use memcpy > with overlapped areas because of unpredictable result. We must copy > byte-by-byte. Why don't you use memmove instead? The man page for memcpy says: Use memmove(3) if the memory areas do overlap. bye michael -- Michael Stefaniuc Tel.: +49-711-96437-199 Sr. Network Engineer Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

1 0

Re: WineD3D: shader cap fixes
by Roderick Colenbrander Aug. 8, 2006

Aug. 8, 2006

Use this updated patch. I forgot to initialize some constants to zero and made the diff against a wrong file because of which some crucial changes were missed. Roderick > Hi, > > This patch adds most missing shader capabilities. Some capabilitise are > read from OpenGL but not everything is mappable to Direct3D in some cases an > extension from lets say Nvidia can be used but it is not really worth it. > If there's no OpenGL cap the minimum required values as required by the > shader specs are used. > > Regards, > Roderick Colenbrander -- "Feel free" – 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail

1 0

Constifying Undocumented Code?
by Andrew Talbot Aug. 8, 2006

Aug. 8, 2006

Where we emulate undocumented code, is it acceptable to constify the formal arguments, where appropriate? Thanks, -- Andy.

3 3

HAL and Copy Protection
by Jesse Allen Aug. 8, 2006

Aug. 8, 2006

Does anyone have HAL and SecuRom copy protection working? I'm starting to get support questions with people using HAL and I'm not sure how to help them. I need information now that HAL support is in Wine on whether SecuRom works with it and how to get it to work as I don't have HAL. Jesse

2 6

Re: wined3d: stub out remaining renderstates
by Stefan Dösinger Aug. 7, 2006

Aug. 7, 2006

Am Dienstag 08 August 2006 00:06 schrieb Jan Zerebecki: > If this patch is rejected from inclusion, please tell me why, as i would > have to ask anyway. It looks like you forgot d3d7 render states like TEXTUREMAPBLEND. This state isn't really important for this patch, I will send an implementation for it tomorrow, but other d3d7 render states are perhaps needed.

1 0

Re: wintrust: Always return ERROR_SUCCESS in WinVerifyTrust [RESEND]
by Paul Vriens Aug. 7, 2006

Aug. 7, 2006

On Mon, 2006-08-07 at 11:11 -0700, James Hawkins wrote: > Hi, > > Accoring to recent comments by Paul Vriens, Process Explorer now > accepts ERROR_SUCCESS from WinVerifyTrust, and several installers > require ERROR_SUCCESS in order to continue, so everyone is happy. > Fixes bugs 5573 and 3619. > > http://bugs.winehq.org/show_bug.cgi?id=5573 > http://bugs.winehq.org/show_bug.cgi?id=3619 > > Changelog: > * Always return ERROR_SUCCESS in WinVerifyTrust. > > dlls/wintrust/wintrust_main.c | 18 +++++------------- > 1 files changed, 5 insertions(+), 13 deletions(-) > When I run process explorer without tracing/debugging everything is fine. As soon as I add +wintrust,+heap it fails again. There is most likely some heap corruption somewhere (couldn't be more vague). Alexandre's patch to add more free list entries only masked the problem, as far as I can see from the results. Cheers and sorry for the misleading remarks, Paul.

2 2

Re: user[2/2]: Preserve LastError.
by Vitaliy Margolen Aug. 7, 2006

Aug. 7, 2006

Saturday, July 29, 2006, 7:28:10 PM, Vitaliy Margolen wrote: > ChangeLog: > user: Preserve LastError. > dlls/user/tests/input.c | 4 ++++ > dlls/winex11.drv/x11drv.h | 3 +++ > 2 files changed, 7 insertions(+), 0 deletions(-) Anything wrong with this patch? Test case clearly shows that we should preserve the LastError. Vitaliy Margolen

2 3