Wine Traffic #284 For 22 Jul 2005

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.

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!

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.

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!

Champagne ? :)

very impressive job Rob :)

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:

wiki.winehq.org/JamesHawkins

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

http://bugs.winehq.org/show_bug.cgi?id=3108

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.

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.

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.

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.

Configure checks for OpenLDAP headers and libraries.

Dynamically load ldap libraries.

Implement ldap_bind* functions.

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.

Implement ldap_init* and ldap_open* functions.

Implement ldap_search* functions.

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:

• Bug 3097
• Bug 3127
• Bug 3139

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

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.

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.

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

What about defining LONG as int in win64?