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