Florian Echtler wrote:
Hi everybody,
we are using a certain tracking software from Advanced Realtime Tracking. This is a windows software, but we decided yesterday that it would be more flexible to be able to use it under Linux, too, so I gave it a try with Wine.
As this software communicates with customized (expensive) cameras via UDP, I noted a strange bug in the Wine debug channel "winsock": the software was sending UDP packets to IP _254_.255.255.255 (note the first octet). After some experimentation, I noticed that while Windows just sends this as a broadcast packet, Linux rejects this address, because the corresponding RFC states that the network 240.0.0.0/4 is reserved and should not be used.
I therefore build a small patch which checks for these strange adresses and replaces them by broadcast adresses. This enabled our software to work. However, the question now is whether it makes sense to include this patch into Wine? On the one hand, it increases the similarity
If an application really depends on a Windows bug to work correctly then chances are good that the patch will be accepted. But you have to write a test case for this behavior. And you'll have to put in a big fat comment in the code why you had to do that.
between Wine's behaviour and Windows's, OTOH it decreases Wine's RFC compliance..
bye michael
--- dlls/winsock/socket.c 2006-02-15 17:02:53.000000000 +0100 +++ dlls/winsock/socket.c 2006-09-14 15:30:18.000000000 +0200 @@ -1392,6 +1392,8 @@ { struct msghdr hdr; int n = -1;
u_int32_t* target;- TRACE( "fd %d, iovec %p, count %d addr %s, len %d, flags %lx\n", fd, iov, count, debugstr_sockaddr(to), tolen, dwFlags);
@@ -1443,6 +1445,13 @@ hdr.msg_flags = 0; #endif
target = &(((struct sockaddr_in*)(hdr.msg_name))->sin_addr.s_addr);if ( ((*target) & 0x000000F0) == 0x000000F0) {fprintf(stderr,"FIXME: i cheated and changed reserved IP address 240.*/4 to 255.*.\n");*target |= 0x000000FF;//printf("%x\n",*target);}- n = sendmsg(fd, &hdr, dwFlags);
out: