Francois Gouget wrote:
winetest can detect if twain_32.dll is there or not, and if it's missing there's nothing to test anyway. Note that make_makefiles will need to be run.
This patch breaks make crosstest for me:
[apevia:~/w/wine/dlls/twain_32/tests] make crosstest i586-mingw32msvc-gcc dsm.cross.o testlist.cross.o -o twain_32_crosstest.exe -L../../../dlls -L../../../dlls/twain_32 -L../../../dlls/user32 -L../../../dlls/gdi32 -L../../../dlls/kernel32 -ltwain_32 -luser32 -lgdi32 -lkernel32 /usr/lib/gcc/i586-mingw32msvc/4.2.1-sjlj/../../../../i586-mingw32msvc/bin/ld: cannot find -ltwain_32 collect2: ld returned 1 exit status make: *** [twain_32_crosstest.exe] Error 1
(it also breaks make test for me, but that may be operator error).
But, what's more, I do not see the point. Twain_32 is not a Microsoft DLL; it is not present by default on most Windows systems. Further, the API specifications are quite clear: you're supposed to LoadLibrary Twain32, and all Twain applications I've tested do so. I don't see the benefit in making our test behave differently than the recommended behavior for this DLL.
Cheers,
Jeremy
On Fri, 27 Feb 2009, Jeremy White wrote: [...]
This patch breaks make crosstest for me:
[apevia:~/w/wine/dlls/twain_32/tests] make crosstest i586-mingw32msvc-gcc dsm.cross.o testlist.cross.o -o twain_32_crosstest.exe -L../../../dlls -L../../../dlls/twain_32 -L../../../dlls/user32 -L../../../dlls/gdi32 -L../../../dlls/kernel32 -ltwain_32 -luser32 -lgdi32 -lkernel32 /usr/lib/gcc/i586-mingw32msvc/4.2.1-sjlj/../../../../i586-mingw32msvc/bin/ld: cannot find -ltwain_32 collect2: ld returned 1 exit status make: *** [twain_32_crosstest.exe] Error 1
You're missing dlls/twain_32/libtwain_32.a. Just run 'make crosstest' in the dlls directory, or 'make libtwain_32.a' in the dlls/twain_32 directory (the crosstest dependencies are not 100%).
(it also breaks make test for me, but that may be operator error).
You're right. I forgot to test that change apparently (it got lost in the skip() -> win_skip() tests). Ironically it's failing because I'm still doing a GetProcAddress() on DSM_Entry so that there is nothing to import from twain_32.dll so that we don't really link with it.
But, what's more, I do not see the point. Twain_32 is not a Microsoft DLL; it is not present by default on most Windows systems. Further, the API specifications are quite clear: you're supposed to LoadLibrary Twain32, and all Twain applications I've tested do so.
I think they just recommend that so that your application (e.g. Photoshop) continues to work even if twain_32.dll is not installed. But our conformance test has no point if twain_32.dll is not installed.
I don't see the benefit in making our test behave differently than the recommended behavior for this DLL.
Three reasons: * Consistency with the other Wine conformance tests. * Ease of programmation. No need to worry about GetProcAddress() & co. (and improved type safety, though less for twain_32 than for other tests) * In the test results on the website, it will be clear that the dll was not installed if that's the case, whereas with LoadLibrary() it will just be one more skip() lost in a sea of skips.
Francois Gouget fgouget@free.fr writes:
- In the test results on the website, it will be clear that the dll was not installed if that's the case, whereas with LoadLibrary() it will just be one more skip() lost in a sea of skips.
If the dll is not present then winetest won't even run the test, it doesn't make any difference whether it's imported statically or dynamically.
-
Alexandre Julliard -
Francois Gouget -
Jeremy White