March 2007 - Wine-Devel - list.winehq.org

Re: (resend) Scroll window fix
by Peter Oberndorfer March 3, 2007

March 3, 2007

On Tuesday 13 February 2007 14:38, Aric Stewart wrote: > finds the case where the scrolling amount exceeds the window but still > falls within the clipping rect. This generates an additional update > region that needs to be invalidated. > includes a test > Hi, I think your patch has a problem. It calls CombineRgn with the deleted Region hrgnClip. I don't know if it impacts real world applications, but i just saw a warning about a invalid handle in my debug log. Maybe moving DeleteObject below the if solves the problem? I don't know... @@ -870,6 +870,26 @@ INT WINAPI ScrollWindowEx( HWND hwnd, IN CombineRgn( hrgnWinupd, hrgnWinupd, hrgnTemp, RGN_OR ); RedrawWindow( hwnd, NULL, hrgnTemp, rdw_flags); DeleteObject( hrgnClip ); //<<<<<<< deleted here + + /* Catch the case where the scolling amount exceeds the size of the + * original window. This generated a second update area that is the + * location where the original scrolled content would end up. + * This second region is not returned by the ScrollDC and sets + * ScrollWindowEx apart from just a ScrollDC. + * + * This has been verified with testing on windows. + */ + if (abs(dx) > abs(rc.right - rc.left) || + abs(dy) > abs(rc.bottom - rc.top)) + { + DeleteObject( hrgnTemp ); + hrgnTemp = CreateRectRgn(rc.left + dx, rc.top + dy, rc.right+dx, rc.bottom + dy); + CombineRgn( hrgnTemp, hrgnTemp, hrgnClip, RGN_AND ); //<<<<<<< used here + CombineRgn( hrgnUpdate, hrgnUpdate, hrgnTemp, RGN_OR ); + + if( !bOwnRgn) + CombineRgn( hrgnWinupd, hrgnWinupd, hrgnTemp, RGN_OR ); + } } DeleteObject( hrgnTemp ); Greetings Peter

1 0

msi ole automation update
by Misha Koshelev March 3, 2007

March 3, 2007

Hi everbody, I have been working on some more stuff for the MSI OLE automation, and I now have a moderately comprehensive conformance test (1000 or so lines, tests each function implemented at least for basic functionality, tests things like return codes, if you set a property and then get it do you get what you set it to, etc.). A few small patches are needed to then make my OLE automation code (which is still hanging out in wine-patches, not in git yet) pass this test. I am going to wait to send all these new patches to wine-patches until my other patches get reviewed/committed by Alexandre. However, I thought I would post them here for any comments. I am going to be _quite_ busy starting Monday for a month though, so I may likely not be able to make any serious modifications to them if people see large problems until April. However, if anyone has any comments about these or my patches already sitting in wine-patches, please do let me know. Thanks Misha

1 1

re: GSoC project proposal: Implement the Negotiate and Kerberos SSPs based on GSSAPI
by Dan Kegel March 3, 2007

March 3, 2007

Kai wrote: >My toy idea is to not implement the ASN.1 stuff myself but instead make >use of GSSAPI for this.... Can you explain for us non-knowledgeable folks what ASN.1 stuff you're talking about? >Should using GSSAPI not work for us for whatever reason, I think it should be >well within the GSoC timeframe to bite the bullet and cobble together an >ASN.1 parser for Negotiate, handle negotiation in Wine and use libkrb5 for >Kerberos. When I first looked at gssapi back in '98 or so, it seemed to be mostly an annoying convenience layer that just got in the way of my project (which was to add authentication to a network game library). Here's a rule of thumb: if a convenience layer does any networking for you, it will do it wrong. Let's look at Heimdal's networking, for instance. In heimdal, its networking implementation uses select(). We've spent a lot of time purging all select()'s from Wine's source tree because any application that uses select() breaks once you have fd's in your app with values above 1024. Sure, we can fix that by submitting patches to Heimdal to use poll() instead, but there are are sure to be other problems. The best thing to do is eschew all functions that do networking for you, and do it all yourself. So, can you do what you're thinking of without being forced to let gssapi do networking for you? For those just tuning in, here's some context: http://www.stacken.kth.se/lists/heimdal-discuss/2006-12/msg00030.html http://www.stacken.kth.se/lists/heimdal-discuss/2006-12/msg00033.html - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

2 1

Re: [PATCH 2/2] comctl32: Added message sequence tests for the tab control
by Vitaliy Margolen March 3, 2007

March 3, 2007

The_Hagop wrote: > assert(tabHandle); > > - SetWindowLong(tabHandle, GWL_STYLE, WS_CLIPSIBLINGS | WS_CLIPCHILDREN | TCS_FOCUSNEVER | style); > - SendMessage (tabHandle, WM_SETFONT, 0, (LPARAM) hFont); > + if (!tabHandle) > + { > + HeapFree(GetProcessHeap(), 0, info); > + return NULL; > + } This check is redundant. assert will terminate the test if window was not created properly. You probably should remove it and skip the test. > @@ -448,22 +717,42 @@ > INT nTabsRetrieved; > INT rowCount; > > + parent_wnd = createParentWindow(); > + ok(parent_wnd != NULL, "Failed to create parent window!\n"); > + ok_sequence(sequences, PARENT_SEQ_INDEX, create_parent_wnd_seq, "create parent window", TRUE); > + flush_sequences(sequences, NUM_MSG_SEQUENCES); > + No need to test window creation sequence here. It's tested in much more details in user32/tests/msg.c Also you are leaking parent window - you don't destroying it at the end of the test. And, same as hTab, don't make it global. You are not using it outside one function. > @@ -474,6 +763,9 @@ > test_getset_tooltip(hTab); > > DestroyWindow(hTab); > + > + ok_sequence(sequences, TAB_SEQ_INDEX, destroy_tab_control_seq, "Tab sequence, after removing tab control from parent", FALSE); > + ok_sequence(sequences, PARENT_SEQ_INDEX, empty_sequence, "Parent sequence, after removing tab control from parent", FALSE); > } > > START_TEST(tab) Same thing here - there are no common controls' related messages in them- no need to test what's already being tested in the other places. And last but not the least - your tests fail on windows 2k and xp pro in interactive mode (set WINETEST_INTERACTIVE=1): tab: 911 tests executed (0 marked as todo, 20 failures), 0 skipped. Vitaliy.

1 0

Re: DirectPlay should convert dwReserved1/2 registry keys from strings to DWORDs
by Joris Huizer March 3, 2007

March 3, 2007

if( i == 0 ) - memcpy( &lpSpData->dwReserved1, returnBuffer, sizeof(lpSpData->dwReserved1) ); + sscanf(returnBuffer, "%x", &lpSpData->dwReserved1); Couldnt you use: strcpy(lpSpData->dwReserved1,returnBuffer); Sorry for only replying now; Your solution is equivalent, except that it is looks more complicated regards, Joris --------------------------------- The fish are biting. Get more visitors on your site using Yahoo! Search Marketing.

2 2

Re: [2/?]WineD3D: Adjust the rhw transformation for offscreen rendering
by Stefan Dösinger March 3, 2007

March 3, 2007

Am Samstag 03 März 2007 02:53 schrieb Stefan Dösinger: > I hope I explained it correctly, these tripple upside down matrix things > are the perfect way to get insane. Actually that is not totally correct - it should be - Y, -Y - height. It works because all games I have seen use Y = 0 I'll resend a fixed patch

1 0

Re: DirectPlay should convert dwReserved1/2 registry keys from strings to DWORDs
by Kai Blin March 3, 2007

March 3, 2007

On Friday 02 March 2007 22:54, Alessandro Pignotti wrote: > Hi, > This is the first of several patches that will make builtin dplayx > compatible with native dpwsockx, so we can kill the native override of > dplayx This patch adds two compile-time warnings about implicitly declaring sscanf. Please include the appropriate header or provide the function header if you use sscanf. Other than that, this patch stops builtin dplay from blowing up in my face with native dpwsockx.dll. Good work. Cheers, Kai -- Kai Blin, <kai Dot blin At gmail Dot com> WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin/ -- Will code for cotton.

1 0

Re: (resend) Scroll window fix
by Dmitry Timoshkov March 3, 2007

March 3, 2007

"Aric Stewart" <aric(a)codeweavers.com> wrote: > + SetRect( &rc, 0,40, 100,60); > + SetRect( &cliprc, 0,0, 100,100); > + ScrollWindowEx( hwnd1, 0, -25, &rc, &cliprc, hrgn, &rcu, SW_INVALIDATE); > + SetRectRgn( tmprgn, 0,15,98,35); > + CombineRgn( exprgn, exprgn, tmprgn, RGN_OR); > + SetRectRgn( tmprgn, 0, 40, 98, 60); > + CombineRgn( exprgn, exprgn, tmprgn, RGN_OR); > + ok( EqualRgn( exprgn, hrgn), "wrong update region in excessive scroll\n"); Under which version of Windows this was tested? According to test.winehq.org this test doesn't pass under any of Win98, NT4, Win2000 nor XP invalidating the (now committed) fix. I'd vote to revert this patch as obviously incorrect. -- Dmitry.

3 4

GSoC project proposal: Implement the Negotiate and Kerberos SSPs based on GSSAPI
by Kai Blin March 3, 2007

March 3, 2007

Hi folks, after I spent my last two summers toying with the NTLM SSP, I'm considering to implement Negotiate and Kerberos this time. As we've discussed on WineConf, there's more than one way to do this. My toy idea is to not implement the ASN.1 stuff myself but instead make use of GSSAPI for this. (With the added bonus that when using Heimdal GSSAPI, we should be able to do NTLM via GSSAPI, too, so Negotiate can actually negotiate between Kerberos and NTLM). I'm not 100% sure that this approach will work, but then again, if I got and write the proof of concept now, I won't have much to do during the summer. Should using GSSAPI not work for us for whatever reason, I think it should be well within the GSoC timeframe to bite the bullet and cobble together an ASN.1 parser for Negotiate, handle negotiation in Wine and use libkrb5 for Kerberos. Dan Kegel seemed to prefer this approach, anyway. In any case I would like to keep the NTLM provider using ntlm_auth in as a fallback solution. What do you think? Kai -- Kai Blin, <kai Dot blin At gmail Dot com> WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin/ -- Will code for cotton.

1 0

Re: winex11.drv: Try to work around an access violation in dib_convert
by Dmitry Timoshkov March 2, 2007

March 2, 2007

"Louis. Lenders" <xerox_xerox2000(a)yahoo.co.uk> wrote: > @@ -849,7 +858,17 @@ static void convert_888_to_0888_asis(int > for (x=0; x < w2; x++) { > /* Do 4 pixels at a time: 3 dwords in and 4 dwords out */ > DWORD srcval1,srcval2; > - srcval1=srcpixel[0]; > + /* Some apps crash in following code-line, possibly they pass a bad pointer*/ > + __TRY > + { > + srcval1=srcpixel[0]; > + } > + __EXCEPT(exception_filter) > + { > + return; > + } > + __ENDTRY; An exception handler should be set around the whole conversion cycle, not around a single pixel read since it's a very expensive (slow) operation in Wine (unlike in Windows). -- Dmitry.

1 0