Hi,
Paul Vriens wrote:
Hi,
this makes the crosstest compile work again for shell32. Result tested on win98/winxp.
Changelog: Use aliases for calls to ordinals.
As far as I know, SHILCreateFromPath, ILFree and ILIsEqual are all exported by name on Windows. So, IMHO, unless we find a problem running the test on some Windows versions it would be better to fix MinGW.
On Wed, 2005-02-16 at 10:58, Francois Gouget wrote:
Hi,
Paul Vriens wrote:
Hi,
this makes the crosstest compile work again for shell32. Result tested on win98/winxp.
Changelog: Use aliases for calls to ordinals.
As far as I know, SHILCreateFromPath, ILFree and ILIsEqual are all exported by name on Windows. So, IMHO, unless we find a problem running the test on some Windows versions it would be better to fix MinGW.
Hi,
I've looked with PEExplorer on my win2k system and I can't see them in the exported list by name.
After adding a alias for SHILCreateFromPath I was able to compile the crosstest.
The test (shell32_crosstest.exe) failed however with a message stating that ILFree and, after I've added an alias for that one, ILISEqual were not exported by shell32.dll.
21/28/155 and 162 are exported as ordinals by shell32.dll (version 5.0.3900.7009) on Windows 2000 Professional.
Cheers,
Paul.
Hi,
Paul Vriens wrote: [...]
I've looked with PEExplorer on my win2k system and I can't see them in the exported list by name.
After adding a alias for SHILCreateFromPath I was able to compile the crosstest.
The test (shell32_crosstest.exe) failed however with a message stating that ILFree and, after I've added an alias for that one, ILISEqual were not exported by shell32.dll.
21/28/155 and 162 are exported as ordinals by shell32.dll (version 5.0.3900.7009) on Windows 2000 Professional.
Ok, that would be a good reason. There's something I don't understand though: when I compile the test before your changes with Visual C++ 6.0 it compiles just fine but it turns out the resulting executable imports these three APIs by ordinal.
Is this something that MinGW can / should do too? And for the Winelib side of things, is this something that winebuild can do?
Francois Gouget wrote: [snip]
Is this something that MinGW can / should do too?
Yes.
BTW, are there any (other) unofficial Wine patches for the MinGW W32API package?
Regards, Filip
Index: lib/shell32.def =================================================================== RCS file: /cvs/src/src/winsup/w32api/lib/shell32.def,v retrieving revision 1.7 diff -u -r1.7 shell32.def --- lib/shell32.def 1 Jan 2004 11:00:43 -0000 1.7 +++ lib/shell32.def 16 Feb 2005 12:30:28 -0000 @@ -32,6 +32,7 @@ SHUpdateRecycleBinIcon@0 SHSetUnreadMailCountW@12 SHSetLocalizedName@12 +SHSimpleIDListFromPath@4 @162 SHQueryRecycleBinW@8 SHQueryRecycleBinA@8 SHPathPrepareForWriteW@16 @@ -43,6 +44,7 @@ SHIsFileAvailableOffline@8 SHInvokePrinterCommandW@20 SHInvokePrinterCommandA@20 +SHILCreateFromPath@12 @28 SHHelpShortcuts_RunDLL@16 SHGetUnreadMailCountW@24 SHGetSpecialFolderPathW@16 @@ -172,11 +174,11 @@ ILCloneFirst@4 ILCombine@8 ILFindChild@8 -ILFree@4 +ILFree@4 @155 ILGetNext@4 ILGetSize@4 -ILIsEqual@8 +ILIsEqual@8 @21 ILIsParent@12 ILLoadFromStream@8 ILRemoveLastID@4
Hi Francois,
In an ideal world, yes we should use the names such as SHILCreateFromPath etc. and fix MinGW.
However, we're not after testing MinGW, rather testing wine compared to Windows. We know MinGW buggy! But, the up-stream "vendor"s have been reluctant to merge in changes. Because of this we've effectively forked MinGW package (albeit in a limit fashion).
Every new (to MinGW) function-call in the test-suite is one that *we* have to support and will break the autobuild of winetest.exe. If we use ordinals, then winetest.exe doesn't break. At the moment, this is happening every couple of weeks or so. We're current getting about ~40% success rate in builds (this year, on average).
So, perhaps I could suggest a compromise. When adding new tests, people check if they work under current MinGW. If they don't, then the ordinal is used.
Once a month (or however often people care about this), we sweep up all the ordinal-based tests, patch MinGW to support them and switch back to named exports. Could we hack together a macro that switches between ordinal-based to name-based exports? That should eliminate a lot of the donkey work.
Advantages: o winetest.exe build doesn't break o less work when collecting/collating patches o less work for me :)
Disadvantages: o slightly more work for developers (but hopefully not *that* much more) o have to put up with ugly ordinal exports. o potential confusion at the switch over.
To me, the advantages out-weight the disadvantages.
Cheers,
Paul.
On Wednesday 16 February 2005 09:58, Francois Gouget wrote:
Paul Vriens wrote:
this makes the crosstest compile work again for shell32. Result tested on win98/winxp.
As far as I know, SHILCreateFromPath, ILFree and ILIsEqual are all exported by name on Windows. So, IMHO, unless we find a problem running the test on some Windows versions it would be better to fix MinGW.
Paul Millar wrote:
Hi Francois,
In an ideal world, yes we should use the names such as SHILCreateFromPath etc. and fix MinGW.
[...]
So, perhaps I could suggest a compromise. When adding new tests, people check if they work under current MinGW. If they don't, then the ordinal is used.
Once a month (or however often people care about this), we sweep up all the ordinal-based tests, patch MinGW to support them and switch back to named exports. Could we hack together a macro that switches between ordinal-based to name-based exports? That should eliminate a lot of the donkey work.
Switching to ordinals only to switch back to importing by name once MinGW is fixed is madness.
MinGW is an open-source project, we have already forked it, so there's no reason not to fix it.
On Wednesday 16 February 2005 12:11, Francois Gouget wrote:
Switching to ordinals only to switch back to importing by name once MinGW is fixed is madness.
No, *implementing* the tests using ordinals, then switching to named is damage limitation in an imperfect world. It separates our buggy MinGW implementation from the work of winetest.exe, resulting in improved testing throughput.
We're not trying to fix MinGW, just test Windows.
MinGW is an open-source project, we have already forked it, so there's no reason not to fix it.
Indeed, but the issue is that what we have is a compilation *service* that uses an incomplete MinGW. An architecture where a service breaks at "random" times in the future is bad/broken: the methodology is wrong and needs fixing.
Still, if people don't mind the tests going AWOL for ~60% of the time, that's fine.
I guess people don't, so that's OK (speak now or forever hold thy peace)
Cheers,
Paul.
Paul Millar paulm@astro.gla.ac.uk writes:
On Wednesday 16 February 2005 12:11, Francois Gouget wrote:
Switching to ordinals only to switch back to importing by name once MinGW is fixed is madness.
No, *implementing* the tests using ordinals, then switching to named is damage limitation in an imperfect world. It separates our buggy MinGW implementation from the work of winetest.exe, resulting in improved testing throughput.
We're not trying to fix MinGW, just test Windows.
Actually no, fixing MinGW is a very desirable side-effect of cross-compiling our tests. If we find bugs in MinGW they should be fixed, not worked around.
Paul Millar wrote:
Indeed, but the issue is that what we have is a compilation *service* that uses an incomplete MinGW. An architecture where a service breaks at "random" times in the future is bad/broken: the methodology is wrong and needs fixing.
Still, if people don't mind the tests going AWOL for ~60% of the time, that's fine.
I guess people don't, so that's OK (speak now or forever hold thy peace)
I am very annoyed by the fact that the tests mostly don't build. So I agree with you.
regards, Jakob
-
Alexandre Julliard -
Filip Navara -
Francois Gouget -
Jakob Eriksson -
Paul Millar -
Paul Vriens