World Wine News

Dimi asked me to give a little status about the single sign-on summer of code project I was doing to the list, and I'm happy to oblige.

Applications running on win32 can use the Security Support Provider Interface (SSPI) to handle authentication via a number of protocols, like kerberos, NTLM, Negotiate and Schannel. My project was to implement the NTLM and Negotiate protocols, using Andrew Bartlett's GENSEC implementation from samba4.

Samba offers a command line tool to provide NTLM ( and, in samba 4, Negotiate ) style authentication for other programs, so my task was to get wine to use ntlm_auth.

Things that got done:

• Base64 codec
  ntlm_auth was first designed as a helper for squid. Squid talks to its helpers using base64, wine just had an encoder for it.
• Code to run ntlm_auth
  ntlm_auth doesn't store all the state information needed for the protocol handshake, so some wrapping code was needed.
• Code that implements the security support providers for NTLM and Negotiate.
  To make the sspi functions behave properly, the api functions have to do the right thing.

Work still left to do:

• Getting the code into cvs:
  While most of the code was already submitted to the wine-patches list, a lot of it was still in need of improvements. I'm currently working on this.
• Getting more of the stubs to actually do something.
  While the code that exists so far can handle the basic NTLM and Negotiate authentication, a lot of functions defined in the API still are stubs.

Conclusion:

As soon as the code is in cvs, wine should be able to do basic NTLM and Negotiate authentication, server and client side. Client side just requires ntlm_auth, server side also requires samba to be set up correctly, and when using samba 3, access to the winbindd named pipe for the user running wine.

Real use of this code seems limited, as most use cases also use the schannel protocol, which isn't implemented yet. Juan Lang is working on this, but needs to get more of crypt32 implemented for that.

I will continue to work on this, there's still a lot of providers to go.

I would like to use this summary to extend my thanks to Google and Chris DiBona for getting the whole Summer of Code set up.

Also, I'd like to thank you guys, particularly Juan, for the help I have received so far. It's really fun to work with the project, I hope to keep doing so for a while.

As some of you may have noticed, I did a bunch of theming-related work in Wine, which was done within a project in Google's Summer of Code.

This is a small overview over what I've done:

• All "non-standard" controls (those that are provided by comctl32, e.g.
Tabs) are themed and seem to work quite well so far.
• All standard controls except Buttons and Scrollbars are themed, though not always perfect.
• Due the fact that uxtheme was actually used, a number of fixes and improvements have been made.

However, there are still things left open:

• Bugs. Notably, the dreaded A->W WM_GETTEXTLENGTH issue breaking all Delphi apps. Working on it though.
• A number of smaller and not so small visual glitches.
• Speed. Seems with alpha blending things are not exactly blazing along.

At least for some of the issues I still have some ideas floating around, so I guess I'll stick around a bit longer and try to get them fixed.

Can someone who understands wine build issues review this RPM spec file for me, please?

The RPMs for RedHat 8 are getting pretty long in the tooth on the Wine downloads page... dating back to May 24. I wanted to build a source RPM to work with, so I modified the 20050524 spec file for 20050830.

It seems that there are changes in fonts and documentation. I removed some lines that were keeping rpmbuild from working. But I feel like I am tampering with issues beyond my grasp. Do the attached changes to the spec file look ok (temporarily marked with "todo")? Any gotchas? Anything missing?

Attached is the spec file I'm using for 20050830 on RH8 (not finished building on all other distributions yet).

--sysconfdir is not needed anymore by configure (harmless if present). dlls/wineps had an installable file not installed by default (fixed since then). See the diff for the rest of it, but your changes pretty much covered it.

The fonts part is because not everyone has fontforge installed, so I prefer to provide already built fonts. Not sure what was your problem with the fonts.

__wine_spec_stress_dll_fini': /home/phil/build/wine/dlls/kernel/stress.spec.c:297: undefined reference to __wine_call_from_16_long'

To fix the problem for me, instead of clean, I'd do the following command in wine tree:

