"Dimitrie O. Paun" dpaun@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.