June 2006 - Wine-Devel - list.winehq.org

Re: wineprefix: Create a cdrom drive if it exists at /media/cdrom

by Vincent Povirk

On 6/1/06, Mike Hearn <mike(a)plan99.net> wrote: > The location CD drives are mounted changes between systems, this patch is > essentially specific to yours. Wine already supports HAL, which should > solve this in a more correct manner (though we have reports it doesn't > work for some games!), so how comes that's not enough? > > thanks -mike I think /media/cdrom is actually some sort of standard. A google search led me to http://www.pathname.com/fhs/pub/fhs-2.3.html#MEDIAMOUNTPOINT I don't know where this standard gets any authority, but most modern linux distros I've seen do have a /media/cdrom directory. If there is a /media/cdrom, one can assume that it is the cd-rom drive (whichever has a cd in it) without relying on HAL at all. A quick test shows that wine 0.9.14, with a clean .wine directory, can install worms: armageddon but not run it (it couldn't find the cd, probably because wine didn't find it). Simply /media/cdrom as d: and using autodetection is enough to make it work. So the HAL thing doesn't work for everyone, and this works for a lot of people. When you see /media/cdrom, you can be sure it's a cd-rom drive. So why not use it? -- Vincent Povirk

June 1, 2006

Winecfg add CoreAudio to audio drivers list

by Emmanuel Maillard

Changelog : Winecfg add CoreAudio to audio drivers list thanks Emmanuel

June 1, 2006

Re: user32, x11drv: patch to send WM_SIZE at window state change (bug 4964)

by Juris Smotrovs

Alexandre Julliard wrote: >>@@ -1435,9 +1435,19 @@ >> "%s: in msg 0x%04x expecting lParam 0x%lx got 0x%lx\n", >> context, expected->message, expected->lParam, actual->lParam); >> } >>- ok_( file, line) ((expected->flags & defwinproc) == (actual->flags & defwinproc), >>- "%s: the msg 0x%04x should %shave been sent by DefWindowProc\n", >>- context, expected->message, (expected->flags & defwinproc) ? "" : "NOT "); >>+ if ((expected->flags & defwinproc) != (actual->flags & defwinproc) && todo) >>+ { >>+ todo_wine { >>+ failcount ++; >>+ ok_( file, line) (FALSE, >>+ "%s: in msg 0x%04x expecting lParam 0x%lx got 0x%lx\n", >>+ context, expected->message, expected->lParam, actual->lParam); >>+ } >>+ } >>+ else >>+ ok_( file, line) ((expected->flags & defwinproc) == (actual->flags & defwinproc), >>+ "%s: the msg 0x%04x should %shave been sent by DefWindowProc\n", >>+ context, expected->message, (expected->flags & defwinproc) ? "" : "NOT "); > > The problem is that this will cause tests that currently succeed to be > turned back into todos. It would be better to do the changes in a way > that doesn't break existing tests. Not exactly. If a test currently succeeds (todo == FALSE), then the else branch will execute, and the else branch is exactly as before the patch. So nothing will change for successful tests. Anyway, if you are wary about changes affecting all tests, I will prepare another patch, simply disabling the particular (todo == TRUE) test causing the problem, with a FIXME comment. This test is unsuccessful both before and after the patch, simply because of currently not checking for todo flag at defwinproc mismatch, it gets reported as test failing the whole msg suite. The defwinproc mismatch itself appears because, after solving the WM_SIZE issue, this message -- correctly -- is sent, so the actual message queue shifts relative to the expected message queue, and -- due to some messages still missing -- three expected defwinproc messages coincide with three actual non-defwinproc messages which are expected later-on. Thus this failure is actually not about messages sent from incorrect place, but simply about missing messages which is a very typical failure among the todo tests. Cheers, Juris Smotrovs >

June 1, 2006

Re: wineprefix: Create a cdrom drive if it exists at /media/cdrom

by Mike Hearn

The location CD drives are mounted changes between systems, this patch is essentially specific to yours. Wine already supports HAL, which should solve this in a more correct manner (though we have reports it doesn't work for some games!), so how comes that's not enough? thanks -mike

June 1, 2006

Re: wine problems on a 64bit system

by Mike Hearn

On Wed, 31 May 2006 07:26:37 +0200, Pavel Troller wrote: > The machines are running very similar kernels. Both are hardened with > exec-shield, but even disabling it on a 64bit by > 'echo 0 >/proc/sys/kernel/exec-shield' doesn't help. The 32bit works even with > exec-shield enabled (and doesn't print the no-exec message). As a hack you can change the code so every range of memory that is mapped is mapped executable. thanks -mike

June 1, 2006

Re: user32, x11drv: patch to send WM_SIZE at window state change (bug 4964)

by Alexandre Julliard

