July 2002 - Wine-Devel - list.winehq.org

10072002 version - printing bug

by leanne

Dear all, I found the 10072002 version of WINE that the layout of printout got problems. some letters overlap. Thanks. Leanne

July 24, 2002

Re: Dinput - Keyb Bug

by Lionel Ulmer

> You need to use the windows dinput.dll as ours is (still) not up to spec. I used to play this game > all the time under linux till tribes2. I dont know if this will work with the directx 8.1 but if > you can find a dinput.dll from dx5 or 6 it should work. > > I will add this information to the wine application database if its not already there and if > someone working on directx can figure out what is going on that would rock long term. Well, you could send me a +dinput trace of your problem. Or (maybe better) a +dinput,+event,+relay trace. Lionel -- Lionel Ulmer - http://www.bbrox.org/

July 24, 2002

Re: Re : Coded breakpoints

by Massimo

Thanx to all for answers ! I was thinking about it since one week... hemmm ... :-) Another question... There's someone that have tested borland debugger in remote mode with wine ? I did it but without success.... I think it's one of most confortable debuggers out there, but had no success yet to make remote part to communicate with the gui part.... Regards Max Subject: Re: Re : Coded breakpoints From: Vincent Béron <vberon(a)mecano.gme.usherb.ca> To: max(a)veneto.com Copies to: wine-devel(a)winehq.com Date sent: 23 Jul 2002 19:58:58 -0400 > Le mer 24/07/2002 à 19:31, Max a écrit : > > Never mind, if WAS a stupid question :-) > > For who needs it too, just add > > > > __asm__("int $0x03\n\t") ; > > > > at the required point, maybe inside an huge if(....) > > Or just a normal breakpoint after the innermost if, on a valid but > useless statement. No? > > Vincent >

July 24, 2002

Re: Coded breakpoints

by Marcus Meissner

On Thu, Jul 25, 2002 at 01:08:51AM +0200, Max wrote: > Maybe it's a stupid question, but... is there a way to hard-code a > breakpoint ? I need to check a bit of code that gets called too many times and > I'd like to put a conditional breakpoints compiled in code; no way to use > winedbg built-in conditional breaks, the condition is too complicated..... Just call DbgBreakPoint(); Ciao, Marcus

July 24, 2002

Re: Coded breakpoints

by Shachar Shemesh

Personally, I do: if( condition) some meaningless nop; And then set or clear the breakpoint on the nop if I want. This gives me debug time control over the breakpoint without giving up on the flexability. Shachar David Hammerton wrote: >You could do a "raise(SIGSTOP)", or if your lazy, "raise(19)". > >Replace SIGSTOP with your faviourate signal. >I know that works when debugging with gdb, I guess it should with winedbg... > >David > >On Thu, 25 Jul 2002 01:08:51 +0200, Max wrote: > >| Maybe it's a stupid question, but... is there a way to hard-code a >| breakpoint ? I need to check a bit of code that gets called too many times and >| I'd like to put a conditional breakpoints compiled in code; no way to use >| winedbg built-in conditional breaks, the condition is too complicated..... > > >

July 24, 2002

Re: Coded breakpoints

by Tony Lambregts

David Hammerton wrote: >You could do a "raise(SIGSTOP)", or if your lazy, "raise(19)". > >Replace SIGSTOP with your faviourate signal. >I know that works when debugging with gdb, I guess it should with winedbg... > >David > >On Thu, 25 Jul 2002 01:08:51 +0200, Max wrote: > >| Maybe it's a stupid question, but... is there a way to hard-code a >| breakpoint ? I need to check a bit of code that gets called too many times and >| I'd like to put a conditional breakpoints compiled in code; no way to use >| winedbg built-in conditional breaks, the condition is too complicated..... > > > Is this documented anywhere? I was thinking about this for a while and poking around the documentation with no success. Thankyou to Max for asking the question because I was simply to shy/embarassed to ask. Tony Lambregts

July 24, 2002

Re: Coded breakpoints

by David Hammerton

You could do a "raise(SIGSTOP)", or if your lazy, "raise(19)". Replace SIGSTOP with your faviourate signal. I know that works when debugging with gdb, I guess it should with winedbg... David On Thu, 25 Jul 2002 01:08:51 +0200, Max wrote: | Maybe it's a stupid question, but... is there a way to hard-code a | breakpoint ? I need to check a bit of code that gets called too many times and | I'd like to put a conditional breakpoints compiled in code; no way to use | winedbg built-in conditional breaks, the condition is too complicated..... -- David Hammerton programmer TransGaming Technologies Inc. http://www.transgaming.com david(a)transgaming.com

July 24, 2002

Re: Coded breakpoints

by Francois Gouget

On Thu, 25 Jul 2002, Max wrote: > Maybe it's a stupid question, but... is there a way to hard-code a > breakpoint ? I need to check a bit of code that gets called too many times and > I'd like to put a conditional breakpoints compiled in code; no way to use > winedbg built-in conditional breaks, the condition is too complicated..... You can do: if (complex condition) { _CrtDbgBreak(); } Or equivalently: if (complex condition) { __asm__ ("\tint $0x3\n"); } The int 3 is a software breakpoint (or rather, a software breakpoint is an int 3). The bove code will cause you to drop in the debugger if the int 3 ever gets executed. This only works on x86 architectures but this is probably all you need. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Advice is what we ask for when we already know the answer but wish we didn't -- Eric Jong

July 24, 2002

Re: Re : Coded breakpoints

by Vincent Béron

Le mer 24/07/2002 à 19:31, Max a écrit : > Never mind, if WAS a stupid question :-) > For who needs it too, just add > > __asm__("int $0x03\n\t") ; > > at the required point, maybe inside an huge if(....) Or just a normal breakpoint after the innermost if, on a valid but useless statement. No? Vincent

July 23, 2002

Re: CallNextHookEx16 strageness

by Alexandre Julliard

Michael Stefaniuc <mstefani(a)redhat.de> writes: > It seems that we don't have an implicit transformation of a HHOOK to a > HANDLE16. Most of the internal HOOK_* functions are using HANDLE16's and > the few functions that accepts as parameter a HHOOK are checking for the > presence of the HOOK_MAGIC and are doing the conversion to a HANDLE16 > with LOWORD(hhook). Well yes, the hook functions are mostly using HANDLE16 internally, but it would be much better to change them to use HHOOK. There isn't much point in making HHOOK work with -DSTRICT if we don't use it anywhere. - return CallNextHookEx16( WH_SHELL, code, wParam, lParam ); + return CallNextHookEx16( (HHOOK)MAKELONG(WH_SHELL, HOOK_MAGIC), code, + wParam, lParam ); WH_SHELL is not a valid hook handle, this code is broken (of course it was broken before too). -- Alexandre Julliard julliard(a)winehq.com

July 23, 2002