[PATCH v2 1/3] user32: Move ToUnicodeEx from wineandroid.drv to user32.

[Rémi Bernon]

On 4/27/21 4:55 PM, Alexandre Julliard wrote:
> Rémi Bernon <rbernon at codeweavers.com> writes:
> 
>> On 4/27/21 4:26 PM, Alexandre Julliard wrote:
>>> Rémi Bernon <rbernon at codeweavers.com> writes:
>>>
>>>> In the end, having the default implementation run all the time didn't
>>>> seem too bad, especially if as it's not doing much, and if we consider
>>>> it could then be extended to cover more cases and reduce the amount of
>>>> driver code.
>>>>
>>>> If we consider keyboard layouts I would think that it could be decided
>>>> based on the HKL, with some special value(s) meaning the layout is
>>>> handled by the driver while "standard" layout would be implemented in
>>>> user32.
>>>>
>>>> Anyway, If you like the NTSTATUS style more, I can do it like this.
>>> I still find it better to call the driver first, and do the extra
>>> work
>>> only if needed. If we do it right, the default implementation is only
>>> going to become more complex, and that would be all the more reason to
>>> ask the driver first.
>>> I'm not sure that I see a need to use NTSTATUS here, plus it
>>> wouldn't
>>> quite fit with the usual user32 calling conventions. At some point we
>>> may want to turn this into a syscall interface and use NTSTATUS
>>> everywhere, but that would be a complete redesign of the driver
>>> interface.
>>>
>>
>> Yes, and I said NTSTATUS with that in mind, but it could very well be
>> BOOL for now and return TRUE/FALSE if it's implemented or not, the
>> inconvenience of changing the driver return paths is pretty much the
>> same though.
>>
>> Ok it's maybe not that bad...
> 
> I find return -2 in the null driver a lot easier, but maybe that's just me ;-)
> 

In this case sure, but then there's things like MapVirtualKeyEx or the 
other calls. But maybe I'm trying too hard to have a consistent pattern 
for something that is subject to change anyway.
-- 
Rémi Bernon <rbernon at codeweavers.com>