Wine Traffic #27 For 24�Jan�2000

By Eric Pouech

Table Of Contents

Introduction

This is the twenty seventh 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).

WineHQ is still having some trouble after the upgrade 2 weeks ago. Most of the servers are up and running, even the NNTP got back its posted articles; however the NNTP server is no longer updated. This is worked upon, but, unfortunately, not yet done.

Mailing List Stats For This Week

We looked at 117 posts in 514K.

There were 39 different contributors. 27 posted more than once. 25 posted last week too.

The top posters of the week were:

1. Wine license change

19�Jan�2000 (1 post) Archive Link: "License change"

People: Alexandre Julliard,�

After the discussions held early December of last year (wn19991206_20.html#0) regarding changing Wine's license, Alexandre Julliard proposed the following changes:
Now that the holiday season is over and that the Y2K apocalypse is safely behind us, I'd like to proceed with the license change. The discussion we had a few weeks ago leads me to the conclusions that:

So I propose that we switch to the X11 license.

I've included a copy of the license below, and I ask all developers (if your name is in the AUTHORS file you are a developer) to please send me a private email stating whether you can accept it or not; even if you don't give a d*mn about the license, please drop me a mail saying just that. Thanks.

PS: the final wording of the copyright line may be a bit different, maybe making reference to the AUTHORS file; we'll probably also include the license text in every source file. But these are implementation details that we can discuss once the license itself is agreed upon.

PPS: I don't need individual agreements from people working on behalf of Corel, since Corel is the copyright holder on their code. I will need an agreement from Corel Corporation itself though.

So, if you're a developer, do drop a note to Alexandre.

As a remainder (and for the layers who may (by mistake ?) read this news letter), here's the proposed license:
Copyright (c) 1993-2000 The Wine Project

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

2. Address space separation has started

19�Jan�2000�-�22�Jan�2000 (17 posts) Archive Link: "Address space separation"

People: Alexandre Julliard,�J�rg Mayer,�Michael Veksler,�CodeWeavers,�,�G�rard Patel,�Peter Ganten

The long awaited work on address space separation has started. This internal enhancement to Wine would provide a separate address space (in Unix term) for every Windows process running under Wine.

Here are a few reasons to put this in place:

Alexandre Julliard sent a first patch (based on his work at CodeWeavers on behalf of Corel) and asked for some further testings. This was only the first step to provide full address space separation. So far, Alexandre's patch provides the following features:

This patch does not yet change the behavior with processes started inside an existing Wine session through CreateProcess, so it shouldn't break anything; but please test it anyway...

Hence, this patch doesn't solve the relocation of DLLs issue, but is a first step towards its resolution. The following steps will likely include using another Unix process while handling the CreateProcess API, but also an in details review of all DLLs to see how they behave with regard to separated address spaces ; sending messages across processes has to be addressed as well.

Anyway, Alexandre's patch didn't generate bad reports (only G�rard Patel found a badly behaving application, but which was due to ddeml.dll not properly handling the different address spaces), so this patch is expected to make its way to CVS soon.

J�rg Mayer pointed out some security/denial of services (DoS) issue: Since the socket used for communicating with the wineserver is located in /tmp, under a user's name (in fact his uid),
This is broken wrt security/DoS attacks. Creating files in /tmp is a bad idea (tm). The first dos that came to my mind immediately was to create a directory with your uid. So next time you want to run wine, you fail. I'm sure in a more subtle way I could even gain gain control over "your" socket. We already have a $HOME/.wine directory. I think $HOME/.wine/run/ would be a good place for that stuff.

Alexandre agreed that /tmp was a bad place, but he feared that $HOME/ could be located on exotic file systems on which unix sockets are badly handled. The first file system to think of is NFS, but lots of people (Olivier Galibert, Peter Ganten to name a few) reported this was working fine on lots of Unices. However, Michael Veksler reported
I have AFS which definitely does not allow sockets/fifos. Nevertheless It was possible to run applications that establish fifos in $HOME/.somename/ by making $HOME/.somename link to /tmp/veksler/somename/.

The morale is: put it in $HOME/.wine/sockets/ and let the user decide if that is a directory or a link to the local file system. Requiring the sysadmin to setup /var/...../user/ or to fight DOS attacks is not very user friendly.

As a conclusion, Alexandre proposed the following solution:
Maybe I should create the socket under /tmp with a unique name and store a pointer to it in $HOME.

3. Merging wine and winelib startup code

18�Jan�2000�-�23�Jan�2000 (13 posts) Archive Link: "First try at Wine/WineLib merge"

People: Ulrich Weigand,�Alexandre Julliard,�,�Bertho Stultiens

Ulrich Weigand posted for review (this week has definitively been a review one !) a first try at merging the wine and winelib startup code.
The main points are:

In fact, implementing this last point even fixes some bugs in the current WineLib setup:

Among the issues, Ulrich noticed with is patch was that some applications from programs/ in the CVS tree no longer link because they were using the "libres hack". This hack was redefining one different resource structure for each supported language; when used in conjonction with Ulrich path, this lead to symbol's name collision. Bertho Stultiens simply proposed to convert those programs resources to the normal resource style (which allows several languages to be supported in a single resource structure). Bertho also announced that he was about to release a new version of wrc which would allow to get rid of gcc preprocessing.

Alexandre Julliard and Ulrich discussed then some technical details linked to the process/thread creation. Alexandre was also not willing to have the first process being a 16 bit one (which Ulrich claimed as required to be able to run native USER), and also to add 16 bit application support for winelib applications.

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.