World Wine News

WHAT'S NEW with Wine-20040121: (see ChangeLog for details)

• Many improvements in the shell32 dll.
• Better support for constructors in C++ Winelib apps.
• Improved Regedit tool.
• Full support for graphic tablets.
• Lots of DirectMusic improvements.
• Better support for video playback.
• Full IME support for Asian locales.
• Lots of bug fixes.

CodeWeavers' Desktop Linux Certification Program includes several key elements:

• A new online CodeWeavers CrossOver Compatibility Center, nicknamed "C4", an Internet-based "headquarters" where Independent Software Vendors (ISVs) can get information about Linux desktop certification for their Windows applications. C4 also gives the Linux desktop community -- now numbering in the millions -- a place to "vote" for Linux support of specific Windows applications, as well as to pledge time and even money to see their favorite or essential Windows applications certified for the Linux desktop.
• The debut of a Desktop Linux Certification Service. The fee-based service, now available to ISVs, provides certification testing of Windows products with CrossOver, CodeWeavers' industry-leading Windows-to-Linux application. Official CrossOver support provides de-facto certification of the application for all distributions of the Linux desktop.
• A new "Desktop Linux Certified [tm]" logo for Windows applications that have passed desktop Linux certification testing. Authorized ISVs can place the logo on websites, packaging, product literature, and other marketing materials for their certified Windows applications.
• The continuing maturation of WINE and The WINE Project, the global open-source movement to create a robust and far-reaching software "bridge" for Windows applications to Linux.

Following the December development report we received an email from Jaroslav Kysela of SUSE, who kindly provided us with some technical insight on how to overcome the limitations we perceived in ALSA. With this information we now believe that we should be able to provide hardware mixing in a straightforward manner while also using memory mapping for data transfer. These two features combined have the possibility of providing some major improvements to speed with a complete rewrite of the winealsa sound driver.

Since the last report we have also been active with our Pixel Shader investigations. We now have a working pass-through implementation that allows us to pass pre-translated fragment programs into OpenGL. The next step here is for us to translate the D3D pixel shaders into OpenGL fragment programs, trying to support as many of the shader language versions as possible on the existing OpenGL fragment program specification. We will be working on refining this for inclusion into WineX as well as working proactively to address some of the limitations of the proposed OpenGL 2.0 specs for fragment programs, making it a better translation target for D3D shaders version 2.0 and up.

We've just launched a major new initiative, the CodeWeavers CrossOver Compatibility Center.

You can check it out at

http://www.codeweavers.com/compatibility/

I wanted to announce it here to give folks a sense of what we're up to, and to apologize a bit in advance for stepping on the toes of folks that have been doing good work within the appdb.

However, the #1 problem we have had over the past year or so is how to handle all the many, many requests we get for applications not on our 'supported' list.

We've basically ended up sending people away, which has been pretty unsatisfying. Further, we haven't had any good way of determining what our priorities should be; we follow major paying clients, but beyond that, we mostly just follow our gut hunches in establishing priorities.

We hope to end that; this new center lets our customers vote for apps, and lets non customers make pledges. We can hopefully follow those pledges to get apps running (and we'd probably be open to having wine hackers committing to support apps in exchange for a piece of the pledges, but we haven't gotten there yet).

We've also, we hope, set the stage for a major new Wine related initiative - we hope to encourage lots of ISVs to certify their apps against Wine.

The rationale for this is pretty simple - apps won't run on Wine as well as they do on Windows until developers start testing against Wine. They've got to start somewhere - we're trying to give them that beginning.

We're obviously also hoping that this will help us to continue funding the work we've been able to do on Wine so far. As much of a struggle as it's been at times, we really feel lucky that we've been able to do so much. We hope that these initiatives will give us an extra little boost so we can help push Wine over the hump.

I sincerely believe that the day when we can honestly tell people "It will most likely work nicely on Wine" is not long off.

I also believe in the tooth fairy and Santa Claus, so make what you will of that <grin>.

At any rate, this is a brand new initiative for us; call it a 0.1.7 release. We're very open to comments and thoughts and suggestions, so I would greatly appreciate any public or private comments you have to make.

