Wine Traffic #83 For 19�Feb�2001
Table Of Contents
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:
- 16 posts in 54K by Alexandre Julliard <email@example.com>
- 11 posts in 36K by Jon Griffiths <firstname.lastname@example.org>
- 9 posts in 34K by Patrik Stridvall <email@example.com>
- 6 posts in 36K by David Elliott <firstname.lastname@example.org>
- 6 posts in 34K by Ian Pilcher <email@example.com>
- Full Stats
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
- Several PostScript driver improvements.
- Improved enhanced metafiles support
- Beginnings of PowerPC support
- Lots of bug fixes
Novell and Wine
Archive Link: "Novell filesystem support"
Simeon Pilgrim,�G�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
However, the read/write operations explained by Simeon are really the
core of the problem as G�rard Patel reported that:
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.
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
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.
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
Various Configurations for various applications
Archive Link: "various config files for various applications"
Martin Pilka,�Jonathonm Griffiths,�,�Jon Griffiths
Martin Pilka asked:
Jon Griffiths raised some potential issues regarding the current code:
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:
[wine] - because of path variable, some
programs want to have something specific there
[x11drv] - for example something runs better
in managed mode, something not
- I'm not quite sure about [fonts], [spooler]
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
. 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
Martin liked Jon ideas but felt they went far beyond what he intended
to do. After some more thinking, Martin made another proposal:
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
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.
Anyway, all the details haven't yet settled down, so don't hold your
breath for this feature...
After discussion we discovered quite big lack of this (EdNote:
) 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
), one configuration per file. Each
file will contain an entry which determines its validity,
e.g. "Filename" = "homesite*.exe". Then there will be the
section and maybe some others.
This breaks wine configuration into two pieces: application
independent part (stored in
drives, paths and all other independent stuff) and application
dependent part (stored in
On startup wine will load
and pass through
files stored in
directory. The first
match against regular expression defined in these files (Filename=...)
causes to overwrite some sections from
The advantage is much easier maintenance. The disadvantage could be that
you can't see the whole configuration in
file anymore - some settings could be overwritten by optional file in
alloca() or not
Archive Link: "Eyes requested"
Jonathonm Griffiths,�Patrik Stridvall,�Alexandre Julliard,�,�Patrik Stridval,�Jon Griffiths,�Ian 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
Patrik Stridval (in this
) made the discussion a bit deeper:
alloca(). It screws up exception handling
because it messes with the stack, and is machine dependent. Maybe
LocalAlloc() would be a better choice?
Jon put up a list of down-sides of
The general problem with using
is that not all
, 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
That said Alexandre has at least once rejected patches from me that
, so he doesn't seem to like it. I don't
remember him saying why though.
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
alloca() may go a bit faster, like in
buffer[siezof(buffer) - 1] = '\0';
which would mean using several guard pages...
Alexandre Julliard expressed his disregard about
If you know that the allocation will be small you don't need
and also gave some indications on the stack usage (on Linux)
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.
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
Archive Link: "process.h patch"
Alexandre Julliard,�David Elliot,�Jonathonm Griffiths,�Francois Gouget,�Gavriel State,�,�Jon 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
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 and
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
I had thrown in the idea of being able to prefix the msvcrt functions
with something like
Jon also pointed out that
MSVCRT_ and then linking against a
library which forwarded the
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.
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
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
Francois Gouget also got a look at the patch:
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
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.
it would be good to
acknowledge their contribution and let them know their modified code is
Gavriel State jumped into the discussion with some legal arguments:
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.
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
The court in that case said:
Computer programs pose unique problems for the application of the
"idea/expression distinction" that determines the extent of copyright
protection. To the extent that there are many possible ways of
accomplishing a given task or fulfilling a particular market demand,
the programmer's choice of program structure and design may be highly
creative and idiosyncratic. However, computer programs are, in essence,
utilitarian articles -- articles that accomplish tasks. As such, they
contain many logical, structural, and visual display elements that are
dictated by external factors such as compatibility requirements
and industry demands... In some circumstances, even the exact set of
commands used by the programmer is deemed functional rather than
creative for the purposes of copyright. When specific instructions,
even though previously copyrighted, are the only and essential means
of accomplishing a given task, their later use by another will not
amount to infringement.
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
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.
Archive Link: "Speeding up wineserver synchronization objects with shared memory"
Gavriel State,�Alexandre Julliard,�,�Ove Kaaven,�TransGaming
Gavriel State opened up an optimization workshop:
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
However, Alexandre Julliard didn't like the approach:
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
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:
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 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.
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.
Sharon And Joy