October 2003 - Wine-Devel - list.winehq.org

RE: UI bugs hampering porting effort for shaped window

by Rob

>Uhh, I've seen several other windows programs that did not rely on the >NULL feature, perhaps because it is documented poorly. These programs do >gethostname() and then gethostbyname(). We will probably need a check in >the gethostbyname path to catch those programs as well. Correct, NULL and gethostname passed into gethostbyname are supposed to operate identically. Hence either way is supposed to be valid. Yes, it is documented poorly. Regardless, the correct thing to do is check if the string passed into gethostbyname matches the result from gethostname OR the string passed is NULL - if it does match or is NULL - then return a list of local IP addresses. This will ensure applications running under WINE, using either the NULL or gethostname method operate as expected, even if native *nix applications can't rely on that behaviour. -Rob

Oct. 31, 2003

Re: UI bugs hampering porting effort for shaped window

by Rein Klazes

On Fri, 31 Oct 2003 09:50:48 -0800, you wrote: > > hi Rein, > > >On my system everything works as expected: I get a list of all ip > >addresses. That is with valid /etc/hostname and /etc/hosts entries. > > That's the trouble. Not every *nux box has the correct results - some do > (like yours) - in fact I'd say many do not. We have done many Linux and > Lindows installs, and none of them had the correct settings in /etc/hostname > and /etc/hosts by default, except one. Incomplete install/configuration or > not, the trouble is that windows guarantees this behaviour and *nix does > not. In the real world, the results are lucky at best we get the correct > results. Those who have tried our product offsite running under WINE run > into the same issue - over and over, the results from gethostname passed > into gethostbyname do not work as it does under windows all of the time. > Worse, they sometimes return the external IP instead of internal IP > addresses. Since we are a windows app - we can't adjust ourselves to bogus > set up /etc/hostname configurations since we have no specific knowledge we > are running under a *nix flavour (as we should not). In order to be > compatible, you MUST guarantee the results from passing NULL or > gethostbyname return a list of local IPs using a different method than > /etc/hostname and /etc/hosts which isn't working right on all *nix machines. > Seems that most people with external IPs had the correct results, but most > people with internal IPs did not. This isn't always the case, but seems to > be a common theme. Uhh, I've seen several other windows programs that did not rely on the NULL feature, perhaps because it is documented poorly. These programs do gethostname() and then gethostbyname(). We will probably need a check in the gethostbyname path to catch those programs as well. In short: even a native linux program that does gethostname() -> gethostbyname() is unlikely to get you these days something else then 127.0.0.1 Dhcp clients whose information is not available is one cause I think. Circumventing that when the program is running under wine is the challenge. Rein. -- Rein Klazes rklazes(a)xs4all.nl

Oct. 31, 2003

RE: UI bugs hampering porting effort for shaped window

by Rob

hi Rein, >On my system everything works as expected: I get a list of all ip >addresses. That is with valid /etc/hostname and /etc/hosts entries. That's the trouble. Not every *nux box has the correct results - some do (like yours) - in fact I'd say many do not. We have done many Linux and Lindows installs, and none of them had the correct settings in /etc/hostname and /etc/hosts by default, except one. Incomplete install/configuration or not, the trouble is that windows guarantees this behaviour and *nix does not. In the real world, the results are lucky at best we get the correct results. Those who have tried our product offsite running under WINE run into the same issue - over and over, the results from gethostname passed into gethostbyname do not work as it does under windows all of the time. Worse, they sometimes return the external IP instead of internal IP addresses. Since we are a windows app - we can't adjust ourselves to bogus set up /etc/hostname configurations since we have no specific knowledge we are running under a *nix flavour (as we should not). In order to be compatible, you MUST guarantee the results from passing NULL or gethostbyname return a list of local IPs using a different method than /etc/hostname and /etc/hosts which isn't working right on all *nix machines. Seems that most people with external IPs had the correct results, but most people with internal IPs did not. This isn't always the case, but seems to be a common theme. -Rob

Oct. 31, 2003

winhq bugs

by Ralf Juengling

I found several bugs in http://www.winehq.com/site/documentation and the online winelib user's guide: - practically empty winedocs-html.tgz - empty winedocs-ps.tgz - unreadable pdfs in winedocs-pdf.tgz Some html pages of chapters 3+ of the online winelib user's guide do not adapt in size (to the browser window). Thanks, Ralf -- Ralf Juengling <juenglin(a)cse.ogi.edu>

Oct. 31, 2003

RE: UI bugs hampering porting effort for shaped window

by Rob