Juris Smotrovs <juris.smotrovs(a)sets.lv> writes: > @@ -1435,9 +1435,19 @@ > "%s: in msg 0x%04x expecting lParam 0x%lx got 0x%lx\n", > context, expected->message, expected->lParam, actual->lParam); > } > - ok_( file, line) ((expected->flags & defwinproc) == (actual->flags & defwinproc), > - "%s: the msg 0x%04x should %shave been sent by DefWindowProc\n", > - context, expected->message, (expected->flags & defwinproc) ? "" : "NOT "); > + if ((expected->flags & defwinproc) != (actual->flags & defwinproc) && todo) > + { > + todo_wine { > + failcount ++; > + ok_( file, line) (FALSE, > + "%s: in msg 0x%04x expecting lParam 0x%lx got 0x%lx\n", > + context, expected->message, expected->lParam, actual->lParam); > + } > + } > + else > + ok_( file, line) ((expected->flags & defwinproc) == (actual->flags & defwinproc), > + "%s: the msg 0x%04x should %shave been sent by DefWindowProc\n", > + context, expected->message, (expected->flags & defwinproc) ? "" : "NOT "); The problem is that this will cause tests that currently succeed to be turned back into todos. It would be better to do the changes in a way that doesn't break existing tests. -- Alexandre Julliard julliard(a)winehq.org

June 1, 2006

Re: wine problems on a 64bit system

by Alexandre Julliard

Pavel Troller <patrol(a)sinus.cz> writes: > This page really is NOT executable. So, why the workaround has been activated > just for one page (6d4d0000 - 6d4d1000) and not for the other ones, where it > also should be ? Why this new page has not been worked-around ? Because the app exception handler ignores the exception instead of propagating it. That's broken IMO, but it would certainly be possible to unprotect a larger range on the first fault. -- Alexandre Julliard julliard(a)winehq.org

June 1, 2006

Re: wine problems on a 64bit system

by Christoph Frick

On Thu, Jun 01, 2006 at 02:59:30PM +0200, Pavel Troller wrote: > root(a)co:/proc/28433# cat maps |grep 6d4 > 6d420000-6d421000 r--p 00000000 09:00 20202255 /home/tv/il2sturmovikfb/bin/hotspot/jvm.dll i run this game (il2+fb+ace+pf) on a opteron system quite well. i found the folling things helpfull - it might shed some more light on the whole thing: a) i have to run this game using win2k (or up - guess nt4 might also work) - it wont work using win98 b) when i configure EnableHardwareShaders=1 (?) in the conf.ini then the game crashes sooner or later (depending on the Water=XXX setting (3 is sooner, 2 is later)) with OutOfMemory exceptions in java. the game takes up to 3 gb ram virtual and a few 100mb resistant acording to "top". the box has 2gb real but i am not sure if i put 1gb or 2gb swap on - so it might actually really use "all my ram". i found it also quite amusing, that 3gb where used - where i guessed windows can only do 2gb per process without further handling (urban legend?). once i disable the hardware shaders the water looks dull within the game but serves my hours of fun without a problem -- cu

June 1, 2006

Re: wine problems on a 64bit system

by Pavel Troller

