Wine Traffic #188 For 19 Sep 2003

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)

Legend

Column	Values
Name	The name of the property/section
Needed	Describes the form the parameter in needed in: no The setting should be removed ac Changeable at configure time only regedt Configurable through regedit only cfg Configurable through winecfg
Dynamic	Indicates if Wine should react to changes in the value of the parameter ar runtime
PerApp	Describes if the configuration parameter need to be customizable on a per-application basis
Default value	The default value for the property. This should allow Wine to run winecfg without user intervention

Name	Needed	Dynamic	PerApp	Default value
[Drive X]
Path	cfg	yes	no
Type	cfg	yes	no
Label	cfg	yes	no
Serial	cfg	yes	no
Filesystem	cfg	yes	no
Device	cfg	yes	no
[wine]
Windows	cfg	no	no	c:\\windows
System	cfg	no	no	c:\\windows\\system
Temp	cfg	no	no
Path	cfg	yes	no
Profile	cfg	yes	no
GraphicsDriver	regedt	yes	no
ShowDirSymlinks	cfg	no	no	true
ShowDotFiles	cfg	no	no	true
ShellLinker	regedt	no	no	wineshelllink
[Version]
Windows	cfg	no	yes	win98
DOS	cfg	no	yes	6.22
[DllOverrides]
<dllname>	cfg	no	yes
[x11drv]
AllocSystemColors	regedt	no	no
PrivateColorMap	regedt	no	no
PerfectGraphics	regedt	no	no
ScreenDepth	cfg	yes	no
Display	cfgt	no	no
Managed	no	no	no
Desktop	cfg	no	yes	640x480
UseDGA	regedt	no	no
UseXVidMode	regedt	no	no
UseTakeFocus	cfg	yes	no	yes
DXGrab	cfg	no	no	no
DesktopDoubleBuffered	cfg	no	no	no
Synchronous	regedt	no	no	no
ClientSideWithRender	regedt	no	no	yes
ClientSideWithCode	regedt	no	no	yes
ClientSideAntiAliasWithRender	regedt	no	no	yes
ClientSideAntiAliasWithCode	regedt	no	no	yes
[fonts]
Resolution	regedt	no	no	<auto>
Default	regedt	no	no	<auto>
DefaultFixed	regedt	no	no	<auto>
DefaultSerif	regedt	no	no	<auto>
DefaultSansSerif	regedt	no	no	<auto>
[FontDirs]
dir<no>	regedt	no	yes	<auto>
[serialports]
Com<no>	regedt	no	yes	/dev/ttySx
[parallelports]
Lpt<no>	regedt	no	yes	/dev/lpx
[ppdev]
<port>	regedt	no	no	/dev/parportX
[spooler]
FILE:	regedt	no	no	<auto>
LPT<no>:	regedt	no	no	<auto>
[ports]
read	cfg	no	no	0x779,0x280-0x2a0
write	cfg	no	no	0x779,0x280-0x2a0
[Debug]
RelayExclude	regedt	no	no
RelayInclude	regedt	no	no
RelayFromExclude	regedt	no	no
RelayFromInclude	regedt	no	no
SnoopExclude	regedt	no	no
SpyExclude	regedt	no	no
[registry]
GlobalRegistryDir	ac	no	no	/etc
LoadGlobalRegistryFiles	regedt	no	no	true
LoadHomeRegistryFiles	regedt	no	no	true
LoadWindowsRegistryFiles	regedt	no	no	true
WritetoHomeRegistryFiles	regedt	no	no	true
PeriodicSave	regedt	no	no	600
SaveOnlyUpdatedKeys	regedt	no	no	true
[Tweak.Layout]
WineLook	cfg	yes	no	Win95
[Clipboard]
ClearAllSelections	regedt	yes	no	false
PersistentSelection	regedt	yes	no	true
[afmdirs]
1	regedt	no	no	/usr/share/ghostscript/fonts
2	regedt	no	no	/usr/share/a2ps/afm
3	regedt	no	no	/usr/share/enscript
4	regedt	no	no	/usr/X11R6/lib/X11/fonts/Type1
[WinMM]
Drivers	regedt	no	no	<auto>
WaveMapper	regedt	no	no	msacm.drv
MidiMapper	regedt	no	no	midimap.drv
[Network]
UseDnsComputerName	regedt	no	no	true
[DSound]
HELmargin	regedt	no	no	5
HELqueue	regedt	no	no	5
SndQueueMax	regedt	no	no	28
SndQueueMin	regedt	no	no	12
HardwareAcceleration	cfg	no	no	true
DefaultPlayback	cfg	no	no	0
DefaultCapture	cfg	no	no	0
EmulDriver	cfg	no	yes	true

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 occures.

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

tricky but doable.

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?)