On 4/27/21 3:41 PM, Alexandre Julliard wrote:
Rémi Bernon rbernon@codeweavers.com writes:
As a default implementation for en_US keyboard layout, calling the driver implementation next so that it can override the result.
Is there really a need to build the default result first and pass it to the driver? Otherwise I'd suggest to call the driver first, and use a special return value like -2 to indicate fallback.
I wanted to avoid special values like this, because they could have a meaning. Maybe not for ToUnicodeEx, but other driver calls for which I'd like to add a default implementation too.
I thought about adding NTSTATUS as a return code instead, and treating for instance STATUS_NOT_IMPLEMENTED as an indication that the driver doesn't implement the call and that we should use the default impl.
But then it would require to move the return value as an output parameter instead, changing more driver code and especially changing their return path, which is sometimes spread out.
Also some driver call actually do
SetLastError(STATUS_NOT_IMPLEMENTED); return 0;
and I found it confusing to have return STATUS_SUCCESS here.
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.