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 #83 For 19 Feb 2001

By Eric Pouech

Table Of Contents

Introduction

This is the 83rd 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).

Mailing List Stats For This Week

We looked at 116 posts in 453K.

There were 41 different contributors. 22 posted more than once. 24 posted last week too.

The top posters of the week were:

1. Headlines

 

People:

Wine 20010216 has been released. Main changes include:

The mail server at WineHQ (sendmail) ran into lots of issues during this week-end. Lots of incoming emails have been bounced out. This turned out to be issues related to some non-answering MTA, which filled to opened connections pool, hence starving the server network resources. Anyway, it has been decided to move to exim, which shall be more robust in this area. Sorry for the inconvenience, and don't hesitate to repost your mails if they don't appear on the mailing-lists.

2. Novell and Wine

12 Feb 2001 (7 posts) Archive Link: "Novell filesystem support"

People: Simeon PilgrimGérard Patel

Simeon Pilgrim started some hacking of Wine to help using the Novell networks (for previous discussions on issues raised by integrating a remote filesystem you can read BROKEN KCREF regarding Samba). Simeon main goal is to let the Pegasus mail reader work in a configuration well the user's mailbox sits on a remote (Novell mounted) filesystem.

Simeon started by fixing the bindery stuff (by rewriting some DLLs), but ran into issues with file permissions:
It's the file create/read/write thats not working. I put a bit of code into file.c:CreateFileA so the UNC files that are on our server get remaped to w:/ files ( where w:/ is a ncpmounted novell directory on my linux box ) so that the normal dos functions should work. Most things work, ie I can see my mail folders but not new mail, ( pegasus email uses single files per new mail, and a index/data pair of files for mail folders ). Also when I try send email to locate users the mail does not get sent for read/write errors. This is because local mail delivery is done by the client program, by writting into the users maildir. How this is done is under novel you can Create files in directories that you cannot see (if that permission is granted to you). But you can't do this under unix. So the need to implement file i/o for novell files arises.

However, the read/write operations explained by Simeon are really the core of the problem as Gérard Patel reported that:
I have my news messages with a reader working under Wine stored on a 4.10 file server since years. It's not exactly fast but I have yet to lose data.

Gérard also suggested to
give the Scan file right to the user. Certainly more simple, and this is not a very serious security breakage IMO.

Simeon answered
I've just asked for this on my user acc. so i'll see how it works. I still would like the other method, as a general idea the admin was not keen for everybody to be able to scan the mail directory.

Really sounds like Wine will need in a near future to really tackle this issue about filesystems, when the underlying layer is not rich enough to provide all the required semantics. But this is another large project.

3. Various Configurations for various applications

11 Feb 2001 - 18 Feb 2001 (4 posts) Archive Link: "various config files for various applications"

People: Martin PilkaJonathonm GriffithsJon Griffiths

Martin Pilka asked:
I know it was already at least mentioned here - how to provide config file that works without change for more than one application. What do you think about this concept?

The changes to config file are relevant to some sections only. I think these are important:

So probably we need to make these sections application dependent. when we parse the config file we don't have a lot information about the application we're going to run - in fact the file name only. Anyway that's probably enough. So maybe we could add the new optional sections like [x11drv-homesite*.exe]. The string after "-" sign could be an case insensitive regular expression. When some of this x11drv optional sections match the condition about its filename, it's taken and no more x11drv sections are considered. If not, the default non-optional x11drv section is taken.

I think we shouldn't follow some "inherit" concept because it could dim things a lot. Simple "this and only this section is valid" should be enough.

Jon Griffiths raised some potential issues regarding the current code:
The problem here is the server. I notice that if you start one application with --managed, all applications started afterwards also get this set, if the server is still active when they start.

I think the server should store its preferences in a process specific area that can be set per-process (but by default would use the .wine/config setup). Everything else should be overridable on the command line, perhaps?

One nice thing about this would be the ability for a (gui?) wine utility to read and change those defaults for a process using server calls. Debug messages could be turned on/off, for example, while the server is still running. Being able to browse the servers process/thread tree, attach a debugger externally etc could also useful.

This would require a small set of 'server browser' calls to be made available, and the current global preferences such as tweak_winelook to be held by the server. However, its a fair bit of work, and unlikely to happen in the immediate future AFAICS.

Martin liked Jon ideas but felt they went far beyond what he intended to do. After some more thinking, Martin made another proposal:
After discussion we discovered quite big lack of this (EdNote: first) model: maintenance. The config file could easily exceed any reasonable size, and that is something we probably don't want (wine-users: send your config file...).

