Re: Move Win16 relay messages to the relay16 channel

[Marcus Meissner]

On Mon, Aug 01, 2005 at 01:57:27PM +0100, Richard Cohen wrote:
> Changelog:
> Move Win16 relay messages to their own channel (relay16)

Why?

Ciao, Marcus

Move Win16 relay messages to the relay16 channel

[Richard Cohen]

Marcus Meissner wrote:
> Why?

When you're debugging 16bit programs, sometimes you only want to see 
16bit calls.:)

Richard.

Move Win16 relay messages to the relay16 channel

[Uwe Bonnes]

> > > > > "Richard" == Richard Cohen  writes:

Richard> Marcus Meissner wrote:
    >> Why?
    >> 
    Richard> When you're debugging 16bit programs, sometimes you only want
    Richard> to see 16bit calls.:)

Isn't your proposal similar to the recent "nrelay" proposal, where only
calls from native code is logged, but not wine code calling other wine code?

Move Win16 relay messages to the relay16 channel

[Felix Nawothnig]

Uwe Bonnes wrote:
> > > Why?
> >
> > When you're debugging 16bit programs, sometimes you only want
> > to see 16bit calls.:)
>
> Isn't your proposal similar to the recent "nrelay" proposal, where only
> calls from native code is logged, but not wine code calling other wine code?

Why exactly do we need this (both nrelay and relay16) when there is 
RelayFromInclude?

Felix

Move Win16 relay messages to the relay16 channel

[Uwe Bonnes]

> > > > > "Felix" == Felix Nawothnig  writes:

Felix> Uwe Bonnes wrote:
    >>>> Why?
    >>> When you're debugging 16bit programs, sometimes you only want to see
    >>> 16bit calls.:)
    >> Isn't your proposal similar to the recent "nrelay" proposal, where
    >> only calls from native code is logged, but not wine code calling
    >> other wine code?

Felix> Why exactly do we need this (both nrelay and relay16) when there
    Felix> is RelayFromInclude?

RelayFromInclude doesn't follow CreateProcess, if I understand things right...

Move Win16 relay messages to the relay16 channel

[Felix Nawothnig]

Uwe Bonnes wrote:
> > > > > Why?
> > > >
> > > > When you're debugging 16bit programs, sometimes you only want to see
> > > > 16bit calls.:)
> > >
> > > Isn't your proposal similar to the recent "nrelay" proposal, where
> > > only calls from native code is logged, but not wine code calling
> > > other wine code?
> >
> > Why exactly do we need this (both nrelay and relay16) when there
> > is RelayFromInclude?
>
> RelayFromInclude doesn't follow CreateProcess, if I understand things right...

How about implementing magic values like %native% and %win16% for it 
then? "option-like" debug channels seem very unintuitive to me...

Felix

Move Win16 relay messages to the relay16 channel

[Uwe Bonnes]

> > > > > "Felix" == Felix Nawothnig  writes:

Felix> Uwe Bonnes wrote:

Felix> How about implementing magic values like %native% and %win16% for
    Felix> it then? "option-like" debug channels seem very unintuitive to
    Felix> me...

Good idea!

Go ahead with implementing ;-)

And let's add %deferred%

Move Win16 relay messages to the relay16 channel

[Richard Cohen]

Uwe Bonnes wrote:
> Go ahead with implementing ;-)

Here is a implementation that can exclude relay calls from builtin dlls. 
  I used '<builtin>' as the magic word because '%' is possible in file 
names.

Calls to window procedures and DLL attach/detach are still shown, but 
that is the same as the original nrelay patch.
> And let's add %deferred%

What do mean by 'deferred'?

Richard.

Move Win16 relay messages to the relay16 channel

[Uwe Bonnes]

> > > > > "Richard" == Richard Cohen  writes:

Richard> Uwe Bonnes wrote:
    >> Go ahead with implementing ;-)
    >> 
    Richard> Here is a implementation that can exclude relay calls from
    Richard> builtin dlls.  I used '<builtin>' as the magic word because '%'
    Richard> is possible in file names.

Richard> Calls to window procedures and DLL attach/detach are still
    Richard> shown, but that is the same as the original nrelay patch.

>> And let's add %deferred%

Richard> What do mean by 'deferred'?

Don't output anything, until some signal is sent or some key pressed.

Move Win16 relay messages to the relay16 channel

[Alexandre Julliard]

Uwe Bonnes  writes:
> RelayFromInclude doesn't follow CreateProcess, if I understand things right...

Not sure what you mean, it's in the registry so child processes will
certainly use the same options.

Move Win16 relay messages to the relay16 channel

[Uwe Bonnes]

> > > > > "Alexandre" == Alexandre Julliard  writes:

Alexandre> Uwe Bonnes  writes:
    >> RelayFromInclude doesn't follow CreateProcess, if I understand things
    >> right...

Alexandre> Not sure what you mean, it's in the registry so child
    Alexandre> processes will certainly use the same options.

For example the main program from the Xilinx ISE suite ise.exe starts
_pn.exe. If I understand right, "RelayFromInclude"="ise.exe" will track
relay calls of ise.exe,but not from _pn.exe.

However I can test, as "RelayFromInclude"="ise.exe" causes _pn.exe to
crash...

Bye

Move Win16 relay messages to the relay16 channel

[Alexandre Julliard]

Uwe Bonnes  writes:
> For example the main program from the Xilinx ISE suite ise.exe starts
> _pn.exe. If I understand right, "RelayFromInclude"="ise.exe" will track
> relay calls of ise.exe,but not from _pn.exe.

Sure, but "RelayFromInclude"="ise.exe;_pn.exe" will track both.
> However I can test, as "RelayFromInclude"="ise.exe" causes _pn.exe to
> crash...

