wine-kthread

[Jan Henrik Sylvester]

I have got two questions about wine-kthread, one about the future of 
that patch and one about a current issue I got.

1. The need for wine-kthread:

wine-kthread was removed from the port with 0.9.45 as the pthread 
version was supposed to "be better by now". For me, the popular game 
Warcraft 3 would not work without wine-kthread and it still segfaults 
immediately with wine(-pthread) as of 1.0.r4. (The German bsdforen wiki 
still recommends wine-kthread for quite a few games. I do not know if 
that is outdated.)

In a long email exchange, Tijl Coosemans was extremely helpful analyzing 
the problem and explaining to me the underlying issues. (Thanks again!) 
The result was the patch-kthread to be found on the wiki. The patch 
actually changes two things: (a) Reintroduce wine-kthread as it seems to 
be needed. (b) Move wine from 0x7bf00400 to 0x81000400 as dri needs more 
heap for Warcraft 3 on certain occasions than is available with the 
standard base address. (I could reproducibly crash it with certain 
larger maps.)

Tijl told me that at least the second issue would be fixed with FreeBSD 
7, but my later testing at the time of 7.0-BETA4 indicated that this was 
not the case. Maybe it was just my failure to separate the correct part 
of the patch.

Tijl did post on wine-devel about the problem: 
http://www.winehq.org/pipermail/wine-devel/2007-September/059426.html 
The only reply does not sound promising to me with my limited 
understanding of the underlying issue.

Since it would probably break other application, Tijl wold me the the 
patch could not go back to the port. (See below: I found the first one 
myself that is affected.) Since FreeBSD 7 might have been able to help, 
the issue was postponed.

2. My current issue:

As I tried to fix a problem with an old application I wrote with ancient 
Borland C++Builder 4, I tried to make BCB4 run using wine. BCB4 fails 
linking a project as long as wine is compiled with patch-kthread -- no 
matter if I start it with wine-ktread or wine(-pthread). The problem 
might be the 0x8 address: "Cannot reserve virtual memory at addr 
90000000 for 33554432 bytes" -- I could provide more details, but I 
guess they are not needed. For the same project (a component needed for 
my application), linking works without patch-kthread.

3. The future of wine-kthread:

(a) Would it be possible to build a wine version with wine-kthread at 
0x81 and wine(-pthread) at 0x7b?
(b) Is there a future for wine-kthread in the FreeBSD port, maybe as an 
OPTION?
(c) Should the heap issue be solvable on FreeBSD 7?

With (a), my current problem would be solved for the moment. I tried to 
analyze which files are affected by patch-kthread to be able to switch 
around and make building both versions easier, but since there seem to 
be quite a few files in the wine package that change with every 
recompile, I am not sure if I found the correct ones. My guess is that 
nothing outside loader/ is affected during build and only bin/wine, 
bin/wine-pthread, and bin/wine-kthread are affected for the package.

Currently, (b) would only help me a little, since I use two more wine 
patches solving issues with Warcraft 3 network (same for others on 
Linux) and opengl (probably specific to my graphic chipset), but I hope 
these regressions will eventually get fixed in wine. (I did test the 
kthread issues to exist without further patches, too.) Anyhow, since the 
wine port recently got OPTIONS...

Of course, (c) is the major point. It would be so much nicer not to have 
patches anymore, especially since they could become incompatible at any 
time.

I repeated most of my earlier tests on wine-1.0.r4 with same results. 
Looking at the changes, 1.0.r5 should not change anything, but I could 
try again.

I depend neither on Warcraft 3 nor on BCB4, thus the issue is not 
extremely high priority for me. Anyhow, I am interested in fixing it, 
but unfortunately my understanding of the issue is too limited to really 
try to fix it myself.

Of course, I can provide more details, but this email already got too 
long and maybe they are not needed.

Thanks in advance for any help,
Jan Henrik