WWN Issue 152

This is the 152nd release of the Wine's kernel cousin publication. Its main goal is to distribute widely what's going on around Wine (the Un*x Windows emulator).

This week, 454 posts consumed 1374 K. There were 85 different contributors. 49 (57%) posted more than once. 36 (42%) posted last week too.

The top 5 posters of the week were:

84 posts in 268K by Dimitrie O. Paun
40 posts in 101K by Dan Kegel
37 posts in 95K by Alexandre Julliard
31 posts in 75K by Sylvain Petreolle
30 posts in 83K by Francois Gouget

News: Distribution Review	03 Jan 2003 00:00:00 -0800	Archive
News Over at DesktopLinux.com there's a review of several desktop operating systems. If you skip to the last page you'll find a discussion of several Linux distributions , some you may never have heard of before. The notable Wine reference discusses using CodeWeavers CrossOver Office with the ELX distribution. Sadly, the author doesn't mention Wine at all.

Direct 3D Status	03 Jan 2003 00:00:00 -0800	Archive
Status Updates 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.

Direct 3D Status

03 Jan 2003 00:00:00 -0800

Archive

Status Updates

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.

Conformance Testing	29 Dec 2002 00:00:00 -0800	Archive
Testing 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.org/docs/wine-devel/testing-windows 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) kernel32/alloc kernel32/file kernel32/locale netapi32/access user32/sysparams user32/win 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: Windows 2000 Pro conformance test update Win2000 Conformance R3: Windows XP conformance test update 1/5 Win98 Compliance Status

Conformance Testing

29 Dec 2002 00:00:00 -0800

Archive

Testing

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.org/docs/wine-devel/testing-windows

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)

kernel32/alloc
kernel32/file
kernel32/locale
netapi32/access
user32/sysparams
user32/win

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:

wxWindows Port Completed 04 Jan 2003 00:00:00 -0800 Archive

Winelib

Looks like Dimi Paun finished his work getting wxWindows to compile under Wine (now comes the fun of integrating changes into various projects):

<kcref></kcref>:

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:


CC=winegcc

CXX=winegcc -xc++

WINDRES=wrc

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! :)

Enjoy!

diffstat wine.diff



 include/wx/filefn.h      
|
    2 +-


 include/wx/longlong.h    
|
    1 +


 include/wx/msw/gccpriv.h 
|
    4 ++--


 include/wx/msw/setup0.h  
|
    2 +-


 include/wx/platform.h    
|
    2 +-


 include/wx/sckaddr.h     
|
    2 +-


 src/common/datetime.cpp  
|
    2 +-


 src/common/dynarray.cpp  
|
    1 +


 src/common/encconv.cpp   
|
    1 +


 src/common/filefn.cpp    
|
    2 +-


 src/common/list.cpp      
|
    1 +


 src/common/mimecmn.cpp   
|
    6 +++---


 src/common/sckaddr.cpp   
|
    4 ++--


 src/common/sckipc.cpp    
|
    2 +-


 src/common/string.cpp    
|
    1 +


 src/common/wxchar.cpp    
|
    2 +-


 src/jpeg/jmorecfg.h      
|
    3 +++


 src/makeg95.env          
|
   24 +++++++++++++++++++++---


 src/msw/app.cpp          
|
    2 +-


 src/msw/dialup.cpp       
|
    1 +


 src/msw/fontenum.cpp     
|
    2 +-


 src/msw/gsocket.c        
|
    4 ++--


 src/msw/ole/automtn.cpp  
|
    1 +


 src/png/pngconf.h        
|
    8 ++++++--




 24 files changed, 56 insertions(+), 24 deletions(-)

Fun Projects Update	06 Jan 2003 00:00:00 -0800	Archive
Project Management 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: http://63.138.153.104/wine/Wine-Fun-0.3.html Check it out, maybe you'll find something that tickles your fancy! ;)

Compiling With distcc	08 Jan 2003 00:00:00 -0800	Archive
Build Process 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.

Compiling With distcc

08 Jan 2003 00:00:00 -0800

Archive

Build Process

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.

Mac OS X + Bochs + Wine = Wish List	04 Jan 2003 00:00:00 -0800	Archive
Ports 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 Mac OS 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: http://darwine.sf.net 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: http://kt.zork.net/wine/wn20020830_133.html#3 http://bugs.winehq.org/show_bug.cgi?id=44 http://www.winehq.org/hypermail/wine-devel/2000/11/0004.html http://www.winehq.org/hypermail/wine-devel/2000/11/0077.html 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 persistent '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).

Mac OS X + Bochs + Wine = Wish List

04 Jan 2003 00:00:00 -0800

Archive

Ports

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 Mac OS 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:

http://darwine.sf.net

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:

http://kt.zork.net/wine/wn20020830_133.html#3

http://bugs.winehq.org/show_bug.cgi?id=44

http://www.winehq.org/hypermail/wine-devel/2000/11/0004.html

http://www.winehq.org/hypermail/wine-devel/2000/11/0077.html

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 persistent '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).

World Wine News