All the news that fits, we print.
This is the 334 issue of the Wine Weekly News publication. Its main goal is to introduce the new AppDB Status changer. It also serves to inform you of what's going on around Wine. Wine is an open source implementation of the Windows API on top of X and Unix. Think of it as a Windows compatibility layer. Wine does not require Microsoft Windows, as it is a completely alternative implementation consisting of 100% Microsoft-free code, but it can optionally use native system DLLs if they are available. You can find more info at www.winehq.org
This week, 140 posts consumed 227 K. There were 63 different contributors. 26 (41%) posted more than once. 0 (0%) posted last week too. The top 5 posters of the week were:
|
News: Wine on the Linux Desktop | Archive | |
---|---|---|
Wine on Linux
As you may have read the Annual
Linux Desktop Survey Results
are in for the year. There's the usual bit
about what browser people use and their favorite distribution. However, the
folk over at linuxdesktop.com
have also
included some interesting information on how people run windows applications
on Linux. Their results can be summed up with the following text and chart:
Of those that do, many turn to Wine (Wine Is Not an Emulator ), which runs the
Windows API (application program interface) on top of Linux. More than 44
percent use Wine for their Windows applications needs.
I suspect that many Wine users actually use Wine with the help of programs
that makes deploying Windows applications on Linux easier. However, of the two
most important of these programs, Cedega, which specializes in running Windows
games on Linux, and CrossOver, which focuses on Windows business and
productivity applications, only 6 percent of our survey respondents said they
used Cedega, while even less, 5 percent, said they used CrossOver.
In a separate
article
, desktoplinux's Steven Vaughan-Nichols also highlights how Linux
users feel about applications:
Given a choice of applications to run on their Linux desktops, most users
would prefer to run a native Linux application rather than a Windows
application. In particular -- Adobe take note -- Linux users continue to
really want Linux versions of Adobe's Photoshop and Dreamweaver. These were
numbers one and three on the Linux users' Windows application migration wish
list. Autodesk's AutoCAD was number two.
If Linux users can't run a particular application on Linux, and there's no
native program that gives them similar functionality, they're almost perfectly
divided between three different methods to get them their required program.
These are using WINE, or a software built on WINE, such as CrossOver Linux, to
run the Windows application in Linux; virtualization; and switching to a
browser-based application, such as Google Docs.
|
Wine Review Blog | Archive | |
---|---|---|
WineReview
Tom Wickline has begun a "Wine-Review" blog . He writes about his experiences trying every windows application he can find on as many different platforms he can find.
The goal of the blog is to post about Wine (and to help people) on any x86 operating system that Wine will run on e.g Linux, BSD, X86 Mac, and even Solaris ... The goal of the Forum is to provide a place for people who are interested in Wine to meet and collaborate about their favorite applications and games. And to be a source for help and suggestions. Tom's blog has done very well thus far; he's quoted to me that he estimates nearly 100,000 hits per month. He is also seeking contributors to his blog. I plan to seek other contributors to the blog as well..... I can't own every Office app or Game out there and I currently don't own an Intel Mac. And what's surprising to me is I received well over 2500 hits from people who run Intel Macs last month, even tho I don't currently post about Wine on that platform. |
DIB Engine Status | Archive | |
---|---|---|
DIB Engine
The DIB (Device Independent Bitmap) engine is one of the few remaining "large" issues that in general the community believes needs to be implemented. The only issue with that is that implementing the DIB is actually very difficult. At present WINE gets around having a DIB engine by translating the calls into something X can handle, lets X do the legwork and then translates the results back. This is for the most part an effective solution, however it's known to be inefficient and not without its problems. Alexandre Julliard has expressed the opinion that implementing a proper DIB engine will likely be done post 1.0. See the wiki page on DIB for more information. In light of all this, Piotr Maceluch writes in to find out the current status of the DIB Engine.
Hi, what's the status of DIB engine (or where can one read about it)? Are the
up-to-date sources still available? What kind of help would be needed?
Thanks Jesse Allen writes in with the status of his project:
If you are talking about my project, it is still available, and I
merged up to a recent git snapshot two weeks ago.
http://repo.or.cz/w/wine/dibdrv.git
I can't promise too much until after finals. I'm going to work on it
and finish the image support during my break. Finishing the image
support and proper forwarding of the missing stuff is probably what is
needed to get it merged into wine.
If you need to have it merged up again, I will do that. If you want to
start hacking on it, pretty much any of the stubs you can work on.
|
AppDB Switches to AGPL | Archive | |
---|---|---|
Licensing
Alexander S generated a bit of discussion a couple weeks ago when he
introduced a change in the AppDB's license to the AGPL. Of course a change of
license like this requires the approval of all authors involved and so the
list asked all authors for consent; it appears all confirm.
Trent Waddington kicks it off recognizing that all authors need to approve:
Interesting. Do you have a list of contributors and their signoff on
this license change?
Alex then agrees, and asks all co-authors to confirm
Well I didn't think that was necessary; but after some thought I realize that
the AppDB only seemed to include a LICENSE file containing the GPL v2, while
a GPL/AGPL v3 change would require previous code to be licenced under 'GPL v2
or later'.
So I'm including the other authors in this mail to see if they agree, or have
already licenced their code under GPL v2 or later
Sorry for all the mess, but legal stuff isn't really my thing. :)
One by one they give permission:
Chris Morgan:
For those of you who appreciate such a thing, the following is the key
difference between the GPL and AGPL (from
affero.org
)
Section 2(d) reads as follows: " If the Program as you received it is intended
to interact with users through a computer network and if, in the version you
received, any user interacting with the Program was given the opportunity to
request transmission to that user of the Program's complete source code, you
must not remove that facility from your modified version of the Program or
work based on the Program, and must offer an equivalent opportunity for all
users interacting with your Program through a computer network to request
immediate transmission by HTTP of the complete source code of your modified
version or other derivative work."
|
New valgrind reports | Archive | |
---|---|---|
Valgrind
Getting sick of having to run reports by hand, Dan Kegel writes in with information about his new valgrind script. Valgrind is a profiling tool used to help track memory leaks. Wine developers regularly check for leaks and make all possible efforts to keep them to a minimum. I finally got tired of doing "history | grep diff" etc, and partially automated the daily valgrind run; the resulting script is at http://kegel.com/wine/valgrind/valgrind-daily.sh
The results are now in directories named like To look at what changed since yesterday, start by looking at the day's summary file. In it, there's one line per test, followed by the changes in that test's results, if any.
Lines that start with + indicate new problems (boo);
For example, in today's summary, Of course, while the new script is nice, it also has its kinks and there are things Dan would like to see improved/changed. I'll try to keep running this script daily, but it'd be nice if somebody else took over (and possibly even increased the automation; I still have to do git pull, run the script, and upload by hand.)
It doesn't help that valgrind only works well on some machines,
but hey, what's life without challenges.
|
Default Homepage in IE on WINE | Archive | |
---|---|---|
shdocvw.dll
On a bit of a lighter note there was some discussion on what WINE should set as its default homepage in IE. It all began with the a patch from Jacek Caban which sets the default homepage to winehq.com However, Aric Stewart was quick to point out the problem with the patch. I see that the native shdocvw sets neither the Start page nor the Search page when registered. This patch forces the users home page to initially be www.winehq.com which can be confusing to IE users who are expecting the normal default of msn.com
While amusing I do not think this is correct. Steve Edwards writes in to second that opinion. Plenty of OEMs change the default IE home page, and we should make it easy to do so in Wine. I think an edit box in winecfg is the best route to go with the default option being about:blank or www.winehq.org
Thanks Jacek Caban tries to clarify the issue with his reasoning behind the patch in the first place. Native shdocvw.dll doesn't support self registration at all and its registration is done by IE installer IMO. If we want to be compatible with native, we'd have to move everything from shdocvw.inf to wine.inf (and that's not the way to go IMO). I've added these registries because an app I've been working on expected default search page to be present. Also we should use it in our InternetExplorer and WebBrowser implementation. We may consider handling these keys like we do with the IE version key. That is, they may be added on iexplore.exe registration. If one wants to install native IE, he has to unregister iexplore.exe first, removing the homepage. Then IE installer will probably set its default homepage. Aric refutes: Humm, maybe I am confused but (at least the win98 version of) shdocvw.dll implements DllRegisterServer which seems to do a lot of stuff. But Setting the Start Page is not one of them. In my experience installing IE does not actually set a Start Page by default, but instead the browser seems to handle not having a Start Page by pulling up a default one. Jakek writes: I've checked it again and it looks like shdocvw registers only its typelib, nothing else like coclasses. I will do more testing later today. |
Wine Benchmarks | Archive | |
---|---|---|
Wine
In addition to the monumental task of implementing and replicating native behavior of the Windows API, WINE has to also do it with near-native speeds. Phoronix has recently Benchmarked a series of different wine versions. Their results are indeed interesting and highlight the importance of remembering both of the goals WINE strives to achieve, compatibility and efficiency. Jonathan Ernst writes in to link wine-devel to the article
Hello,
"The performance in the fourteen 3DMark 2001 SE and 3DMark 2003 tests
were fairly consistent in the releases between WINE 0.9.44 and WINE
0.9.50 -- generally only swaying a few frames in either direction --
though the performance overall has slightly declined and we were
surprised by a few of the results."
I guess it's linked with http://bugs.winehq.org/show_bug.cgi?id=10631
Stefan Dosinger's take on this issue:
No, it doesn't look like they are hit by the 3dmark2k1 bug, which is strange.
They are hit by the stencil test slowness in 3dmark2k3 though, which we
resolved as a driver bug on geforce 8 cards, since we couldn't reproduce it
elsewhere. Bryan Haskins thinks it's an 8-Series: Phoronix often uses the 8 series cards when not testing things like driver versions, we can probably assume they did use an 8 series. So the issue of why Phoronix obtained such odd results in .49 and .50 remains. This is a good time however to discuss the bug mentioned originally by Jonathan Ernst. Indeed, this bug, related to a patch by Stefan Dosinger, seems to have stirred the hornet's nest of late. The patch fixes some graphical glitches but introduced a couple cases in which performance was severely crippled. Stefan however is working hard to fix these cases. In reference to the same patch, Stefan writes : This patch caused quite a few similar regressions, I fixed one of them before the .50 release, and another one afterwards, so you might want to give the current git code a try. However, there is at least one (not yet known) situation left where shaders recompile all over. |
AppDB Application Status Changes | Archive | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
AppDB
*Disclaimer: This list of changes is automatically generated from information entered into the AppDB. These results are subject to the opinions of the users submitting application reviews. Even if an application is upgraded to 'Gold' or 'Platinum' in this list, the Wine community cannot guarantee that you will have the same experience and would provide a similar rating.
Updates by App Maintainers
Updates by the Public
|
All Kernel Cousin issues and summaries are copyright their original authors, and distributed
under the terms of the
GNU General Public License,
version 2.0.