WWN Issue 229

This is the 229th issue of the Wine Weekly News publication. Its main goal is to light fireworks. It also serves to inform you of what's going on around Wine. Wine is an open source implementation of the Windows API on top of X and Unix. Think of it as a Windows compatibility layer. Wine does not require Microsoft Windows, as it is a completely alternative implementation consisting of 100% Microsoft-free code, but it can optionally use native system DLLs if they are available. You can find more info at www.winehq.org

This week, 90 posts consumed 290 K. There were 38 different contributors. 18 (47%) posted more than once. 16 (42%) posted last week too.

The top 5 posters of the week were:

11 posts in 32K by Mike Hearn
9 posts in 61K by Uwe Bonnes
6 posts in 12K by George Marshall
5 posts in 11K by Alexandre Julliard
5 posts in 13K by Bill Medland

News: Interview with Shachar, Reviews	06/26/2004	Archive
News This past week we discussed Wine's internationalization efforts with Shachar Shemesh. Read the interview. In the as-seen-on-Slashdot category, they posted some reviews of both CrossOver Office and TransGaming's Cedega. As always there were many comments from the community about both products, most of which were very positive. This issue is getting pushed out the door kicking and screaming. I'm headed out for a long weekend and am a bit crunched for time to fully complete this. However, one thread I really wanted to cover both last week and this week concerned FreeBSD. You can find the whole thread here . Basically, there seems to be a problem with FreeBSD right now that's preventing it from running Wine and the proper fix seems to be changing the FreeBSD kernel. John Birrell is looking into it, but it's unclear how long it will take to sort things out.

News: Interview with Shachar, Reviews

06/26/2004

Fixed Mandrake RPMs	06/29/2004	Archive
Build Process Mike Hearn found a problem with recent Mandrake RPMs: Ivans comment that the Mandrake RPMs didn't work on Red Hat/Fedora surprised me, so after encountering a stuck Mandrake user for whom the RPMs weren't working either on IRC I decided to check them out. It turns out the reason they don't work on Fedora is because they don't work at all - wine.inf is in /usr/share/doc/wine-20040615 which is wrong, it needs to be in /usr/share/wine. As this file is in the wrong place Wine refuses to start on a new user account. Once I manually copied the file to the right place Wine worked just fine. A quick look on the SourceForge download page shows that the files haven't been updated. However you can perform the simple fix Mike described.

Making Wine Upgradable	06/29/2004	Archive
Configuration Dimi wanted to get everyone's thoughts concerning how Wine should support being upgraded: It seems that we are getting ever so closer to 0.9. Slow, but steady. Looking at the TODO, it looks like upgrading is one of the big showstoppers, in that it will affect (1) the end-user experience, and (2) how we deal with the configuration. So this seems like a good time to start discussing this topic, as we need to eventually reach the elusive 0.9. This seems to be a difficult topic, so we need to approach the problem well prepared. That is, we need to first define (and agree) on what we need to solve here. So after a tumultuous discussion on IRC, I decided to get the ball rolling. Intuitively, upgrading wine is simple to understand: once a new version is installed, we need to get users in a state where they can use it. While simple to state, this problem is complicated by the various corner cases that can appear in Real Life (TM): native vs. builtin DLLs handling multiple Wine installations on a box updating only some DLLs integrating into the Unix environment dealing with Windows software We can also look at some important use-cases that we need to support, but before we do, the following must hold true in all cases: administrators should be able to install a new Wine on the system easily with "rpm -U" (or equivalent). the upgrade should not erase registry settings that are managed by the user Let's look at the use-cases: A. Global Install In this case, both Wine code, as well as applications are installed globally, for all users to access. This is the most Unix-like setup, but unfortunately the most difficult to support, due to the fact that Win32 apps simply expect a different environment. Since we can't control application's code, this setup may present some limitations, but it may be sufficient for sites that need a limited set of applications. For this to work, it is acceptable that we ship special scripts that know about the applications that are supported, so that they can work around inherent limitations in the applications themselves. Users should transparently be able to use the new version of wine, the next time they start wine. B. Mixed Install Here, Wine code is installed globally, but applications are installed in the user's account. In a way is like (A) but with some additional applications installed directly into the user's account. Same requirements apply to this case as well. C. Local Install Both Wine code, as well as applications are installed locally, into the user's account. The Wine code is still installed globally by the administrator (as in A & B), but it is copied locally before it's being used. An upgrade in this case may require an explicit action by the user, so the upgrade can happen at a controlled time, when the user desires it. In all of the above, there is always state in the user directory. Thus, it is imperative that the upgrade process makes sure that after the upgrade, the user-private state is consistent with the new code base. Also, any solution must take into account that the registry must be created on the fly, as it is created when registering the DLLs. Before we go any further, I'd like to ask everybody to contribute their thoughts/requirements/desires so that we get a comprehensive view of the problem we are trying to solve. There wasn't a whole lot of discussion, which probably means a lot of people agreed with Dimi's assessment. The few posts generated seemed to be concerned primarily with if, or how, Wine could support being upgraded while actually still running on the box (i.e. keeping the Wineserver process intact.)

