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?