Wine Traffic Brian Vincent

This is the 284th issue of the Wine Weekly News publication. Its main goal is to lose trailers. 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
News codeweavers Microsoft News

CodeWeavers has thrown down the gauntlet. Program installation, a long time thorn in the side of Wine users, is getting some attention. CodeWeavers announced plans to get any installer running under Wine. If your favorite program doesn't install, then contact CodeWeavers and they'll promise to fix the bugs in Wine and make it work. In return, you'll have to use their test framework to make sure regressions don't slip in later that breaks things.

The press release outlines the goals of the project. For information about how to get involved, check out the installer challenge page. From that page:

We are on a mission to improve Wine until it can run nearly every Windows program, and we would like your help.

Over the past year we've completed support for a set of technologies key to making Windows applications install: the Component Object Model (COM aka OLE) DLLs and the Microsoft Installer service (MSI). That work is now largely done, and we would like to start taking advantage of it to showcase what Wine can do.

The basic idea is that if you send us a piece of software, we will commit to making it install. In exchange, we need you to promise to run a regression test of that installation, thereby insuring that it continues to install into the future.

RPC / COM / OLE CodeWeavers Uwe Bonnes Dimi Paun Codeweavers

Jeremy White sent a long email to wine-devel to discuss the big projects tackled by Codeweavers over the past few months:

You may have noticed Rob submitting a long string of OLE patches.

That is formally the last set of 'hard work' we planned to do as part of our work on our 5.0 release. Now we just have to do the 'easy part' - stabilizing for release &<g&>.

The big picture items included the window manager rewrite, the OLE/COM work, and the work on MSI.

I'd like to take a minute to thank all the people, both inside and outside CodeWeavers, that helped to work on these projects.

I think that these tasks represent a fairly signficant milestone for Wine - we seem to have enough working that Alexandre is willing to contemplate a non alpha release; that's a pretty big deal. (Another 11 years, and maybe 1.0 will actually happen :-/).

At any rate, this work has been a bit hard on us, because it's largely been under the hood, unsexy work that tends to cause regressions. So from a customer perspective, the rational analysis is: "you did all that work and now my windows don't scroll right? Morons!"

But one of the key benefits that the OLE/MSI work gives us, in particular, is that we can now intelligently debug issues with COM, which was always a nightmare to debug before.

And, as you all probably know, many installers rely heavily on both COM and MSI to do their work.

So we now believe that many, many more installers will 'just work' than before. And we further believe that those that don't work can be fixed in a much more straightforward way.

Thus, I am now making good on my promise to lock Rob and Aric in a room and make installers go. We've announced a formal, CrossOver based program over on our web site. However, I wanted to let you know that we'll do the same on an informal basis, particularly for known Wine developers.

I'm hoping that as a result of this work we'll soon be able to claim with a straight face: "Most things install."

So, if you have an app that doesn't install, post a message to wine-devel, and let's see if we can't make some lemonade and have a party!

That long string of patches mentioned by Jeremy hit wine-patches at almost the exact same time as the announcement. It consisted of 16 patches touching on all sorts of DCOM stuff way over my head and using words like marshal and ITypeInfo. For for those of you just tuning in, this seems to be the culmination of about nine months of work. Last November a big push began to overhaul DCOM with a lot of major changes. In reality, DCOM issues have been plaguing Wine for about 5 years now with a series of successes and failures on our part. We're not out of the woods yet, and there's certainly more work to be done, but things are definitely on an upswing. Rob explained what was behind the patches:

I can put all of the patches in to one big patch if anyone wants to test before the patches are committed.

Here is a list of some of the applications I tested with:

  • Adobe Acrobat Reader 6.01 - has some graphical glitches and requires IE to be installed but still installs. InstallShield.
  • iTunes - Has some stability problems - sometimes deadlocks (due to marshaling proxies?), but installs most of the time. InstallShield.
  • Halo - Installs fine.
  • Everquest - Installs fine.
  • Dark Ages of Camelot - Installs fine.
  • World of Warcraft - Installs fine.
  • Starcraft - Installs fine.
  • Wordperfect Office 12 - Installs fine. InstallShield.
  • CSI Dark Motives - Installs fine. InstallShield.
  • Google Earth - Installs fine. InstallShield.
  • X-Win32 LX - Installs fine. InstallShield.
  • Sims 2 (CD) - Leaves files open on CD so can't install.
  • Final Fantasy XI - Hangs during install. InstallShield.
  • Call of Duty - Leaves setup.exe open on CD so can't change disks.
  • Palm Desktop - Fails as it requires interprocess ROT. InstallShield.
  • Battlefield 2 - Hangs during install. InstallShield.

Uwe Bonnes requested Alexandre notify everyone when the patches were in place. He didn't have to wait very long; the patches were committed within a few hours and Alexandre replying, Everything should be in now (with many thanks to Rob for doing a great job of splitting his work in small self-contained chunks).

Dimi Paun was impressed:

Yeah -- this was one of the nicest patch set I've seen in a while.

Guys, this is simply *amazing*! I'm in constant awe at the quality and volume of the patches that I've seen lately, to speak nothing of the difficulty behind them.

Kudos!

Raphael Junqueira was too:

Champagne ? :)

very impressive job Rob :)

Now, everyone go find an installer to break and get it to CodeWeavers.

Web/HTML

James Hawkins gave a status update on some work he's doing:

