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

[Alexandre Julliard]

Rémi Bernon <rbernon at codeweavers.com> writes:

> 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.

Yes, the driver interface is pretty much ad-hoc, there's no need to try
hard to be consistent. In general, the idea is for the driver entry
points to look as much as possible like their user32 counterparts, so in
that sense a magic return value is better than extra parameters.

-- 
Alexandre Julliard
julliard at winehq.org