rm */*/*.spec.*

After "cvs update" it no longer knew how to clean the tree.

make clean
cvs up
./configure ...
make depend
make

is the right sequence, and not

cvs up
./configure ...
make clean
make depend
make

I had a problem with Wine20050830 compilation.

Error: error parse before "BerElement";

in lines: 289, 290, 322, 323 in "wine/dlls/wldap32/winldap_private.h" file.

In file winldap.h I found declaration of BerElement type. This header is not included in winldap_private.h. I put declaration of BerElement type to winldap_private.h and it resolved the problem.

I tried add line: #include "winldap.h" to winldap.h too, but it makes double declaration errors.

1. Adding the Bugzilla entry as a news item is a good idea. However, we're possibly close to a September drop, so at this point it's probably easiest to just wait for that. I'm very open to adding news items to the front page, so definitely feel free to drop me an email when you think of things like that. How about WWN coverage instead?
2. CVS drops are just that - drops. They haven't been compiled on a bazillion systems or tested with real-world applications to ensure things aren't massively broken. Furthermore, no work was done to stabilize the release other than normal bug fixes. Instead, it represents a point in time where Alexandre ran the regression tests, things worked for him, and a tarball was made. There was discussion of that process changing after a beta release is made.
3. Binary packages are highly recommended unless you prefer to muck around occasionally with source code. That probably doesn't apply to you since you're reading wine-devel, but for 99% of the people in the world they should use the binaries. In theory we'll catch things at that point.

I updated CVS yesterday and then tried to run notes 6.51 and got this backtrace. It works fine with 20050726

$ wine ./nlnotes
fixme:uniscribe:ScriptGetProperties 0x61be3aa8,0x61be3a7c
fixme:uniscribe:ScriptRecordDigitSubstitution 1024,0x61be3a70
wine: Call from 0x4154ba5c to unimplemented function
usp10.dll.ScriptCacheGetHeight, aborting

OK, then a correct fix would involve implementing (or at least providing an implementation that "appears" to return valid data) the entry point (and any others used by Notes) rather than just providing a stub.

Unfortunately the documentation for the Uniscribe functions in MSDN is atrocious even by Microsoft standards. At a guess Notes has called ScriptGetFontProperties, which should populate the script variable.

Try the following (untested, may not even compile) as a starting point (You will need to fill out the ScriptFreeCache entry in the spec file).

I've got a weird issue and was wondering if anyone could advise on how to resolve. (Comes from a 16bit windows app, but is a more general debugging issue).

The problem is ...

1. If I run the application, it just hangs - no overly helpful information at all.
2. If I add WINEDEBUG +relay trace, it runs ok :-) (Workaround...!)
3. If I add anything else on WINEDEBUG other than relay, it fails
4. Running under winedbg didn't help at all - I could code to stop it before the hang but it wouldn't step through to the failure
5. Attaching to the hung process shows code in 16 bit user app, and winedbg didn't overly help there either

So - I've (painstakingly) got to the point of failure with the add of debug tracepoints and comparing the relay with the debug statements.

Now the odd bit!

If you look at dlls\user\wnd16.c, routine RegisterClass16 the final line is:

return RegisterClassEx16( &wcex );

If I change this to

fred = RegisterClassEx16( &wcex );
TRACE("Here... %d\n", fred);
return fred;

it all works.....!

How can I debug this further? I was thinking about trying to dump the registers before and after the trace statement, but I really can't think of what could be causing the problem!

This sounds like the stack is getting trashed. That is usually the case when randomly added functions make it not crash. You want to look for places where local variables (on the stack of course) are being overwritten. A good example of this is copying a larger string into a smaller local char array. When looking for a stack crasher, I comment out huge sections of code until it doesn't crash anymore, and then piece by piece uncomment the next function. For example,

void foo()
{
#if 0
a();
b();
c();
#endif
}

doesn't crash, but

void foo()
{
a();
#if 0
b();
c();
#endif
}

This winedbg stack trace (info stack) is equivalent to the examine command:

x /24x $esp

(24 words == 0x60 bytes). Change the repeat count from 24 to what you want. If there is a stack corruption, this way you can find out where and then you can add a watch point on it.