On Thu, 27 Nov 2003 14:31:45 -0800 (PST), you wrote:
ChangeLog: remove annoying message about missing entry in /etc/services
The behavior when the entry is missing is already correct, so the warning isn't useful.
Well if that call fails on Wine+Linux but succeeds on Windows I don't call that correct, even if is not technically Wine that is wrong. Point is that there is no other place then inside Wine to put this message.
( Compare this to a recent discussion on the gethostbyname(NULL) behavior on wine-dev, which goes even further..)
I put this in, for a banking program that uses a FTP protocol on a pair of non standard ports. AFAIK the program is not used anymore, so I don't care the message going away. But it must go, if would change it to a WARN or a TRACE, so that at least a winsock trace will reveal the problem easy.
Rein.
--- Rein Klazes rklazes@xs4all.nl wrote:
On Thu, 27 Nov 2003 14:31:45 -0800 (PST), you wrote:
ChangeLog: remove annoying message about missing
entry
in /etc/services
The behavior when the entry is missing is already correct, so the warning isn't useful.
Well if that call fails on Wine+Linux but succeeds on Windows I don't call that correct, even if is not technically Wine that is wrong. Point is that there is no other place then inside Wine to put this message.
I don't think the behavior is any different under Windows and Wine+Linux, that's why I felt the warning is useless. I just observed that Windows' netstat.exe prints port numbers (try 'wine -- netstat.exe -a') if the service isn't found, so it expects to deal with failure. MSDN documents the return value as NULL if the service isn't found, and this matches getservbyport(3).
Ahh, I think I see your point: the Wine+Linux variant uses /etc/services, while Windows uses a file of the same format, but in a different location (system\services for Win9x, typically system32\drivers\etc\services for WinNT+). Is that right?
In that case, I'm not sure what the correct behavior should be. On one hand, it doesn't match Windows' behavior 100% when using a real Windows install. On the other hand, it'll match native (Linux) programs' behavior on the same machine.
Because a user (non-developer) can't take any action to correct this, I think the output is unnecessary. Point taken that at least a TRACE may be useful, though, since it's of use to developers.
Or this there another reason I'm missing? --Juan
__________________________________ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/
On Fri, 28 Nov 2003 11:43:06 -0800 (PST), you wrote:
Ahh, I think I see your point: the Wine+Linux variant uses /etc/services, while Windows uses a file of the same format, but in a different location (system\services for Win9x, typically system32\drivers\etc\services for WinNT+). Is that right?
Yes, although I do not remember for sure whether this services file under windows is actually used by these winsock calls.
In that case, I'm not sure what the correct behavior should be. On one hand, it doesn't match Windows' behavior 100% when using a real Windows install. On the other hand, it'll match native (Linux) programs' behavior on the same machine.
Purpose of wine is to run win applications that users want to run under Linux. We occasionally go beyond the way from 100% correctness to help make that happen.
Because a user (non-developer) can't take any action to correct this, I think the output is unnecessary. Point taken that at least a TRACE may be useful, though, since it's of use to developers.
I don't follow here. There are plenty of users around that would be able to read, understand and act on this message.
Rein.
--- Rein Klazes rklazes@xs4all.nl wrote:
Ahh, I think I see your point: the Wine+Linux
variant
uses /etc/services, while Windows uses a file of
the
same format, but in a different location (system\services for Win9x, typically system32\drivers\etc\services for WinNT+). Is
that
right?
Yes, although I do not remember for sure whether this services file under windows is actually used by these winsock calls.
It is (just checked on WinME).
Because a user (non-developer) can't take any
action
to correct this, I think the output is
unnecessary.
Point taken that at least a TRACE may be useful, though, since it's of use to developers.
I don't follow here. There are plenty of users around that would be able to read, understand and act on this message.
Plenty of us, yes, but not all users IMO. I'm on a kick to get rid of annoying messages that might be misinterpreted as errors by casual users of WINE. Like I said in my prev response, this message isn't indicative of an error, it may be doing precisely what it's meant to. For instance, here's a snippet from my netstat -a output on Windows at the moment: TCP juan:1064 JUAN:0 LISTENING TCP juan:1055 f465.mail.yahoo.com:80 TIME_WAIT With this MESSAGE, each entry for unknown port #s (1064, 1055 in this output) will print out a message about a missing entry in /etc/services. This isn't what I'd expect, since a random port # used on the client end of a tcp connection shouldn't be using a well-known port most of the time. I'd argue this message isn't useful to casual users, either.
So, I'd still argue that the behavior is correct a large percentage of the time, without the message. The only time the behavior isn't correct is when WINE is being run against a native windows install, and the services file under Linux differs from the services file on that native windows install, and the user is trying to getservbyproto something that appears only in the windows install. And whether the behavior here is incorrect is still debatable in my mind, because the Windows app will be using the same services file the Linux apps do, and will behave the same as them.
Whew.. sorry I'm beating this to the ground. In any event, Alexandre didn't apply my patch :) What do you say about changing from MESSAGE() to TRACE()?
--Juan
__________________________________ Do you Yahoo!? Free Pop-Up Blocker - Get it now http://companion.yahoo.com/
-
Juan Lang -
Rein Klazes