Archive

Configuration

Dimi wanted to get everyone's thoughts concerning how Wine should support being upgraded:

It seems that we are getting ever so closer to 0.9. Slow, but steady. Looking at the TODO, it looks like upgrading is one of the big showstoppers, in that it will affect (1) the end-user experience, and (2) how we deal with the configuration.

So this seems like a good time to start discussing this topic, as we need to eventually reach the elusive 0.9. This seems to be a difficult topic, so we need to approach the problem well prepared. That is, we need to first define (and agree) on what we need to solve here. So after a tumultuous discussion on IRC, I decided to get the ball rolling.

Intuitively, upgrading wine is simple to understand: once a new version is installed, we need to get users in a state where they can use it. While simple to state, this problem is complicated by the various corner cases that can appear in Real Life (TM):

native vs. builtin DLLs handling
multiple Wine installations on a box
updating only some DLLs
integrating into the Unix environment
dealing with Windows software

We can also look at some important use-cases that we need to support, but before we do, the following must hold true in all cases:

administrators should be able to install a new Wine on the system easily with "rpm -U" (or equivalent).
the upgrade should not erase registry settings that are managed by the user

Let's look at the use-cases:

A. Global Install: In this case, both Wine code, as well as applications are installed globally, for all users to access. This is the most Unix-like setup, but unfortunately the most difficult to support, due to the fact that Win32 apps simply expect a different environment. Since we can't control application's code, this setup may present some limitations, but it may be sufficient for sites that need a limited set of applications. For this to work, it is acceptable that we ship special scripts that know about the applications that are supported, so that they can work around inherent limitations in the applications themselves. Users should transparently be able to use the new version of wine, the next time they start wine.
B. Mixed Install: Here, Wine code is installed globally, but applications are installed in the user's account. In a way is like (A) but with some additional applications installed directly into the user's account. Same requirements apply to this case as well.
C. Local Install: Both Wine code, as well as applications are installed locally, into the user's account. The Wine code is still installed globally by the administrator (as in A & B), but it is copied locally before it's being used. An upgrade in this case may require an explicit action by the user, so the upgrade can happen at a controlled time, when the user desires it.

In all of the above, there is always state in the user directory. Thus, it is imperative that the upgrade process makes sure that after the upgrade, the user-private state is consistent with the new code base. Also, any solution must take into account that the registry must be created on the fly, as it is created when registering the DLLs.

Before we go any further, I'd like to ask everybody to contribute their thoughts/requirements/desires so that we get a comprehensive view of the problem we are trying to solve.

There wasn't a whole lot of discussion, which probably means a lot of people agreed with Dimi's assessment. The few posts generated seemed to be concerned primarily with if, or how, Wine could support being upgraded while actually still running on the box (i.e. keeping the Wineserver process intact.)

About Converting W->A Calls 06/29/2004 Archive