I'm also a tiny bit concerned that the site seems to blur its focus a bit - it seems to be positioned as a replacement for the appdb, despite the fact that it's CrossOver specific: I think there's enough forkage between CX Office and Wine now to make them basically separate products.

For instance, on the front page, there is this paragraph:

"Up to this point, the perception has been that Wine only runs a limited number of Windows applications. For instance, CodeWeavers' CrossOver Office only officially supports about a dozen applications. However, the truth is that CrossOver runs many Windows applications quite well, although they may not be officially supported. Now, we're raising the bar. We are confident that Wine has matured to the point that CrossOver will run 95% of all Windows applications by the end of 2005. This Compatibility Center has been established in order to document that progress as Wine makes the next great leap forward."

This piece of text seems to use the names Wine and CrossOver interchangably, when they are clearly different.

As for the database itself, well, it seems that it duplicates a lot of stuff needlessly - take "Alone in the dark". In the appdb there is only one comment which is basically "Works great!", but there is no indication the game works in C4. There's also no indication in either database whether it actually works as of Jan 2004.

Worst of all, there's no way to verify this except for a Wine developer buying a copy of the game, checking it, and possibly fixing regressions. So I'm not sure that an appdb type thing is even a good idea - a dedicated application maintainer who brings the app up to scratch, periodically checks it still works and so on is easily more valuable than a hundred appdb entries saying "This app doesn't work June 1998" or whatever, even if you have far fewer of them.

The idea of advocates is a turn off for me. It sounds like a revival of the old application owners idea, except that (again) it's crossover specific. It also feels a bit misleading. I think we'd all agree that the following phrases:

"Here at the Compatibility Center, we're looking for similarly talented individuals who have a passion to see their favorite Windows applications running on Linux under CrossOver."
"Volunteer your time to get an application working."

... makes it sound like all you have to do to get foo-app working is download CXO nightlies and report back the results. We already have this in effect, it's called bugzilla, and we all know that getting tester feedback of sufficiently high quality to fix the bug is while not rare, not the expected outcome. Bugzilla and the appdb are littered with comments like, "The app starts but then I get a message about flat scrollbars which crashes wine".

Is the CrossOver team going to trawl through C4 looking for feedback from the Advocates fixing bugs given (at best) a stack trace and a logfile? It'd be nice but the incoming workload scales much better than the workforce does.

Possibly there's something I'm missing here, like CXTest. Something like that sounds invaluable for tracking regressions if it works well, and maybe it's the secret sauce. I'm not sure.

Finally (sorry guys! :) the FAQ lists the first advantage of C4 over the appdb as the fact that it's maintained, but the cynic in me can't help noting that if you're capable of maintaining C4 you'd be capable of doing the same for the appdb ;)

I know I'm giving you a hard time here, and while I really appreciate all you're doing I thought I'd better air my concerns.

I also have a crazy dream of buying thousands of MS Windows titles, locking Aric in room until they all install, and then nailing them all to the floor with CXTest. I think this is conceivable (except for the part where Aric goes crazy and bludgeons his way out of the room with his laptop <grin>). And, I would argue, if were to truly make an effort to get every application to install and come to the main menu, we could make my prediction come true. I just need a bit more money, and a secure enough room to hold Aric...

We're genuinely motivated primarily by a desire to see Wine fly. However, we are also required by our spouses and physical law to make enough money to eat.

C4 is intended as a community primarily surrounding CrossOver, although the carry over to Wine is obvious. Essentially, the C4 community becomes another benefit of buying Wine from us, rather than simply downloading it for free.

So, yes, it is intentional that C4 is focused around CrossOver.

