Hans Leidekker [email protected] at Oct 31, 2008 5:32 AM wrote about Re: wininet: let automated testers force all DNS lookups to return localhost
Only include this in debugging builds.
What happened to your /etc/hosts proposal? It has the advantage that we don't need changes to Wine source code.
This would not work on Macs as /etc/hosts is locked to admins only and would be a problem to implement.
James McKenzie
2008/10/31 James Mckenzie [email protected]:
This would not work on Macs as /etc/hosts is locked to admins only and would be a problem to implement.
I don't see how that's a problem, or how that's different from eg. Linux.
More on-topic, I don't think it would be hard to do some LD_PRELOAD hacks on getaddrinfo(), gethostbyname(), and whatever else is appropriate.
On Fri, Oct 31, 2008 at 8:11 AM, Henri Verbeet [email protected] wrote:
2008/10/31 James Mckenzie [email protected]:
This would not work on Macs as /etc/hosts is locked to admins only and would be a problem to implement.
I don't see how that's a problem, or how that's different from eg. Linux.
More on-topic, I don't think it would be hard to do some LD_PRELOAD hacks on getaddrinfo(), gethostbyname(), and whatever else is appropriate.
How would we do this on Windows? (We need the winetest results to be reliable, too.) That was the main reason I didn't go for LD_PRELOAD... I guess we do some sort of DLL injection, but I haven't done it personally before. - Dan
2008/10/31 Dan Kegel [email protected]:
How would we do this on Windows? (We need the winetest results to be reliable, too.) That was the main reason I didn't go for LD_PRELOAD... I guess we do some sort of DLL injection, but I haven't done it personally before.
- Dan
You could patch the IAT, but that's quite a bit less nice than LD_PRELOAD, of course.
On Fri, Oct 31, 2008 at 8:51 AM, Henri Verbeet [email protected] wrote:
2008/10/31 Dan Kegel [email protected]:
How would we do this on Windows? (We need the winetest results to be reliable, too.) That was the main reason I didn't go for LD_PRELOAD... I guess we do some sort of DLL injection, but I haven't done it personally before.
You could patch the IAT, but that's quite a bit less nice than LD_PRELOAD, of course.
The thing is, I want to support running tests on Windows as well. May as well do it the same way everywhere... - Dan
Rob wrote:
Later we should provide a script to set up a local test server that can handle all of our conformance tests' requests, but for now, just letting patchwatcher or winetest redirect everything to localhost will let tests fail reliably instead of randomly.
This approach won't help users of the Wine conformance tests running on Windows,
Sure it would; just make the test server setup script run on cygwin properly.
We should instead rewrite any existing tests that use a public server to instead use a server started by the Wine test code (see dlls/wininet/tests/http.c:server_thread).
Yes, absolutely. The more tests that set up their own mock servers, the better.
But while we're waiting for that, a "nuke DNS resolution" approach makes tests behave repeatably, and would even be useful after we implement the fix you propose, as it would protect us from new tests that sloppily depend on the public internet.
As someone pointed out, actually nuking DNS resolution is kind of tricky; my patch did it for DLLs that use win32 networking, but not for DLLs that use native networking. It probably can't be done the same way everywhere, so I guess for Linux I'll punt and try shared library overriding. - Dan
On So, 2008-11-02 at 10:58 -0800, Dan Kegel wrote:
This approach won't help users of the Wine conformance tests running on Windows,
Sure it would; just make the test server setup script run on cygwin properly.
require an installed cygwin is broken by design. winetest.exe is a standalone application.
We should instead rewrite any existing tests that use a public server to instead use a server started by the Wine test code (see dlls/wininet/tests/http.c:server_thread).
Yes, absolutely.
That will add a lot of code. Add a local_server.c for every dll that need it is another Idea.
I prefer to have a winetest.dll for that. A winetest.dll / winetest.sys allow us to create even more tests. (Global Hooks and Device Drivers as examples)
On Mon, Nov 3, 2008 at 1:50 PM, Detlef Riekenberg [email protected] wrote:
This approach won't help users of the Wine conformance tests running on Windows,
Sure it would; just make the test server setup script run on cygwin properly.
require an installed cygwin is broken by design. winetest.exe is a standalone application.
It wouldn't be required. You'd only need to run the script if you wanted to avoid relying on winehq.org.
I prefer servers built into wine's conformance test suite. But if we're going to keep using external servers, we should at least document which ones we use, and how to set them up.
We should instead rewrite any existing tests that use a public server to instead use a server started by the Wine test code (see dlls/wininet/tests/http.c:server_thread).
I prefer to have a winetest.dll for that. A winetest.dll / winetest.sys allow us to create even more tests. (Global Hooks and Device Drivers as examples)
Go for it... - Dan
On Friday 31 October 2008 15:52:43 James Mckenzie wrote:
What happened to your /etc/hosts proposal? It has the advantage that we don't need changes to Wine source code.
This would not work on Macs as /etc/hosts is locked to admins only and would be a problem to implement.
That's true for Unix in general, but I think we require admin rights already because the services need to bind ports below 1024 for example.
-Hans
On Friday 31 October 2008 16:11:58 Hans Leidekker wrote:
On Friday 31 October 2008 15:52:43 James Mckenzie wrote:
What happened to your /etc/hosts proposal? It has the advantage that we don't need changes to Wine source code.
This would not work on Macs as /etc/hosts is locked to admins only and would be a problem to implement.
That's true for Unix in general, but I think we require admin rights already because the services need to bind ports below 1024 for example.
That's where the Samba style socket wrapper would help. The tricky part is that this would have to be implemented in winsock, so it wouldn't necessarily port to windows too well. On the other hand, binding to low ports isn't that big of a problem on windows, and we require administrator privileges for the tests anyway.
Cheers, Kai
-
Dan Kegel -
Detlef Riekenberg -
Hans Leidekker -
Henri Verbeet -
James Mckenzie -
Kai Blin