Hi folks,
after I implemented NTLM authentication using samba's ntlm_auth for last year's SOC, I'm considering entering again this year.
Now what I wanted to as was the following. I've recently started to look into the GENSEC library samba4 has to implement SSPI authentication and signing/sealing, as the latter is impossible to do with ntlm_auth. Now, would you consider this to be too cheesy to do as a project for summer of code? If yes, I would of course try to think of something else I can do, but I'd really like to see SSPI doing all that's possible on win32 one day. And I think GENSEC is the way to go.
So far this has the issue of GENSEC not being under the LGPL, but I've already talked to Andrew Bartlett about this, and I'm currently writing a proof of concept application that GENSEC is usable from outside the samba source. Once I have that talking to SSPI on the windows side, I guess I can convince him to relicense GENSEC as LGPL.
The backup plan to that would be to add a small wrapper program and use a stdio interface to GENSEC similar to the solution with ntlm_auth now.
Cheers, Kai
* Kai Blin blin@gmx.net [17/04/06, 20:44:30]:
Now what I wanted to as was the following. I've recently started to look into the GENSEC library samba4 has to implement SSPI authentication and signing/sealing, as the latter is impossible to do with ntlm_auth. Now, would you consider this to be too cheesy to do as a project for summer of code? If yes, I would of course try to think of something else I can do, but I'd really like to see SSPI doing all that's possible on win32 one day. And I think GENSEC is the way to go.
Judging from the lack of feedback as compared to the other proposals, I guess you don't like it. I'll go look for something else then.
Kai
When you hang around just a while on wine's IRC channel you'll see that(i'd guess) more than 50% of the user's questions is about how to get their games running. I think it would be cool if there would be some proposals for SOC project to get better DirectX(/wined3d) support. From the wine-users point of view i think that's what they want :) I'm sure some of the developers that currently work on wined3d can think of proposals that students could work on. At least , wouldn't be fixing bug 2398 be an idea for SOC?
Hi,
On Wed, Apr 19, 2006 at 08:35:41AM +0000, Louis Lenders wrote:
When you hang around just a while on wine's IRC channel you'll see that(i'd guess) more than 50% of the user's questions is about how to get their games running. I think it would be cool if there would be some proposals for SOC project to get better DirectX(/wined3d) support. From the wine-users point of view i think that's what they want :) I'm sure some of the developers that currently work on wined3d can think of proposals that students could work on. At least , wouldn't be fixing bug 2398 be an idea for SOC?
Yes please! Gaming is one of the major deterrents of wider Linux desktop use, so any positive development in this area is very nice.
Andreas Mohr
Am Mittwoch, 19. April 2006 10:44 schrieb Andreas Mohr:
Hi,
On Wed, Apr 19, 2006 at 08:35:41AM +0000, Louis Lenders wrote:
When you hang around just a while on wine's IRC channel you'll see that(i'd guess) more than 50% of the user's questions is about how to get their games running. I think it would be cool if there would be some proposals for SOC project to get better DirectX(/wined3d) support. From the wine-users point of view i think that's what they want :) I'm sure some of the developers that currently work on wined3d can think of proposals that students could work on. At least , wouldn't be fixing bug 2398 be an idea for SOC?
Yes please! Gaming is one of the major deterrents of wider Linux desktop use, so any positive development in this area is very nice.
Andreas Mohr
I'd guess the DIB engine proposal would help there as well. One of the most important improvements, IMHO. Windowed OpenGL support would be nice as well, for game level editors (and many other things)... :-)
On Wed, Apr 19, 2006 at 10:59:14AM +0200, Willie Sippel wrote:
I'd guess the DIB engine proposal would help there as well. One of the most important improvements, IMHO. Windowed OpenGL support would be nice as well, for game level editors (and many other things)... :-)
The DIB engine would only help some games (from my experience, I would guess 5 % of the old DirectX <= 7 games which uses GetDC). For all other games, it has absolutely no impact at all.
Lionel
On Wednesday 19 April 2006 20:26, Lionel Ulmer wrote:
On Wed, Apr 19, 2006 at 10:59:14AM +0200, Willie Sippel wrote:
I'd guess the DIB engine proposal would help there as well. One of the most important improvements, IMHO. Windowed OpenGL support would be nice as well, for game level editors (and many other things)... :-)
The DIB engine would only help some games (from my experience, I would guess 5 % of the old DirectX <= 7 games which uses GetDC). For all other games, it has absolutely no impact at all.
But MS thought about you:
new Dx9 APIs: IDirect3DSurface9::GetDC IDirect3DSurface9::ReleaseDC
Anyway fixing the DIB engine will improve a lot professional applications as photoshop, ...
Lionel
Regards, Raphael
On Wed, Apr 19, 2006 at 11:07:43PM +0200, Raphael wrote:
new Dx9 APIs: IDirect3DSurface9::GetDC IDirect3DSurface9::ReleaseDC
Yeah I suppose that they exist... But as it's a stub for now, I suppose that not many application require it :-)
Anyway fixing the DIB engine will improve a lot professional applications as photoshop, ...
Sure it does. I just wanted to point out the fact the the DIB engine is not the silver bullet that will make all games work faster (as many people seem to believe).
Lionel
Am Mittwoch, 19. April 2006 22:51 schrieb Lionel Ulmer:
On Wed, Apr 19, 2006 at 11:07:43PM +0200, Raphael wrote:
new Dx9 APIs: IDirect3DSurface9::GetDC IDirect3DSurface9::ReleaseDC
Yeah I suppose that they exist... But as it's a stub for now, I suppose that not many application require it :-)
Anyway fixing the DIB engine will improve a lot professional applications as photoshop, ...
Sure it does. I just wanted to point out the fact the the DIB engine is not the silver bullet that will make all games work faster (as many people seem to believe).
Sorry, didn't know that there aren't many games that would benefit. Still, a DIB engine would be great, it would fix quite visual glitches in certain applications. I also tested a few applications recently (audio apps, no games) that were unusable slow with X at almost 100% CPU load on every interface redraw - I guess that's an issue the DIB engine would fix...?
Willie Sippel wrote:
Still, a DIB engine would be great, it would fix quite visual glitches in certain applications. I also tested a few applications recently (audio apps, no games) that were unusable slow with X at almost 100% CPU load on every interface redraw - I guess that's an issue the DIB engine would fix...?
*cross fingers*, would it fix Shockwave Player running in Firefox?
It's currently _*horribly*_ slow compared to running it under VMware..
On 4/19/06, Raphael fenix@club-internet.fr wrote:
Anyway fixing the DIB engine will improve a lot professional applications as photoshop, ...
The big one for me is powerpoint. OpenOffice just does not cut it with presentations and powerpoint is still quite slow under Wine.
-- Steven Edwards
"There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
* Louis Lenders xerox_xerox2000@yahoo.co.uk [19/04/06, 08:35:41]:
When you hang around just a while on wine's IRC channel you'll see that(i'd guess) more than 50% of the user's questions is about how to get their games running. I think it would be cool if there would be some proposals for SOC project to get better DirectX(/wined3d) support. From the wine-users point of view i think that's what they want :)
So you're basically suggesting to just cover the "sexy" topics?
I'm sure some of the developers that currently work on wined3d can think of proposals that students could work on. At least , wouldn't be fixing bug 2398 be an idea for SOC?
While sticking to bug fixing will help the project to, well, get bugs fixed, I think that summer of code could be used to have some people work on some more experimental (and fun) projects. Now, don't get me wrong, fixing bugs is an important part of software development, but it's something you'll regularly do in software development.
Just my thoughts on that, of course.
Cheers, Kai
On Wed, Apr 19, 2006 at 08:35:41AM +0000, Louis Lenders wrote:
what they want :) I'm sure some of the developers that currently work on wined3d can think of proposals that students could work on. At least , wouldn't be fixing bug 2398 be an idea for SOC?
Well, I do not really see the link between game and this bug... Bug 2398 does not affect any game at all (the only thing game-related it affects is the NVM toolset AFAIK).
Moreover, fixing this may introduce some performance hit in the 'normal' GL code (a bit like Huw's patch for GL on DIB rendering) so it may actually be seen as a regression for gamers :-)
Lionel
Lionel Ulmer <lionel.ulmer <at> free.fr> writes:
On Wed, Apr 19, 2006 at 08:35:41AM +0000, Louis Lenders wrote: wouldn't be fixing bug 2398 be an idea for SOC?
Well, I do not really see the link between game and this bug... Bug 2398 does not affect any game at all (the only thing game-related it affects is the NVM toolset AFAIK).
It's not like that the bug should be fixed for gaming, but just because it's a major pain. That's why i thought it was a good idea for SOC. I just tested Stefan Dosinger patches and looks like this bug is also going to affect all ddraw applications as soon as they get merged (Videolan player works well with the patches but the rest of my screen turns black completely :( )
Moreover, fixing this may introduce some performance hit in the 'normal' GL code (a bit like Huw's patch for GL on DIB rendering) so it may actually be seen as a regression for gamers
Lionel
Am Dienstag, 25. April 2006 15:38 schrieb Louis Lenders:
Lionel Ulmer <lionel.ulmer <at> free.fr> writes:
On Wed, Apr 19, 2006 at 08:35:41AM +0000, Louis Lenders wrote: wouldn't be fixing bug 2398 be an idea for SOC?
Well, I do not really see the link between game and this bug... Bug 2398 does not affect any game at all (the only thing game-related it affects is the NVM toolset AFAIK).
It's not like that the bug should be fixed for gaming, but just because it's a major pain. That's why i thought it was a good idea for SOC. I just tested Stefan Dosinger patches and looks like this bug is also going to affect all ddraw applications as soon as they get merged (Videolan player works well with the patches but the rest of my screen turns black completely :( )
I'm with you. This is the single most annoying regression I've ever seen in Wine. As this seems to be top-priority anyway, it's one of the best possible SOC candidates (this and a DIB engine), given that most regular devs that might be able to fix the regression don't seem all too motivated to really touch that issue. Who cares if games take a slight performance hit, if a fix would unbreak lots and lots of applications that used to work - an acceptable tradeoff, IMHO...
Moreover, fixing this may introduce some performance hit in the 'normal' GL code (a bit like Huw's patch for GL on DIB rendering) so it may actually be seen as a regression for gamers
Lionel
Hi,
I'm with you. This is the single most annoying regression I've ever seen in Wine. As this seems to be top-priority anyway, it's one of the best possible SOC candidates (this and a DIB engine), given that most regular devs that might be able to fix the regression don't seem all too motivated to really touch that issue. Who cares if games take a slight performance hit, if a fix would unbreak lots and lots of applications that used to work
- an acceptable tradeoff, IMHO...
If you are talking about the pbuffer way, and I understand this correctly, then this wouldn't be a slight hit, but a major performance loss. I think the solution would be to render to an offscreen texture. This would mean to copy the rendered image back to main memory, copying it through the cpu and then sending it back to the card. For a 1024x768x32 image this are 3 megabytes per frame.
The current directdraw code handles it this way for windowed direct3d rendering. I can get about 20 fps with moto racer 2 in windoed mode at 512x384 on my radeon mobility M9. If the game wouldn't cap the speed at 35fps, I'd expect it to achieve 200fps on the same hardware(it's a very old Direct3d1 game).
For fullscreen mode we could still use the normal rendering way, but windowed apps still wouldn't work very well.
Am Dienstag, 25. April 2006 18:03 schrieb Stefan Dösinger:
Hi,
I'm with you. This is the single most annoying regression I've ever seen in Wine. As this seems to be top-priority anyway, it's one of the best possible SOC candidates (this and a DIB engine), given that most regular devs that might be able to fix the regression don't seem all too motivated to really touch that issue. Who cares if games take a slight performance hit, if a fix would unbreak lots and lots of applications that used to work - an acceptable tradeoff, IMHO...
If you are talking about the pbuffer way, and I understand this correctly, then this wouldn't be a slight hit, but a major performance loss. I think the solution would be to render to an offscreen texture. This would mean to copy the rendered image back to main memory, copying it through the cpu and then sending it back to the card. For a 1024x768x32 image this are 3 megabytes per frame.
AFAIK, there are four targets OpenGL can draw to on X: X windows, Pbuffers, FBOs or GLX pixmaps. EXT_framebuffer_object should be the most interesting approach, as it's supposed to somewhat similar to Pbuffer rendering, but supposed to be more portable and faster: "This extension defines a simple interface for drawing to rendering destinations other than the buffers provided to the GL by the window-system." But I guess a FBO or a GLX pixmap would still introduce a similar performance hit compared to Pbuffer rendering?
Forest Hale (and Lionel Ulmer) suggested a different, but probably more hacky and difficult approach (from http://wiki.winehq.org/OpenGL): "I would recommend overriding the glViewPort and glScissor calls, as well as gl[En/Dis]able GL_SCISSOR_TEST, and arrange the glViewPort for the proper projection for rendering, but use glScissor to set the region that can be rendered in the current DC, also there should be no slowdown from having scissor test permanently on."
Another practical way to handle the issue would be to partially restore the old WM handling, and draw only OpenGL viewports to seperate X windows (if it's possible for Wine to determine what viewport uses OpenGL).
The current directdraw code handles it this way for windowed direct3d rendering. I can get about 20 fps with moto racer 2 in windoed mode at 512x384 on my radeon mobility M9. If the game wouldn't cap the speed at 35fps, I'd expect it to achieve 200fps on the same hardware(it's a very old Direct3d1 game).
For fullscreen mode we could still use the normal rendering way, but windowed apps still wouldn't work very well.
Sorry, I don't get this. Windowed applications should not be affected? There is no problem with windowed OpenGL applications, they are not affected by bug 2398 anyway. Only applications with embedded OpenGL viewports are affected, so a workaround would only need to target embedded viewports...?
Hi,
AFAIK, there are four targets OpenGL can draw to on X: X windows, Pbuffers, FBOs or GLX pixmaps. EXT_framebuffer_object should be the most interesting approach, as it's supposed to somewhat similar to Pbuffer rendering, but supposed to be more portable and faster: "This extension defines a simple interface for drawing to rendering destinations other than the buffers provided to the GL by the window-system." But I guess a FBO or a GLX pixmap would still introduce a similar performance hit compared to Pbuffer rendering?
FBOs are very interesting for this, but the mail performance issue is to read back from the video card. Video cards are mainly output devices, reading from them is slow. AFAIK the driver even has to use PCI transfers for that, because AGP isn't designed for reading back data. I could be wrong with this, and I don't know how PCIe affects this.
Forest Hale (and Lionel Ulmer) suggested a different, but probably more hacky and difficult approach (from http://wiki.winehq.org/OpenGL): "I would recommend overriding the glViewPort and glScissor calls, as well as gl[En/Dis]able GL_SCISSOR_TEST, and arrange the glViewPort for the proper projection for rendering, but use glScissor to set the region that can be rendered in the current DC, also there should be no slowdown from having scissor test permanently on."
That is the plan for Direct3D, where I consider that easier because WineD3D can control GL, without the chance that the app does opengl calls which interfere.
Sorry, I don't get this. Windowed applications should not be affected? There is no problem with windowed OpenGL applications, they are not affected by bug 2398 anyway. Only applications with embedded OpenGL viewports are affected, so a workaround would only need to target embedded viewports...?
This comes from the way DirectDraw apps handle windowed Direct3D. See my description for the IWineD3DDevice::SetFrontBackBuffers call: http://article.gmane.org/gmane.comp.emulators.wine.patches/23491
Stefan
Am Dienstag, 25. April 2006 19:20 schrieb Stefan Dösinger:
Hi,
AFAIK, there are four targets OpenGL can draw to on X: X windows, Pbuffers, FBOs or GLX pixmaps. EXT_framebuffer_object should be the most interesting approach, as it's supposed to somewhat similar to Pbuffer rendering, but supposed to be more portable and faster: "This extension defines a simple interface for drawing to rendering destinations other than the buffers provided to the GL by the window-system." But I guess a FBO or a GLX pixmap would still introduce a similar performance hit compared to Pbuffer rendering?
FBOs are very interesting for this, but the mail performance issue is to read back from the video card. Video cards are mainly output devices, reading from them is slow. AFAIK the driver even has to use PCI transfers for that, because AGP isn't designed for reading back data. I could be wrong with this, and I don't know how PCIe affects this.
Probably got something wrong, but FBOs are supposed to be very fast, exactly because you _don't_ have to read the data back? It also needs no context switches, and it's supposed to work on pretty much all graphic cards, even very old ones.
Here's a small presentation by Simon Green/ Nvidia, including comparison between FBOs, Pbuffers and WGL_ARB_render_to_texture: http://download.nvidia.com/developer/presentations/2005/GDC/OpenGL_Day/OpenG...
And a small overview, also by Simon Green: http://www.gamedev.net/columns/events/coverage/feature.asp?feature_id=75
On Tuesday 25 April 2006 17:26, Willie Sippel wrote:
Am Dienstag, 25. April 2006 15:38 schrieb Louis Lenders:
Lionel Ulmer <lionel.ulmer <at> free.fr> writes:
On Wed, Apr 19, 2006 at 08:35:41AM +0000, Louis Lenders wrote: wouldn't be fixing bug 2398 be an idea for SOC?
Well, I do not really see the link between game and this bug... Bug 2398 does not affect any game at all (the only thing game-related it affects is the NVM toolset AFAIK).
It's not like that the bug should be fixed for gaming, but just because it's a major pain. That's why i thought it was a good idea for SOC. I just tested Stefan Dosinger patches and looks like this bug is also going to affect all ddraw applications as soon as they get merged (Videolan player works well with the patches but the rest of my screen turns black completely :( )
I'm with you. This is the single most annoying regression I've ever seen in Wine. As this seems to be top-priority anyway, it's one of the best possible SOC candidates (this and a DIB engine), given that most regular devs that might be able to fix the regression don't seem all too motivated to really touch that issue. Who cares if games take a slight performance hit, if a fix would unbreak lots and lots of applications that used to work
- an acceptable tradeoff, IMHO...
Well implemented OpenGL applications works: http://nehe.gamedev.net/data/lessons/lesson.asp?lesson=42
if anyone can find a simple sample who reproduce the problem we can look how to fix it (and if impact can be sufficient for a SoC project)
Regards, Raphael
Am Mittwoch, 26. April 2006 01:10 schrieb Raphael:
On Tuesday 25 April 2006 17:26, Willie Sippel wrote:
Am Dienstag, 25. April 2006 15:38 schrieb Louis Lenders:
Lionel Ulmer <lionel.ulmer <at> free.fr> writes:
On Wed, Apr 19, 2006 at 08:35:41AM +0000, Louis Lenders wrote: wouldn't be fixing bug 2398 be an idea for SOC?
Well, I do not really see the link between game and this bug... Bug 2398 does not affect any game at all (the only thing game-related it affects is the NVM toolset AFAIK).
It's not like that the bug should be fixed for gaming, but just because it's a major pain. That's why i thought it was a good idea for SOC. I just tested Stefan Dosinger patches and looks like this bug is also going to affect all ddraw applications as soon as they get merged (Videolan player works well with the patches but the rest of my screen turns black completely :( )
I'm with you. This is the single most annoying regression I've ever seen in Wine. As this seems to be top-priority anyway, it's one of the best possible SOC candidates (this and a DIB engine), given that most regular devs that might be able to fix the regression don't seem all too motivated to really touch that issue. Who cares if games take a slight performance hit, if a fix would unbreak lots and lots of applications that used to work - an acceptable tradeoff, IMHO...
Well implemented OpenGL applications works: http://nehe.gamedev.net/data/lessons/lesson.asp?lesson=42
if anyone can find a simple sample who reproduce the problem we can look how to fix it (and if impact can be sufficient for a SoC project)
The bug report lists quite a few applications that show the problem. Sorry, I don't know any simple sample, but a few freeware applications and demos affected by the regression, for example: DAZ|Studio: http://studio.daz3d.com/ Luxology Modo: http://luxology.com/user/secure/eval/account.aspx
A few open source applications might be affected as well, But I can't test anything myself anymore, due to another OpenGL regression (BadMatch/ X_GLXMakeCurrent). SharpConstruct: http://sharp3d.sourceforge.net/ Wings 3d: http://www.wings3d.com/
On Wednesday 26 April 2006 00:53, Willie Sippel wrote:
Am Mittwoch, 26. April 2006 01:10 schrieb Raphael:
On Tuesday 25 April 2006 17:26, Willie Sippel wrote:
Am Dienstag, 25. April 2006 15:38 schrieb Louis Lenders:
Lionel Ulmer <lionel.ulmer <at> free.fr> writes:
On Wed, Apr 19, 2006 at 08:35:41AM +0000, Louis Lenders wrote: wouldn't be fixing bug 2398 be an idea for SOC?
Well, I do not really see the link between game and this bug... Bug 2398 does not affect any game at all (the only thing game-related it affects is the NVM toolset AFAIK).
It's not like that the bug should be fixed for gaming, but just because it's a major pain. That's why i thought it was a good idea for SOC. I just tested Stefan Dosinger patches and looks like this bug is also going to affect all ddraw applications as soon as they get merged (Videolan player works well with the patches but the rest of my screen turns black completely :( )
I'm with you. This is the single most annoying regression I've ever seen in Wine. As this seems to be top-priority anyway, it's one of the best possible SOC candidates (this and a DIB engine), given that most regular devs that might be able to fix the regression don't seem all too motivated to really touch that issue. Who cares if games take a slight performance hit, if a fix would unbreak lots and lots of applications that used to work - an acceptable tradeoff, IMHO...
Well implemented OpenGL applications works: http://nehe.gamedev.net/data/lessons/lesson.asp?lesson=42
if anyone can find a simple sample who reproduce the problem we can look how to fix it (and if impact can be sufficient for a SoC project)
The bug report lists quite a few applications that show the problem. Sorry, I don't know any simple sample, but a few freeware applications and demos affected by the regression, for example: DAZ|Studio: http://studio.daz3d.com/ Luxology Modo: http://luxology.com/user/secure/eval/account.aspx
A few open source applications might be affected as well, But I can't test anything myself anymore, due to another OpenGL regression (BadMatch/ X_GLXMakeCurrent).
Well this make me .... :(
Maybe one day i'll get the time to fix it. You can try that patch (hack for tests) to by-pass problem (but PBuffers will not work)
Regards, Raphael
Am Dienstag, 25. April 2006 15:38 schrieb Louis Lenders:
Lionel Ulmer <lionel.ulmer <at> free.fr> writes:
On Wed, Apr 19, 2006 at 08:35:41AM +0000, Louis Lenders wrote: wouldn't be fixing bug 2398 be an idea for SOC?
Well, I do not really see the link between game and this bug... Bug 2398 does not affect any game at all (the only thing game-related it affects is the NVM toolset AFAIK).
It's not like that the bug should be fixed for gaming, but just because it's a major pain. That's why i thought it was a good idea for SOC. I just tested Stefan Dosinger patches and looks like this bug is also going to affect all ddraw applications as soon as they get merged (Videolan player works well with the patches but the rest of my screen turns black completely :( )
This will indeed affect direct3d7 apps when they render in windowed mode, just as it already affects d3d8 and d3d9 apps nowadays. But for D3D, this can be easier fixed because WineD3D has full control over the gl viewport. I expect that this can work around the placement issue and size of the rendering, but not the problems with overlapping.
OpenGL accelerated DirectDraw(2D) won't work for windowed rendering, because apps render to a normal offscreen surface then, and it will be very tricky and prone to errors to detect which surface to use as the opengl back buffer. However, the usual software directdraw should work as usual, and full screen ddraw can be accelerated with opengl.
On 19/04/06, Louis Lenders xerox_xerox2000@yahoo.co.uk wrote:
I'm sure some of the developers that currently work on wined3d can think of proposals that students could work on.
I think some of the features in NVPerfHUD would be quite usefull for debugging wined3d code.
Kai Blin wrote:
- Kai Blin blin@gmx.net [17/04/06, 20:44:30]:
Now what I wanted to as was the following. I've recently started to look into the GENSEC library samba4 has to implement SSPI authentication and signing/sealing, as the latter is impossible to do with ntlm_auth. Now, would you consider this to be too cheesy to do as a project for summer of code? If yes, I would of course try to think of something else I can do, but I'd really like to see SSPI doing all that's possible on win32 one day. And I think GENSEC is the way to go.
Judging from the lack of feedback as compared to the other proposals, I guess you don't like it. I'll go look for something else then.
I do not think it's a matter of liking it or not but that's a part of Wine that probably only you and Juan Lang are familiar with. From the perspective of the $HOME user it isn't usefull for them but what about the business Wine users? That question can be probably answered by the Codeweaver guys and Dan Kegel.
bye michael
* Michael Stefaniuc mstefani@redhat.com [19/04/06, 11:17:10]:
Judging from the lack of feedback as compared to the other proposals, I guess you don't like it. I'll go look for something else then.
I do not think it's a matter of liking it or not but that's a part of Wine that probably only you and Juan Lang are familiar with. From the perspective of the $HOME user it isn't usefull for them but what about the business Wine users? That question can be probably answered by the Codeweaver guys and Dan Kegel.
Judging from what Jeremy White said, it's needed to fully support Outlook 2003 talking to an Exchange server.
I think the interesting part about this is that getting Wine to use GENSEC will be a step to making more linux based apps zero in on that library when they need to do windows auth things. I think this is preferable to every developer reinventing the wheel every time.
But I guess you are right, this doesn't really concern the end user, whereas "Can I run my game" does, pretty much.
Cheers, Kai
Kai Blin wrote:
- Kai Blin blin@gmx.net [17/04/06, 20:44:30]:
Now what I wanted to as was the following. I've recently started to look into the GENSEC library samba4 has to implement SSPI authentication and signing/sealing, as the latter is impossible to do with ntlm_auth. Now, would you consider this to be too cheesy to do as a project for summer of code? If yes, I would of course try to think of something else I can do, but I'd really like to see SSPI doing all that's possible on win32 one day. And I think GENSEC is the way to go.
Judging from the lack of feedback as compared to the other proposals, I guess you don't like it. I'll go look for something else then.
Kai
Kai, don't feel bad. I actually do think it is a good idea, but to me it looks like you are describing a proposal that will end up going into samba's tree, not ours. If you could clarify what this will do for wine, I think you might generate a lil more contructive activity (vs "yes please implement more game stuff!").
Tom
* "Tom Spear (Dustin Booker, Dustin Navea)" speeddymon@gmail.com [19/04/06, 05:52:32]:
Kai, don't feel bad. I actually do think it is a good idea, but to me it looks like you are describing a proposal that will end up going into samba's tree, not ours. If you could clarify what this will do for wine, I think you might generate a lil more contructive activity (vs "yes please implement more game stuff!").
Sure, easy thing.
So far (since SOC 2005) wine implements SSPI authentication for NTLM (and Negotiate, in theory, but that patch never made it) via a tool provided by Samba, called ntlm_auth.
The problem with this approach is that ntlm_auth was never meant to do much besides NTLM authentication for Squid. For anything besides authenticating, ntlm_auth isn't feasible. This could of course be fixed by hacking more functionality into ntlm_auth, but the Samba developers already said they wouldn't accept patches that bloat ntlm_auth more than it already is.
The OpenSource reaction to this would be forking the Samba4 code and doing your own version, but I doubt that really is feasible. Especially as you would then conflict with existing Samba installations.
Now, Samba4 exposes all this authentication/communication code in a library you can load from an external program. Using this library to handle authentication wouldn't change to the current setup. But when using the library it's possible to do more than authentication, like signing packages to make sure they were not tampered with and sealing packages to make sure noone reads their content. Outlook 2003 seems to use that.
As mentioned before, the only problem about this setup is that so far GENSEC is only available under the GNU GPL and thus not directly useable. The Samba people (Andrew Bartlett et al.) indicated that if that was the only thing stopping us from using the lib, they would relicense it to LGPL for us.
The benefits for Wine would be the following: An easy way to implement the SSPI providers for NTLM, Negotiate, Schannel and Kerberos, as those are handled by GENSEC. (We might decide to go our own way for Schannel and Kerberos, Juan Lang might be able to comment on that, he's working on the crypt32 api Schannel can alternatively be built on). As GENSEC is a seperate library, it doesn't need the rest of Samba4 installed, so it can be packaged extra. This way Wine + Gensec would give you a platform to run your SSPI things on, as opposed to Wine + Samba4, which might conflict with and already installed samba3 install. Samba4 as a whole will not be released for any time soon.
Whew, this got bigger than I expected. Kai
On Wed, 19 Apr 2006 09:26:18 +0200, Kai Blin wrote:
Judging from the lack of feedback as compared to the other proposals, I guess you don't like it. I'll go look for something else then.
I think it's more that most of us don't understand that part of the code ;)
* Mike Hearn mike@plan99.net [19/04/06, 12:57:00]:
On Wed, 19 Apr 2006 09:26:18 +0200, Kai Blin wrote:
Judging from the lack of feedback as compared to the other proposals, I guess you don't like it. I'll go look for something else then.
I think it's more that most of us don't understand that part of the code ;)
Still I would expect that answers like "To make SOC interesting, pick something else" or "Sounds interesting enough, why don't you write up the proposal" or at least some comments would pop up. Like they are now.
Cheers, Kai
Kai Blin wrote:
- Kai Blin blin@gmx.net [17/04/06, 20:44:30]:
Now what I wanted to as was the following. I've recently started to look into the GENSEC library samba4 has to implement SSPI authentication and signing/sealing, as the latter is impossible to do with ntlm_auth. Now, would you consider this to be too cheesy to do as a project for summer of code? If yes, I would of course try to think of something else I can do, but I'd really like to see SSPI doing all that's possible on win32 one day. And I think GENSEC is the way to go.
Judging from the lack of feedback as compared to the other proposals, I guess you don't like it. I'll go look for something else then.
Whoa nelly. I would not say that at all. Just because it didn't get anyone skimming the list excited, you shouldn't get discouraged. Some of the more important changes in Wine were awfully unsexy, frankly.
In fact, that reminds me that I should probably instigate something a bit more official looking. /me starts new thread.
Cheers,
Jeremy
* Jeremy White jwhite@winehq.org [19/04/06, 08:24:33]:
Whoa nelly. I would not say that at all. Just because it didn't get anyone skimming the list excited, you shouldn't get discouraged. Some of the more important changes in Wine were awfully unsexy, frankly.
Yeah, I think I overreacted a bit, sorry. I was just a bit anxious to get my application for SOC sorted out in a more timely manner than last year, where I heard about it two days before they stopped accepting proposals. I'll apply with getting SSPI more fleshed out anyway, I did get some feedback now, after all.
Sorry about the fuss. Kai
-
Andreas Mohr -
H. Verbeet -
Jeremy White -
Kai Blin -
Lionel Ulmer -
Louis Lenders -
Michael Stefaniuc -
Mike Hearn -
Molle Bestefich -
Raphael -
Stefan Dösinger -
Steven Edwards -
Tom Spear (Dustin Booker, Dustin Navea) -
Willie Sippel