Hi Rein, >When I implemented the case that name == NULL ( another call for help, I >wasn't aware of your bug report, sorry), the only reference I could find >was this: > >| If null is provided in the name parameter, the returned string is the same >| as the string returned by a successful gethostname function call. I can't remember where I saw it (as I have been developing with winsock for years), all I do know that it's well known among windows winsock developers. In fact, since passing gethostname into gethostbyname is guarenteed to return back local IPs in Windows, you can therefor logically deduce that passing in NULL guarentees that local IPs are returned as well. In fact, I would say you should be checking for NULL and return back local IPs AND you should also do your own call to gethostname and if that equals the string passed into gethostbyname, then you should return a list of local IPs as well. On *nux, this behaviour is not guarenteed, like it is on Windows. Our application relies on this behaviour to function under all OSes (98 through XP). If Microsoft were to change how this worked, it would break our application and many others. Only on Windows CE do we have to pass the results of gethostname() into the function to get correct results as WinCE doesn't like NULL. WinCE has many conflicts with the Win32 API - so this isn't surprising. We can pass in the results of gethostname into the function and it will return local IPs as well - the trouble is that on Linux gethostname passed into gethostbyname doesn't always work as it does in windows (i.e. returning back local IPs). Certainly, documented or not, the results from passing in NULL should be identical to the windows platform. One more thing, 127.0.0.1 is filtered in the results when passing in NULL - at least on Windows 2000. It's a safe bet to screen for it since any developer would have to anticipate the loopback address missing from the results even if other Win OSes included the loopback (which is doubtful they return this result either). -Rob -----Original Message----- From: Rein Klazes [mailto:rklazes(a)xs4all.nl] Sent: October 31, 2003 3:01 AM To: cto(a)xten.com Cc: Mike Hearn; wine-devel(a)winehq.com Subject: Re: UI bugs hampering porting effort for shaped window On Thu, 30 Oct 2003 10:59:40 -0800, you wrote: > > Hi Mike, > > bug 1541 is still *not* fixed correctly. See when passing in NULL in windows > to gethostbyname, it is guarenteed to return a list of local IP addresses > mapped on the box. However, with WINE, passing NULL causes gethostname to be > passed into gethostbyname and does *not* always return back the list of > local IP addresses on the box. When I implemented the case that name == NULL ( another call for help, I wasn't aware of your bug report, sorry), the only reference I could find was this: | If null is provided in the name parameter, the returned string is the same | as the string returned by a successful gethostname function call. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winsock/win sock/gethostbyname_2.asp Small detail: gethostbyname does not return a string, but this is what I guessed the intention of the writer was. Can you point to any documentation where this guarantee is specified? Rein. -- Rein Klazes rklazes(a)xs4all.nl

Oct. 31, 2003

Re: UI bugs hampering porting effort for shaped window

by Rein Klazes

On Thu, 30 Oct 2003 10:59:40 -0800, you wrote: > > Hi Mike, > > bug 1541 is still *not* fixed correctly. See when passing in NULL in windows > to gethostbyname, it is guarenteed to return a list of local IP addresses > mapped on the box. However, with WINE, passing NULL causes gethostname to be > passed into gethostbyname and does *not* always return back the list of > local IP addresses on the box. This may work on some boxes, and not others, > depending on how the machine is configured and if the DNS lookup on the host > name resolves to the local IP addresses. After an experiment on win2k is don't see any difference in the result of gethostbyname(NULL) and gethostbyname(name_returned_by_gethostname). Each returns a single struct hostent, which contain a list of ip addresses. > whereas if (!name) should use SIOCGIFCONF - SIOCGIFADDR or something... How sure are you that the problem does not lie with the gethostbyname(name_returned_by_gethostname) part? On my system everything works as expected: I get a list of all ip addresses. That is with valid /etc/hostname and /etc/hosts entries. What systems go wrong? Rein. -- Rein Klazes rklazes(a)xs4all.nl

Oct. 31, 2003

Re: bug 1541

by Dan Kegel

Mike Hearn wrote: > On Fri, 2003-10-31 at 00:51, Dan Kegel wrote: > >>getifaddrs() is indeed the right beast, though who knows, maybe you'll >>have to filter out 127.0.0.1. Hitch is, Linux doesn't provide it. > > > I think it does as of the latest glibc, at least it's marked as "done" > on their TODO list. Hey, you're right. It's there on Red Hat 8 even. So you could use that when present, and fall back on the current hack (or my implementation) if the system doesn't provide it. - Dan -- Dan Kegel http://www.kegel.com http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

Oct. 31, 2003

Re: Misc wine debugging questions

by Dimitrie O. Paun

On October 31, 2003 02:41 am, Gregory M. Turner wrote: > BTW, note that transports like http, tcp, etc, could allow wine to do DCOM > without resolving the "priveleged ports" issue (at least for fixed > endpoints).... of course, our wire protocol is way off and will need fixing > before that's possible... luckily I have archived the spec (enclosed for > your amusement), which AFAIK fell off the 'net. Older revisions are > available by searching (<a href="http://www.brassroots.org/google.html">do > not > Google!</a>) the 'net; the enclosed version was linked to by Don Box's > delicious blog back when it existed at > http://www.globecom.net/ietf/draft/draft-brown-dcom-v1-spec-03.html. This is a lot of cool stuff, maybe we can organize a development page for all this info, and stick it somewhere on WineHQ. Otherwise, all these links (and the ones Mike found) will soon be forgoten, and in 3 months\ time, we'll have the same discussion... -- Dimi.

Oct. 31, 2003

Re: New tarball of valgrind for WINE available

by Dimitrie O. Paun

On October 31, 2003 05:38 am, Adam Gundy wrote: > that looks unlikely at the moment :-( Darn. Even if we have to provide a switch (like --wine) to valgrind? That would be so much better than a different binary. What's the problem, BTW? -- Dimi.

Oct. 31, 2003

Re: bug 1541 (was: UI bugs hampering porting effort for shaped window)

by Dimitrie O. Paun

On October 31, 2003 05:32 am, Mike Hearn wrote: > I think it does as of the latest glibc, at least it's marked as "done" > on their TODO list. So we can stick Dan's implementation in libs/port, and do a configure check for it... -- Dimi.

Oct. 31, 2003