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?
James Hawkins wrote:
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?
I think that for all functions we can, but care should be taken about what "can" means.
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
On Apr 5, 2005 1:19 AM, Shachar Shemesh wine-devel@shemesh.biz wrote:
I think that for all functions we can, but care should be taken about what "can" means.
It's understandable that there will be functions where this process is not applicable, but for a majority of the api, we can implement the conversion with relative ease. Figuring out which conversions would be easy is up to us I guess.
"James" == James Hawkins truiken@gmail.com writes:
James> Hi, In the current state of wine, we have several A/W functions. James> Sometimes both the A and W functions are separately implemented James> with an ansi and unicode implementation respectively. Other A/W James> functions have the A forward to the W, converting the ansi to James> unicode. For all the functions that can, should we forward all A James> to their W counterparts? When it comes to the conformance test James> suite, this would be ideal. Only the A functions would have to James> be tested and in doing so, we test the A/W conversion and the James> functionality of the W functions (we're striving for all-unicode James> internally anyway). This would reduce the number of bugs, and James> the time it takes to fix current bugs. When both A and W are James> implemented and we find a bug in one of them, we have to remember James> to fix the same bug in the other function. For most of the James> functions, converting ansi to unicode is boilerplate code. This James> process could even be a janitorial project. What do you think?
Even in the case when all A-functions are forwarded to W-functions, a test-suite for only the A-functions may not be enough, as often there are some decisions in the A-function before the W-function is called. It the breakout condition is met, the W-function is not called, and so this condition is not tested for the W-function
-
James Hawkins -
Shachar Shemesh -
Uwe Bonnes