Wine Traffic #196 For 14�Nov�2003

Motivated by my previous mail to the list, I have tried some more of my games with wine, and 2 out of 5 works perfect, but has some minor problems. Hmm, I guess a trace could be needed on some of them? But anyway here it goes:

• Risk II:
  The "loading screen" displays, but:
  wine: Unhandled exception (thread 0009), starting debugger...
• Empire Earth:
  winevdm: can't exec 'G:\Empire Earth\Empire Earth.exe': error=21
• Europa Universalis 2:
  Is a bit slow but works perfectly. :D But can only be started from the konsole. If I try to start it from konqueror it says it can't find its data files. Something to do with konqueror not setting cwd? (or whatever it's called) The konsole is full of:
  err:ddraw:Main_DirectDrawSurface_GetSurfaceDesc Impossible/Strange struct size 0.
• BattleField 1942:
  Alot of KEYFOUND: ... happens. But there is never displayed any graphic. Could this be something to do with the no-cd crack?
• Master of Orion 3:
  Game works perfect, some menu graphic missing, and mouse cursor ugly. I found something VERY interesting with this game and wine, the nebulas in game is different in wine and surely looks way better :D.

Last time the subject came up, someone suggested I make the date available so it can be published on the winehq.org site.

I'm going to give a lecture about Wine in a club called "Telux". The web site is at http://www.cs.tau.ac.il/telux/ (supposedly in Hebrew, but if you click the "Advanced lectures" english link at the left, you will get a pretty readable schedule even for non-Hebrew speaking).

The lecture will be on Nov 30th, at the Tel Aviv University. The lecture will be given in Hebrew. It will start 18:30 in the math building at the university. No advance registration is required, and no fee.

I've just checked and we're in Top 30 downloads over the last 7 days at SourceForge. More exactly, we're 28th most downloaded project, with over 20000 downloads. Not bad.

We'll need over 30000 d/l for Top 20, and over 50000 for Top 10. We'll get there sooner or later. :)

This patch is almost complete, one macro hasnt been rewritten yet.

alsa09.diff must be applied to allow compilation with alsa 0.9.

Please test it with alsa 0.9 or 1.0 and give me the result.

With yesterday cvs update, whch adds a glibc-threading detection, wine doesnt load a _Windows_ program anymore.

Using the RedHat rpm Yarrow kernel, I get :

err:virtual:map_image Standard load address for a Win32 program
(0x00400000) not available - security-patched kernel ?
wine: could not load L"C:\\arakas.exe" as Win32 binary

Funny thing : If I set up a symlink to the wine-glibc in another directory, it works without problems.

Exec-shield is activated by default, as well as prelinking. Read the release notes of Yarrow if you want to disable them.

What probably happened is you were lucky the first week, in that the random addresses assigned to the various libraries left 0x400000 (the default loading address for Win32 binaries) available, and with enough place to load what you loaded.

The loading addresses for system libraries are changed once per week (or 2 weeks, don't remember). System libraries added after the last complete assignation are assigned a random address at each load, so is you try to execute 10 times in a row the same program, it'll fail some of the time and succeed the remaining times.

I haven't been able to see that message with winelib applications (probably not in a codepath used for winelib apps, didn't checked yet). But it's pretty easy to hit if using Win32 apps.

Disabling exec-shield (either via setarch i386 or with the proc thing) works sometimes, depending on the loading addresses assigned to libraries. If something (libc, libm, libdl, etc.) uses that address, nothing Win32 will be usable. When exec-shield is disabled, new libraries will be assigned loading addresses starting at the lower value possible, but already assigned ones (via prelinking) will still keep theirs, hence possibly blocking execution.

Sorry, forgot to come back to say how testing went.

The best workaround I found (from http://www.codeweavers.com/site/support/tickets/browse/?ticket_id=34072) is to change the default prelinking options, so that the required address is still free for Win32 apps.

If you're hit by this, in file /etc/sysconfig/prelink, change

PRELINK_OPTS=-mR

to

PRELINK_OPTS="-mR --no-exec-shield"

The loading addresses chosen will be from 0x40000000, the default value on Linux systems, rather than trying to put the maximum of libraries before 0x01000000 (so that the first byte is always 0x00, rendering string buffer overflows mor difficult to exploit), hence crowding the area we want to keep free (0x00400000).

So far (little testing only, but still), I haven't had a problem with those settings, either running Wine or Linux apps.

Further reading in the referenced page shows Alexandre is in contact with some RedHat people, so hopefully they can come to a solution. RHEL 3 is affected as well, not only Fedora.

I somewhat impetuously requested a table for the Wine Project at the LinuxWorld New York expo, without really thinking if anyone could man the table.

We'll have a CodeWeavers specific area in another part of the expo, so we won't really be able to provide a lot of help (and won't need any extra promotion).

So, I was wondering if anyone wanted to go to New York and represent the Wine Project.

If so, let me know privately. If I don't hear anything, I'll quietly tell IDG nevermind .