Wine Traffic Brian Vincent

This is the 289th issue of the Wine Weekly News publication. Its main goal is to start looking for new skis. 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
Controls Microsoft Frank Richter

I thought I'd take a look this week at the new theming support being added to Wine by Frank Richter. We've had a bunch of patches come in to improve support and it appears it's becoming quite usable. Unlike the older Microsoft Plus! style themes, the uxtheme engine supports special .msstyles files that can retheme all of the Windows controls. This is more or less the same kind of theming that modern Linux desktops have supported for years. Before showing some eye candy, I thought I'd write a quick list of steps you can follow if you'd like to try this out:

  1. Download a Windows XP theme. Be sure it contains a .msstyles file.
  2. Create a set of new directories in your fake Windows drive:
      $ mkdir -p ~/.wine/drive_c/windows/Resources/themes/name-of-your-theme
  3. Move the .msstyles to that new name-of-your-theme directory.
  4. Use the new Appearance tab of winecfg to select the new theme.

If you're curious what the theming looks like, here's a shot of winecfg's Drives tab showing lots of different controls. Of course it works with non-Winelib apps as well. Here's Word Viewer showing a document and drop down menu. All in all, theming seems to progressing nicely. The user interface in winecfg could use a little work, such as browsing for .msstyles files and automatically installing them, but considering the Appearance tab is only a week old it's understandable.

Integration

Kai Blin's work on getting Wine to authenticate with real Windows servers seems to be picking up. A lot of the base infrastructure seems to be in place and Kai's been trying to get a large patch in for about a week. His latest try seems to have broken the patch up into three different ones, but before he did that he described what it did:

base64_codec.c converts to and from base64 encoding, which is used by ntlm_auth.

dispatcher.c runs ntlm_auth to do authentication. This will also be used by the Negotiate provider. Fixed to close all file descriptors. Also won't use stdio anymore.

NTLM will authenticate clients against ntlm_auth. If it's a samba3 ntlm_auth, this requires access to the winbindd privileged pipe. Client side authentication in samba3 will work, it's broken in samba4's ntlm_auth, but will work there once ntlm_auth is fixed. Will also zero the password that is stored in the helper once it's not needed anymore.

This version also checks if ntlm_auth is in the right version. This check is not really needed for the NTLM provider, but as ntlm_auth in samba3 can't do Negotiate correctly, it will be more useful for Negotiate.

The tests have been updated to succeed on either SEC_E_OK and SEC_E_LOGON_DENIED, as both indicate that the tests ran correctly. That way the tests will work as long as ntlm_auth is present.

You can find more info about ntlm_auth on the Samba website.

Status Updates Jesse Allen

Ivan Leo Puoti has been working on Safedisc support for Wine and this week announced things have progressed, Safedisc1 now successfully passes all anti debugger check, and recognises the CD correctly. It then attempts to start the game, but this doesn't work yet because of the nested exception on signal stack bug. Hopefully we aren't too far from getting it to run.

I'm not familiar with the "nested exception on signal stack" bug, so I can't really fill any details in on that. Jesse Allen volunteered to test some games as the patch progresses. To help with narrowing down Safedisc copy protection, Oliver Stieber gave a pointer, There's a large list of copy protected games and the protection they use here http://www.gameburnworld.com/PCprotectedgames.htm, the site also has some details on other copy protection methods and tools to detect copy protection.

WineHQ WineHQ cvs

There's been a planned upgrade of WineHQ for about 4 months now. Jeremy Newman, webmaster/sys admin/and all-round guru, announced last week:

I will be taking the website offline tomorrow starting at 09:00 CDT (04:00 GMT). I will be moving it to a new ISP. Expect downtime to last for up to 8 hours as I will also be doing a complete reinstall of the OS. This will also affect the mailing lists and the CVS.

Last I talked with Newman, WineHQ would be switching to Debian. Updated versions of PHP will fix some of the bugs plaguing the AppDB developers. As Jeremy mentioned, a new ISP local to St. Paul, Minnesota will also go in place. Later in day Jeremy replied that the move had been postponed until the end of the month since the ISP wasn't ready.

So, at some point in the near future you can expect some downtime for WineHQ. Several people were concerned about that and thought a mirror should be set up, but really it doesn't appear to be worth the effort. Ivan Leo Puoti pointed out many things will be accessible:

Luckly we've got a CVS mirror, for those who didn't know, you can use the european mirror following these instructions

if you need CVS during the downtime. And google will kindly mirror the web pages too :-)

