WWN Issue 27

This is the twenty seventh release of the Wine's kernel cousin publication. Its 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.

This week, 117 posts consumed 514 K. There were 39 different contributors. 27 (69%) posted more than once. 25 (64%) posted last week too.

The top 5 posters of the week were:

15 posts in 38K by Alexandre Julliard
12 posts in 112K by Ulrich Weigand
8 posts in 16K by Bertho Stultiens
7 posts in 14K by Juergen Schmied
7 posts in 15K by Ove Kaaven

Wine license change	19 Jan 2000 00:00:00 -0800	Archive
After the discussions held early December of last year 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: most developers do not care much nobody seems opposed to a change there is a consensus that an existing license is better that inventing a new one the X11 license is preferred over the FreeBSD one, because of ambiguity with the different BSD licenses 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.

Wine license change

19 Jan 2000 00:00:00 -0800

Archive

After the discussions held early December of last year 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.

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.

Address space separation has started 19 Jan 2000 00:00:00 -0800 Archive

Address space separation has started	19 Jan 2000 00:00:00 -0800	Archive
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: security: under Windows 9x and NT, a process cannot directly access the memory of another process. runnability: some DLLs do not have relocation records. This is fine when a single process occupies the address space, but is problematic when two different processes try to load at the same address two DLLs (the address being hardwired in each DLL). Only one of the two DLLs can be loaded. This is the source of the (in)famous errors like: `FATAL: Need to relocate foo.dll, but no relocation records present (). Try to run that file directly !` 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: the server is now always a separate program, that can accept connections on a Unix socket in /tmp a newly started Wine will connect to an existing server if it can find one running (on a per-user basis) the system heap is shared among all Wine sessions connected to the same server. 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.

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:

FATAL: Need to relocate foo.dll, but no relocation
records present (). Try to run that file directly !

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.

Merging wine and winelib startup code	18 Jan 2000 00:00:00 -0800	Archive
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: WineLib apps use a .spec file to define a normal PE header, complete with resources and imports and main entry point (the special LIBRES hack dies; winestub is no longer necessary) the main Wine executable does the same, in effect it becomes itself just a normal WineLib app initialization of the initial thread/process shares much more code with initialization of other threads, to remove special cases and possible differences in 'environment' In fact, implementing this last point even fixes some bugs in the current WineLib setup: WineLib apps were always marked as 16-bit processes in the PDB and TEB flags settings (influencing e.g. SendMessage() ...) WineLib apps were not executing on the correct thread stack (leading to problems with exception dispatching) the wine debugger now works in WineLib as well 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.

Merging wine and winelib startup code

18 Jan 2000 00:00:00 -0800

World Wine News