As already discussed last week, 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 server: 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 concurrency.

As an additional minor benefit, the "strace" program can be modified to read these specific system calls.

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 synchronization).

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: 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 and process...).

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 solutions.

Another area open to some improvement is file I/O mechanism. As David Howells put it: 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.

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: 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.

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 this one.

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.

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 a previous WWN.

However, Gérard ran also some benches: 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 :

NT

• 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)

Wine

• 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 :-)

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).

Linux 2.4 networking incompatibilities with Wine are old story. Problems reported in previous issue have found a proper fix.

Jonathon Griffiths wanted to enhance CRTDLL functionalities. He also asked if someone was already working on the same area, and had a few unanswered questions:

• 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 at anyone?

Uwe Bonnes was quite against implementing CRTDLL in Wine:

• CRTDLL is huge with a lot of (unclean and undocumented) entries
• 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.

Lots of people were not very happy with Uwe's proposal. Gavriel State, for example, felt that CRTDLL was quite useful with WineLib applications; 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 would be.

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.

Marcus Meissner pointed out an interview of Alexandre on LinuxNews, which gives some outlook on the Wine future.