Wine Traffic #292 For 30 Sep 2005

By Brian Vincent

Table Of Contents

Introduction

This is the 292nd issue of the Wine Weekly News publication. Its main goal is to search for the DBA hat. It also serves to inform you of what's going on around Wine. Wine is an open source implementation of the Windows API on top of X and Unix. Think of it as a Windows compatibility layer. Wine does not require Microsoft Windows, as it is a completely alternative implementation consisting of 100% Microsoft-free code, but it can optionally use native system DLLs if they are available. You can find more info at www.winehq.org (http://www.winehq.org)

Mailing List Stats For This Week

We looked at 182 posts in 347K.

There were 70 different contributors. 41 posted more than once. 28 posted last week too.

The top posters of the week were:

1. Summer of Code Update: Single Sign-On

(1 post) Archive Link: "Single sign-on SoC project summary"

Topics: Status Updates

People: Kai BlinJuan LangAndrew Bartlettcvs

Kai Blin wrote in to give a status update of his Summer of Code project to implement authentication within Wine:

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:

Work still left to do:

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 implmented 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 recieved so far. It's really fun to work with the project, I hope to keep doing so for a while.

2. Summer of Code Update: Theming

(1 post) Archive Link: "Theming SoC outcome"

Topics: Status Updates

People: Frank Richter

Another Summer of Code project was to add theming to Wine. Frank Richter gave a status update of his project:

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:

However, there are still things left open:

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.

3. Red Hat/Fedora RPMs

(2 posts) Archive Link: "RH8 spec for 20050830"

Topics: Build Process

People: Michael OstVincent Beron

Have you downloaded a Wine RPM for Red Hat or Fedora lately? Hopefully not. Vincent Béron has been pretty busy and hasn't been able to build any for a few months. As a result, we've got some stale RPM's on SourceForge. Michael Ost seems to be interested in stepping up and building a recent version:

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?

Apparently Vincent has spent some time on it apparently:

Attached (http://www.winehq.com/pipermail/wine-devel/2005-September/040387.html) 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 a 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.

4. Build Changes

(8 posts) Archive Link: "build errors"

Topics: Build Process

People: Phil KrylovMarcelo DuarteMarcus MeissnerOliver Stiebercvs

Alexandre has been making some change to Wine's build system over the past few weeks. It's pretty far over my head and there's things like outputting the delayed import table using assembly. If that means nothing to you, don't worry. It doesn't mean much to me either. For the most part this process has been completely seamless. However, if you've run into problems building Wine recently it could be because of that. Phil Krylov reported a problem with a lot of errors that looked like:

Marcelo Duarte reported the quick fix:

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

Marcus Meissner gave another solution using make clean:

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

is the right sequence, and not

Oliver Stieber also noticed something else as a result of recent changes, " I can no longer use .so's from older builds of wine with the current tree (which means I have to merge all my local changes, and merge any regression tests). "

5. Compile Problems from Wine-20050830

(5 posts) Archive Link: "Problem Resolve"

Topics: Fixes

People: AnonymousBrian VincentWineHQ

Someone ran into a problem compiling last month's CVS drop of Wine. They explained the workaround:

I had a problem with Wine20050830 compilation.

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.

Molle Bestefich pointed out they should RTFM, or rather, search the mailing list archives and dig through Bugzilla first before posting on wine-devel. In this case the problem was obscure enough that posting to wine-devel was probably ok. However, Molle did have a good idea that showstopper items like that should be posted as news items on WineHQ. At this point it's a little late to include warnings for the August drop when September's is likely close. I replied back along those lines:

  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 bizillion 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.

6. Lotus Notes Breakage and Fix

(11 posts) Archive Link: "Wine CVS as of 9/25/2005 Kills Notes"

Topics:

People: Kevin DeKorteTroy RolloOliver StieberMicrosoft

Adding functionality to Wine can actually break things more than it fixes things sometimes. That's especially true when a new DLL gets added that consists mostly of "stubbed" functions that don't do anything other than return a value like TRUE. However, sometimes just getting a base DLL stubbed out can be a lot of work. It's been proven that implementing stubs is a good way to encourage others to actually turn the stubs into real functions. That seems to be the case for usp10.dll, the Uniscribe Script Processor.

Kevin DeKorte ran into a problem with Lotus Notes that included these errors:

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

Troy Rollo asked if it worked when Wine's builtin usp10.dll.so was deleted from /usr/local/lib/wine. Kevin reported that it did. Alternatively, Oliver Stieber suggested just disabling the DLL in the DLL overrides.

Troy blamed it on Wine's stub implementation and described the correct fix:

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 (http://mail.google.com/mail/?view=att&disp=attd&attid=0.1&th=106955b06dd806e2) (untested, may not even compile) as a starting point (You will need to fill out the ScriptFreeCache entry in the spec file).

7. Finding Stack Corruption

(8 posts) Archive Link: "Help debugging a problem!"

Topics: Debugging

People: Jason EdmeadesJames HawkinsRein KlazesJasonRein Klaze

Trying to track down bugs can be daunting in any project, let alone one the size of Wine. Jason Edmeades described a strange one this week and asked for help:

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:

If I change this to

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!

James Hawkins thought it smelled like stack corruption:

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,

doesn't crash, but

does crash, then your culprit is in a(). Then you recurse into a() and repeat the process all over again till you find the stack crasher.

After more investigation, it appeared more likely the issue was stack corruption. Rein Klazes suggested:

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

(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.

 

 

 

 

 

 

Sharon And Joy
 

Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at kernel.org. All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.