Table Of Contents
|1.||3 Jan 2003 - 20 Jan 2003||(1 post)||News: Distribution Review|
|2.||3 Jan 2003||Direct 3D Status|
|3.||29 Dec 2002 - 5 Jan 2003||(20 posts)||Conformance Testing|
|4.||4 Jan 2003||(1 post)||wxWindows Port Completed|
|5.||6 Jan 2003 - 7 Jan 2003||(6 posts)||Fun Projects Update|
|6.||8 Jan 2003 - 10 Jan 2003||Compiling With distcc|
|7.||4 Jan 2003||(5 posts)||MacOS X + Bochs + Wine = Wish List|
This is the 152nd 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 454 posts in 1374K.
There were 85 different contributors. 49 posted more than once. 36 posted last week too.
The top posters of the week were:
1. News: Distribution Review
3 Jan 2003 - 20 Jan 2003 (1 post) Archive Link: "News"
People: , DesktopLinux, News
Over at DesktopLinux.com there's a review of several desktop (http://www.desktoplinux.com/articles/AT9485255756.html) operating systems. If you skip to the last page you'll find a discussion of several Linux distributions (http://www.desktoplinux.com/articles/AT8266871610.html) , some you may never have heard of before. The notable Wine reference discusses using CodeWeaver's CrossOver Office with the ELX distribution. Sadly, the author doesn't mention Wine at all.
2. Direct 3D Status
3 Jan 2003 Archive Link: http://www.winehq.com/hypermail/wine-devel/2003/01/0.html
Topics: Status Updates
People: Lionel Ulmer, Jason Edmeades, , Christian Costa
There's been a lot of work on Direct 3D lately and it hasn't gotten much attention here - mostly because the changes haven't been controversial. Over the past month there's been almost 100 patches submitted on various parts of Wine's Direct 3D. They've come from primarily from Lionel Ulmer, Jason Edmeades, Christian Costa, and Raphaël Junqueira. So I asked Lionel about the work and how it's going. Below are questions asked by me and answers from him.
What exactly is the status of Direct 3D (v. 1-8) in Wine?
The status is that D3D 1-7 is mostly complete. One big stuff remaining to be done is direct surface operation for the D3D device (locking, blitting, ...). The rest are only optimisations or optional features (like multi-texturing). A lot of other stuff would remain to be done but we did not find yet any game using them, so we consider them unneeded to be implemented (yet :-) ).
What's some of the new stuff that's really important?
All the support for the various types of DrawPrimitive (non-indexed, indexed, via a vertex buffer, ...). The rest was already here before the start of the revival, just a lot less clean.
Does it affect D3D8?
Not at all.
Some other folks have been working on it too, have you been coordinating with them?
Yup. I am in regular contact with two other French guys (one, Christian, working like me on D3D1-7, the other, Raphael, working on D3D8) on how to plan ahead on making the most code common between the two code paths.
I had also some discussions with Jason (the main D3D8 developper) and also some people working to get some of their favourite games to work.
What's the most exciting thing you've gotten to work?
For me that would be System Shock 2. It's not playable yet (as it misses surface locking) but it's certainly nice to be able to start to walk around the 3D stuff.
Even better is to see people starting to ask me to review some patches they are writing to get their games working. That means that it's in a state where anybody could help just adding one little patch here or there to fix their favourite game.
3. Conformance Testing
29 Dec 2002 - 5 Jan 2003 (20 posts) Archive Link: "Conformance Testing"
People: Francois Gouget,
There's been a lot of people lately doing testing with Wine's test programs on Windows to see if the output matches what's expected by Wine. Pretty simple concept really - compile little Win32 programs run them under Wine and Windows and compare the results. In theory, the results should be the same. Anyway, this topic is composed of several threads and has been going on for over a month. I've neglected to cover it because it's pretty boring - you probably don't want to see test output and reports like "14 of 42 tests failed". What's a little more interesting is to link to Francois Gouget's page where he has a running list of the tests. You can find that at: http://fgouget.free.fr/wine/tests-en.shtml.
If you're looking for a way to contribute to Wine, that might be a good starting point. Francois has the tests compiled and available as a .zip file ready to be run on Windows (no compiling necessary!) There's still quite a few versions of Windows that haven't had some of the tests run on them. If you have output different than what's already reported I'm sure he'd love to hear about it. The tests are known to have problems, hence the differences between Windows versions and Wine. Figuring out why a test won't work is a great way to start digging into Wine. I'll include the intro Francois wrote to give you an idea of what's been going on:
14 tests out of 42 have failures on one or more Windows platforms
(last time I counted).
That's 33% of incorrect tests! Making progress. That's still pretty bad
since a good part of the progress comes from the addition of the generated
tests that succeed on all platforms. But it is much better than the initial
75% of 2002/12/03 :-)
Click on the link below to download pre-compiled windows binaries and see for yourself:
winetests.zip -- Sunday, 05-Jan-2003 04:32:51 MET -- 1.1M
What Wine needs most currently is volunteers to go over these errors and
to send patches to wine-patches fixing the tests so that they complete
successfully on all versions of Windows: at this time running the tests on
more platforms would mostly confirm already known bugs. If you fix a test
let me know and I will update this page accordingly.
See the following URL for instructions on how to compile (and debug) the tests on Windows using Visual C++: http://www.winehq.com/docs/wine-devel/testing-windows.shtml
Note () : These tests are conformance tests which means their main function is to describe the behavior of Windows APIs, and then to allow us to verify that Wine behaves like the test says. So obviously if a test fails on Windows its description of the Windows API behavior is incorrect and is useless as far as testing the correctness of Wine. Thus in the 'Wine' column I am marking any test that fails on a Windows platform as 'incorrect'. It must be fixed first. Then we can consider the results of running the test on Wine.
On Wednesday Francois posted a message asking for help with some specific tests:
However now I need *help* to fix the following test failures. I.e these tests fail and I don't know how to fix them so a patch, or hints as to what needs to be done would be greatly appreciated: (well, the alternative is that I could also just remove them)
There are more tests that fail and I would certainly appreciate help with these too (would free me lots of time to do other things on Wine). Otherwise I will have a crack at them and see what I can do.
If you're interested to see how people are reporting problems, here's some links to threads about testing:
4. wxWindows Port Completed
4 Jan 2003 (1 post) Archive Link: "wxWindows: it's now official (almost)"
People: Dimitrie Paun,
Looks like Dimi Paun finished his work getting wxWindows to compile under Wine (now comes the fun of integrating changes into various projects):Issue #150, Section #5 (24 Dec 2002: wxWindows Under Wine) :
Last night I had nothing better to do than to cleanup my wxWindows patch. The entire thing is less than 500 lines! This says quite a few things about the maturity of our headers.
The changes to the build system are just a few lines changed in src/makeg95.env. In fact, most of those are just documentation changes, and convenience things. *All* interesting changes are just:
Needless to say, I am sooooo happy! :)))) Below I've included a diffstat of the patch (to give you an idea how few things I had to change), and the patch itself (first to show how trivial the changes are, and second in the hope that my experience doing this port can be of some use to someone else).
The exact same patch (with the only difference being that it has only 2 lines of context for the unified diff, to conform to the wxWindows patch guidelines) will be submitted for inclusion in the official wxWindows tree in the next 10 minutes. But I figured you guys should be the first to know, so here it is! :)
5. Fun Projects Update
6 Jan 2003 - 7 Jan 2003 (6 posts) Archive Link: "Wine Fun v0.3"
Topics: Project Management
People: Dimitrie Paun,
Dimi updated his fun projects list - the one that got slashdotted last time he posted it:
I haven't released a version of the Fun page in a loooong time, and a _lot_ of things changed. In fact, I would say at least 90% of it has changed since last time. Here it is for your viewing pleasure:
Check it out, maybe you'll find something that tickles your fancy! ;)
6. Compiling With distcc
8 Jan 2003 - 10 Jan 2003 Archive Link: "distcc and wine"
Topics: Build Process
People: Martin Pool, , Dan Kegel
A few weeks ago we reported some comparisons with compile times. In that we noted Dan Kegel had failed to see a speedup compiling with a distcc - a compiler that distributes across a bunch of machines. This week Martin Pool replied:
I saw (reading my referrer logs :-) people were interested in distcc with Wine, so I thought I would add it to distcc's performance benchmark.
Across three machines I saw a 2.58x speedup -- details are attached. The machines were all 1GB, 1700MHz Pentium IV with a 100Mbps switched connection. Building on just one took 22m57s, and across all three took 8m53s. There is probably still some scheduling inefficiency here, which I hope to reduce over the next few months.
I'm not sure what was happening with the person who saw little change. Perhaps they had distcc misconfigured, or perhaps they hit a bug. Either way I would be interested in hearing the details ($DISTCC_HOSTS, etc) and seeing if I can help fix it.
I hope you find ccache and distcc useful. Wine is a cool project.
Dan was pleasantly surprised by the results. He surmised the reason was because his machines were different types. Martin thought the scheduler with distcc had some problems and said he'd take a look at trying to improve it.
7. MacOS X + Bochs + Wine = Wish List
4 Jan 2003 (5 posts) Archive Link: "Mac OS X/Darwin port of Wine"
People: Jim White, Brian Vincent, Lionel Ulmer,
The only reason I'm covering this thread is because the next time it comes up on wine-devel I'll just post a link and point to this. Anyway, Jim White had a question about getting Wine to integrate into MacOS X:
A few weeks ago when I thought how cool it would be to marry Wine and Bochs to run Windows progams on Mac OS X & Darwin, I checked around, including this list, and didn't find any activity.
So I opened a SourceForge project to focus on just that goal:
After I uploaded the home page tonight, I checked here again and found this topic had just come up last week!
I don't know yet whether it makes sense to maintain a separate discussion and/or repository for this purpose. Seems like it would at least be useful during active initial work and then perhaps phase out.
In any case, the resource is ready-to-use and I'ld like to hear from others interested in this port.
I posted the following:
This issue comes up a few times a year (isn't it in a FAQ somewhere?) Anyway, take a look at these threads:
The fact that you're using Bochs does make it unique, but you may still glean some useful info from those links.
Lionel Ulmer then wrote in with an interesting idea:
Yeah, this is one of the most persistant 'Wine dream' around :-)
I had once a long discussion with a fellow hacker on this subject (going into the likes of using Valgrind's virtualization engine to output non-X86 code to do dynamic translation and so on). We agreed that before starting with Wine, one could start with running, for example, Linux/x86 binaries on Linux/PPC. That would already validate the fact that you can draw the line at one point and from there run such an heterogenous environment.
It's a very nice subject... A pitty it has such a low importance (seeing how X86 dominates the desktop market).
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.