Hi,
We didn't have a new winetest executable for the last few days. MinGW doesn't know anything about a d3dx9 dll (yet) that's imported in the d3dx9_36 tests.
Especially while in the process of getting ready for 1.0 we should have winetest run as much as possible.
My main focus will be adding tests btw until 1.0 is out. These will be both tests to proof the correctness of the current implementation as well as tests to show missing stuff. There are loads of functions for which we have no tests yet and with the 1.0 in sight I think it becomes very important to have tests for virtually every function we (have) implement(ed).
On Tue, Mar 25, 2008 at 4:08 AM, Paul Vriens paul.vriens.wine@gmail.com wrote:
Hi,
We didn't have a new winetest executable for the last few days. MinGW doesn't know anything about a d3dx9 dll (yet) that's imported in the d3dx9_36 tests.
Especially while in the process of getting ready for 1.0 we should have winetest run as much as possible.
My main focus will be adding tests btw until 1.0 is out. These will be both tests to proof the correctness of the current implementation as well as tests to show missing stuff. There are loads of functions for which we have no tests yet and with the 1.0 in sight I think it becomes very important to have tests for virtually every function we (have) implement(ed).
While that's a worthy goal, I think a better short-term goal for the run up to 1.0 is to fix the current failing tests in Windows.
James Hawkins wrote:
On Tue, Mar 25, 2008 at 4:08 AM, Paul Vriens paul.vriens.wine@gmail.com wrote:
Hi,
We didn't have a new winetest executable for the last few days. MinGW doesn't know anything about a d3dx9 dll (yet) that's imported in the d3dx9_36 tests.
Especially while in the process of getting ready for 1.0 we should have winetest run as much as possible.
My main focus will be adding tests btw until 1.0 is out. These will be both tests to proof the correctness of the current implementation as well as tests to show missing stuff. There are loads of functions for which we have no tests yet and with the 1.0 in sight I think it becomes very important to have tests for virtually every function we (have) implement(ed).
While that's a worthy goal, I think a better short-term goal for the run up to 1.0 is to fix the current failing tests in Windows.
But either way we need an up-to-date winetest executable ;-)
Fixing currently failing tests is as always top on my list as well until I have some real time to spend again on implementing stuff.
On Tue, Mar 25, 2008 at 4:27 AM, Paul Vriens paul.vriens.wine@gmail.com wrote:
James Hawkins wrote:
On Tue, Mar 25, 2008 at 4:08 AM, Paul Vriens paul.vriens.wine@gmail.com wrote:
Hi,
We didn't have a new winetest executable for the last few days. MinGW doesn't know anything about a d3dx9 dll (yet) that's imported in the d3dx9_36 tests.
Especially while in the process of getting ready for 1.0 we should have winetest run as much as possible.
My main focus will be adding tests btw until 1.0 is out. These will be both tests to proof the correctness of the current implementation as well as tests to show missing stuff. There are loads of functions for which we have no tests yet and with the 1.0 in sight I think it becomes very important to have tests for virtually every function we (have) implement(ed).
While that's a worthy goal, I think a better short-term goal for the run up to 1.0 is to fix the current failing tests in Windows.
But either way we need an up-to-date winetest executable ;-)
No argument there. I've been waiting all weekend. Hopefully we can get the issue resolved and a new build out to test.
On Tue, Mar 25, 2008 at 4:27 AM, Paul Vriens paul.vriens.wine@gmail.com wrote:
James Hawkins wrote:
On Tue, Mar 25, 2008 at 4:08 AM, Paul Vriens paul.vriens.wine@gmail.com wrote:
Hi,
We didn't have a new winetest executable for the last few days. MinGW doesn't know anything about a d3dx9 dll (yet) that's imported in the d3dx9_36 tests.
Especially while in the process of getting ready for 1.0 we should have winetest run as much as possible.
My main focus will be adding tests btw until 1.0 is out. These will be both tests to proof the correctness of the current implementation as well as tests to show missing stuff. There are loads of functions for which we have no tests yet and with the 1.0 in sight I think it becomes very important to have tests for virtually every function we (have) implement(ed).
While that's a worthy goal, I think a better short-term goal for the run up to 1.0 is to fix the current failing tests in Windows.
But either way we need an up-to-date winetest executable ;-)
Are you currently working on this? Is it a problem that needs to be fixed on the mingw side?
James Hawkins wrote:
On Tue, Mar 25, 2008 at 4:27 AM, Paul Vriens paul.vriens.wine@gmail.com wrote:
James Hawkins wrote:
On Tue, Mar 25, 2008 at 4:08 AM, Paul Vriens paul.vriens.wine@gmail.com wrote:
Hi,
We didn't have a new winetest executable for the last few days. MinGW doesn't know anything about a d3dx9 dll (yet) that's imported in the d3dx9_36 tests.
Especially while in the process of getting ready for 1.0 we should have winetest run as much as possible.
My main focus will be adding tests btw until 1.0 is out. These will be both tests to proof the correctness of the current implementation as well as tests to show missing stuff. There are loads of functions for which we have no tests yet and with the 1.0 in sight I think it becomes very important to have tests for virtually every function we (have) implement(ed).
While that's a worthy goal, I think a better short-term goal for the run up to 1.0 is to fix the current failing tests in Windows.
But either way we need an up-to-date winetest executable ;-)
Are you currently working on this? Is it a problem that needs to be fixed on the mingw side?
It's indeed a mingw issue and has to be fixed on that side.
I've never touched mingw so I'm relying on either Hans Leidekker, Stefan Leichter or Paul Millar to take this up.
Cheers,
Paul (Vriens).
Are you currently working on this? Is it a problem that needs to be fixed on the mingw side?
It's indeed a mingw issue and has to be fixed on that side.
I've never touched mingw so I'm relying on either Hans Leidekker, Stefan Leichter or Paul Millar to take this up.
The problem is that it is a mingw issue but they don't want any patches from wines win32 api in their mingw w32api. They believe that looking at the actual ms header files taints our headers legally speaking. Stefan, hans, and PaulM maintain a rather large set of patches against w32api. [1]
So its a constant catchup game from when wines headers get new additions until someone sends paulm a patch updating the mingw w32api.
I made a script [2] that will cross build winetest from git source no mingw patches needed. In theory this could be useful in keeping the cross built winetest.exe's rolling.
To use the script you need 3 dirs a wine-git, wine-native, and a wine-pe. Set those locations in the config part of the script as well as the build and host settings for your compiler and cross compiler. At the end winetest.exe will be in wine-pe/programs/winetest/ folder. This setup is from PaulMs recipe [3] with some tweaking.
Also if you trust me and just want the exe its at [4].
Hope this helps, John
P.S. I logged some test results from my win2k machine, it seems they are at [5]. Seems like I missed some setting though as the date is not right. Advice on how to fix that would be delicious =)
[1] http://readlist.com/lists/lists.sourceforge.net/mingw-users/1/5419.html [2] http://klehm.net/wine/crossbuild_winetest.sh [3] http://www.winehq.org/pipermail/wine-devel/2006-December/053069.html [4] http://klehm.net/wine/winetest.exe [5] http://test.winehq.org/data/06d429d6b6b6d63beaeda130a3bb261ef3b9fb41/
John Klehm wrote:
P.S. I logged some test results from my win2k machine, it seems they are at [5]. Seems like I missed some setting though as the date is not right. Advice on how to fix that would be delicious =)
It uses the file programs/winetest/build.id for this.
"John Klehm" xixsimplicityxix@gmail.com writes:
P.S. I logged some test results from my win2k machine, it seems they are at [5]. Seems like I missed some setting though as the date is not right. Advice on how to fix that would be delicious =)
It's now using the git commit sha1 instead of a date when building from a git tree, that's a feature. I'm hoping we can standardize on that to make sure all test runs properly identify the exact source used.
Alexandre Julliard wrote:
"John Klehm" xixsimplicityxix@gmail.com writes:
P.S. I logged some test results from my win2k machine, it seems they are at [5]. Seems like I missed some setting though as the date is not right. Advice on how to fix that would be delicious =)
It's now using the git commit sha1 instead of a date when building from a git tree, that's a feature. I'm hoping we can standardize on that to make sure all test runs properly identify the exact source used.
Wouldn't it be nicer to have something like:
0.9.58-06d429d6b6b6d63beaeda130a3bb261ef3b9fb41
Just a thought? The SHA's itself are not very pleasant for the eye. With the above you can at least group them visually.
Paul Vriens paul.vriens.wine@gmail.com writes:
Wouldn't it be nicer to have something like:
0.9.58-06d429d6b6b6d63beaeda130a3bb261ef3b9fb41
Just a thought? The SHA's itself are not very pleasant for the eye. With the above you can at least group them visually.
Presentation issues should be separate from the actual id. Once all builds are using SHA1 we can do a lot of fancy stuff in how we display them.
"John Klehm" xixsimplicityxix@gmail.com wrote:
The problem is that it is a mingw issue but they don't want any patches from wines win32 api in their mingw w32api. They believe that looking at the actual ms header files taints our headers legally speaking. Stefan, hans, and PaulM maintain a rather large set of patches against w32api. [1]
So its a constant catchup game from when wines headers get new additions until someone sends paulm a patch updating the mingw w32api.
Then perhaps we (Alexandre) should reconsider the stance about using Wine headers and import libraries in preference to mingw ones.
On 28/03/2008, Dmitry Timoshkov dmitry@codeweavers.com wrote:
"John Klehm" xixsimplicityxix@gmail.com wrote:
The problem is that it is a mingw issue but they don't want any patches from wines win32 api in their mingw w32api. They believe that looking at the actual ms header files taints our headers legally speaking. Stefan, hans, and PaulM maintain a rather large set of patches against w32api. [1]
So its a constant catchup game from when wines headers get new additions until someone sends paulm a patch updating the mingw w32api.
Then perhaps we (Alexandre) should reconsider the stance about using Wine headers and import libraries in preference to mingw ones.
I would have expected that when building for mingw, Wine would use the Wine headers and libraries. Otherwise, as mentioned above, if someone adds tests that rely on items that are not in the mingw headers then the tests will not be built for the conformance tests, as has been seen recently. Also, what happens with the widl generated headers?
- Reece
On Fri, Mar 28, 2008 at 9:35 AM, Reece Dunn msclrhd@googlemail.com wrote:
I would have expected that when building for mingw, Wine would use the Wine headers and libraries. Otherwise, as mentioned above, if someone adds tests that rely on items that are not in the mingw headers then the tests will not be built for the conformance tests, as has been seen recently. Also, what happens with the widl generated headers?
We have always depended on the w32api package for the tests and programs partly to make sure our own code is sane by having another coverage point like building with the MSVC headers when compiling on MSVC. Dmitry and I have disagreed with this for years though because the mingw w32api maintainers can be a real PITA about getting patches in and also because of the breakages that result when something is missing like you mention. Switching to a using the wine headers and import libs everywhere is long overdue and welcome!
On Fri, Mar 28, 2008 at 1:53 PM, Steven Edwards winehacker@gmail.com wrote:
On Fri, Mar 28, 2008 at 9:35 AM, Reece Dunn msclrhd@googlemail.com wrote:
I would have expected that when building for mingw, Wine would use the Wine headers and libraries. Otherwise, as mentioned above, if someone adds tests that rely on items that are not in the mingw headers then the tests will not be built for the conformance tests, as has been seen recently. Also, what happens with the widl generated headers?
We have always depended on the w32api package for the tests and programs partly to make sure our own code is sane by having another coverage point like building with the MSVC headers when compiling on MSVC. Dmitry and I have disagreed with this for years though because the mingw w32api maintainers can be a real PITA about getting patches in and also because of the breakages that result when something is missing like you mention. Switching to a using the wine headers and import libs everywhere is long overdue and welcome!
What is the process for making this switch? Do we need to contact Paul Millar? The lack of a new winetest is putting a hamper on our efforts to fix up the tests in Windows.
On Fri, Mar 28, 2008 at 3:01 PM, James Hawkins truiken@gmail.com wrote:
What is the process for making this switch? Do we need to contact Paul Millar? The lack of a new winetest is putting a hamper on our efforts to fix up the tests in Windows.
There should just be a few rules that need to be changed as far as I know. Thats all that was needed for the programs case, I cannot Imagen why the tests would be any more complex. If Alexandre has not already done so, I'll look at it and submit patches tonight.
On Fri, Mar 28, 2008 at 2:22 PM, Steven Edwards winehacker@gmail.com wrote:
On Fri, Mar 28, 2008 at 3:01 PM, James Hawkins truiken@gmail.com wrote:
What is the process for making this switch? Do we need to contact Paul Millar? The lack of a new winetest is putting a hamper on our efforts to fix up the tests in Windows.
There should just be a few rules that need to be changed as far as I know. Thats all that was needed for the programs case, I cannot Imagen why the tests would be any more complex. If Alexandre has not already done so, I'll look at it and submit patches tonight.
Winetest with todays git [1]
John
[1] http://klehm.net/wine/20080328-winetest-438868f37796e387cd6f6db5da1f73a7017b...
On Fri, Mar 28, 2008 at 3:22 PM, Steven Edwards winehacker@gmail.com wrote:
There should just be a few rules that need to be changed as far as I know. Thats all that was needed for the programs case, I cannot Imagen why the tests would be any more complex. If Alexandre has not already done so, I'll look at it and submit patches tonight.
The rules for building the import libs has changed quite a bit since the last time I looked at them and I am not quite sure about how to fix a couple of problems so I'll wait for Alexandre to comment.
Hi all,
I've added support in MinGW support for d3dx9 (with help from Stefan Leichter, thanks!) and a build has now gone through. New results should start to appear as people upload their results.
On Saturday 29 March 2008 06:58:42 Steven Edwards wrote:
On Fri, Mar 28, 2008 at 3:22 PM, Steven Edwards winehacker@gmail.com
wrote:
[...] If Alexandre has not already done so, I'll look at it and submit patches tonight.
The rules for building the import libs has changed quite a bit since the last time I looked at them and I am not quite sure about how to fix a couple of problems so I'll wait for Alexandre to comment.
I, too, was going to have a look at this (but, if you want to do it, Steven, feel free ;-). I'm not sure how best to approach this, though.
Cheers,
Paul.
On Sat, Mar 29, 2008 at 6:01 AM, Paul Millar paul@astro.gla.ac.uk wrote:
Hi all,
I've added support in MinGW support for d3dx9 (with help from Stefan Leichter, thanks!) and a build has now gone through. New results should start to appear as people upload their results.
Thanks Paul!
On Fri, 28 Mar 2008, Steven Edwards wrote:
On Fri, Mar 28, 2008 at 3:01 PM, James Hawkins truiken@gmail.com wrote:
What is the process for making this switch? Do we need to contact Paul Millar? The lack of a new winetest is putting a hamper on our efforts to fix up the tests in Windows.
There should just be a few rules that need to be changed as far as I know. Thats all that was needed for the programs case, I cannot Imagen why the tests would be any more complex. If Alexandre has not already done so, I'll look at it and submit patches tonight.
Maybe we can have separate targets: make crosstest would build PE tests using Wine's headers and libraries make mingwtest would build PE tests using MinGW's headers and libraries
This would let us test either configuration.
"Dmitry Timoshkov" dmitry@codeweavers.com writes:
"John Klehm" xixsimplicityxix@gmail.com wrote:
The problem is that it is a mingw issue but they don't want any patches from wines win32 api in their mingw w32api. They believe that looking at the actual ms header files taints our headers legally speaking. Stefan, hans, and PaulM maintain a rather large set of patches against w32api. [1]
So its a constant catchup game from when wines headers get new additions until someone sends paulm a patch updating the mingw w32api.
Then perhaps we (Alexandre) should reconsider the stance about using Wine headers and import libraries in preference to mingw ones.
Agreed, the idea of using w32api is that we want to help improve mingw by finding problems in their headers and libraries, but if they are not going to accept our patches anyway, then there's clearly no point in continuing to make our life harder by using their stuff.
Alexandre Julliard wrote:
"Dmitry Timoshkov" dmitry@codeweavers.com writes:
"John Klehm" xixsimplicityxix@gmail.com wrote:
The problem is that it is a mingw issue but they don't want any patches from wines win32 api in their mingw w32api. They believe that looking at the actual ms header files taints our headers legally speaking. Stefan, hans, and PaulM maintain a rather large set of patches against w32api. [1]
So its a constant catchup game from when wines headers get new additions until someone sends paulm a patch updating the mingw w32api.
Then perhaps we (Alexandre) should reconsider the stance about using Wine headers and import libraries in preference to mingw ones.
Agreed, the idea of using w32api is that we want to help improve mingw by finding problems in their headers and libraries, but if they are not going to accept our patches anyway, then there's clearly no point in continuing to make our life harder by using their stuff.
And can't we just start creating the winetest executable at winehq somewhere?
Paul Vriens paul.vriens.wine@gmail.com writes:
And can't we just start creating the winetest executable at winehq somewhere?
We probably can, but how would this help?
Alexandre Julliard wrote:
Paul Vriens paul.vriens.wine@gmail.com writes:
And can't we just start creating the winetest executable at winehq somewhere?
We probably can, but how would this help?
It wouldn't help as we will face the same issues. It's just that it seems more logical to create this where multiple resources have access in case there are issues.
We need a place where people can download the latest winetest executable and in the past it has been proven difficult to have it available all the time. Despite the excellent work that Paul Millar (and of course Hans and Stefan) is doing.
So having this at winehq has nothing to do with fixing this particular issue.
On Fri, Mar 28, 2008 at 9:35 AM, Alexandre Julliard julliard@winehq.org wrote:
Agreed, the idea of using w32api is that we want to help improve mingw by finding problems in their headers and libraries, but if they are not going to accept our patches anyway, then there's clearly no point in continuing to make our life harder by using their stuff.
Thank you!
Hi,
We didn't have a new winetest executable for the last few days. MinGW doesn't know anything about a d3dx9 dll (yet) that's imported in the d3dx9_36 tests.
Especially while in the process of getting ready for 1.0 we should have winetest run as much as possible.
My main focus will be adding tests btw until 1.0 is out. These will be both tests to proof the correctness of the current implementation as well as tests to show missing stuff. There are loads of functions for which we have no tests yet and with the 1.0 in sight I think it becomes very important to have tests for virtually every function we (have) implement(ed).
-- Cheers,
Paul.
As a sidenote. You are also cross compiling wine dlls so now and then. It would be useful to also cross compile d3d8/d3d9 and wined3d but for wined3d -DUSE_WIN32_OPENGL must be set.
Roderick
On Tue, Mar 25, 2008 at 4:39 AM, Roderick Colenbrander thunderbird2k@gmx.net wrote:
As a sidenote. You are also cross compiling wine dlls so now and then. It would be useful to also cross compile d3d8/d3d9 and wined3d but for wined3d -DUSE_WIN32_OPENGL must be set.
Well let me know how this works for you. I'll refactor my script a bit later today but for right now you have to run this one after the winetest script, as this one counts on the environment that the winetest script sets up.
Script to crossbuild d3d dlls [1] and the dlls themselves [2], [3], [4] are out there.
John
[1] http://klehm.net/wine/crossbuild_d3d_dlls.sh [2] http://klehm.net/wine/d3d8.dll [3] http://klehm.net/wine/d3d9.dll [4] http://klehm.net/wine/wined3d.dll
On Fri, Mar 28, 2008 at 6:05 AM, John Klehm xixsimplicityxix@gmail.com wrote:
On Tue, Mar 25, 2008 at 4:39 AM, Roderick Colenbrander thunderbird2k@gmx.net wrote:
As a sidenote. You are also cross compiling wine dlls so now and then. It would be useful to also cross compile d3d8/d3d9 and wined3d but for wined3d -DUSE_WIN32_OPENGL must be set.
Well let me know how this works for you. I'll refactor my script a bit later today but for right now you have to run this one after the winetest script, as this one counts on the environment that the winetest script sets up.
Script to crossbuild d3d dlls [1] and the dlls themselves [2], [3], [4] are out there.
John
[1] http://klehm.net/wine/crossbuild_d3d_dlls.sh [2] http://klehm.net/wine/d3d8.dll [3] http://klehm.net/wine/d3d9.dll [4] http://klehm.net/wine/wined3d.dll
Sorry I forgot it the first time, but you'll also need libwine.dll [1] in addition to the other d3d dlls. Test them out on your own window machine with [2]. Just put them in the same directory as the program.
John
[1] http://klehm.net/wine/libwine.dll [2] http://www.codesampler.com/source/dx8_multitexture.zip
On Fri, Mar 28, 2008 at 6:05 AM, John Klehm xixsimplicityxix@gmail.com wrote:
Well let me know how this works for you. I'll refactor my script a bit later today but for right now you have to run this one after the winetest script, as this one counts on the environment that the
Here's the refactored script [1]. With some inspiration from winetricks ;)
Example uses: $crossbuild_tricks winetest
$crossbuild_tricks d3d => builds d3d8,d3d9,wined3d, libwine
$crossbuild_tricks test cabinet => use test verb for individual tests
$crossbuild_tricks dll wintrust => use dll verb for individual dlls
First release and I've tested it some, seems to work but let me know if it breaks for you.
Regards, John
On Wed, Apr 2, 2008 at 2:51 PM, John Klehm xixsimplicityxix@gmail.com wrote:
On Fri, Mar 28, 2008 at 6:05 AM, John Klehm xixsimplicityxix@gmail.com wrote:
Well let me know how this works for you. I'll refactor my script a bit later today but for right now you have to run this one after the winetest script, as this one counts on the environment that the
Here's the refactored script [1]. With some inspiration from winetricks ;)
Example uses: $crossbuild_tricks winetest
$crossbuild_tricks d3d => builds d3d8,d3d9,wined3d, libwine
$crossbuild_tricks test cabinet => use test verb for individual tests
$crossbuild_tricks dll wintrust => use dll verb for individual dlls
First release and I've tested it some, seems to work but let me know if it breaks for you.
Regards, John
Updated version of crossbuild_tricks: http://klehm.net/wine/crossbuild_tricks.sh
Changes:
-improved build time: builds only the minimum required targets now.
New verbs: libs => build just the import libs (*.a). Puts them in wine-pe/libs/wine as usual. alldlls => build all possible dlls. Copies them to wine-pe/binaries for easy downloading.
Dlls known not to cross build: dbghelp dnsapi gdi32 glu32 icmp iphlpapi kernel32 msvcrt ntdll opengl32 rpcrt4 secur32 shell32 winex11.drv wininet winmm ws2_32
distclean => clean up the wine-native and wine-pe dirs and run distclean in wine-src (a "wash me clean of this dirty script" verb ;)
Use the patch I sent in the other mail that adds mingw like no op exception stuff if you really need to cross build crypt32 (maybe others) that complain about missing __try etc.
Any problems let me know.
Enjoy, John
On Tue, Mar 25, 2008 at 4:08 AM, Paul Vriens paul.vriens.wine@gmail.com wrote:
Hi,
We didn't have a new winetest executable for the last few days. MinGW doesn't know anything about a d3dx9 dll (yet) that's imported in the d3dx9_36 tests.
Especially while in the process of getting ready for 1.0 we should have winetest run as much as possible.
My main focus will be adding tests btw until 1.0 is out. These will be both tests to proof the correctness of the current implementation as well as tests to show missing stuff. There are loads of functions for which we have no tests yet and with the 1.0 in sight I think it becomes very important to have tests for virtually every function we (have) implement(ed).
Might make a good SoC project?
-
Alexandre Julliard -
Austin English -
Dmitry Timoshkov -
Francois Gouget -
James Hawkins -
John Klehm -
Paul Millar -
Paul Vriens -
Reece Dunn -
Roderick Colenbrander -
Steven Edwards