InitThreadInput16

[Alexandre Julliard]

"Dimitrie O. Paun" <dpaun at rogers.com> writes:

> True, but InitThreadInput16 is not such a function, InitThreadInput is.
> So we had to invent a new name that does not exist in Windows.
> And I thought the policy for new names which are wine specific was
> to prefix them with wine_*. But in a way I see a point in this naming
> convention, as it keeps the name close to an official function. However,
> it is a departure from our naming policy, right?

No, the naming policy has always been that 16-bit functions have a
"16" suffix. That's necessary because most of the time there is a
32-bit one with the same name, and in our code they are in the same
namespace. Usually they are only called from inside the same dll so
you don't need to add the extra 32-bit export, but the naming
convention is the same in both cases.

> Also, there is a small problem with this 16-bit stuff: it is usually
> called from 32-bit code, and this code has to do a 32->16 bit conversion
> on handles, coordinates, etc, which are lossy. So I think it would make 
> more sense to export InitThreadInput32 (if we have to export a new name 
> anyway), and have InitThreadInput16 call it. This way we will have no 
> deps on 16bit code, and we can compile it out (just for kicks, winelib, 
> and to check that there are no 32->16 transitions).

I disagree. The right fix to avoid calling 16-bit functions is to
change the whole logic to not depend on them; simply hiding them
behind a 32-bit export that doesn't exist on Windows is not a good
fix. At least with the 16 suffix it's clear that something is wrong.

-- 
Alexandre Julliard
julliard at winehq.com