Hi,
With the current version of winetest, conformance tests for which the main dll is not available will not run anymore. This will be reported on test.winehq.org. We will be seeing the new approach as of 12:00 GMT when the new winetest.exe is available and the first tests come in.
Several tests currently check for the existence of the dll via LoadLibrary and do a lot of GetProcAddress calls to retrieve function pointers.
This should not be needed anymore in most cases. The tests that come to mind:
d3d8 d3d9 d3drm gdiplus localspl localui pdh uxtheme
and there are (and will be in the future) others.
My plan, and this is open for discussion of course, is to:
1. Add the main dll back as part of the IMPORTS in the Makefile.in files 2. Change LoadLibrary to GetModuleHandle and still use GetProcAddress to catch unexported functions (for a short period). We do need to reporting missing functions. 3. Remove GetModuleHandle and/or GetProcAddress's if possible and make more use of 'skip' if needed.
This will be a lengthy process so if there are volunteers, please step up.
Eventhough this is some considerable amount of work to be done, in the end the code will be cleaner (and several lines shorter).
Comments/remarks ?
Cheers,
Paul.
On 07/08/07, Paul Vriens paul.vriens.wine@gmail.com wrote:
Eventhough this is some considerable amount of work to be done, in the end the code will be cleaner (and several lines shorter).
Comments/remarks ?
For what it's worth, the d3d tests typically only need a single export. That should make it relatively easy to change them, but it also means there's not a lot to gain there.
H. Verbeet wrote:
On 07/08/07, Paul Vriens paul.vriens.wine@gmail.com wrote:
Eventhough this is some considerable amount of work to be done, in the end the code will be cleaner (and several lines shorter).
Comments/remarks ?
For what it's worth, the d3d tests typically only need a single export. That should make it relatively easy to change them, but it also means there's not a lot to gain there.
You mean 'Direct3DCreate8' in the d3d8 tests (Oh wait, there's also 'ValidateVertexShader' and 'ValidatePixelShader') and 'Direct3DCreate9' in the d3d9 tests?
For consistency sake we should change it there as well. Although it's just a LoadLibrary turned into a GetModuleHandle.
Paul.
On 07/08/07, Paul Vriens paul.vriens.wine@gmail.com wrote:
You mean 'Direct3DCreate8' in the d3d8 tests (Oh wait, there's also 'ValidateVertexShader' and 'ValidatePixelShader') and 'Direct3DCreate9' in the d3d9 tests?
For consistency sake we should change it there as well. Although it's just a LoadLibrary turned into a GetModuleHandle.
Yeah.
Am Dienstag, 7. August 2007 10:29 schrieb H. Verbeet:
On 07/08/07, Paul Vriens paul.vriens.wine@gmail.com wrote:
You mean 'Direct3DCreate8' in the d3d8 tests (Oh wait, there's also 'ValidateVertexShader' and 'ValidatePixelShader') and 'Direct3DCreate9' in the d3d9 tests?
For consistency sake we should change it there as well. Although it's just a LoadLibrary turned into a GetModuleHandle.
Yeah.
I am not an expert on this, but I think using LoadLibrary helps compilation on systems where the library is not available, e.g. cross compiling. Last time I checked mingw did not have a d3d10.a file to link to d3d10.dll, and it would also help to compile d3d10 apps on winxp(not sure if there's a need for that though).
Then there are also sort of undocumented internal dlls which wine still has to implement - ddrawex.dll comes to my mind, which seems to be a special ddraw lib for Internet Explorer. It contains the IDirectDraw3 interface, sort of a missing link, and I didn't find a ddrawex.lib or ddrawex.a to link against.
Stefan Dösinger wrote:
Am Dienstag, 7. August 2007 10:29 schrieb H. Verbeet:
On 07/08/07, Paul Vriens paul.vriens.wine@gmail.com wrote:
You mean 'Direct3DCreate8' in the d3d8 tests (Oh wait, there's also 'ValidateVertexShader' and 'ValidatePixelShader') and 'Direct3DCreate9' in the d3d9 tests?
For consistency sake we should change it there as well. Although it's just a LoadLibrary turned into a GetModuleHandle.
Yeah.
I am not an expert on this, but I think using LoadLibrary helps compilation on systems where the library is not available, e.g. cross compiling. Last time I checked mingw did not have a d3d10.a file to link to d3d10.dll, and it would also help to compile d3d10 apps on winxp(not sure if there's a need for that though).
Then there are also sort of undocumented internal dlls which wine still has to implement - ddrawex.dll comes to my mind, which seems to be a special ddraw lib for Internet Explorer. It contains the IDirectDraw3 interface, sort of a missing link, and I didn't find a ddrawex.lib or ddrawex.a to link against.
I guess it would help in cross compilation. But isn't that the 'responsibility' of the cross-compiling package? If you want to crosscompile d3d10 on linux (and are using mingw) then mingw should provide you with the necessary stuff.
The special dll like ddrawex.dll falls under the same category I guess.
But I'm a little bit biased in this of course :-).
Cheers,
PAul.
Am Tuesday 07 August 2007 09:43 schrieb Paul Vriens:
This will be a lengthy process so if there are volunteers, please step up.
Eventhough this is some considerable amount of work to be done, in the end the code will be cleaner (and several lines shorter).
Comments/remarks ?
Make sure that Paul Millar has time to update the mingw build environment. Otherwise we have to wait some time to get a new winetest.exe from the download side.
Bye Stefan
Stefan Leichter wrote:
Am Tuesday 07 August 2007 09:43 schrieb Paul Vriens:
This will be a lengthy process so if there are volunteers, please step up.
Eventhough this is some considerable amount of work to be done, in the end the code will be cleaner (and several lines shorter).
Comments/remarks ?
Make sure that Paul Millar has time to update the mingw build environment. Otherwise we have to wait some time to get a new winetest.exe from the download side.
Bye Stefan
The only issue I see there is if we now do a LoadLibrary and when we add the dll back to the IMPORTS of the Makefile.in. This could lead to issues if some dll/function is not known to mingw.
The best thing to catch these upfront is to do a 'make crosstest' before submitting any patch, right? (But that's something I'm doing most of the time anyway.)
Cheers,
PAul.
On Di, 2007-08-07 at 09:43 +0200, Paul Vriens wrote:
My plan, and this is open for discussion of course, is to:
- Add the main dll back as part of the IMPORTS in the Makefile.in files
Some API are defined once, but implemented many times: The monitor in localspl and localui as examples.
You must make sure, that the tests can still be compiled with msvc. (localspl.lib / localui.lib does not exist)
-
Detlef Riekenberg -
H. Verbeet -
Paul Vriens -
Stefan Dösinger -
Stefan Leichter