But I am concerned about the impact this will have on the appdb. I didn't really want to step on the toes of anyone that has been working on the appdb; that's a hard and largely thankless job. But I still believe in the original vision of the appdb (that's why I paid Jer to build it); I just think its going to work better in a context where it has a chance to pay for itself, so I can afford to pay someone the dirty job of keeping it up to date.

Further, we do think that CXTest is going to add a meaningful and useful component to this. If nothing else, I'm hoping that CXTest will let us 'lock' applications in so that once they start working right, we can prevent them from regressing.

Again, the primary purpose of C4 is to give our customers somewhere meaningful to go when they want to work on an app that is outside of our 'supported' list. People can either put their money or their time where their mouth is, or stop bugging me <grin>.

As an aside, we have started working on a new policy of patch submission. We had always held an internal tree, worked against it, and then submitted a delta after a release. The merging started to become unmanageable, and so we've switched policy so that (ostensibly) all of our guys submit patches here first, and then we merge into CrossOver frequently. Once we get going with C4 and CXTest, this should have the nice side effect that Wine will get a regression testing tool and a company to run said regression tests every night. (Our goal is to be able to pinpoint the exact patch that breaks half-life <grin>).

We don't get paid to maintain the appdb, and if we did maintain it, we'd encourage people to *not* buy CrossOver, imho. We do get paid by people who buy CrossOver, and we've hopefully given them a reason to be glad that they chose to give us their dollars.

I appreciate the concerns; I really appreciate that you looked it over carefully and took the time to raise your concerns.

We're genuinely trying to figure out the best way forward, and we want to do what's best for everyone involved.

As a result, we're very open to suggested changes.

Looks great to me; although there are not any discussions yet (or are there?) in the "forums" area to demonstrate the quality of the forum interface, if it's something along the lines of phpBB, then it's perfect.

In my mind, the appdb is great, but better, threaded, discussion areas were needed for people to really get serious about it.

As for wine vs CrossOver -- I presume that "plain old wine" users are welcome to participate? If so, then there really isn't a problem.

A quick awk script on my cvs in box produced monthly number of cvs commits. That includes the commits to winehq.

Output attached, a graph produced with gnumeric is on

http://home.wanadoo.nl/~wijn/wine/cvs.png

Since some people have been complaining that MSHTML is a useless distraction in it's current form (there's some element of truth in that), here's a small patch to redirect calls to Mozilla's Active X control. You need to add a "mshtml"="builtin,native" override in the config file and download and install the control before this patch can try to use it:

http://www.iol.ie/~locka/mozilla/control.htm

This patch hasn't been tested too much... but it's better than the current implementation of MSHTML :)

Very nice Mike! I guess this requires a Win32 build of Mozilla, no? Anyway, if the patch goes in, it would be nice if our good packagers can come up with a binary package (say, wine-mozilla?) that just installs alongside with the wine package and provides this capability.

BTW Mike, did you try to see if HTML Helps works with the Mozilla control? We had a task to add CHM support to WinHelp, but first we needed an implementation for IWebBrowser. People were arguing that Mozilla is not that IE compatible, and that using it for the IWebBrowser component will not work for a lot of cases, but I still think this is the way forward. Even if we chose in the future to have another IWebBrowser implementation based on khtml, this will nicely fill in the gap in the meanwhile, without any maintenance problems for us.

I didn't really have much time to do testing with it... tried to use it in place of IE6 and IE4's mshtml, but it didn't work.

Using Mozilla to implement IWebBrowser seems to be the Right Way for me, as the Mozilla project is already trying to do that themselves... it's a common goal that we can work together on!

It would be pretty cool if we could compile Mozilla as a winelib app, or figure out how to do get debugging info out of the control so we could see what needs to be fixed for it to work.

I'm pretty interested to work on this too, but unfortunately there's other "real work" that I need to get done at the moment.

A large UXTHEME update was committed in the last few days. It appears this causes the IE installer to crash. I'm currently bogged down with exams, it'll go on my list of regressions to track down and nail, but may take a few days or weeks, depending on how things go here. For now I'd suggest using 20031212, CVS is highly unstable and iesetup regresses all the time at the moment.

I've copied this one to wine-devel as well so Kevin can see the crash.

First, a big "Thank you" to Ove : maintaining a Debian package is work, and maintaining a beast such as Wine is *hard* work. I feel very grateful to Debian maintainers, and to Ove.

