On 07/20/2010 06:14 AM, Andrew Nguyen wrote:
dlls/shlwapi/tests/string.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
This patchset introduces crashes in these tests on W2K, XP and W2K3:
http://test.winehq.org/data/tests/shlwapi:string.html
Further than that it seems that none of the test are run on several platforms now.
If I look at my Win98 box I get "The xx.exe file is linked to missing export SHELL32.DLL:StrChrA"
and on some Vista+ boxes (not on my Vista for example):
http://testbot.winehq.org/JobDetails.pl?Key=3663&scrshot_106=1#k106
Could you have a look? Notice the mentioning of SHELL32 in those errors.
On 07/22/2010 04:32 AM, Paul Vriens wrote:
On 07/20/2010 06:14 AM, Andrew Nguyen wrote:
dlls/shlwapi/tests/string.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
This patchset introduces crashes in these tests on W2K, XP and W2K3:
http://test.winehq.org/data/tests/shlwapi:string.html
Further than that it seems that none of the test are run on several platforms now.
If I look at my Win98 box I get "The xx.exe file is linked to missing export SHELL32.DLL:StrChrA"
and on some Vista+ boxes (not on my Vista for example):
http://testbot.winehq.org/JobDetails.pl?Key=3663&scrshot_106=1#k106
Could you have a look? Notice the mentioning of SHELL32 in those errors.
Hmm, I'm skeptical that the patches are directly responsible for the crashes.
The shlwapi string tests with the patches were first run for build 061eb12ca39d (July 20) without issues. What's really peculiar in the results you linked is that the shlwapi tests are being skipped entirely on almost all platforms except for Win2k/XP/Win2k3, which was not the case previously.
The only changes between build 061eb12ca39d and the latest that I can see for dlls/shlwapi/tests is Alexandre's global changes to the DLL imports (commit b86d515ed6c3) and Andrew Eikum's change to shlwapi which introduced a test and a corresponding import for shell32 (commit d6a827d08315). I'll investigate further.
On 07/22/2010 12:31 PM, Andrew Nguyen wrote:
On 07/22/2010 04:32 AM, Paul Vriens wrote:
On 07/20/2010 06:14 AM, Andrew Nguyen wrote:
dlls/shlwapi/tests/string.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
This patchset introduces crashes in these tests on W2K, XP and W2K3:
http://test.winehq.org/data/tests/shlwapi:string.html
Further than that it seems that none of the test are run on several platforms now.
If I look at my Win98 box I get "The xx.exe file is linked to missing export SHELL32.DLL:StrChrA"
and on some Vista+ boxes (not on my Vista for example):
http://testbot.winehq.org/JobDetails.pl?Key=3663&scrshot_106=1#k106
Could you have a look? Notice the mentioning of SHELL32 in those errors.
Hmm, I'm skeptical that the patches are directly responsible for the crashes.
The shlwapi string tests with the patches were first run for build 061eb12ca39d (July 20) without issues. What's really peculiar in the results you linked is that the shlwapi tests are being skipped entirely on almost all platforms except for Win2k/XP/Win2k3, which was not the case previously.
The only changes between build 061eb12ca39d and the latest that I can see for dlls/shlwapi/tests is Alexandre's global changes to the DLL imports (commit b86d515ed6c3) and Andrew Eikum's change to shlwapi which introduced a test and a corresponding import for shell32 (commit d6a827d08315). I'll investigate further.
Andrew Eikum's patch looks like a good candidate as StrChrA for example can be found in both shell32 and shlwapi. We probably need to do more explicit function loading.
On 07/22/2010 06:03 AM, Paul Vriens wrote:
On 07/22/2010 12:31 PM, Andrew Nguyen wrote:
On 07/22/2010 04:32 AM, Paul Vriens wrote:
On 07/20/2010 06:14 AM, Andrew Nguyen wrote:
dlls/shlwapi/tests/string.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
This patchset introduces crashes in these tests on W2K, XP and W2K3:
http://test.winehq.org/data/tests/shlwapi:string.html
Further than that it seems that none of the test are run on several platforms now.
If I look at my Win98 box I get "The xx.exe file is linked to missing export SHELL32.DLL:StrChrA"
and on some Vista+ boxes (not on my Vista for example):
http://testbot.winehq.org/JobDetails.pl?Key=3663&scrshot_106=1#k106
Could you have a look? Notice the mentioning of SHELL32 in those errors.
Hmm, I'm skeptical that the patches are directly responsible for the crashes.
The shlwapi string tests with the patches were first run for build 061eb12ca39d (July 20) without issues. What's really peculiar in the results you linked is that the shlwapi tests are being skipped entirely on almost all platforms except for Win2k/XP/Win2k3, which was not the case previously.
The only changes between build 061eb12ca39d and the latest that I can see for dlls/shlwapi/tests is Alexandre's global changes to the DLL imports (commit b86d515ed6c3) and Andrew Eikum's change to shlwapi which introduced a test and a corresponding import for shell32 (commit d6a827d08315). I'll investigate further.
Andrew Eikum's patch looks like a good candidate as StrChrA for example can be found in both shell32 and shlwapi. We probably need to do more explicit function loading.
There are a few things I'm wondering about:
When the winetest shlwapi binary was built, what made the compiler decide to import shell32 for the problematic string functions? Neither my local cross-compile build nor the build that the test bot performs seemed to do this. I notice that shell32 is the first import listed in dlls/shlwapi/tests/Makefile.in. Was it possible that the listed import order influenced how the compiler linked the string functions, and would changing the import order be preferable to explicitly loading string functions that seem to be available on all shlwapi versions?
Also, how is the skip detection for the case of a purported unavailable DLL done? It seems strange that the shlwapi tests were skipped entirely on various platforms when shlwapi should have been available for testing.
On 07/22/2010 02:03 PM, Andrew Nguyen wrote:
There are a few things I'm wondering about:
When the winetest shlwapi binary was built, what made the compiler decide to import shell32 for the problematic string functions? Neither my local cross-compile build nor the build that the test bot performs seemed to do this. I notice that shell32 is the first import listed in dlls/shlwapi/tests/Makefile.in. Was it possible that the listed import order influenced how the compiler linked the string functions, and would changing the import order be preferable to explicitly loading string functions that seem to be available on all shlwapi versions?
No clue. If we want to test some function in shlwapi however why not explicitly load them?
Also, how is the skip detection for the case of a purported unavailable DLL done? It seems strange that the shlwapi tests were skipped entirely on various platforms when shlwapi should have been available for testing.
The first thing winetest does is run a "<dll>_test.exe --list" for each dll. If there is a missing export (or import library) it will not include this dll in the tests (so none of the subtests will run).
On 07/22/2010 07:21 AM, Paul Vriens wrote:
On 07/22/2010 02:03 PM, Andrew Nguyen wrote:
There are a few things I'm wondering about:
When the winetest shlwapi binary was built, what made the compiler decide to import shell32 for the problematic string functions? Neither my local cross-compile build nor the build that the test bot performs seemed to do this. I notice that shell32 is the first import listed in dlls/shlwapi/tests/Makefile.in. Was it possible that the listed import order influenced how the compiler linked the string functions, and would changing the import order be preferable to explicitly loading string functions that seem to be available on all shlwapi versions?
No clue. If we want to test some function in shlwapi however why not explicitly load them?
Well, I figure that since the problematic string functions under test resided in the shlwapi tests, it seems natural to expect that shlwapi would be linked in for the relevant functions rather than a different imported DLL. I concede that explicitly loading the functions might be the best way to resolve the ambiguity, however.
On 07/22/2010 02:36 PM, Andrew Nguyen wrote:
On 07/22/2010 07:21 AM, Paul Vriens wrote:
On 07/22/2010 02:03 PM, Andrew Nguyen wrote:
There are a few things I'm wondering about:
When the winetest shlwapi binary was built, what made the compiler decide to import shell32 for the problematic string functions? Neither my local cross-compile build nor the build that the test bot performs seemed to do this. I notice that shell32 is the first import listed in dlls/shlwapi/tests/Makefile.in. Was it possible that the listed import order influenced how the compiler linked the string functions, and would changing the import order be preferable to explicitly loading string functions that seem to be available on all shlwapi versions?
No clue. If we want to test some function in shlwapi however why not explicitly load them?
Well, I figure that since the problematic string functions under test resided in the shlwapi tests, it seems natural to expect that shlwapi would be linked in for the relevant functions rather than a different imported DLL. I concede that explicitly loading the functions might be the best way to resolve the ambiguity, however.
Just changed the order in the Makefile.in and now winedump shows that the Str* functions are imported from shlwapi.dll.
No idea what the best approach is here, anyone?
Paul Vriens paul.vriens.wine@gmail.com writes:
On 07/22/2010 02:03 PM, Andrew Nguyen wrote:
There are a few things I'm wondering about:
When the winetest shlwapi binary was built, what made the compiler decide to import shell32 for the problematic string functions? Neither my local cross-compile build nor the build that the test bot performs seemed to do this. I notice that shell32 is the first import listed in dlls/shlwapi/tests/Makefile.in. Was it possible that the listed import order influenced how the compiler linked the string functions, and would changing the import order be preferable to explicitly loading string functions that seem to be available on all shlwapi versions?
No clue. If we want to test some function in shlwapi however why not explicitly load them?
The order matters, so functions will be resolved to shell32 first. A better fix is to get rid of the shell32 import. We do want to import shlwapi to test ordinal imports.
On 07/22/2010 02:55 PM, Alexandre Julliard wrote:
Paul Vrienspaul.vriens.wine@gmail.com writes:
On 07/22/2010 02:03 PM, Andrew Nguyen wrote:
There are a few things I'm wondering about:
When the winetest shlwapi binary was built, what made the compiler decide to import shell32 for the problematic string functions? Neither my local cross-compile build nor the build that the test bot performs seemed to do this. I notice that shell32 is the first import listed in dlls/shlwapi/tests/Makefile.in. Was it possible that the listed import order influenced how the compiler linked the string functions, and would changing the import order be preferable to explicitly loading string functions that seem to be available on all shlwapi versions?
No clue. If we want to test some function in shlwapi however why not explicitly load them?
The order matters, so functions will be resolved to shell32 first. A better fix is to get rid of the shell32 import. We do want to import shlwapi to test ordinal imports.
So something like the attached? Not fully tested yet.
Paul Vriens paul.vriens.wine@gmail.com writes:
So something like the attached? Not fully tested yet.
Yes.
-
Alexandre Julliard -
Andrew Nguyen -
Paul Vriens