About Converting W->A Calls	06/29/2004	Archive
Internationalization Wine's Janitorial Projects are a great way to get involved. We actually have a pretty good track record of finishing things, but there's always more to do. One big project is to change the way ASCII and Unicode functions are called. Much of the Windows API has provisions for two different versions of a function - one is the regular ASCII version and the other handles "Wide" characters. Many functions were originally implemented only as the "A" version. Howver, with the switch to Unicode we now have to support the "W" version as well. The simple way that was done was to just call the A version from the W version and be done with it. But that conversion is lossy, so a better way is to implement everything in the W version of the function and have the A version call that. An alternative is to implement two complete versions that handle their respective type of character. James Hawkins wanted to work on this clean up and asked for what approach would be best: I am currently working on the janitorial task of getting rid of W->A calls and I have a few questions about how I should implement these changes. I'll start the question with an example: `dlls/advapi32/crypt.c line 255, 482` Initially CryptAcquireContextW converts all of its arguments to ansi then calls CryptAcquireContextA (which is intuitively not what we're wanting and thus the cleanup.) The question is, what exactly is the best way to clean this up? It seems to me that there are two main options as to what can be done: A) convert the W->A calls in the wide-char functions to A->W calls in the ascii functions and implement the wide-char functions instead, or B) implement both ascii and wide-char functions separately i.e. ascii functions only call ascii functions etc. If we are to choose plan A, I have seen several different methods of converting ascii to wide-char, and I am wondering which method is best. I would have to argue that implementing both the ascii functions and wide-char functions separately would be the most efficient way to solve the W->A problem. Throughout all the wine libs, many conversion calls are being made from W->A and A->W, when most of these calls could be left out. I think performance would improve without all of the conversion calls. Granted the size of the code would increase, but speed would also increase. There are a couple snags when it comes to implementing ascii and wide-char functions independently, but that can be discussed later. If I'm totally off the mark, let me know, and if there are other jobs I could be doing, let me know as well because I would like to contribute, but I'm not exactly sure what to do yet. Thank you for your time. Marcelo Duarte advised: I did not check your code, but each situation has its reason and you decide which will be better. I suggest you to start converting something simple, like: `dlls/shell32/systray.c: shell32: Shell_NotifyIconW: illegal call to Shell_NotifyIconA dlls/version/install.c: version: VerInstallFileW: illegal call to VerInstallFileA` When I made one of these conversions, I chose "`dlls/shell32/shlexec.c: shell32: ShellExecuteExW: illegal call to ShellExecuteExAand` " very laborious and was complicated. You can give a look at one I made: http://cvs.winehq.com/patch.py?id=10692 Steven Edwards also had some suggestions, Welcome! I don't think it matters from a performance point of view. From my reading of documentation regarding Windows NT it seems they have about a 20% performance hit on the ASCII calls vs the Unicode calls. I think that they implement both ASCII and Unicode rather than have ASCII call the unicode functions. (This is due to the fact that they had a semi-share source base with Win9x). Most of Wine just has the A function call the W function so I would follow this standard. It will reduce code duplication and prob'l lessen bugs.

Internationalization

Wine's Janitorial Projects are a great way to get involved. We actually have a pretty good track record of finishing things, but there's always more to do. One big project is to change the way ASCII and Unicode functions are called. Much of the Windows API has provisions for two different versions of a function - one is the regular ASCII version and the other handles "Wide" characters. Many functions were originally implemented only as the "A" version. Howver, with the switch to Unicode we now have to support the "W" version as well. The simple way that was done was to just call the A version from the W version and be done with it. But that conversion is lossy, so a better way is to implement everything in the W version of the function and have the A version call that. An alternative is to implement two complete versions that handle their respective type of character. James Hawkins wanted to work on this clean up and asked for what approach would be best:

I am currently working on the janitorial task of getting rid of W->A calls and I have a few questions about how I should implement these changes.

I'll start the question with an example:

dlls/advapi32/crypt.c line 255, 482

Initially CryptAcquireContextW converts all of its arguments to ansi then calls CryptAcquireContextA (which is intuitively not what we're wanting and thus the cleanup.)

The question is, what exactly is the best way to clean this up?

It seems to me that there are two main options as to what can be done:

A) convert the W->A calls in the wide-char functions to A->W calls in the ascii functions and implement the wide-char functions instead, or

B) implement both ascii and wide-char functions separately i.e. ascii functions only call ascii functions etc.

If we are to choose plan A, I have seen several different methods of converting ascii to wide-char, and I am wondering which method is best.

I would have to argue that implementing both the ascii functions and wide-char functions separately would be the most efficient way to solve the W->A problem. Throughout all the wine libs, many conversion calls are being made from W->A and A->W, when most of these calls could be left out. I think performance would improve without all of the conversion calls. Granted the size of the code would increase, but speed would also increase.

There are a couple snags when it comes to implementing ascii and wide-char functions independently, but that can be discussed later.

If I'm totally off the mark, let me know, and if there are other jobs I could be doing, let me know as well because I would like to contribute, but I'm not exactly sure what to do yet. Thank you for your time.

Marcelo Duarte advised:

I did not check your code, but each situation has its reason and you decide which will be better. I suggest you to start converting something simple, like:


dlls/shell32/systray.c: shell32: Shell_NotifyIconW: illegal call to 
Shell_NotifyIconA

dlls/version/install.c: version: VerInstallFileW: illegal call to 
VerInstallFileA

When I made one of these conversions, I chose "dlls/shell32/shlexec.c: shell32: ShellExecuteExW: illegal call to ShellExecuteExAand " very laborious and was complicated. You can give a look at one I made: http://cvs.winehq.com/patch.py?id=10692

Steven Edwards also had some suggestions, Welcome! I don't think it matters from a performance point of view. From my reading of documentation regarding Windows NT it seems they have about a 20% performance hit on the ASCII calls vs the Unicode calls. I think that they implement both ASCII and Unicode rather than have ASCII call the unicode functions. (This is due to the fact that they had a semi-share source base with Win9x). Most of Wine just has the A function call the W function so I would follow this standard. It will reduce code duplication and prob'l lessen bugs.

World Wine News