How does it crash?

Move Win16 relay messages to the relay16 channel

[Uwe Bonnes]

> > > > > "Alexandre" == Alexandre Julliard  writes:

Alexandre> Uwe Bonnes  writes:
    >> For example the main program from the Xilinx ISE suite ise.exe starts
    >> _pn.exe. If I understand right, "RelayFromInclude"="ise.exe" will
    >> track relay calls of ise.exe,but not from _pn.exe.

Alexandre> Sure, but "RelayFromInclude"="ise.exe;_pn.exe" will track
    Alexandre> both.

Sure, but this requires the user to first track what's going on, then change
user.reg and restart. If the error happens in a dll, this dll has also to be
included in RelayFromInclude inuser.reg. Xilinx ISE is polluted with Dlls:

ise71> ls bin/nt/*dll|wc
    314     314    8123

With 314 possible dlls, an catch-all like %nrelay% would really come handy.

>> However I can test, as "RelayFromInclude"="ise.exe" causes _pn.exe to
    >> crash...

Alexandre> How does it crash?

As ise.exe does an exit soon after _pn.exe is started, this combination is
always hard to debug. Starting with winedbg. I get something like this:

000b:Ret  kernel32.InterlockedExchange() retval=00000000 ret=0040d9ef
000b:Call kernel32.CreateProcessA(00000000,7b122380 ""C:/ise71/bin/nt/_pn.exe"",00000000,00000000,00000000,00000000,00000000,00000000,7ba9fd84,7ba9fdc8) ret=00401c82
fixme:process:CreateProcessW app (null) cmdline L""C:/ise71/bin/nt/_pn.exe""
trace:relay:init_debug_lists RelayExclude = L"RtlEnterCriticalSection;RtlLeaveCriticalSection;_EnterSysLevel;_LeaveSysLevel;_CheckNotSysLevel;gdi32.*;winex11.drv.*;ntdll.*"
trace:relay:init_debug_lists RelayFromInclude = L"ise.exe"
000d:Call kernel32.__wine_kernel_init() ret=7bec5040
000b:Ret  kernel32.CreateProcessA() retval=00000001 ret=00401c82
000b:Call kernel32.InterlockedExchange(0046b70c,00000001) ret=0040d9ef
...
000b:Ret  PE DLL (proc=0x7beb2830,module=0x7bea0000 L"ntdll.dll",reason=PROCESS_DETACH,res=0x1) retval=1
Invalid address (0x0043b52d) for breakpoint 1, disabling it
Process of pid=0x0000000a has terminated
Wine-dbg>000d:Call PE DLL (proc=0x7beb2830,module=0x7bea0000 L"ntdll.dll",reason=PROCESS_ATTACH,res=0x1)
000d:Ret  PE DLL (proc=0x7beb2830,module=0x7bea0000 L"ntdll.dll",reason=PROCESS_ATTACH,res=0x1) retval=1
000d:Call PE DLL (proc=0x7bb32ac6,module=0x7bb30000 L"kernel32.dll",reason=PROCESS_ATTACH,res=0x1)
...
000d:Ret  PE DLL (proc=0x7af7f729,module=0x7af70000 L"shlwapi.dll",reason=PROCESS_ATTACH,res=0x1) retval=1
000d:Call PE DLL (proc=0x7afbf41a,module=0x7afb0000 L"MFC71.DLL",reason=PROCESS_ATTACH,res=0x1)
000e:Starting thread (entryproc=0x7bfadd10)
000d:Ret  PE DLL (proc=0x7afbf41a,module=0x7afb0000 L"MFC71.DLL",reason=PROCESS_ATTACH,res=0x1) retval=1
000d:Call PE DLL (proc=0x7acc31c7,module=0x7acc0000 L"comctl32.dll",reason=PROCESS_ATTACH,res=0x1)
...
000d:Call PE DLL (proc=0x7ab2c803,module=0x7ab00000 L"LIBSTG_EDIT.dll",reason=PROCESS_ATTACH,res=0x1)
trace:seh:__regs_RtlRaiseException code=c0000005 flags=0 addr=0xf6850824
trace:seh:__regs_RtlRaiseException  info[0]=00000000
trace:seh:__regs_RtlRaiseException  info[1]=f6850824
trace:seh:__regs_RtlRaiseException  eax=ffffffff ebx=7946ffbc ecx=7946ffbc edx=797d0288 esi=00000001 edi=00000004
trace:seh:__regs_RtlRaiseException  ebp=00000001 esp=7ba9fcb8 cs=0073 ds=007b es=007b fs=003b gs=0033 flags=00010202
trace:seh:EXC_CallHandler calling handler at 0x7ab2eafd code=c0000005 flags=0
trace:seh:EXC_CallHandler handler returned 1
trace:seh:EXC_CallHandler calling handler at 0x7ab2eb32 code=c0000005 flags=0
trace:seh:EXC_CallHandler handler returned 1
trace:seh:EXC_CallHandler calling handler at 0x7ab2c4d0 code=c0000005 flags=0
trace:seh:EXC_CallHandler handler returned 1
trace:seh:EXC_CallHandler calling handler at 0x7bb334a0 code=c0000005 flags=0
wine: Unhandled exception (thread 000d), starting debugger...
trace:seh:start_debugger Starting debugger "z:/spare/bon/wine/wine/programs/winedbg/winedbg --auto 12 300"
fixme:process:CreateProcessW app (null) cmdline L"z:/spare/bon/wine/wine/programs/winedbg/winedbg --auto 12 300"
No process loaded, cannot execute 'c'
Wine-dbg>err:winedbg:main Invalid event handle: 0x12c
No process loaded, cannot execute 'c'

No time to investigate further at the moment. Let me know. if you need more
information.

Cheers