Glenn Wurster posted a patch with a changelog that read, Don't pass on non-continuable exceptions. It led Alexandre to ask why he wanted to do that. Glenn said:

In short, because we're never going to be able to continue, so there's no point on trying to pass because that's going to fail.

In long, because I've got another patch in the pipeline (it needs some tweaking) that moves the calling of the debugger into the signal handler. It allows the debugger to catch exceptions that would previously have resulted in a total crash (non-continuable exceptions), and it more accurately reflects how the Windows debugger is called. Using a debugger will also no longer modify program memory as it does currently. In all, it should allow the debugger to work in more circumstances than it currently does.

With regards to the exception handling, Alexandre disagreed, Not really, if the app handles the exception there's no reason it would fail. Not passing the exception will break things like IsBadReadPtr. He was skeptical Glenn could get the debugger to behave better. Glenn described more of what he was trying to do, I'm not looking to change exception handling at the application level, just trying to make the debugger work better. Again, EXCEPTION_NONCONTINUABLE was the wrong flag to check, EH_STACK_INVALID is what the revised patch checks, because exceptions with this flag will never make it to the application at all anyway.

He went on to describe more issues with the current handling of exceptions:

Doing SEH via the application stack is correct in the current code. Passing exceptions to the debugger via the application stack is not correct. I've attached a small C file which will demonstrate the problem. On windows, you can single step through the assembly code correctly, on Wine, you can not. The one conclusion that we can draw is that the method for calling the debugger on Windows must not use the application stack at all. Furthermore, if an exception does occur while the stack pointer is bad in windows, the debugger will trap it and let you examine the situation. Wine right now crashes.

Moving the calling of the debugger into the signal handler takes away the dependance on a correct signal stack. It lets us:

  1. Debug a program without having to modify it's memory to call the debugger.
  2. Set breakpoints and single step through areas where the stack pointer is incorrect.
  3. Use the debugger even when the application is at it's upper stack limit (so we can see where the stack overflow exists).
  4. Examine exceptions and application state when an exception is generated while stack pointer is bad.

All these can be done on Windows, and therefore sending events to the Windows debugger must be done without relying on the program stack. It would make sense for the wine debugger to be equally capable.

Now, if calling the debugger shifts positions to the signal stack, it is possible to detect whether we can deliver a corresponding SE to the applications SEH. If we can detect when the exception can not actually be delivered, then we can force the debugger to stop, even if this is the first notification of a excpetion to the debugger. The point behind the non-continuable change was to tell the debugger this. That patch was wrong. I should have used EH_STACK_INVALID (it would be impossible to even pass this flag to the debugger if the debugger relied on the application stack).

Alexandre was still skeptical, Sure, that would be nice, just be aware that it's not acceptable to break anything in the normal exception handling semantics, since that has to always take priority over the debugger support. Also note that we used to handle exceptions on the signal stack, and it was causing lots of problems, which is why I'm a bit skeptical. Now, doing only the first chance bit on the signal stack would probably be easier, but it's still far from trivial...

Fixes

Wine's IDL compiler, widl, has really improved over the past few years. More and more code is being generated with IDL than ever before. James Hawkins ran into a problem though:

I need to be able to include itss.h from dlls/itss in order to read CHM files. Mike offered the solution that I add -I($SRCDIR)../itss to hhctrl's Makefile.in. The next problem comes when I run make depend. make depend looks for itss.h but can't find it because it hasn't been built yet. Mike then suggested adding ../dlls/itss/itss.idl to IDL_SRCS in include/Makefile.in. That works fine up until make install which gives these two errors:

    /usr/bin/install: cannot create regular file `/usr/include/wine/windows/../dlls/itss/itss.idl': No such file or directory
    /usr/bin/install: cannot create regular file `/usr/include/wine/windows/../dlls/itss/itss.h': No such file or directory

Do you have any suggestions on how to access itss.h from hhctrl.ocx?

Alexandre had an easy solution, No, you can't do that sort of thing. You have to move the idl file to the include directory (probably in include/wine).

James Hawkins

Google's programs have been popular for Wine users and developers to play with. Picasa2 runs quite well as does the newer Google Earth (see WWN #281). This week Andrew Ramage tried out the new Google Talk, but ran into some problems:

Googletalk is a free chat program from Google with integrated VoIP. I installed the program and received a message saying Googletalk required Windows 2000, XP or 2003. The program started after installation and almost immewdiately crashed. Here is the output.

James Hawkins reported the particular error Andrew was seeing had been fixed in the latest CVS. Andrew tried again and this time ran into a different problem. So, as it stands, Google is 2 for 3 on their applications.