The biggest news of the week is CodeWeavers announcement of their newest product. Dubbed "Crossover Office" it allows:

you to install your favorite Windows productivity applications in Linux, without needing a Microsoft Operating System license. CrossOver includes an easy to use, single click interface, which makes installing a Windows application simple and fast. Once installed, your application will integrate directly with your Gnome or KDE environment. Just click and run your application, exactly as you would in Windows, but with the full freedom of Linux. CrossOver Office is capable of running a range of Windows software, but CodeWeavers will support the following applications:

• Microsoft Office 97 and 2000
• Microsoft Word
• Microsoft Excel
• Microsoft Powerpoint
• Microsoft Outlook
• Lotus Notes

In the near future, CodeWeavers will dramatically expand the list of applications it will support with CrossOver Office.

CodeWeavers submitted a huge patch a few months ago to wine-patches, presumably it came from the work that was put into this product. And since the patch was generated against CVS from November it can surmised they've done substantially more development.

DesktopLinux.com has a review of the product, LinuxPlanet does too. CodeWeavers has a bunch of screenshots of Microsoft Office running on Linux... [ 1 ] [ 2 ] [ 3 ] [ 4 ]

CodeWeavers is offering several different products now, and you can even purchase the Crossover Plugin and Office products together at a reduced price. And yes, this includes support.

Transgaming gave a status update on WineX 2.0 - it's coming soon. Included will be support for Diablo 2's Battle.net. Also in the future will be a naming contest for their logo, details to be announced soon.

And not to leave out Lindows.com, but they added a "Warehouse" section to their website for their upcoming Sneak Preview 2.0. The goal of this will be integration between the desktop and the web site to allow apps to be downloaded and installed.

Increasingly I've been including news about commercial companies within this news section. The reason is simply because there's been more news. At the same time, the contributions from these companies are greatly increasing the viability of Wine and how well it performs. As long as their contributions benefit the community I would like to continue to cover news about them. However, this may be at odds with what you believe so I'd like to take this opportunity to solicit your thoughts concerning whether KC Wine and Wine Weekly News should continue to cover the more commercial aspects of development. Please email me at vinn at theshell.com and let me know what you think. Okay, time to stop editorializing, I'm gonna mail this to Zack so I can go skiing.

To follow up on last week's coverage of Wineconf, Andreas Mohr mentioned, I just added a link to my final wineconf 2002 summary page at http://home.arcor.de/andi.mohr/wine/wineconf2002/ to the WineHQ News. If anyone else has anything to contribute, then feel free to tell me NOW :)

Russell Howe asked,

I'm afraid this is a little off-topic, but every time Wine starts, as it builds the font metrics, xfs-xtt (the font server) dies. I'm assuming there's a font (or few) in the system which it doesn't like, or which are corrupt.

It makes wine rather annoying to use (and means that if I kill wine and restart the font server, it thinks the metrics are already done and ignores most of my fonts!)

Does anyone know an easy way to find out which fonts they are?

Huw Davies stepped up and replied:

Try deleting ~/.wine/cachedmetrics* , re-run wine with --debugmsg +font, the last font that gets listed before the crash should be the problem one.

A much better way to do font rendering in Wine is to use the new client side rendering code. For this you need an XServer capable of supporting the RENDER extension (xdpyinfo will tell you whether you have such a beast) and a copy of the FreeType library version at least 2.0.5 (but the later the better). Add a [FontDirs] section to your ~/.wine/config file, with entries pointing at any directories that contain TT fonts

eg

[FontDirs]
"dir1"="/usr/X11R6/lib/X11/fonts/TT"
"dir2"="/usr/share/fonts/TT"


Huw has done a lot of work on fonts and gave a presentation at Wineconf on the topic. Huw also mentioned that there's no need to list the Window's font directory, it's searched automatically.

Duane Clark reported, This got me to try out the client side rendering. It really does make the fonts (in MS Word in particular) not suck! Nice job. Guess I will stick with this configuration.

Duane reported a small problem that he worked around by hardcoding some values. He wondered what the proper solution was though. Francois Gouget suggested upgrading to the newest FreeType library. Duane tried that without success. Huw then asked for a trace so he could debug it.

Shachar also asked for help from any fluent Arabic speaking developers to help him with the process.

Alexandre replied, You don't want to include the full library in the tree of course; there is already a bunch of unicode stuff in libwine_unicode so what you probably want to do is take algorithms from fribidi and merge them into libwine_unicode. The unicode tables in there could easily be extended to add the required information; I can help you with that if necessary. I doubt you could use fribidi directly anyway since AFAICS it uses 32-bit Unicode chars, while Wine needs 16-bit chars. He also pointed out that there's no problem including LGPL code now that Wine uses that license also.

Hetz Ben Hamo felt it wasn't nearly as simple as Shachar believed and pointed out two problems:

1. As it stands now - you can't even see hebrew because, simply put, the fonts rendering doesn't support it - run Word Viewer with a hebrew document and see what I mean.
2. The hebrew keyboard is not supported at all, plain and simple.

Shachar wasn't sure about the keyboard support but felt it shouldn't be any different for other multi-locale keyboards. As far as font rendering, Shachar mentioned he had already tested a small Unicode program using DrawText that printed Hebrew without any problems.

