http://bugs.winehq.org/show_bug.cgi?id=4634
------- Additional Comments From saulius.krasuckas@elst.vtu.lt 2006-23-02 05:12 ------- | And apparently the toolhelp.dll.ClassFirst is not yet implemented on WINE:
Though I think it should be implemented already:
$ ll dlls/toolhelp* | -rw-rw-r-- 1 s2 s2 13 Feb 22 12:50 dlls/toolhelp.dll16 | lrwxrwxrwx 1 s2 s2 15 Feb 13 00:42 dlls/toolhelp.dll.so -> kernel32.dll.so
$ cat dlls/toolhelp.dll16 | kernel32.dll
Looks like another reference to the same builtin module "kernel32.dll".
$ cat dlls/kernel32.dll.so | strings | grep ClassFirst | ClassFirst | __wine_stub_ClassFirst
Stub?
$ grep -r ClassFirst dlls/kernel | dlls/kernel/toolhelp.h:BOOL16 WINAPI ClassFirst16( CLASSENTRY *pClassEntry ); | dlls/kernel/toolhelp.spec:#69 pascal -ret16 ClassFirst(ptr) ClassFirst16 | dlls/kernel/toolhelp.spec:69 stub ClassFirst | Binary file dlls/kernel/kernel32.dll.so matches | Binary file dlls/kernel/toolhelp.spec.o matches
Stub, but lets go further:
$ grep -r ClassFirst dlls/*/*.c | dlls/user/class.c: * ClassFirst (TOOLHELP.69) | dlls/user/class.c:BOOL16 WINAPI ClassFirst16( CLASSENTRY *pClassEntry )
So, it's implemented, only in another module, in "user32.dll". I don't know whether it can be forwarded at imports level. Probably it cannot. Kernel32 must not depend on User32, I guess.
Then it perhaps can be imported during run-time linking via GetProcAddres().
Or maybe the situation will change in nearest future as I saw AJ doing some module-load-rewrite recently. :)