Wine Traffic #31 For 21 Feb 2000
Table Of Contents
This is the 31st release of the Wine's kernel cousin
publication. It's main goal is to distribute widely what's
going on around Wine (the Un*x windows emulator).
Mailing List Stats For This Week
We looked at 97 posts in 393K.
There were 27 different contributors.
14 posted more than once.
20 posted last week too.
The top posters of the week were:
- 20 posts in 42K by Alexandre Julliard <email@example.com>
- 12 posts in 53K by Patrik Stridvall <firstname.lastname@example.org>
- 8 posts in 16K by Ove Kaaven <email@example.com>
- 7 posts in 23K by Andreas Mohr <firstname.lastname@example.org>
- 6 posts in 5K by Marcus Meissner <email@example.com>
- Full Stats
WineHQ web server
Archive Link: "Network TTL trouble"
There were a couple of issues with the WineHQ server this
week. Firstly, Bertho Stultiens, who is kindly hosting www.winehq.com
and a few days later, Bertho kept experiencing the Murphy's Law:
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
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 22.214.171.124 (winehq). Mainly
because the IP is an alias. However, I just got the network running
again and the whole site is accessible again (afaik).
Everything has been back on tracks before the week-end.
Of compilers and calling conventions
Archive Link: "Wine's dependency on the pascal calling convention (stdcall)"
Patrik Stridvall, Alexandre Julliard, , Patrik Stridval, Marcus Meissner
Patrik Stridvall started another staircase discussion with Alexandre
Julliard regarding Wine's adhere to the GNU's compiler.
Wine, as Windows, relies on the pascal (aka stdcall) calling
convention: a function's calling convention defines in which order the
parameters are pushed onto the stack: C (aka cdecl) pushes the
parameters from left to right, pascal does it the other way).
Most of Windows APIs are defined with the pascal calling
convention. So, when Wine implements a Windows API, the function is
(most) always pascal.
However, Patrik pointed out:
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.
Patrik then announced he had had some success making WineLib work with
Solaris Workshop C, which has the following advantages:
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.
Marcus Meissner pointed out that using latest gcc (2.95) and binutils
would reduce debug information (by merging it between different
Anyway, Patrik's main point remained: if Wine is asked to run, let's
say native x86 code (using the pascal calling convention) with regular
code (using only cdecl calling convention), then there's a need for a
Patrik's main application was to be able to run Wine on Itanium (aka
Merced) and using it x86 hardware emulation part.
A lengthy discussion went on between Patrik and Alexandre. Alexandre
concluded it with:
Final decision will be made on
- there are two different issues: adding a x86 emulator to
Wine and compiling Wine on a compiler without support of stdcall
- first issue is a high priority one, whereas the second
isn't (gcc can be used, even if not the best compiler around)
- changes for both issues on core Wine code shall be as
small as possible (mainly modifying the thunk tools and code)
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.
Do animals drink Wine ?
Archive Link: "COREL: typelib speedup"
Ove Kaaven, Alexandre Julliard, CodeWeavers, , codeweavers, Ove Kåven, Marcus Meissner
Marcus Meissner, in the bunch of patches he submitted from the Corel
CVS tree, provided one with the following Changelog:
Alexandre Julliard <firstname.lastname@example.org> (for Corel)
A suspicious Ove Kåven asked:
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?
Later on, Alexandre gave also an update on the
Wine's license survey:
It is the Alexandre-working-on-behalf-of-Corel, not the
Alexandre-hacking-Wine-on-his-own-time; they are quite different
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
Sharon And Joy