So here is the revision: Application specific config information could be stored in separate directory (let's say ~/.wine/app-config), one configuration per file. Each file will contain an entry which determines its validity, e.g. "Filename" = "homesite*.exe". Then there will be the [DllOverrides] section and maybe some others.

This breaks wine configuration into two pieces: application independent part (stored in ~/.wine/config, contains drives, paths and all other independent stuff) and application dependent part (stored in ~/.wine/app-config, contains things like [DllOverrides]).

On startup wine will load ~/.wine/config and pass through files stored in ~/.wine/app-config directory. The first match against regular expression defined in these files (Filename=...) causes to overwrite some sections from ~/.wine/config.

The advantage is much easier maintenance. The disadvantage could be that you can't see the whole configuration in ~/.wine/config file anymore - some settings could be overwritten by optional file in ~/.wine/app-config.

Anyway, all the details haven't yet settled down, so don't hold your breath for this feature...

4. alloca() or not

11 Feb 2001 - 12 Feb 2001 (2 posts) Archive Link: "Eyes requested"

People: Jonathonm GriffithsPatrik StridvallAlexandre JulliardPatrik StridvalJon GriffithsIan Pilcher

While reviewing a patch posted by Ian Pilcher, Jon Griffiths opened another can of worms:
I don't know anything about the Win32 print API, but style wise I tend to stay away from alloca(). It screws up exception handling because it messes with the stack, and is machine dependent. Maybe LocalAlloc() would be a better choice?

Patrik Stridval (in this mail) made the discussion a bit deeper:
The general problem with using alloca is that not all platforms supports alloca, however I think all reasonable platforms that has enough power to support Wine is likely to have it so I don't see any real reason not to use it.

Currently Wine uses it indirectly since the files generated by flex/bison uses it.

That said Alexandre has at least once rejected patches from me that used alloca, so he doesn't seem to like it. I don't remember him saying why though.

Jon put up a list of down-sides of alloca() use. Patrik discusses them a bit, mainly arguing around the links between alloca and the guard page at the end of the stack (which is used to grow the stack when read/write is done to it). However, most stack manipulation is done in an increment by one machine-word way, whereas alloca() may go a bit faster, like in
void foo(void)
{
	char buffer[10*PAGE_SIZE];
	buffer[siezof(buffer) - 1] = '\0';
}
which would mean using several guard pages...

Alexandre Julliard expressed his disregard about alloca():
If you know that the allocation will be small you don't need alloca(), you can use a constant-size buffer. And if you don't know the allocation maximum size you cannot use alloca() either because it may crash. So it doesn't buy anything and introduces potential portability problems.
and also gave some indications on the stack usage (on Linux)
the stack space is limited to 1Mb per thread (unless the application changed the defaults); it's not very tight, but it still means we cannot allocate arbitrary-sized data.

So, the final words are: thou shalt not use alloca().

5. Headers' copyright

12 Feb 2001 - 15 Feb 2001 (10 posts) Archive Link: "process.h patch"

People: Alexandre JulliardDavid ElliotJonathonm GriffithsFrancois GougetGavriel StateJon Griffiths

Jon Griffiths did post a while ago a patch to enhance the msvcrt headers. However, he didn't get any news from it, so he asked from feedback.

The issues with mixing standard C libraries headers (from the Unix world) with the Windows' ones is a favorite wine-devel's discussion topics. See BROKEN KCREF, BROKEN KCREF, BROKEN KCREF and BROKEN KCREF.

Alexandre Julliard replied
I was hoping to get some feedback from the winelib experts out there on whether this is better than the approach with macros suggested by David.

David Elliot gave some more explanations on the impact of the MSVCRT_ prefix:
I had thrown in the idea of being able to prefix the msvcrt functions with something like MSVCRT_ and then linking against a library which forwarded the MSVCRT_function to MSVCRT.DLL.function. Thus using MSVCRT_function in the program would use the MSVCRT implementation, and using just function in the program would use the normal libc function. The idea behind this was the some source files could include header files which #defined function MSVCRT_function, other source files could include normal libc headers. Thus the references are set during compile time and not link time and also would allow you to essentially link to an MSVCRT and a libc within the same program if desired.

Jon also pointed out that
with the @ignore directive in your .spec, it is now possible to link with msvcrt and optionally have individual functions resolved to libc
even this has to be set for a whole DLL and not on a per function call basis like David's solution allows.

Jon and Alexandre Julliard also discussed on how Wine core file (starting with MSVCRT DLL) should use those macros. Unlike Jon, Alexandre was really in favor of using the new headers, so that
they will then automatically get tested by anybody compiling Wine; while with the other approach they only get tested by people compiling Winelib apps, i.e. just about nobody <grin>

Francois Gouget also got a look at the patch:
The headers look pretty good and as they are an important part of Winelib I would really like to see them get into CVS. But there's one thing to absolutely do first.

In your email you say "I took the rsxnt headers as a base since they are very uncluttered, and also released without copyright". Well, that's a big problem because if there's no copyright and no license information then we cannot use them, at least under US law. So you/we need to find the author(s) of these headers and get their authorization to use their headers and to release them under a license compatible with the X11 license. I see that a google search on rsxnt seems to give good results so at least contacting the authors should be quite feasible.

Jon later on replied that the project which created the headers had given away their copyright (there's a notice in the header files). However, Jon admitted
it would be good to acknowledge their contribution and let them know their modified code is being used.

Gavriel State jumped into the discussion with some legal arguments:
While Jon has addressed this issue in regards to the MSVCRT headers, this might be a good time to point out that the legality of enforcing copyright on header files through licensing restrictions is questionable.

I'll preface this with the usual mention of the fact that I am not a lawyer, nor do I play one on TV. Please consult a qualified professional before taking action on anything I've written.

Copyright law does not protect idea, just the expression of them. Several court decisions have been rendered which suggest that the 'purely functional' elements of a computer program are not copyrightable. There are several cases that explicitly deal with the issue of copyright and header files. The most relevant one for Wine development is probably the 1992 decision in Sega v. Accolade, where Accolade reverse engineered the headers for Sega's ROM libraries in order to develop games compatible with Sega's hardware without paying Sega's royalties. ( http://www.eff.org/pub/Legal/Cases/sega_v_accolade_977f2d1510_decision.html") The court in that case said:

Since Wine absolutely requires the specific header file layout, structure and function names, etc to be the way the Windows headers express them, there is good cause to believe that the header files are unprotected by copyright.

In fact, development tool licenses that attempt to restrict usage of these headers may even constitute anti-trust copyright misuse. Early versions of MS Visual C++ contained a shrinkwrap license that forbade the use of the product to create software for platforms other than Windows. Later revisions (ie: SP3) removed that restriction, so perhaps MS realized that this was not protectable.

One fly in the legal ointment is that while the headers may not be copyrightable, the shrinkwrap license may still be legal as a contract. There's a case where a court suggested that someone who buys a copy of a product that contains a shrinkwrap license agreement and unwraps it is legally bound to follow it, while the person who later finds the unwrapped CD 'on the street' with no such license is allowed to copy the portions that are unprotected by copyright. It's unclear where the anti-trust issue fits in there.

Some further arguments went further (like on applicability of those issues in Europe and so), but the final word seems to be that it seems rather safe to reuse native headers contents, at least on a pure interface point of view, hence removing all the attached comments.

6. Wine speedup

15 Feb 2001 - 18 Feb 2001 (5 posts) Archive Link: "Speeding up wineserver synchronization objects with shared memory"

People: Gavriel StateAlexandre JulliardOve KaavenTransGaming

Gavriel State opened up an optimization workshop:
We've recently been working on getting American McGee's Alice (a visually stunning game, if you haven't seen it before) running well under Wine, and we've run into a serious speed issue with synchronization objects like Mutexes.

Currently, Alice runs at about 50% the framerate it gets in Windows with the same graphics driver (NVidia). When we started investigating, it turned out that the reason for this is that it's spending half of it's time in the WineServer. At first we assumed that this was due to the fact that the GL thunks need to grab the X11 lock. We realized that this wasn't necessary for most GL calls if we're using a direct rendering GL implementation, and turned off the locks. There was no effect - because there really wasn't much contention for the x11 lock.

After going through a number of similar Wine internal possibilities and getting nowhere, we finally realized that the problem was the app itself. It's grabbing and releasing a mutex of it's own bazillions of times each frame. Since there's nothing much we can do about that we started thinking about the proposed linux kernel module (EdNote: BROKEN KCREF) approach. After re-reading the thread and looking over the prototype, I have to concur with Alexandre's judgement - the prototype that exists is trying to do too much work.

Gavriel and Ove Kaaven then proposed, instead of letting the Wine server do all the job (and getting invoked for each operation on the mutex), to cope with the easy part on the application side. This would use a shared memory section across all the processes (because a handle can be shared across processes, hence in different address spaces), and try the lock operation on the server side. If the lock fails (some one already has the lock), then the wait operation shall be done in the server.

However, Alexandre Julliard didn't like the approach:
I don't see how you are going to make this work reliably. A basic design principle of the server is that no matter what a client process does, it cannot break either the server or other clients; given the number of bugs Windows apps contain, I feel this is very important.

As soon as you introduce a shared memory area, you need the collaboration of all clients to ensure the stability of the whole system, since any client can corrupt system data structures. This is very bad. Also since the server is single-threaded its data structures don't need to be protected; but as soon as you manipulate them from multiple threads you need locking mechanisms, which will probably cost a lot in performance too.

Gavriel tried to minimize the impact of such a modification, and thought that a real kernel module would be the only solution to provide both reliability and speed. However, this sounds beyond the current scope what Gav wanted to achieve, and this looked for an acceptable solution in user-space.

But nothing seemed to come out, at least in a way that satisfies Alexandre's requirements. However, the TransGaming folks may provide a solution on their own which is sufficiently available to run at full speed some games.

 

 

 

 

 

 

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.