James Hawkins wrote:
I think that for all functions we can, but care should be taken about what "can" means.Hi,
In the current state of wine, we have several A/W functions. Sometimes both the A and W functions are separately implemented with
an ansi and unicode implementation respectively. Other A/W functions
have the A forward to the W, converting the ansi to unicode. For all
the functions that can, should we forward all A to their W
counterparts? When it comes to the conformance test suite, this would
be ideal. Only the A functions would have to be tested and in doing
so, we test the A/W conversion and the functionality of the W
functions (we're striving for all-unicode internally anyway). This
would reduce the number of bugs, and the time it takes to fix current
bugs. When both A and W are implemented and we find a bug in one of
them, we have to remember to fix the same bug in the other function. For most of the functions, converting ansi to unicode is boilerplate
code. This process could even be a janitorial project. What do you
think?
For example, some experiments on Windows lead me to believe that GetCharacterPlacementW calls the A version, instead of vice versa (that is, on Windows 2000). Trying to reorder a string with Unicode characters not in the locale simply doesn't work. Obviously, is almost no one calls GetCharacterPlacement at all, this is not something we should be overly worried about, but I'm just trying to point out that such situations exist.
Other places where converting the dependent calls have been tricky is with all the functions that put up a dialog box (and thus require a message handler function). These are fairly tricky to get right without repeating code, and in many places we preferred not to.
What I'm trying to say is that I'm with you on that one, but stating it as you have may lead some people to be overly enthusiastic about things.
Shachar
-- Shachar Shemesh Lingnu Open Source Consulting ltd. Have you backed up today's work? http://www.lingnu.com/backup.html