Dimitrie Paun wondered if the Unicode stuff should be separated from Wine. He felt there were too many implementations of it and maybe another project would find the code useful. Shachar pointed out that Fribidi did have it's own implementation. He also was concerned because, as Alexandre pointed out, Fribidi uses UTF-32 and Wine expects 16-bit not 32-bit characters.

This is the first of two threads Francois Gouget started concerning features to be added to Wine. He asked for opinions of other developers on how to approach them. The first thread was about implementing a DIB engine:

The DIB engine was discussed quite a lot at WineConf. I am now trying to summarize these discussions to update bug 421 - Implement a DIB engine.

http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=421

Is the following accurate, complete, etc? Comments? Other ideas? Any volunteers?

This was discussed quite a bit at WineConf. Ideas that were floated around are:

1. Have X export the required API
2. Copy the relevant X code into Wine
3. Copy the relevant code from MicroWindows/NanoGUI to Wine
4. Copy the relevant code from GGI to Wine

Those last points were summarized. Please refer to Francois' original post for more details.

DIB stands for "Display Independent Bitmap". Windows uses a DIB engine to do 32-bit graphics manipulation. These operations are performed in memory rather than transferring to the graphics card for hardware acceleration. As a result, one of the problems facing Wine is how to perform these operations in an efficient manner without adding a lot of overhead. Francois thought TransGaming had come up with some method for doing this, but wasn't sure.

David Hammerton explained TransGaming's approach:

We make use of Shared Memory Pixmaps to reduce the copying (in WineX).. So we have app memory which stores the image in the mode requested by the app, this then gets copied into a SHMPixmap of the depth supported by X so X can do whatever it wants to (render to it or whatever) and it then gets copied back when needed, same method..

One of the big savers here is that the ShmPixmap means we dont have to be sending stuff between X server/client, saves alot of time..

As for X supporting multiple depths - I investigated this and talked to some of the X coders, its still not "wonderfully" supported.. ehm, it lacks alot of the most common modes - eg 8bit paletted - its not really worth it from what I can see.. The X developers suggested that if I wanted to go down this road to first write an X extension, ShmPixmaps were nicer and almost as fast...

The second thread Francois started was about Unicode support. Right now there's a bug referencing it, but it's quite vague. Francois requested comments about creating specific goals to make the task seem more manageable. He wondered what controls still needed Unicode support and what common dialogs need work.

Dmitry Timoshkov felt some things needed work, but added, One more thing that should be addressed IMO as the part of the unicode support in Wine: file APIs. For instance in the current state all russian file names created by windows programs are completely unreadable in Linux because they are created in code page 1251 but native russian encoding in Linux is KOI8-R (code page 20866). Therefore all file APIs should work with unicode natively, and convert file names to code page specified somewhere in the config file (like [x11drv]/TextCP) on create, and vice versa on reading file names from disk.

Dimitrie Paun thought that Linux's support of UTF8 would be enough. But Dmitry didn't think that was sufficient, I'm afraid that will help to Linux only based installations of Wine, and in any case all functions in Wine implementing file APIs should internally use unicode.

Dmitry proposed creating filenames on disk in encoding used in Linux because it's necessary to support general mount options, used by *all* russian users in the world to be able correctly see cyrillic filenames under Linux from a vfat partition: mount -t vfat -o codepage=866,iocharset=koi8-r.

Shachar Shemesh wasn't sure Windows would be able to read them. But Dmitry explained Windows would be able to thanks to magic mounting options I mentioned earlier. Native Linux localized applications know nothing about anything other than KOI8-R, and filenames created by them on a vfat partition are readable under Windows just fine.

Geoffrey Hausheer had some ideas for making the testing framework easier to use:

As I've been writing tests (only for the last week or so), I realized that as we get a lot more tests, it will be very difficult to keep track of what is being tested, and what is not. I'd like to propose a list of which functions for each DLL are being tested, which file tests it, as well as any comments on the current tests.

In general, while Francois' presentation is a good place to get started, I think it'd be a lot easier if there was a document off of winehq with recommendations on how to build, test, and document tests. Lowering the difficulty threshold, is more likely to draw more people to do so.

Francois Gouget replied:

I agree. Documenting and finishing the test framework is on the list for Wine 0.9.0. I added the corresponding tasks yesterday:

• 526 [NEW] - Document the regression testing framework
  http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=526
• 530 [NEW] - Package the regression tests for Windows
  http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=530
• 527 [NEW] - Running C regression tests on Windows with MSVC
  http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=527
• 528 [NEW] - Running C regression tests on Windows with Cygwin/MinGW
  http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=528
• 529 [NEW] - Running Perl regression tests on Windows
  http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=529

Geoffery also wondered, Is there a reason we can't just use environment variables rather than argc/argv? I would think that would be less of a hassle than using argc/argv.

Francois replied:

The goal of some of these tests is precisely to check that what you get in argc/argv is what you expect. For instance, if the command line specified to CreateProcess is ... "a\"b\\" c\" d you would expect:

argv[1] = [a"b\]
argv[2] = [c"]
argv[3] = [d]

That would be hard to check without accessing argc/argv in some way.