I have read the bug report about MS Office and the consecutive somewhat heated argument. While I won't delve in the "necessities" of using MS programs, I agree that there is not yet a free tool able to reach into .mdb databases sent by people you can't demand another format. (Yes, I'm aware of the .mdb tools. They crash on me any time I try to use them on a French .mdb ...). Ant that might be justification enough to try to get Wine working with that piece of s...oftware.

The following recipe *might* help people not yet able to get rid of MS Office. Start by getting the latest (20031212) version of wine (that's in unstable for you, Debian users ...). This version seems to be a *vast* improvement over whatever I tried before (last time was summer '03, IIRC).

You will need a working Windows 98 installation (for which, of course, you have a valid license...). But you'll have to start with a fresh no-windows installation. The simplest way I found is to rename any previous .wine/config file and .wine/fake-windows directory, then to call winsetup and to ask for the creation of a new config file without Windows installation.

Starting from here, install from the MS cdrom : wine /cdrom/install.exe. This installation will copy a lot of files, then FAIL. That's not a problem.

You'll then grab the following files from your working Windows installation:

• stdole32.tlb (This one is the only one needed for Winword, PowerPoint and maybe Excel).
• ole32.dll
• vbajet32.dll (and maybe vba332.dll (that's not a typo), can't recall at the moment).
• oleaut32.dll
• msacnv30.dll
• tzisolat.dll
• (maybe) odbc.dll

IIRC, all of this, except vba332.dll come from the \Windows\System directory of your native Win98 installation and go to .wine/fake_windows/Windows/System directory. In the .wine/config file, mark these libraries as "native,builtin" in the [DLLOverrides] section.

Restart the installation of MS Office from the CD. This time, the installation should work (and be much faster than the first time around, since almost all file already exist). It will complaint that it cannot DDE-connect to the desktop (in order to create the shortcuts), but that's harmless : just hit "Ignore".

The first launch of the applications may be painful : at first run, MS Office apps try to launch a "helpful" dialog box "presenting" the application, which have trouble communicating with the main program. I found that minimizing and restoring the main window may help. Don't ask me why.

As far as my limited test can tell, Winword and PowerPoint work fine. With the relevant fonts in xfs and a correct CUPS setup, printing is automatic and gives very good results.

MS Access still gives me guff : I have Cyrillic characters in place of Western accented characters, form creation dialog boxes have serious quirks (e. g. the "Properties" dialog box fights for focus with the "Save as" dialog box in Design mode), I had a crash trying to display an "outer join" view, etc ... But that is infinitely better that no MS Access at all ... I have now some hope of solving some of these hurdles.

The SR1 and SR2 "service packs" can be installed with no problems.

Hoping this helps,

Emmanuel Charpentier

PS : Ove, if you think this might be of interest elsewhere, and does not step too rudely on the (very) sensitive toes of DFSG and Social Contract, please feel free to forward to any relevant place, cut and paste or paraphrase at will ...

PPS : Mandatory disclaimer : I found this by trial and error. I might be wrong. But that's my problem. Now, I won't accept *ANY* responsibility for the (mis-)use you may make of this information, either technical or legal. In other words, you're on your own : if this blows your system, drowns your basement, launches against you a thousand of ships full of angered Microsoft lawyers, shaves your cat or rapes your grandma (or vice-versa), that's *YOUR* problem, buddy, not mine.

This is a stub implementation of the undocumented IActiveSetup from Internet Explorer's INSENG.DLL. I'm not sure that any other software except for Internet Explorer uses INSENG, however in case anybody is ever interested in it, I'm posting it here.

To build this dll in wine place the following 3 files in dlls/inseng, remove the #MKDLL_SKIP line from Makefile.in, add dlls/inseng/Makefile to configure.ac and run make_dlls.

Hopefully this will be of use to somebody someday...

Well, I don't think we need to implement it, unless we find some other program that uses it but doesn't install IE first.

I started writing this because IE didn't seem to install INSENG.DLL when using Version=win2k, but later found that it was a weird dll override problem.

Rather than just throw away the work from that misadventure, I decided to post it here in case somebody did need it or was curious :)