In light of a recent wine-users' query about wine's help system, I've decided to shed some light on the status of wine's HTML Help implementation. I decided not to send patches till I had the base interfaces fleshed out, and this process is almost complete. As of now you can pass a .chm file to hh.exe which will bring up the help viewer. The toolbar with the Back, Stop, Refresh etc buttons is complete (minus correct icons..I can't draw), and the user can browse through the contents of the help file (the most important part). I still have to implement the navigator pane, but that's really secondary to the browser. I have a working .exe and visual studio project if anyone wants to take a look at it before I start submitting patches; just reply and I'll send it to you. For more information on what's left TODO with the project, check out my wiki page:

RPC / COM / OLE Microsoft Rob Shearman

Related to the DCOM work, Ivan Gyurdiev wanted to know what was going on with the stdole2.tlb typelib. For some background on this, see WWN #238 for more information about this topic. Ivan wrote:

I was wondering what the status is of stdole2.tlb in wine. GTA: San Andreas will not install without it..

Rob Shearman explained what was going on:

Ivan, I believe the status was that a similar enough stdole2 cannot be generated using widl without some extensions.

There are two options:

  1. Generate the file manually by invoking ICreateTypeLib2 functions (I believe Microsoft do it this way).
  2. Add another mode to widl that allows the necessary forward references in idl files. Huw Davies knows more about this problem.

Huw Davies then submitted a patch implementing it and explained:

Here's a semi-complete stdole2.tlb. There are a few small issues with widl and enums that mean that the uuids of two enums are commented out, as is one function that takes a defaultvalue parameter that is an enum. It should be easy enough to fix widl to cope with these.

The harder problem is that coclass StdFont contains dispinterface FontEvents, which appears later on in the typelib than the coclass itself. It's not possible to do this in idl, so we'll need to come up with some sort of widl extension to let us do so. For the time being the reference to FontEvents in StdFont is commented out.

I've not tested this with an InstallShield installer - feedback welcome.

Ivan reported some success with his installer:

Thank you very much - GTA will now begin installing, will get through all the InstallShield screens, and then it gets to the last one where it should begin installing, and it freezes and nothing happens.
Integration

Hans Leidekker has been implementing WLDAP32 for several weeks now. He originally posted this message about two weeks ago:

The last three weekends I have been working on an implementation of WLDAP32 (comes standard on XP) on top of OpenLDAP. I have many functions fleshed out now so I think it's about time to start feeding patches.

Some of the individual patches have noted these additions in the changelogs:

#1

Configure checks for OpenLDAP headers and libraries.

#2

Dynamically load ldap libraries.

#3

Implement ldap_bind* functions.

#4

Although not strictly necessary, I did the ldap_unbind functions as wrappers because I'd like the debug logging to show ldap_bind and matching ldap_unbind calls.

Changelog

    Implement ldap_simple_bind* and ldap_unbind* functions.

#5

Implement ldap_init* and ldap_open* functions.

#6

Implement ldap_search* functions.

Hans is continuing to work on adding more functionality and patches have been arriving steadily for the past few weeks.

Debugging

Uh oh.. there may be monsters lurking in the woods. Robbert Xerox sent in an unconfirmed bug with this description:

I know this is not a wine-bug channel, but this bug is affecting quite some apps, and seems to affect more and more ...

At least five apps from wine-bug mailinglist throw up an exception which either reads: "Assertion Failed !bogus context in Local_Unwind()" or "in Exception_Handler". As a reference a filed 2 bugs, and commented another one where you can read the +relay,+seh logs:

Some googling around makes me believe that this is a Borland specific error. I tried to install Demo Borland compiler in wine to see if i could reproduce this error, but unfortunately it fails with exactly the same error.

all programs show the same pattern before an exception is thrown: they call LoadstringA() ,with something like L"Failed to get data for '%s'" or L"Access violation at address %p in module '%s'. %s of address %p" See the bugs for more info.

I think this bug is really affecting quite some more apps then the ones mentioned in wine-bugs so would be great if anyone could shine a light on this, as of how to solve the bug. Regards

Alexandre thought the problem was hiding somewhere else:

I tried several of the apps you mention and they all work fine here, so I suspect some sort of glibc/kernel issue. You should provide more details on your setup, and ask other people who see the problem to provide details too so that we can see if there's a correlation with kernel versions etc.
Ports

Making changes to allow for 64-bit support has been on the minds of many people. Dmitry Timoshkov seems to have tackled the problem first about 9 months ago. I remember Dmitry discussing it with some people at WineConf and a bunch of us thinking that some things were hard. Since then various folks have taken stabs at it in some form or another. Kevin Koltzau asked this week about a compiler difference:

gcc and msvc++ have different opinions on the size of a long in 64bit code, gcc has sizeof(long)==8 while msvc++ has sizeof(long)==4

Binary compatibility with win64 will be just about impossible as the long datatype is used extensively throughout the headers and code

doing -Dlong=int works in simple cases, but not as a general rule

I'm at a loss as to where to go from here, suggestions are most welcome.

Juan Lang thought the problem wasn't that difficult:

Can you give an example of a non-simple case?

What about defining LONG as int in win64?

Kevin explained, you could start with running "grep long *" inside the include directory. Every instance would need to be changed in some form, I count well over a thousand instances in just the headers.

Dmitry suggested redefining things to handle those instance, We need to replace 'long' by 'LONG' and 'int' by 'INT' in the headers. That's a job for a simple script. Then synchronize headers with an actual implementation, that's a little bit harder since we need to closely inspect every API implementation.

A patch for that hasn't appeared, but Kevin did add several other 64-bit related functions.