> > > It looks that the first exception is the No-exec, then there is one more lonely > > one (at 0x6d4db3ef) and the third one (at 0x6d4d5d7b) is the first invocation > > of the looping one - this one repeats in the log at the same address forever. > > Sounds like the whole code section is non-executable. Check where this > section comes from using +module and/or winedump. > Hi Alexandre! By making +seh,+module dump and then grepping for 6d4, I've found the following interesting excerpts: At first: trace:module:load_native_dll Trying native dll L"Z:\\home\\tv\\il2sturmovikfb\\bin\\hotspot\\jvm.dll" trace:module:map_image mapped PE file at 0x6d420000-0x6d4ef000 trace:module:map_image mapping section .text at 0x6d421000 off 1000 size 94000 virt 93dd0 flags 60000020 trace:module:map_image mapping section .rdata at 0x6d4b5000 off 95000 size 9000 virt 8ca7 flags 40000040 trace:module:map_image mapping section .data at 0x6d4be000 off 9e000 size 11000 virt 24638 flags c0000040 trace:module:map_image mapping section .reloc at 0x6d4e3000 off af000 size c000 virt bf20 flags 42000040 It looks, from this one, that 0x6d4dxxxx belongs to .data section of jvm.dll. And next: trace:seh:raise_exception code=c0000005 flags=0 addr=0x6d4d08b0 trace:seh:raise_exception info[0]=00000008 trace:seh:raise_exception info[1]=6d4d08b0 trace:seh:raise_exception eax=00000001 ebx=7fe02cf0 ecx=7fe02cf0 edx=00000003 esi=7fe02cf0 edi=6d4e0e90 trace:seh:raise_exception ebp=7fb2fd70 esp=7fb2fd68 cs=0023 ds=002b es=002b fs=006b gs=0063 flags=00010293 trace:seh:call_stack_handlers calling handler at 0x401f00 code=c0000005 flags=0 trace:seh:_except_handler3 exception c0000005 flags=0 at 0x6d4d08b0 handler=0x401f00 0x7fb2fa44 0x7fb2f984 semi-stub trace:seh:_except_handler3 filter = 0x401e62 trace:seh:_XcptFilter (-1073741819,0x7fb2f8c0) trace:seh:_except_handler3 filter returned CONTINUE_SEARCH trace:seh:_except_handler3 reached TRYLEVEL_END, returning ExceptionContinueSearch trace:seh:call_stack_handlers handler at 0x401f00 returned 1 trace:seh:call_stack_handlers calling handler at 0x7b82be80 code=c0000005 flags=0 fixme:seh:check_no_exec No-exec fault triggered at 0x6d4d08b0, enabling work-around trace:seh:call_stack_handlers handler at 0x7b82be80 returned 0 We already know this one. It's the first attempt to access this address range. Workaround has been tried to activate. And now: trace:module:MODULE_InitDLL (0x6d420000 L"jvm.dll",THREAD_ATTACH,(nil)) - CALL trace:module:MODULE_InitDLL (0x6d420000,THREAD_ATTACH,(nil)) - RETURN 1 trace:seh:raise_exception code=c0000005 flags=0 addr=0x6d4db3ef trace:seh:raise_exception info[0]=00000008 trace:seh:raise_exception info[1]=6d4db3ef trace:seh:raise_exception eax=7fb2fb28 ebx=797f2e80 ecx=7fb2fbec edx=7fb2fcb0 esi=7fe02cf0 edi=6d4db3ef trace:seh:raise_exception ebp=7fb2fb74 esp=7fb2faf8 cs=0023 ds=002b es=002b fs=006b gs=0063 flags=00010246 trace:seh:call_stack_handlers calling handler at 0x6d4b4bba code=c0000005 flags=0 trace:seh:_except_handler3 exception c0000005 flags=0 at 0x6d4db3ef handler=0x6d4b4bba 0x7fb2f7d4 0x7fb2f714 semi-stub trace:seh:_except_handler3 filter = 0x6d469332 trace:seh:_except_handler3 filter returned CONTINUE_EXECUTION trace:seh:call_stack_handlers handler at 0x6d4b4bba returned 0 trace:seh:raise_exception code=c0000005 flags=0 addr=0x6d4d5d7b trace:seh:raise_exception info[0]=00000008 trace:seh:raise_exception info[1]=6d4d5d7b trace:seh:raise_exception eax=7fb2fb28 ebx=797f2e80 ecx=7fb2fbec edx=7fb2fcb0 esi=7fe02cf0 edi=6d4db3ef trace:seh:raise_exception ebp=7fb2fb74 esp=7fb2faf8 cs=0023 ds=002b es=002b fs=006b gs=0063 flags=00010246 trace:seh:call_stack_handlers calling handler at 0x6d4b4bba code=c0000005 flags=0 trace:seh:_except_handler3 exception c0000005 flags=0 at 0x6d4d5d7b handler=0x6d4b4bba 0x7fb2f7d4 0x7fb2f714 semi-stub trace:seh:_except_handler3 filter = 0x6d469332 trace:seh:_except_handler3 filter returned CONTINUE_EXECUTION trace:seh:call_stack_handlers handler at 0x6d4b4bba returned 0 Now we see another access to this area. According to /proc/<pid>/maps: root(a)co:/proc/28433# cat maps |grep 6d4 6d420000-6d421000 r--p 00000000 09:00 20202255 /home/tv/il2sturmovikfb/bin/hotspot/jvm.dll 6d421000-6d4b5000 r-xp 00001000 09:00 20202255 /home/tv/il2sturmovikfb/bin/hotspot/jvm.dll 6d4b5000-6d4be000 r--p 00095000 09:00 20202255 /home/tv/il2sturmovikfb/bin/hotspot/jvm.dll 6d4be000-6d4cf000 rw-p 0009e000 09:00 20202255 /home/tv/il2sturmovikfb/bin/hotspot/jvm.dll 6d4cf000-6d4d0000 rw-p 6d4cf000 00:00 0 6d4d0000-6d4d1000 rwxp 6d4d0000 00:00 0 6d4d1000-6d4e3000 rw-p 6d4d1000 00:00 0 6d4e3000-6d4ef000 r--p 000af000 09:00 20202255 /home/tv/il2sturmovikfb/bin/hotspot/jvm.dll This page really is NOT executable. So, why the workaround has been activated just for one page (6d4d0000 - 6d4d1000) and not for the other ones, where it also should be ? Why this new page has not been worked-around ? With regards, Pavel Troller

June 1, 2006

Re: How are we doing?

by Mike Hearn

On 6/1/06, Alexandre Julliard <julliard(a)winehq.org> wrote: > > It's possible to see on wiki the "trust points" positions ? :) > > And on each WWN, see the variations (seems the famous kde buzz) :) > > The commit logs contain the time of the change and the time of the > commit, so you could use that to build a top-10 of the developers with > the best patch-to-commit times ;-) Heh :) Bear in mind that it depends a lot on the patch and what kind of work you're doing. Getting some clearly correct typo fixes in for an obscure DLL is going to be a lot easier even for 'untrusted' developers than, say, implementing SetThreadPriority which touches the core of Wine in a sensitive area and is somewhat controversial. There's no special privilege for CW employees or SoC students, though we appreciate it may look that way at first glance. I'm a CW employee on and off (more off than on lately due to university) and I get patches rejected all the time <chuckle> :) thanks -mike

June 1, 2006