This is the 131st 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).
A new CVS drop occured on August 4th. Alexandre noted
the following changes in the
announcement:
CodeWeavers announced CrossOver Office 1.2.0. The notable additions are support for Quicken and Visio. QuickBooks, while not officially supported, is reportedly working to some degree. Worth noting is a review with lots of screenshots. The second page of the review is actually an interview with Jeremy White.
TransGaming announced WineX 2.1 adding the ability to run even more games. Screenshots of some of new games include:
There were some other announcements out of TransGaming. First, a web store is in the works and set to open soon. Gavriel State mentioned that a source-enabled port of Kohan will be available from the store soon. Also of note are the winners of the "Name the Logo" contest. Thomas Wouters, Ethan James and Aaron Glover each suggested the name "Spike" for the TransGaming logo.
Some news out of Xandros this week points towards another beta release in August and release date of September or October. They plan to show off their desktop solution at LinuxWorld including "a spectacular office suite".
Jacek Bator asked,
I'm tring to understand current wine gdi architecture, and as far as I
see its strictly based on and mixed with XWindows. Is it inheritance of
early development. Does any one tried ever to rewrite this layer not
only to separate dll, but to implement real drivers for graphics
rendering.
Marcus Meissner pointed out that there were some abstraction layers
there. Ove Kåven offhandedly mentioned,
David Hammerton is in possession of an experimental DIB engine of Wine,
but I don't recall whether he ever got around to submitting it to wine
yet.
To which David replied,
Hmm, I thought you were going to check it into rewind Ove? maybe I'll resend it
if you've lost it?
Adding a DIB engine to Wine has been discussed in the past,
Bang Jun-Young reported a problem building Wine:
I got the following error with wine-20020804 when I skipped 'make depend' before doing 'make':
[ link to error ]
A ton of people wrote back to inform Jun-Young to just do the make
depend. If it worked in the past without it, then it was just luck.
Sylvain Petreolle pointed out,
See configure output and follow its instructions - it says to run
'
make depend && make'.
Jun-Young wondered why it was really required though. He felt the source code should compile without it. Several people admitted they didn't know exactly why it was there, just that it was needed. Alexandre explained:
The reason is that some headers are generated at build time, and thus need
proper dependencies in order to be generated in the right order. So we
either have to require make depend before building, or manually
maintain the dependencies for these headers. Neither solution is
perfect, but at least the make depend approach has the advantage that
it doesn't break if you change a #include and forget to update the
makefile.
David Hagood needed some advice on setting up CUPS printing:
I've been having trouble with my RH7.2 LPRng based printing, so I decided I'd try installing CUPS. After fighting for hours to get this so-called easier printing system installed and working, I finally got to where I could print from Linux apps. Now, however, Wine steadfastly refuses to bring up a meaningful print dialog.
I've gone into system.reg and win.ini and removed all the entries relating to the printing system, to no avail. Wine sort of recognises that there is a printer named "Color" managed by CUPS, but it cannot get any kind of properties for it - no paper size, no queue, and any attempt to accept the dialog is either ignored or results in a fault.
Andreas Mohr took a jab at CUPS first:
Yep, I've always been asking myself how this company came to name itself Easy Software Products. At least the CUPS install on Debian is rather problematic. You even have to type in printer URLs *by hand* in several cases ! The menu choices are not exactly non-confusing. A web-based system could be considered to be *made* for a good context-sensitive help system, yet there's none to be found.
CUPS *should* be totally easy to set up in Wine, yet for some reason Wine stumbles hard and dies instantly. If noone has a stab at fixing this, then maybe I'll have some time to fix it. Don't ask for a close look at my ToDo list, though... ;-)
Josh Thielen pointed that a bug had already been filed on it.
Max had a question about maintaining an up to date copy
of the Wine code,
I downloaded complete CVS wine repository, but the instructions on how to use
CVSUP to mantain it up to date are not complete (for me at least !).
Can anybody explain me how to do it ?
Tony Lambregts suggested:
When I update from CVS I use
cvs update -PAd
./configure
make depend && make
su
make installThe configure is optional if no makefiles have been changed.
Dimi Paun does it a different way:
Here is my setup:
[dimi@dimi dimi]$ ls -ld /var/cvsup
drwxrwxrwx 4 root root 4096 May 21 03:25 /var/cvsup
[dimi@dimi dimi]$ ls -ld /var/cvs
drwxr-xr-x 3 root root 4096 May 21 03:29 /var/cvs
[dimi@dimi dimi]$ ls -l /var/cvs
total 4
drwxr-xr-x 2 root root 4096 May 21 03:29 CVSROOT
lrwxrwxrwx 1 root root 14 May 21 03:28 wine -> ../cvsup/wine/
[dimi@dimi dimi]$ cat ~/cvsup.sup
*default base=/var/cvsup delete compress
wine release=wine host=cvs.winehq.com
[dimi@dimi dimi]$
What I do then is:
cvs -d /var/cvs co wine
to create your working directory.When I want to update, I do:
[dimi@dimi wine] cvsup ~/cvsup.sup
[dimi@dimi wine] cvs upEverything else is as if you work directly with the WineHQ tree, only _a_lot_ faster.
Steve Lustbader asked when it's necessary to run wineinstall. Tony Lambregts explained:
wineinstall sets up your ~/.wine/config file and the default registries in addition to compiling wine so most of the time if you already have these set up then it is not nessesary to use wineinstall.
However the structure of both the .wine/config and registries and thier contents has changed over time and as new features are added to wine. For example over time more functionality has been added to the various dlls and in the default config file various dlls now default to builtin rather than native. So running wineinstall once a month and letting it overwrite your old config is not a really bad idea. Your old config is called config.sav and you can run "diff -u config.sav config>config.dif" to see what it has changed.
Kristoffer Ericson was looking for some help to get a game working:
I'm trying to get StarSiege Tribes (1) to work, and from what i gather is it suffering from a quite common wine-gaming-problem (both wine & winex).
The game starts smoothly enough but keyboard is dead. When i press any key it will instantly drop out and quit. No error message or breaks. Considering the keyboard makes you move it basicly leaves you jumping up and down shooting at everything that comes..=) Other than the keyboard error tribes runs fine.
Steven Edwards had a quick solution,
You need to use the windows dinput.dll as ours is (still) not up to spec. I used to play this game
all the time under linux till tribes2. I dont know if this will work with the directx 8.1 but if
you can find a dinput.dll from dx5 or 6 it should work.
That seemed to work, but Kristoffer went on to mention some other problems such as sound not quite working right, OpenGL not working at all, and full-screen mode feeling sluggish. Lionel Ulmer asked for some debugging output which Kristoffer and Jesse Allen provided. Steven Edwards' solution for the hardware acceleration was to use older Voodoo cards with GLIDE since the game supported it.
Francois Gouget reported a threading problem with Solaris:
Some time ago I did some tests of Wine on Solaris x86 and found that there is a problem with the way we handle threads due to the differences between the Linux and Solaris threading models. These differences are also relevant for Solaris Sparc and probably many other Unices.
Unfortunately I don't have time to work on it anymore so I created a bug report in Bugzilla where I tried to dump the relevant information, including a patch to illustrate the issues and the start of a fix. I hope it will be useful to someone... maybe Gregg who has been doing a lot of Solaris work recently.
In the bug report Francois noted the following details:
- on Linux a process can contain multiple threads and each thread gets a unique system-wide identifier which is confusingly called a pid (process id). It can be argued that Linux does not in fact have the notion of what a process is: there is no object that represents the process that contains all these threads. So you cannot kill a process, you can only kill its individual threads. This is because you can only send signals to specific threads so that when you 'kill -9 pid', you only kill one individual thread in the process.
- on Solaris too a process can contain multiple threads (called lightweight processes or lwp for short). However, processes and threads are each separate system objects. When you send a signal it is sent to the process: 'kill -9 pid' will kill the process and all its threads. Also, individual lwps do not have a globally unique identifier. Instead their ids (typically 0, 1, 2, etc.) are only unique within a process. So if you want to refer to a specific lwp in the system you must use specify both the pid and the lwpid.
Wine and in particular the Wine server, need the following functionality:
- uniquely identify a thread in the system
- sending a signal to a specific thread
- precisely identifying a thread's parent thread (for handle inheritance when creating a new process, etc. It is a prerequisite for the debugger too)
Gregg Mattinson dived into it and came up with a patch a few days later. He noted the following changes:
Here is my first attempt at fixing threads for Solaris. This patch is based on the comments from and bug entered by Francois Gouget.
I compiled the wineserver under i386-solaris, and it runs. I do not have the resources to compile ALL of wine under i386, or on any OS other than Solaris so the linux and BSD portions of this code are completly un-tested.
ChangeLog:
Improved wineserver's handling of LWPs by following recommendations from http://bugs.winehq.com/show_bug.cgi?id=904 With LWPs (Solaris), each wine process contains the unix_pid, and each thread contains the LWP id. Without LWPs (Linux, BSD, ...) each process contains the unix_pid 0, and each thread contains the actual unix pid in it's tid member.