Included below are my latest results for Bug 448. The problem there is that winsock connects to port 512 although a service at port 5557 was specified.
The winsock functions seem to work correctly: -> getservbyname16 returns port 0x15b5 = 5557 -> connect16 receives port 512 (!) directly after that.
(the only thing that happens in between is a socket() call). The interesting part is that 512 in network byte order is 0x0002, i.e. the same as the protocol family (0x0002=AF_INET).
Is it possible that something gets overwritten here when connect() is called? My problem is that I have no clue hall the magic relaying between 16 and 32 bit code in wine works.
Perhaps someone can give me a hint?
Martin
------- Additional Comments From martin.wilck@fujitsu-siemens.com 2002-09-05 07:58 -------
I finally got some time to look into this. It does not seem to be a winsock error.
By inserting some TRACES, I can clearly see that getservbyname() correctly returns port 5557 (hex 0x15b5):
trace:winsock:WINSOCK_getservbyname16 "ctsql", "tcp" trace:winsock:__ws_getservbyname name ctsql proto tcp flag 2 i 6 trace:winsock:WS_dup_se s_name ctsql s_port 15b5 s_proto tcp trace:winsock:WS_dup_se 16 s_port 15b5 trace:winsock:__ws_getservbyname s_name ctsql s_port 15b5 s_proto tcp
[ ... ] But when "connect" is called, it is passed port 512 (hex 0200):
trace:winsock:WINSOCK_connect16 socket 0048, ptr 0x40c493d6, length 16 sockaddr_in: family 2, address 172.25.186.5, port 512 02 00 02 00 ac 19 ba 05 00 00 00 00 00 00 00 00
Interestingly, (since the port is in network byte order) the hex patterns for address family and port are both 0x0002. This looks as if either - the app is assigning the family to the port number (?) (This would mean that the shouldn't be able to run on Windows either, since you say all was fine in 20011108, there must be another reason) - something goes wrong when the argument is passed from the 16- to 32bit layer.
Have to look further.
-
Martin Wilck