Wine Traffic #60 For 11�Sep�2000
Table Of Contents
This is the 37th 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).
Wine-20000909 snapshot has been released. Main changes are:
- Better handling of Win32 dll loading.
- More DBCS codepages support.
- Several multimedia improvements.
- Beginnings of reentrant wineserver protocol.
- Lots of bug fixes.
Mailing List Stats For This Week
We looked at 104 posts in 354K.
There were 32 different contributors.
18 posted more than once.
13 posted last week too.
The top posters of the week were:
- 12 posts in 74K by David Howells <David.Howells@nexor.co.uk>
- 12 posts in 30K by Alexandre Julliard <firstname.lastname@example.org>
- 9 posts in 24K by Uwe Bonnes <email@example.com>
- 8 posts in 29K by Patrik Stridvall <firstname.lastname@example.org>
- 8 posts in 21K by Eric Pouech <Eric.Pouech@wanadoo.fr>
- Full Stats
A way to speed up Wine
Archive Link: "possibility for massive wineserver speedup"
David Howells,�Alexandre Julliard,�Linus Torvalds,�
As already discussed BROKEN KCREF,
David Howells proposed a way to speed up drastically Wine.
David's idea was to move some of the features of the wine server into a
Linux kernel module, hence reducing the latency of the calls to the
David even proposed some benchmarks of his module, showing some
(slight) gains over Windows 2000 (20%) and huge gains over current
Wine implementation (900%).
However, those raw figures only demonstrate the gain that can be
obtained in the synchronization mechanisms, but it's hard to tell the
final gain on a reasonable program (which does many other things than
However, Wine is intended to be used on non-Linux platforms (like
*BSD, Solaris...), so maintenance issues between the current wine
server and a kernel module must be tackled. Alexandre Julliard was the
one who opened fire:
Because the current wineserver interface involves each wine process
making a socket connection to a separate server process, which then
arbitrates access to synchronization objects and various other things.
All this involves message passing and lots of process context
switching (slow). By moving this into the kernel, advantage can be
taken of kernel services for handling synchronization, scheduling and
As an additional minor benefit, the "strace" program can be modified
to read these specific system calls.
The kernel module approach is interesting, but I'm afraid it's not
really practical to re-implement the complete server in the kernel,
unless we can somehow build both the kernel module and the user-mode
server from the same sources. An intermediate approach that may be
worth investigating is to keep the server in user-space but implement
a faster request mechanism with a small kernel module; Unix sockets
are not very well suited to the request/reply model that we need, and
I think it should be possible to make the communication much faster
with a specialized kernel call.
Alexandre also argued upon the bits to be moved inside the kernel. He
advocate for having only a couple of specific syscalls inside Linux
just to speed up the synchronization issues, but keep all of the work
inside the wineserver ; David was more in favor of migrating entire
parts of the wine server inside the kernel (handles management, thread
As a whole, Alexandre was rather reluctant to move entire parts of the
wine server into the kernel, and was more attracted to improving first
the request/response mechanism used in wine (even if this needs adding
new syscalls to the kernel):
I'm not so sure. I did a few tests with using signals and ptrace as a
communication mechanism instead of sendmsg/recvmsg, and the total time
for a server round-trip got reduced by half. I don't know how much of
that is because of extra context switches or of sendmsg overhead, but
there is certainly a large potential to improve things here. And
before deciding to move everything in the kernel I think it would be a
good idea to investigate what we can achieve with less radical
Another area open to some improvement is file I/O mechanism. As David
Howells put it:
David, even if his proposal and its architecture didn't fire
Alexandre's enthusiasm, posted to linux-kernel his patch for
comment. Linus (tm) answered:
What I'm most concerned about with wine is the fact that every time a
file operation is issued, the client makes a call to the server to
convert the Win32 file handle into a UNIX fd (via sendmsg/recvmsg),
which gets used once and then discarded.
I've seen programs that do a lot of I/O (for instance PVCS) hammer the
server lots with requests for file handle conversion, and so they run
quite a bit slower on Linux than on Windows.
Another part of the discussion evolved into the details of mounting a
windows registry file (call me hive) as a filesystem using the mount
command. But it lead almost to nowhere, so don't wait too much for
As a conclusion, David opened an interesting area in Wine:
optimization. Lots remains to be done, but this is at least a good
starting point. We'll keep you updated on the evolution of David's
work, and its inclusion in Wine.
Hmm.. I have this feeling that it would be much nicer to just implement
the NT system calls directly.
We used to have the iBCS2 project, and I was actually considering
making it part of the standard kernel when it started becoming a
non-issue simply because there started to be more native Linux
programs than iBCS2 programs.
And we've already had the vm86 mode and the BIOS trap stuff speedups
for DOSEMU for a long time.
It looks like if you want to do this, it would be better to just try
to do it outright, and have the same kind of "emulate the ones we know
about and care about performance" in the kernel that we already have
with the vm86 mode emulation.
I wouldn't be adverse to supporting Wine better - as long as it's
fairly cleanly separated. This doesn't look too bad.
GDI heap overflow
Archive Link: "GDI heap overflow (again)"
G�rard Patel,�Andreas Mohr,�
Andreas Mohr posted a debug trace from an application, obviously
crashing because of misbehaving GDI handles.
After some detailed trace examination, G�rard Patel concluded that the
program was leaking GDI handles hence, the crash. This issue has been
covered in BROKEN KCREF.
However, G�rard ran also some benches:
Anyway, it seems those differences on the GDI handles limits may cause
bad behaviors such as the one reported here. No potential fix has been
submitted so far (and not even foreseen).
Hmm, along the lines of 'let's have fun with Windows' I wrote a
crappy test app to leak Gdi objects and here are the results under
Windows NT 4.0 SP3 and Wine :
- Brushes: after about 12000 brushes, Gdi gave up and returned errors.
- Pen: same
- Palette: same
- DC: after somewhat 3000 DC, Windows NT stopped the test (It's a bad idea to leak DCs under NT4 SP3)
- Brushes: 1000 was all right, the second time I pressed on the
test button, Wine cried 'CombineRgn: invalid region'
- Pen: same
- Palette: 1000 all right, after that things turned ugly, my form
did not respond correctly anymore.
- DC: 1000 already gave a memory allocation error
LOCAL_GetBlock not enough space in GDI heap
It makes sense since DC is a much bigger structure.
On the bright side of things, I could ask
for 5000 DC and still be
able to exit cleanly my app so Wine has an edge here :-)
Linux 2.4 networking and Wine
Archive Link: "linux 2.4 winsock fix"
Linux 2.4 networking incompatibilities with Wine are old
story. Problems reported in BROKEN KCREF have found a proper fix.
Implementing CRTDLL or not
Archive Link: "CRTDLL"
Jonathon Griffiths,�Uwe Bonnes,�Gavriel State,�
Jonathon Griffiths wanted to enhance CRTDLL functionalities. He also
asked if someone was already working on the same area, and had a few
Uwe Bonnes was quite against implementing CRTDLL in Wine:
- The number of implemented functions is quite small - does this
mean that most people (including winelib users) are using the M$
version of this DLL?
- Does anyone know of a good test suite/app with source for
testing crt functions? Or, if I produce a testharness should it be
booked in as a sample/tool?
- Are there any other issues I should be aware of that leap out
Lots of people were not very happy with Uwe's proposal. Gavriel State,
for example, felt that CRTDLL was quite useful with WineLib
- CRTDLL is huge with a lot of (unclean and undocumented)
- Native CRTDLL seems abandoned by Microsoft and the MingW people
said that CRTDLL has problems with threads. Most newer programs use
MSVCRT, so we would have to implement MSVCRT too
- Native CRTDLL doesn't implement low level functionality
directly but uses Kernel for that functionality. So it is save to use
native crtdll under Wine
- Native CRTDLL should be distributed with most programs that use
it, so programs needing it would come with it.
A WineLib apps's fopen call needs to
get redirected to CRTDLL fopen, not glibc's fopen. There's also a
need for implementations of things like fscanf that know how to deal
with DOS CR/LFs. Gav reminded also that this is useful for
transforming Windows path into Unix ones (so that glibc can handle
them), but also deal with CR/LF ugliness from the old days of DOS.
Uwe also pointed that some Visual Studio CDs contain the source of
CRTDLL and/or MSVCRT, and wondered whereas the Wine native DLLs could
be built out of this code (after sorting out the legal issues), as MFC
Finally, Jonathon decided to keep on working on enhancing CRTDLL (as a
first step), and perhaps, in a second step, to work also on MSVCRT.
Alexandre Julliard gets talkative
Archive Link: "LinuxNews: WINE aging gracefully"
Marcus Meissner pointed out an interview of Alexandre on
, which gives some outlook on the Wine future.
Sharon And Joy