Wine Traffic #65 For 16 Oct 2000
Table Of Contents
Introduction
This is the 65th 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 88 posts in 280K.
There were 30 different contributors.
17 posted more than once.
20 posted last week too.
The top posters of the week were:
- 8 posts in 32K by Patrik Stridvall <ps@leissner.se>
- 8 posts in 29K by Uwe Bonnes <bon@elektron.ikp.physik.tu-darmstadt.de>
- 7 posts in 16K by Ove Kaaven <ovehk@ping.uio.no>
- 7 posts in 14K by Marcus Meissner <marcus@jet.franken.de>
- 6 posts in 19K by Alexandre Julliard <julliard@winehq.com>
- Full Stats
1.
Headlines
People:
, codeweavers, Martin Pilka
2.
Wine press
9 Oct 2000 - 10 Oct 2000
(4 posts)
Archive Link: "Wine press"
People:
Jeremy White, CodeWeavers, , Francois Gouget
Following last week discussion on Corel and Microsoft deal, Paul E.
Merrel posted another article on the subject: a
Linux world article reports on Corel's Rene Schmudt (executive VP
of Corel's Linux product group) on Wine and .NET from a Corel point of
view.
Later on, Paul also posted a LinuxPlanet article where Wine
development was discussed, with good parts from Jeremy White (CodeWeavers CEO)
http://www.linuxplanet.com/linuxplanet/opinions/2439/1/
Jeremy felt the need
to briefly 'adjust' an
impression that this may have left about something I said to Kevin
(
EdNote: the LinuxPlanet's article writer).
I
personally care more about Winelib than about Wine, and I think
Winelib is more relevant to my customers, particularly here in the
U.S., where paying for VMWare or Win4Lin isn't that much of a barrier
to my potential customers.
I don't speak for the personal goals of the rest of the CodeWeavers
team, many of whom care passionately about the Wine loader. Further,
we're making a major effort to boost Wine as a whole (in fact, prior
to Francois's (
EdNote: Francois Gouget) work, all of what we
did served to help Wine as a whole as opposed to Winelib). Finally,
I'm actually very excited about the progress of Wine (I was just
disappointed - I had hoped to show off some cool new 1.0 stuff to
Kevin, but the demos didn't work out).
I'm just the nutty kind of geek who gets more of a thrill out of
watching 500,000 lines of Windows code compile than I do out of
watching Starcraft run <g>.
3.
Directory access modes
12 Oct 2000
(6 posts)
Archive Link: "Dir readonly problem"
People:
Rein Klazes, Francois Gouget, , Uwe Bonnes, David Elliot, Rein Klaze
Rein Klazes proposed a patch for the following issue he had:
A winrar self extracting archive, created a read-only dir and tried to
unpack the archive into that dir. Unfortunately readonly for dirs
means quite different things, in dos/win the directory is protected
from deleting, in unix you cannot create new files in it.
Rein then proposed a simple fix: not to create the directory with read
only attribute, but this triggered a few comments.
David Elliot proposed another solution: the directory would be created
read-only, and any file operation on this directory would imply a set
of operations (set the dir attribute to writable, do the file
operation, reset the dir attributes to their original state). This
should also be done in an atomic way, involving dir locking/unlocking.
However, portability of such a solution across all known Unix file
system would certainly raise lots of issues (like chmod on a FAT
system).
Some other people suggested, like Uwe Bonnes, suggested implementing
the tricks on the wine server side. But this wasn't a good suggestion
either.
Francois Gouget had the final word, stating that Rein's first proposal
was in fact the correct solution:
All the solutions that have been discussed on wine-devel are too
complex and flawed at the root because of the semantics difference:
FILE_ATTRIBUTE_READONLY applied to a directory means 'make it so this
directory cannot be deleted'. This is impossible to do in Unix (except
on systems that support ACLs).
Francois even tested the same type of operation using Samba, and the
Windows read-only directories were created with read-write attributes.
David Elliot agreed with Francois latest proposal. The only remaining
solution shall be based on ACL, but is another magnitude of complexity.4.
Graphics optimization
12 Oct 2000 - 15 Oct 2000
(21 posts)
Archive Link: "optimization using assembler"
People:
Mark Dufour, Eric Pouech, Ulrich Weigand, Patrik Stridvall, , Huw Davies, Patrik Stridval, Mark
Mark Dufour, after reading the benchmark results (see
BROKEN KCREF),
wondered if windows does many of the
involved operations so much faster than wine because of x86
optimizations. Wouldn't wine run much faster in many areas if
assembler equivalents were written for critical operations, for
different processors ? I understand that some maintenance problems
would result from this...
Eric Pouech gave a quick overview of the situation:
Results from the benchmark are also slow because:
- benchmark mostly stresses the graphics API
- Wine's graphic APIs are known to be slow (overlay on top
of X11; no rendering engine per se)
I doubt assembly would
help (unless we build our own rendering engine)
Mark get lurking around to find some possible improvements and asked
whether the coordinate computation code according to the DC mapping
could be optimized: since MM_TEXT is a widely used mapping mode, and
there's no need to rescale the coordinate, just change the origin,
Mark noted that lots of computation were not useful.
Patrik Stridvall proposed a way to code this, based on the fact that a
mapping shall be constant across a graphic operation call (like
LineDraw), so different paths doing only the requested conversions
according to the mapping could be implemented.
Ulrich Weigand wasn't sure this would bring some speed (had to be
tested), but rather suggested to update the coordinate conversion
macro with Patrik's proposal and let the compiler do the rest of the
job with common subexpression elimination (in this case applied to the
mapping testing). He also didn't like Patrik's code duplication
because:
But I was rather trying to search for a solution that affects
maintainability of the code as little as possible, while still
offering as much performance improvement as possible.
Generally, the problem with performance optimizations is that they
tend to make the code less maintainable, by introducing code
duplication, special cases, even things like inline assembly etc. At
least in the current state of Wine, I tend to think maintainability
more important than performance ...
- no modification needed
- translation applied
- translation and scaling applied
- world transform
and would directly call the right function, hence reducing the cost of
comparison in the functions.
However, Patrik agreed that Premature optimization is
the root to all evil"
and wondered if we
should wait with these kind of optimizations until after Wine
1.0.
5.
Another Explorer project
15 Oct 2000
(2 posts)
Archive Link: "GXExplorer Open Source Project"
People:
Paul E. Merrell, Juergen Schmied,
Paul Merrell reported a another open source effort around Windows
basic software:
Just ran across the EXExplorer open source project, which is
developing a Delphi-based replacement for the Windows Explorer and
file manager on the Windows platform.
http://gexperts.com/GXExplorer/contents.html
. I don't remember seeing it mentioned on this list before.
Y'all will know far better than me whether that project might
complement the Wine effort, but it occurred to me that there might be
some expertise there that might be useful to you.
It's just one more program what can be used with wine. I don't think
we are trying to supply a set of applets to replace the windows ones
since all of these are already available as native applications. I see
the focus of the wine project (exe-loader part) more in supplying a
possibility for executing games(joe user) and special customer
applications (corporate user).
The GXExplorer works quite good with wine but you have to use some
native dll's since it's using quite a bit of the ole stuff. Last time
I tried (some months ago) I had to use ole* dlls and many registry
keys from a native windows. This program is a good test for the build
in shell32, comctl32 and ole* since it uses many advanced features.
Sharon And Joy