Kernel Traffic
Latest | Archives | People | Topics 		Wine
Latest | Archives | People | Topics 		GNUe
Latest | Archives | People | Topics
Czech
Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Stalled Traffic
 

Wine Traffic #60 For 11 Sep 2000

By Eric Pouech

Table Of Contents

Introduction

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:

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:

1. A way to speed up Wine

29 Aug 2000 - 8 Sep 2000 (31 posts) Archive Link: "possibility for massive wineserver speedup"

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

2. GDI heap overflow

5 Sep 2000 - 6 Sep 2000 (12 posts) Archive Link: "GDI heap overflow (again)"

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

Wine

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

3. Linux 2.4 networking and Wine

6 Sep 2000 (2 posts) Archive Link: "linux 2.4 winsock fix"

People:

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

4. Implementing CRTDLL or not

6 Sep 2000 - 7 Sep 2000 (11 posts) Archive Link: "CRTDLL"

People: 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 unanswered questions:

Uwe Bonnes was quite against implementing CRTDLL in Wine:

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.

5. Alexandre Julliard gets talkative

8 Sep 2000 (1 post) Archive Link: "LinuxNews: WINE aging gracefully"

People: , News, Marcus Meissner

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

 

 

 

 

 

 

Sharon And Joy
 

Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at kernel.org. All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.