Wine Traffic #119 For 30 Mar 2002
Table Of Contents
Introduction
This is the 119th release of the Wine's kernel cousin publication. It's main goal
is to distribute widely what's going on around Wine (the Un*x windows emulator).
Mailing List Stats For This Week
We looked at 132 posts in 386K.
There were 44 different contributors.
24 posted more than once.
25 posted last week too.
The top posters of the week were:
- 16 posts in 43K by Francois Gouget <fgouget@free.fr>
- 14 posts in 33K by Eric Pouech <eric.pouech@wanadoo.fr>
- 9 posts in 23K by Lonnie Cumberland <lonnie@outstep.com>
- 9 posts in 20K by Alexandre Julliard <julliard@winehq.com>
- 7 posts in 15K by Warren_Baird@cimmetry.com
- Full Stats
1.
News: Crossover Office, WineX 2.0
24 Mar 2002 - 30 Mar 2002
(3 posts)
Archive Link: "News"
Topics: News
People:
codeweavers, CodeWeavers, , Transgaming, Brian Vincent, Lindows.com, DesktopLinux, News
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.
(ed. [Brian Vincent] 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.
)
2.
Wineconf 2002 (con't)
31 Mar 2002
(2 posts)
Archive Link: "wineconf 2002 summary"
Topics: Documentation
People:
Andreas Mohr, , News
To follow up on
last week's coverage of Wineconf, Andreas Mohr
mentioned,
3.
Making Fonts Suck Less
24 Mar 2002 - 25 Mar 2002
(10 posts)
Archive Link: "OT: Buggy fonts"
Topics: Fixes
People:
Russell Howe, Huw Davies, Duane Clark, , Francois Gouget
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"
etc...
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.
4.
Implementing BiDi Fonts
24 Mar 2002 - 25 Mar 2002
(6 posts)
Archive Link: "Adding new libraries to the repository"
Topics: Internationalization
People:
Shachar Shemesh, Alexandre Julliard, Hetz Ben Hamo, , Dimitrie Paun
Shachar Shemesh opened discussion on adding BiDi support to Wine:
Like I mentioned ealier last week, I intend to add BiDi support to WINE.
There is a library called fribidi (
http://fribidi.sourceforge.net/)
that does a pretty good job, and seems exactly apropriate for this task. I
have two questions:
- What are my chances of getting a patch of this magnitude incorporated
into the tree. The library is not particularily big, but includes a set
of unicode translation files that are automatically generated from the
unicode standard. It seems that WINE holds similar files itself, for
similar purposes. I have not yet checked whether they conflict, and if
they do, whether this conflict is resolvable.
- The library is under the LGPL license. I understand that some of the
WINE tree is under the same license, while other parts are under the X11
license. Can someone please comment on the implications of such a move?
What things do I need to take into consideration?
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:
-
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.
- 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.
5.
Implementing a DIB Engine
29 Mar 2002 - 30 Mar 2002
(5 posts)
Archive Link: "DIB engine"
Topics: Multimedia
People:
Francois Gouget, David Hammerton, , codeweavers, TransGaming
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:
- Have X export the required API
- Copy the relevant X code into Wine
- Copy the relevant code from MicroWindows/NanoGUI to Wine
- 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...
6.
Unicode and I18N Support
29 Mar 2002 - 31 Mar 2002
(12 posts)
Archive Link: "Unicode, i18n support"
Topics: Internationalization
People:
Dmitry Timoshkov, , Shachar Shemesh, Dimitrie Paun
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.
7.
Improving Regression Testing
28 Mar 2002
(15 posts)
Archive Link: "Improving the regression testing infrastructure"
Topics: Testing
People:
Geoffrey Hausheer, Francois Gouget, , codeweavers
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:
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.
Sharon And Joy