Wine Traffic #31 For 21 Feb 2000

There is a chance that some network-connections never will arrive at the www.winehq.com server. This is due to extreme hop-counts between networks. We have experienced hop-counts over 40 from our internal net and I just discovered that the external computers also reach over 30 many times.

The problem always starts after about 15:00 CET local time (09:00 EST) and stops first (gets less bad) when the USA's eastcoast is getting ready for dinner (24:00..01:00 CET). The increased traffic in the US is resulting in rerouting of many packets and increased router-involvement. Our network is almost completely routed through a US-connection for USA, Australia and Asia traffic. However, I've also seen problems within Europe.

We are considering a couple of IPIP-tunnels to get the hopcount down, but this involves serious work and will not be done all too soon. If you have problems, please notify me with a trace from your local site.

Note: most Linux machines will not have problems because the default TTL is set at 64 (RFC1700 page 64 use 'cat /proc/sys/net/ipv4/ip_default_ttl'). However, older machines may still have their TTL at 32 (RFC1060 page 23 or even worse, at 15 as recommended in RFC791...). I do not know about other OSes what their defaults are, but please set them higher than 32 if you want to keep on using the internet.

The network-card gave up (a ne2000 clone). The problem was that I did not have another 10Mbit card at hand (only 100Mbit) and it took a while to lay hands on a new card. But, as usual, not everything is working instantly with a new card. The problem during the last 10 hours or so has been that the router's arp-cache refused to timeout and I could not get packets out from 130.225.13.222 (winehq). Mainly because the IP is an alias. However, I just got the network running again and the whole site is accessible again (afaik).

While GNU C supports it (pascal calling convention), some other compilers like the Solaris Workshop C compiler doesn't AFAIK. This is not very surprising since ANSI C doesn't require support for it.

The most important issue is the size of the debug info. With Solaris Workshop C 4.2 the total size of the *.so files with stabs debug info (used by dbx) is about 9.8 Mb. With GNU C 2.91.66 the total size of the *.so files is about 77 Mb. No I'm not joking it is almost a factor 8 difference. Further more Solaris Workshop C generates better code and compiles faster. Secondly supporting more compilers is nice in itself.

a matter of cost vs. benefit. And in the case of stdcall the benefit is so small that I seriously doubt you can make it worthwhile. If you disagree, by all means go ahead and implement it, and then we'll judge on the code.

I'm sure there must be other people than me wondering... which Alexandre is this who needs to have his patch submitted to Wine by someone else?

It is the Alexandre-working-on-behalf-of-Corel, not the Alexandre-hacking-Wine-on-his-own-time; they are quite different animals.

The work I do for Corel is owned by them, and they can do what they want with it; it may or may not end up in their CVS tree, and as long as it isn't released to the public I don't have any right to put it in the WineHQ tree. Once it shows up in the Corel tree I could of course merge it into WineHQ myself, but if other people do the work for me I'm not going to complain...

Even though Corel are very cool about this, and of course intend to release all the Wine code back to the community anyway, I think it is important to make a clear distinction, to ensure that I don't take credit for changes paid for by Corel (or that they take credit for changes I do on my own...) This is also why I have adopted the convention of putting my CodeWeavers email in the log entry of all the patches I did on behalf of Corel.

I have received an OK from about 75 people, and more are still arriving. Since I haven't received any opposition so far I think it is safe to say that we will be able to do the change pretty soon.