OK,
This DLL stuff is a bit confusing. In dlls/user/user32.spec we have
409 pascal16 InitThreadInput(word word) InitThreadInput16
so the exported name is InitThreadInput, right?
Then how come in ./dlls/x11drv/desktop.c we call it like so:
win->hmemTaskQ = InitThreadInput16( 0, 0 );
Shouldn't this yield an error?
"Dimitrie O. Paun" dpaun@rogers.com writes:
This DLL stuff is a bit confusing. In dlls/user/user32.spec we have
409 pascal16 InitThreadInput(word word) InitThreadInput16
so the exported name is InitThreadInput, right?
No, that line is not in user32.spec, it's in user.exe.spec which is the 16-bit one. 16-bit functions cannot be imported from other dlls since this would require calling down to 16-bit which we want to avoid. So that InitThreadInput export is only available for 16-bit binaries, not for Winelib dlls.
Then how come in ./dlls/x11drv/desktop.c we call it like so:
win->hmemTaskQ = InitThreadInput16( 0, 0 );Shouldn't this yield an error?
It should, but to work around it we have added an InitThreadInput16 export in user32.spec; this time it's a normal 32-bit export so it can be used from other dlls. This is really a hack because Windows doesn't do it like this of course.
On September 27, 2002 01:06 pm, Alexandre Julliard wrote:
It should, but to work around it we have added an InitThreadInput16 export in user32.spec; this time it's a normal 32-bit export so it can be used from other dlls. This is really a hack because Windows doesn't do it like this of course.
But it seems that InitThreadInput is an undocumented API. Why export an (and depend on) undocumented 16-bit function. If we need the functionality, shouldn't we rather export a 32-bit API, with a name like wine_init_thread_input or what have you, and with a well defined, and understood semantics?
"Dimitrie O. Paun" dpaun@rogers.com writes:
But it seems that InitThreadInput is an undocumented API. Why export an (and depend on) undocumented 16-bit function. If we need the functionality, shouldn't we rather export a 32-bit API, with a name like wine_init_thread_input or what have you, and with a well defined, and understood semantics?
No, it's better to always use official functions. It doesn't matter if it's not documented, we have to understand it and implement it correctly anyway. So it's better to use it internally too than to invent a different one to do the same thing.
On September 27, 2002 01:57 pm, you wrote:
No, it's better to always use official functions.
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?
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).
"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.
-
Alexandre Julliard -
Dimitrie O. Paun