Checking Wine's spec files
Francois Gouget
fgouget at free.fr
Tue Feb 22 10:19:24 CST 2005
On Mon, 21 Feb 2005, Alexandre Julliard wrote:
[...]
> Yes I think they are very useful, though I wouldn't suggest blindly
> fixing things based on the reports since I suspect that at least in
> some cases we have wrong ordinals and this will cause complaints about
> the wrong functions.
It turns out that a lot of the functions my script complains should have
the -noname or not have the -noname property should:
* really not have a name at all
* or be marked as -private
Is this something we want to do?
This is shown by this small program which fails to link using the SDK's
shell32.lib file:
__declspec(dllimport) int __stdcall DoEnvironmentSubst(int, int);
__declspec(dllimport) int __stdcall FileMenu_AbortInitMenu();
__declspec(dllimport) int __stdcall Shell_GetImageList(int, int);
__declspec(dllimport) int __stdcall SHRegCloseKey(int);
int main()
{
DoEnvironmentSubst(0,0);
FileMenu_AbortInitMenu();
Shell_GetImageList(0,0);
SHRegCloseKey(0);
return 0;
}
Similarly in kernel32.spec we have a bunch of entry-points for Windows
9x APIs which Windows exports by ordinal only. However these APIs are
given names:
1 stdcall -register -i386 VxDCall0(long) VxDCall
24 stdcall GlobalAlloc16(long long)
That seems wrong since none of the kernel32 dlls ever exports a VxDCall0
or GlobalAlloc16 function. Shouldn't this be written as follows instead?
1 stdcall -register -i386 @(long) VxDCall
24 stdcall @(long long) GlobalAlloc16
The drawback is that this is going to make it harder to use these APIs
from other dlls (as in one would have to use GetProcAddress())...
Is this something we want to do anyway? Maybe just for the functions
which are not called from other dlls?
--
Francois Gouget fgouget at free.fr http://fgouget.free.fr/
I haven't lost my mind, it's backed up on tape around here somewhere...
More information about the wine-devel
mailing list