Wine Traffic #268 For 1 Apr 2005

I am very happy to announce that today we have shipped version 4.2 of CrossOver Office. This includes a long awaited update to our server product, CrossOver Office Server Edition.

This release includes support for Quicken 2005, as well as new support for Quickbooks, versions 2001-2004 (note that Quickbooks 2005 is not yet supported). This release now supports the latest version of iTunes, and the iPod support code has been tuned to work with that version. We've also started an effort to properly support EndNote.

I also want to take a minute to stop and thank everyone that has purchased CrossOver from us. As I look back on the 7 years (7!) I've been involved in the Wine project, no part has been as rewarding as the time we've been working on CrossOver. There are many employees at CodeWeavers, and we are able to pursue a dream, and still provide for our families, entirely because of your support.

For example, we've been able to invest a lot of energy into Wine over the last few months; the changes that we've put into WineHQ that will come out as part of 5.0 this summer are going to be very exciting. The changes include a window manager rewrite, which should finally give us the tools to nail all those pesky visual glitches, a complete implementation of MSI and COM, which should allow us to get just about anything installed and up and running, and many other improvements too numerous to list.

In short, I think that this is the year that we start to really push Wine to fulfill its promise, and we have only been able to do this work because of your support. I hope that we have showed and continue to show our appreciation for your support through the improvements we make to Wine and by the support we provide to you.

This whitepaper by Codeweavers COO Jon Parshall and CEO Jeremy White takes a detailed look at the potential value of WINE ("Wine Is Not an Emulator") as an ingredient in a strategy for enterprise migration from Windows to Linux desktops. The paper itemizes the requirements for enterprise desktop migration, examines a range of available tactics, and then suggests strategies for making the journey in ways that are "pragmatic, economical, and customer focused," the authors say.

I decided that it's time to write here about my work. I'm working on an implementation of MSHTML using Gecko (Mozilla's engine) API. Results of this work you can see here:

http://members.lycos.co.uk/merplayers/wine/

Yes, it is Internet Explorer on Mozilla's engine under Wine! At last... it doesn't work as nice as one can think looking at the picture... but it's starting to work.

I'd like to do it using Linux Mozilla, but to do it I'd need to pass GtkWidget to Gecko. So AFAIK there is no way to do it in an acceptable way for Wine. If there is, please let me know.

Gecko API is based on XPCOM that is quite similar to MSCOM. We cannot use Gecko's headers as they are designed for C++, but I wrote idl files that can be used by widl to generate binary-compatibile headers. Fortunetly, excluding interfaces, we can do everything using only C functions. Currently Wine's implementayion uses Mozilla ActiveX Comtrol. It's enough for some applications using it as replacement of WebBrowser Control, yet I don't know anyone using it as replacement of HTMLDocument (and it won't work as this is control, not document).

This code needs a lot of cleanup and I need to remove temporary hacks, but I think it's time to start sending patches. Unfortunately I'll be out next week and this week I won't have much time. This week I'll send only some simple code, and later will come more.

This is the initial agenda for WineConf. I hope to add a few more items, but Jeremy suggested I pull the trigger and announce it. I agree - there's enough here to fill two days and leave a lot of time for people to get together in small groups. Only the first two items are in any formal order:

• Alexandre - Keynote (He said he's reusing last year's slides.)
• Dimi - to do list / status update
• Steven Edwards and the ReactOS crew
• Charles W Stevenson - Winelib / Winelib porting / and a commercial perspective
• Andrew Barlett / Samba team? - Samba 4, authentication, lots of intelligent ideas
• Juan Lang - Wine's RPC + Samba or something like that :)
• Jeremy White - CXTest
• Jason Edmeades - DirectX 9 / wined3d / eye candy

I think a full agenda would be about 11 items. If you would like to present something let me know - there's definitely space available. If you've been wondering, "There's a neat project I'd like to do if I could only get a few more people interested", well, this is the perfect time to bring it up. If there's something strategic to Wine development, this is a great time to discuss it. For example, we've had mixed feelings regarding revision control and its been suggested to bring it up as a topic. Would anyone find it useful to discuss subversion vs. arch vs. cvs? We could probably get Mike Hearn to show off how he manages patches with SVK and then let him arm wrestle Alexandre about whether arch is better.

Friday night we will have an informal dinner after meeting up at the hotel. The conference will kick off Saturday morning on campus around 8am. Lunch will be provided on Saturday and Sunday as well as dinner on Saturday. There will definitely be a lot of time for informal discussion.

For the Samba guys - I think there's a great opportunity to share some knowledge to prevent anyone from reinventing the wheel. If there's any topic you'd find interesting, let me know. If you'd just like to hear a specific topic from the Wine folks, we can arrange that.

For travel arrangements, please join wineconf_at_winehq.org ( http://www.winehq.org/mailman/listinfo/wineconf ) For instance, I'm actually flying into Frankfurt on April 23rd and it'd be cool to hang out with anyone arriving early. If you haven't made reservations at a hotel, don't worry too much. There's still rooms available as Mr. Schmid described here:

http://www.winehq.com/hypermail/wine-devel/2005/03/1119.html

If you haven't signed up on the RSVP list, please do so. It can be found on the WineConf page:

http://www.winehq.com/site/wineconf

I'd like to present something on the way Samba4 stores the extra NTFS meta-data in posix filesystems (streams, NT ACLs, DOS attributes, extra timestamps etc) and open up a discussion on whether we could come to an agreement with the wine project on how this should be done. I can provide a demo of the implementation we currently have in the posix NTVFS backend in Samba4.

I'd similarly like to discuss cooperating on share modes, oplocks and byte range locks.

In each case I will be trying to encourage methods which can store the full NTFS semantics, rather than limiting ourselves to only the things that fit natually in posix filesystems. I'm guessing we will have some lively discussion on whether this is a worthwhile aim :-)

Finally, if we have time, I'd like to discuss cooperation on IDL files and MSRPC interfaces.

I don't know if I can find the time to prepare a proper presentation, but if I do, I'd like talk about and get some input from you on the subject of testing.

1. I want the conformance tests done faster. (I have a clear idea how.)
2. What's almost never been brought up on wine-devel is the unit testing in the XP sense.

1 has been discussed on wine-devel quite a bit, so I'll skip it in this mail.

regarding 2:

CXTest is like application testing. This is good, high-level testing.

The conformance tests test the Windows API. But in the case of a complicated API (and Windows is complicated) maybe we need to test the smaller units behind the API.

So, the conformance tests often are somewhere between application testing and unit testing.

Can we have an infrastructure for running unit tests of small units of code private to the implementation?

I am trying to write a script which, at one point, needs to run the wine test suite, accomplished with:

make -k test

Even though this skips over bad tests, it does not prevent the debugger from kicking in every once in a while and asking for user input. I would like this script to be robust enough to run the test suite without user input, even when one of the tests fails badly enough to call the debugger.

So, is there any way to disable the debugger so that the script can just continue on errors and not sit at a "Wine-dbg>" prompt?

Alternately you could add the '--auto' option and winedbg should then run in non-interactive mode. This will also cause it to dump a stack trace which is nice for later debugging if you save the output somewhere.

[Software\\Microsoft\\Windows NT\\CurrentVersion\\AeDebug]
"Auto"="1"
"Debugger"="winedbg.exe --auto %ld %ld"

There are a number of issues with InstallShield currently. I had hoped that getting one working would get all working, but this doesn't seem to be the case from the current discussion on wine-devel. I am aware of 3 issues with ole32, 2 deadlocks and one error. The remaining issues appear to be with the typelib marshaler, which unfortunately lacks regression tests.