Re: Fix compilation on systems that don't support nameless unions.
"Francois Gouget" <[EMAIL PROTECTED]> wrote: This fixes compilation with gcc 2.95. programs/cmd/batch.c |8 1 files changed, 4 insertions(+), 4 deletions(-) As a more general solution that would also prevent this kind of breakage in future would be to move #define NONAMELESSUNION #define NONAMELESSSTRUCT from directory.c to wcmd.h. -- Dmitry.
Re: (resend) Scroll window fix
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
Re: msi ole automation update
On Sat, 2007-03-03 at 17:03 -0600, Misha Koshelev wrote:
> 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
Whoops, one small typo. Updated file attached.
Misha
From 9edf7480405e5aa133e834fc09711e54e3c18e19 Mon Sep 17 00:00:00 2001
From: Misha Koshelev <[EMAIL PROTECTED]>
Date: Sat, 3 Mar 2007 17:33:10 -0600
Subject: msi: automation: Return exceptions like native.
---
dlls/msi/automation.c | 102 +
1 files changed, 86 insertions(+), 16 deletions(-)
diff --git a/dlls/msi/automation.c b/dlls/msi/automation.c
index a504734..9825496 100644
--- a/dlls/msi/automation.c
+++ b/dlls/msi/automation.c
@@ -279,6 +279,9 @@ static HRESULT WINAPI AutomationObject_G
return ITypeInfo_GetIDsOfNames(This->iTypeInfo, rgszNames, cNames,
rgDispId);
}
+/* Maximum number of allowed function parameters+1 */
+#define MAX_FUNC_PARAMS 20
+
/* Some error checking is done here to simplify individual object function
invocation */
static HRESULT WINAPI AutomationObject_Invoke(
IDispatch* iface,
@@ -337,6 +340,41 @@ static HRESULT WINAPI AutomationObject_I
if (bstrName == NULL) ITypeInfo_GetDocumentation(This->iTypeInfo,
dispIdMember, &bstrName, NULL, NULL, NULL);
FIXME("Method %d, %s wflags %d not implemented, clsid %s\n",
dispIdMember, debugstr_w(bstrName), wFlags, debugstr_guid(This->clsid));
}
+else if (pExcepInfo &&
+ (hr == DISP_E_PARAMNOTFOUND ||
+ hr == DISP_E_EXCEPTION)) {
+static WCHAR szComma[] = { ',',0 };
+static WCHAR szExceptionSource[] = {'M','s','i',' ','A','P','I','
','E','r','r','o','r',0};
+WCHAR szExceptionDescription[MAX_PATH];
+BSTR bstrParamNames[MAX_FUNC_PARAMS];
+unsigned namesNo, i;
+BOOL bFirst = TRUE;
+
+if (FAILED(ITypeInfo_GetNames(This->iTypeInfo, dispIdMember,
bstrParamNames,
+ MAX_FUNC_PARAMS, &namesNo)))
+{
+TRACE("Failed to retrieve names for dispIdMember %d\n",
dispIdMember);
+}
+else
+{
+memset(szExceptionDescription, 0, sizeof(szExceptionDescription));
+for (i=0; iwCode = 1000;
+pExcepInfo->bstrSource = szExceptionSource;
+pExcepInfo->bstrDescription = szExceptionDescription;
+hr = DISP_E_EXCEPTION;
+}
+}
/* Make sure we free the return variant if it is our dummy variant */
if (pVarResult == &varResultDummy) VariantClear(pVarResult);
@@ -582,7 +620,7 @@ HRESULT WINAPI RecordImpl_Invoke(
V_BSTR(pVarResult) = SysAllocString(szString);
else
{
- TRACE("MsiRecordGetString returned %d\n", ret);
+ ERR("MsiRecordGetString returned %d\n", ret);
V_BSTR(pVarResult) = NULL;
}
} else if (wFlags & DISPATCH_PROPERTYPUT) {
@@ -591,7 +629,10 @@ HRESULT WINAPI RecordImpl_Invoke(
hr = DispGetParam(pDispParams, DISPID_PROPERTYPUT, VT_BSTR,
&varg1, puArgErr);
if (FAILED(hr)) return hr;
if ((ret = MsiRecordSetStringW(This->msiHandle, V_I4(&varg0),
V_BSTR(&varg1))) != ERROR_SUCCESS)
-TRACE("MsiRecordSetString returned %d\n", ret);
+{
+ERR("MsiRecordSetString returned %d\n", ret);
+return DISP_E_EXCEPTION;
+}
}
break;
@@ -628,7 +669,7 @@ HRESULT WINAPI ViewImpl_Invoke(
if (wFlags & DISPATCH_METHOD)
{
hr = DispGetParam(pDispParams, 0, VT_DISPATCH, &varg0,
puArgErr);
-if (SUCCEEDED(hr))
+if (SUCCEEDED(hr) && V_DISPATCH(&varg0) != NULL)
MsiViewExecute(This->msiHandle, ((AutomationObject
*)V_DISPATCH(&varg0))->msiHandle);
else
MsiViewExecute(This->msiHandle, 0);
@@ -639,13 +680,21 @@ HRESULT
Re: GSoC project proposal: Implement the Negotiate and Kerberos SSPs based on GSSAPI
On Saturday 03 March 2007 18:35, Dan Kegel wrote: > 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? ASN.1 is a standard, formal method of describing communication protocols, among other things. (See http://en.wikipedia.org/wiki/ASN1) Negotiate (called so by Microsoft, RFC 2478 calls it SPNEGO) uses the distinguished encoding rules. So does Kerberos 5. If I want to work with SPNEGO data coming over the wire, I need a DER parser. There's libtasn1 from the GNUTLS project, but that's unusable due to licensing reasons. I haven't looked into using e.g. Heimdal's asn1 lib, though. > >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). Incidently, this is the way Microsoft went with DirectPlay. (Up until dplay9, where they added a SHA-1 checksum (and another checksum they call 8-bit, I haven't looked at that yet.). But I'm rambling. > 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. Yeah, that makes sense to me. SSPI doesn't do networking, either. :) > So, can you do what you're thinking of without being forced > to let gssapi do networking for you? As far as I can see, GSSAPI doesn't do networking at all. Heimdal's example code uses krb5_send to send stuff, but the mit example code uses plain POSIX send(). GSSAPI is more interesting than my last try with GENSEC, as GSSAPI is MIT-licensed. I've been burnt by licensing issues before, which is why I have a backup plan this time, and that's reinventing the wheel if I can't use the old one. I'd just like to avoid it if possible. Cheers, Kai -- Kai Blin, WorldForge developerhttp://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin/ -- Will code for cotton. pgpxG4uuqmonm.pgp Description: PGP signature
re: GSoC project proposal: Implement the Negotiate and Kerberos SSPs based on GSSAPI
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
Re: [PATCH 2/2] comctl32: Added message sequence tests for the tab control
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.
Re: [PATCH 1/2] comctl32: Added getter-setter tests for the tab control (second attempt)
The_Hagop wrote:
> @@ -1,5 +1,6 @@
> /* Unit test suite for tab control.
> *
> + * Copyright 2007 Hagop Hagopian
> * Copyright 2003 Vitaliy Margolen
> *
> * This library is free software; you can redistribute it and/or
These are sorted in historical order.
> @@ -52,6 +59,8 @@
>
> static HFONT hFont = 0;
>
> +static HWND hTab;
> +
> static HWND
> create_tabcontrol (DWORD style, DWORD mask)
> {
You using exactly the same name as parameter to all of your functions.
This creates lots of confusion. Please remove this global variable and
pass it as a function parameter instead.
> +/* Creating a tooltip window*/
> +hwndTT = CreateWindowEx(WS_EX_TOPMOST,
> +TOOLTIPS_CLASS,
> +NULL,
> +WS_POPUP | TTS_NOPREFIX | TTS_ALWAYSTIP,
> +CW_USEDEFAULT,
> +CW_USEDEFAULT,
> +CW_USEDEFAULT,
> +CW_USEDEFAULT,
> +hTab,
> +NULL,
> +0,
> +NULL
> +);
> +
> +SetWindowPos(hwndTT,
> +HWND_TOPMOST,
> +0,
> +0,
> +0,
> +0,
> +SWP_NOMOVE | SWP_NOSIZE | SWP_NOACTIVATE);
This looks just plain bad. Please put all parameters one after another.
There are absolutely no need to have each on it's own line.
> +ti.rect.left = rect.left;
> +ti.rect.top = rect.top;
> +ti.rect.right = rect.right;
> +ti.rect.bottom = rect.bottom;
You can assign structures to structures in C:
ti.rect = rect;
> +todo_wine{
> +/* Testing CurFocus with negative value */
> +SendMessage(hTab, TCM_SETCURFOCUS, -1, 0);
> +focusIndex = SendMessage(hTab, TCM_GETCURFOCUS, 0, 0);
> +expect(-1, focusIndex);
> +}
Here and all other places - the only part of the test that's failing is
"expect(,)". Add "todo_wine" at front of it only.
Also it would be interesting to test larger negative numbers, like -10.
This is because number of places use -1 to indicate that nothing is
selected. So in a sense you might be getting a correct number.
> +expect((int) extendedStyle, (int) prevExtendedStyle);
> +todo_wine{
> +extendedStyle = SendMessage(hTab, TCM_GETEXTENDEDSTYLE, 0, 0);
> +expect(TCS_EX_FLATSEPARATORS, (int) extendedStyle);
> +}
Why are you casting DWORD to int?
> +static void test_getters_setters(INT nTabs)
> +{
> +RECT rTab;
> +INT nTabsRetrieved;
> +INT rowCount;
> +
> +hTab = createFilledTabControl(TCS_FIXEDWIDTH, TCIF_TEXT|TCIF_IMAGE,
> nTabs);
> +ok(hTab != NULL, "Failed to create tab control\n");
> +
> +SendMessage(hTab, TCM_SETMINTABWIDTH, 0, -1);
> +
> +/* Testing GetItemCount */
> +nTabsRetrieved = SendMessage(hTab, TCM_GETITEMCOUNT, 0, 0);
> +expect(nTabs, nTabsRetrieved);
> +
> +/* Testing GetRowCount */
> +rowCount = SendMessage(hTab, TCM_GETROWCOUNT, 0, 0);
> +expect(1, rowCount);
> +
> +/* Testing GetItemRect */
> +SendMessage(hTab, TCM_GETITEMRECT, 0 , (LPARAM) &rTab );
> +CheckSize(hTab, TAB_DEFAULT_WIDTH, -1 , "Default Width");
> +
> +test_getset_curFocus(hTab, nTabs);
> +test_getset_curSel(hTab, nTabs);
> +
> +test_getset_extendedStyle(hTab);
> +test_getset_unicodeFormat(hTab);
> +test_getset_item(hTab);
> +test_getset_tooltip(hTab);
> +
> +DestroyWindow(hTab);
> +}
All your small functions should go inside this function. There is no
need to create 100 small functions that do 1-3 tests.
> +
> +test_getters_setters(5);
> }
This part part of your patch appears to be malformed.
Vitlaiy
Re: DirectPlay should convert dwReserved1/2 registry keys from strings to DWORDs
--- Frank Richter <[EMAIL PROTECTED]> wrote: > On 03.03.2007 13:56, Joris Huizer wrote: > > > > if( i == 0 ) > > - memcpy( &lpSpData->dwReserved1, > returnBuffer, > > sizeof(lpSpData->dwReserved1) ); > > + sscanf(returnBuffer, "%x", > &lpSpData->dwReserved1); > > > > > > > > Couldnt you use: > > strcpy(lpSpData->dwReserved1,returnBuffer); > > Reading a string and interpreting it as a hex value, > this value then > being stored in a DWORD, is not quite the same as > copying the string > into the memory occupied by the DWORD. > > -f.r. > Ow I'm sorry, then I mis-interpreted what was happening- sorry for that Looking for earth-friendly autos? Browse Top Cars by "Green Rating" at Yahoo! Autos' Green Center. http://autos.yahoo.com/green_center/
Re: DirectPlay should convert dwReserved1/2 registry keys from strings to DWORDs
On 03.03.2007 13:56, Joris Huizer wrote: > > if( i == 0 ) > - memcpy( &lpSpData->dwReserved1, returnBuffer, > sizeof(lpSpData->dwReserved1) ); > + sscanf(returnBuffer, "%x", &lpSpData->dwReserved1); > > > > Couldnt you use: > strcpy(lpSpData->dwReserved1,returnBuffer); Reading a string and interpreting it as a hex value, this value then being stored in a DWORD, is not quite the same as copying the string into the memory occupied by the DWORD. -f.r.
Re: DirectPlay should convert dwReserved1/2 registry keys from strings to DWORDs
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.
Re: [2/?]WineD3D: Adjust the rhw transformation for offscreen rendering
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 pgp7t8xINQ5Bx.pgp Description: PGP signature
Re: DirectPlay should convert dwReserved1/2 registry keys from strings to DWORDs
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, WorldForge developerhttp://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin/ -- Will code for cotton. pgpBLXfsdUTv5.pgp Description: PGP signature
Re: (resend) Scroll window fix
I think you misunderstand. I wrote extensive tests _on windows_ that I used for this patch which where independent on the existing test in wine as i could not get the wine test to work properly in window, most likely, do to a lack of understand on the testing framework. After i made the patch my tests worked in both places however I could not get my tests to behave in the testing framework. So i tried to modify the existing test to work and found what i believed to be the correct test. Evidently I was wrong. I may still have my tests on my windows machine back in the office if they would be helpful. -aric Dmitry Timoshkov wrote: "Aric Stewart" <[EMAIL PROTECTED]> wrote: I did my work comparing to windows 2000. I could not get the test to run at all on my windows box so i had to try to fiddle with the test to get it to work. What exactly was the problem? I spent a lot of time working on windows 2000 to make this behavior the same and so feel the patch is not "obviously incorrect" and most likely I did something incorrect in the test. Well, apparently the fix was based on a test (that was supposed to mimic a real application behaviour that exposed a bug), and since the test is wrong (since it doesn't pass on a single flavour of Windows) the fix is wrong as well. We need some kind of a resolution to the problem, and I don't see a better way than reverting the whole patch.
Re: (resend) Scroll window fix
"Dmitry Timoshkov" <[EMAIL PROTECTED]> writes: > Well, apparently the fix was based on a test (that was supposed to mimic > a real application behaviour that exposed a bug), and since the test is > wrong (since it doesn't pass on a single flavour of Windows) the fix is > wrong as well. The test failing on Windows doesn't necessarily imply that the fix is wrong, only that the test is broken. The first thing to do is to make the test pass on Windows, which will then tell us if the fix was correct depending on whether the fixed test still passes on Wine. -- Alexandre Julliard [EMAIL PROTECTED]
Re: (resend) Scroll window fix
"Aric Stewart" <[EMAIL PROTECTED]> wrote: I did my work comparing to windows 2000. I could not get the test to run at all on my windows box so i had to try to fiddle with the test to get it to work. What exactly was the problem? I spent a lot of time working on windows 2000 to make this behavior the same and so feel the patch is not "obviously incorrect" and most likely I did something incorrect in the test. Well, apparently the fix was based on a test (that was supposed to mimic a real application behaviour that exposed a bug), and since the test is wrong (since it doesn't pass on a single flavour of Windows) the fix is wrong as well. We need some kind of a resolution to the problem, and I don't see a better way than reverting the whole patch. -- Dmitry.
Re: (resend) Scroll window fix
I did my work comparing to windows 2000. I could not get the test to run at all on my windows box so i had to try to fiddle with the test to get it to work. I spent a lot of time working on windows 2000 to make this behavior the same and so feel the patch is not "obviously incorrect" and most likely I did something incorrect in the test. -aric Dmitry Timoshkov wrote: "Aric Stewart" <[EMAIL PROTECTED]> 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.
GSoC project proposal: Implement the Negotiate and Kerberos SSPs based on GSSAPI
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, WorldForge developerhttp://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin/ -- Will code for cotton. pgpSDTBGCG6JA.pgp Description: PGP signature
RE: DIB Engine & GSoC
Damjan Jovanovic [mailto:[EMAIL PROTECTED] wrote: >There are probably several ways to do a DIB engine. > >The way I would do it, is the way that Transgaming did it in that patch a number >of years back, ie. where wine does: Actually better would be IMO to place it all in GDI. A lot of the Eng.. API functions that win32k.sys exports (which is basically just the GDI engine put into the kernel Space, and GDI32.DLL exports them actually too by forwarding to win32k.sys) deal with just this stuff among other things. Basically a W2K display driver can hook certain DIB operations to do itself and in case he only implements certain features such as bit depths he can forward the rest to those Eng.. functions too. If a driver did not hook the particular DIB operation (or maybe even if it failed it) win32k.sys will also call this Eng.. functions. The problem I see with this is that implementing those Eng.. Functions that are documented in the DDK would make most sense by using the same prototypes but this Eng.. API is much more modelled around the w2k display driver interface that has by far not the direct 1:1 function mapping to the actual GDI functions as what the Wine display driver currently uses. Even the functions that are functionally similar use quite different parameter types. >But I asked Alexandre about this, and he said the whole point of the DIB engine is >that you shouldn't need the locking. How that would work is beyond me, after all, >if you only draw on the client-side, you still have to upload the image to the X server >when you want it to become visible, but what about images that aren't double-buffered, >and what about mixed drawing with OpenGL? The idea is that once DIBs are entirely handled in the DIB engine, no locking is required anymore. Basically locking (and synchronization) is necessary since a DIB can be either handled through GDI functions or through direct memory access through its bitmap pointer. So for direct memory access whenever the DIB is in server mode it needs to be converted back to local mode before allowing access to the memory and when a display driver function is called to operate on a DIB the opposite needs to be done. The only synchronisation for DIBs when having a fully working DIB engine would be when the DIB is blitted to the display. There is possibly a complication with OpenGL and Direct3D here but I'm not sure about the details for that. Ge van Geldorp [EMAIL PROTECTED] wrote: >I was actually quite proud of that code generator and the code it produced. >The DIB code generator is absolutely clean, MS doesn't ship anything like it >so it's simply impossible that it was created using reverse engineering. I put >the code generator under the LGPL, specifically so it could be used by Wine >if so desired. Note that the scope of this is limited to BitBlt's though, it >won't help when you need to draw a 3-pixel wide dash-dotted ellips on your >DIB surface... Thanks Ge for this lengthy and good explanation. As to the drawing optimization I don't think that is a real trouble, certainly not to start with. Wine wants first something working correct and then one can decide if some fancy optimization for (dashed) lines, ellipses etc are at its place. Rolf Kalbermatter
