World Wine News

TODO: (in rough order of priority)

• A mind bogglingly vast amount of stuff
• Complete X11DRV page, so all controls are hooked up
• Implement autodetect for drive configuration
• Figure out whether we need the virtual vs real drive selection stuff at the top of the property page
• Implement explicit mode vs instant-apply mode
• AppDefaults handling
• DLL editing
• Make a list of prefs that have been dropped from the UI/should be eliminated
• Multimedia page
• Settings migration code (from old configs)

I recently installed Mandrake 9.1 and updated it to the newest packages .. I'm using the ATI fglrx 3.2.5 driver for XFree 4.3.0 (I have a Hercules Radeon 9700) and playing 3D games like tuxracer works great. However, when I try to start any program with wine my screen gets dark and goes into standby. This happens even with Notepad or the programs included with Wine! This problem didn't happen on my earlier installations of Linux, but I can't say if it's the driver of my graphics card (maybe I should try an older version? mmh.), my Mandrake 9.1 or wine itself (I'm using the current version from CVS, just updated). Maybe somebody had this problem too and knows how to get wine running again?

The funny thing is: My PC keeps running, I can connect to it using SSH and kill wine, but this doesn't do anything about my screen. I can even start wine again (wine notepad.exe) and it gives me the usual output, no Errors or Warnings.

When I try to play "The Elder Scroll III: Tribunal" version 1.4.1313 german under wine I get a page fault after some time. The time span differs and so the calling point of the heap management but it always occurs in HEAP_CreateFreeBlock in line 415.

Generating of a full "-debugmsg +heap" log is nearly impossible because it takes too long to start the game and start playing (after > 200 min. it still wasn't finished with initializing).

Something else that might help is an algorithm I suggested a long time ago, and which was not thought as worth the effort. Since I have not tried to run Wine with valgrind yet, I don't know whether it is or isn't.

The gist of it is that you pad each and every alloc with more memory, and you fill it in with signatures. When you release the memory, you check that the signatures are ok. Tweaking the amount of extra memory can cause you to not corrupt the heap structure at some point, which will allow you reliable pin-pointing the buffer in which the overflow occurs.

I have never worked with valgrind (though I love the principle behind it), so I can't say whether it is more effective at this sort of problems. My method, in any case, is not very difficult to implement, so if valgrind does not provide what you need, I may invest the time in it.

The issue with this approach is that you only trigger the check when releasing the block. It might well happen that the crash takes place before you free the memory. IMO, this is well suited to situations where either you have, from time to time, synchronisation points (you check the heap situation) or you check a memory block before using it (think of overloading operator-> in C++).

In this case it would help if:

• crash doesn't take place before buffer release
• you are able to identify the buffer (where it has been allocated)
• then you can set a hardware watchpoint on the buffer to know who overwrites it

IMO, running valgrind will allow you actually stop on the faulty write operation. valgrind is worth a try.

I have flagged this before, but got no answer. Once again, this a C++ Winelib app (one of the wxWindows samples):

trace:module:load_dll Trying native dll 'C:\WINDOWS\SYSTEM\calendar-wrap.dll'
warn:module:load_dll Failed to load module 'C:\WINDOWS\SYSTEM\calendar-wrap.dll'; status=c000000f
Error: Could not load the application's module calendar-wrap.dll (126)


The piece of code that fails is from the automatically generated wrapper[1]. Here is the part that fails:

LoadLibrary("calendar-wrap.dll");

I have the WINEDLLPATH set, what gives? Alexandre, I can't really track this easily back, but I have a gut feeling it got triggered by one of the reorganizations that you did around the loader...

Hmm, that would be very odd. Do you see any problem with these:

[dimi_at_dimi calendar]$ ldd calendar.exe.so
    libwine.so =>usr/local/lib/libwine.so (0x40029000)
    libdl.so.2 =>lib/libdl.so.2 (0x40040000)
    libstdc++.so.5 =>usr/lib/libstdc++.so.5 (0x40044000)
    libm.so.6 =>lib/tls/libm.so.6 (0x400f8000)
    libgcc_s.so.1 =>lib/libgcc_s.so.1 (0x4011a000)
    libc.so.6 =>lib/tls/libc.so.6 (0x42000000)
    /lib/ld-linux.so.2 =>lib/ld-linux.so.2 (0x80000000)
[dimi_at_dimi calendar]$ ldd calendar-wrap.dll.so
    libwine.so =>usr/local/lib/libwine.so (0x402f5000)
    libstdc++.so.5 =>usr/lib/libstdc++.so.5 (0x4030c000)
    libm.so.6 =>lib/tls/libm.so.6 (0x403bf000)
    libgcc_s.so.1 =>lib/libgcc_s.so.1 (0x403e2000)
    libc.so.6 =>lib/tls/libc.so.6 (0x42000000)
    libdl.so.2 =>lib/libdl.so.2 (0x403ea000)
    /lib/ld-linux.so.2 =>lib/ld-linux.so.2 (0x80000000)

It seems to me calendar-wrap.dll.so has the same dependencies as calendar.exe.so (in a bit different order, does it matter?)