Wine in Fedora 13 x64

The shiny new Fedora 13 is to be released in a few hours. I've installed its x64 variant since beta. And I've spent a lot of time to make wine work in Fedora. And it actually works with PulseAudio :) So, if you are going to use wine in Fedora 13 x64 here is some info which might be helpful.

Getting the latest wine version

At the time of this writing latest wine version in Fedora repos is 1.1.38, in upstream 1.1.44. The latter is also available if Fedora testing repo. So, you might want to enable that repo while installing wine:

yum --enablerepo=updates-testing install wine

Getting rid of crash on audio tab

x64 build of wine is not perfect yet. It actually crashes on audio tab. So, use 32-bit version to configure wine:

wine32 winecfg

It's actually a good idea to use wine32 instead of wine.

Adding readable wine fonts

Default wine font is hardly readable. You should have sharp eyes and good imagination to understand what is written on wine dialogs :)

Installing corefonts with winetricks should fix it:

yum install cabextract
wget http://www.kegel.com/wine/winetricks
chmod a+x winetricks
./winetricks corefonts

Adding mp3 support

Some games (including Morrowind) require mp3 support. Fedora's wine without mp3 support in contrast to Ubuntu. To enable it you should install a mp3 codec. It is recommended to use l3codecx codec, then rename l3codecx.acm file to winemp3.acm. Alternatively you can grab that file from Windows, if you have one at hand. I had no Windows, so I tried installation approach. I've searched for l3codecx and found a few installators (for Windows, of cause). One of them failed in wine but another one worked. l3codecx.acm file appeared in $HOME/.wine/drive_c/windows/syswow64 folder. Instead of renaming it I just made a symbolic link:

cd .wine/drive_c/windows/syswow64 folder
ln -s l3codecx.acm winemp3.acm

And that's all :)

Android's sharedUserId

Android is a wonderful platform for development. It also provides good security framework. Each application has its own user ID and thus application A can't directly access the data of application B. So, Android is quite resistant to viruses plague. In contrast to Windows.

But this security makes it difficult to develop a set of applications which should work tightly with one another, e.g. browser and its plugins, translator and its dictionaries, etc.

To address this problem Android provides the developer with sharedUrerId attribute in manifest. Setting the same sharedUserId to multiple application and signing them with same signature will enable them to access one another's data. Great!

But... but there are two nasty bugs related to sharedUserId which you must take into account.

1. Issue #3763 messes up if you decide to change the sharedUserId value.
2. Issue #1227 bites you if you add sharedUserId to your application.

In both cases after upgrade to the new version your application won't be able to access its own data (probably, because its user ID was changed, but chown was not called on its data). You'll see some strange errors in console. Like database can't be opened.

So, if you are developing some application for Android and if there is even a slightest chance that the application might need to use sharedUserId attribute - use it right from the start. Before uploading the application to the Market. And don't change sharedUserId value in the future.

Update. Issue #1227 just celebrated it's 5-th birthday. And people are sill affected by the problem. Looks like Android is getting closer to Java when it comes to anniversaries of important issues.