On Fri, 9 Sep 2005 15:09:24 -0400
"Dimi Paun" <[EMAIL PROTECTED]> wrote:
> From: "Phil Krylov" <[EMAIL PROTECTED]>
> > OK, should we then make a patch which adds an IsWindow() check after every
> > notification in every control? This one fixes a really annoying bug, while
> > the other places are
From: "Phil Krylov" <[EMAIL PROTECTED]>
> OK, should we then make a patch which adds an IsWindow() check after every
> notification in every control? This one fixes a really annoying bug, while
> the other places are not proved to crash.
Well, if it's a entire class of bugs, we should fix them all
On Fri, 9 Sep 2005 13:59:05 -0400
"Dimi Paun" <[EMAIL PROTECTED]> wrote:
> From: "Phil Krylov" <[EMAIL PROTECTED]>
> > Here is a patch which adds checking if the window has been destroyed at
> > that point. I don't know if it is acceptable but it fixes the problem.
>
> But this could potentially
From: "Phil Krylov" <[EMAIL PROTECTED]>
> Here is a patch which adds checking if the window has been destroyed at
> that point. I don't know if it is acceptable but it fixes the problem.
But this could potentially happen on any notification,
what makes this particular one special (sorry, I was awa
Phil Krylov wrote:
Hi Michael,
On Thu, 8 Sep 2005 23:10:18 +0200
Michael Jung <[EMAIL PROTECTED]> wrote:
Wouldn't it be enough to call notify_click after notify_itemactivate? I've
attached a modification of your patch, which does just this. Seems to work
fine for me.
Probably, but what if s
Hello Dimi,
On Thursday 08 September 2005 23:37, Phil Krylov wrote:
> Michael Jung <[EMAIL PROTECTED]> wrote:
> > Wouldn't it be enough to call notify_click after notify_itemactivate?
> > I've attached a modification of your patch, which does just this. Seems
> > to work fine for me.
>
> Probably,
Hi Michael,
On Thu, 8 Sep 2005 23:10:18 +0200
Michael Jung <[EMAIL PROTECTED]> wrote:
> Wouldn't it be enough to call notify_click after notify_itemactivate? I've
> attached a modification of your patch, which does just this. Seems to work
> fine for me.
Probably, but what if some apps depend
Hi Phil,
On Thursday 08 September 2005 19:23, Phil Krylov wrote:
> * Every double click on a folder in the listview destroys this listview
> object (effectively destroying all underlying structures), creates a new
> one, and returns control to the place where double click notification was
>
On Fri, 26 Aug 2005 23:03:33 +0200
Michael Jung <[EMAIL PROTECTED]> wrote:
> Every time you double click a folder, the current ShellView object is
> destroyed and a new one is created. Given that I have to browse into like 30
> different folders before it crashes on me, I can't pin down the rele
Duane Clark wrote:
As of the current CVS, the problem seems to have disappeared for me. It
is not clear to me what patch fixed it.
Oops, spoke too soon. Still there.
Michael Jung wrote:
On Monday 29 August 2005 18:09, Duane Clark wrote:
I am seeing it now, using winecfg and browsing to "Add application..."
in the Applications tab. And this entirely within wine drives.
Are you saying you are not using the unix filesystem namespace and you are
seeing the
Hi Michael,
2) Did other people see this bug already?
TextPad 4.5 broke just around the time when you checked in the patch. It
crashes at startup, the crash location is strange and has already
changed a few times when I updated the WINE source tree.
You can get TextPad 4.5 here:
ftp://ft
Michael Jung wrote:
On Monday 29 August 2005 18:09, Duane Clark wrote:
I am seeing it now, using winecfg and browsing to "Add application..."
in the Applications tab. And this entirely within wine drives.
Are you saying you are not using the unix filesystem namespace and you are
seeing the
On Monday 29 August 2005 18:09, Duane Clark wrote:
> I am seeing it now, using winecfg and browsing to "Add application..."
> in the Applications tab. And this entirely within wine drives.
Are you saying you are not using the unix filesystem namespace and you are
seeing the crash anyway?
Bye,
Phil Krylov wrote:
On Fri, 26 Aug 2005 22:10:16 +0200
Michael Jung <[EMAIL PROTECTED]> wrote:
2) Did other people see this bug already?
Yes, I confirm it.
I am seeing it now, using winecfg and browsing to "Add application..."
in the Applications tab. And this entirely within wine drives.
On Fri, 26 Aug 2005 22:10:16 +0200
Michael Jung <[EMAIL PROTECTED]> wrote:
> 2) Did other people see this bug already?
Yes, I confirm it.
-- Ph.
Hi,
On Fri, Aug 26, 2005 at 07:30:55PM -0700, Robert Shearman wrote:
> Andreas Mohr wrote:
> >In theory it's possible, but valgrind currently doesn't work with Wine any
> >more
> >(or rather the other way around), AFAIK.
> >
> >
>
> It used to as of a few months ago. Have you tried it recently
Andreas Mohr wrote:
Hi,
On Fri, Aug 26, 2005 at 10:10:16PM +0200, Michael Jung wrote:
3) Would valgrind be of help to debug this?
In theory it's possible, but valgrind currently doesn't work with Wine any more
(or rather the other way around), AFAIK.
It used to as of a few months
Hi,
On Fri, Aug 26, 2005 at 11:03:33PM +0200, Michael Jung wrote:
> Thanks for your comments. The problem is that things are really dynamic here.
> Every time you double click a folder, the current ShellView object is
> destroyed and a new one is created. Given that I have to browse into like 30
Hi Andy,
On Friday 26 August 2005 22:26, Andreas Mohr wrote:
> Why not use a watchpoint on that location?
> Choose some significant function call a while before the crash,
> have a breakpoint on that function (a DPA related function probably is
> best), check out which infoPtr is the relevant one,
Hi,
On Fri, Aug 26, 2005 at 10:10:16PM +0200, Michael Jung wrote:
> 1) Can someone give me some advice on how to debug such a problem?
Why not use a watchpoint on that location?
Choose some significant function call a while before the crash,
have a breakpoint on that function (a DPA related func
Hi,
Sometimes while browsing the unixfs namespace in the file dialog wine crashes
with the following console output:
=
wine: Unhandled exception (thread 0009), starting debugger...
WineDbg starting on pid 0x8
Unhandled e
Andreas Rosenberg:
>If somebody could provide me the problematic exe of DK and the address
>where the crash occurs I will put it through IDA pro. This might help
lifting the
>mystery. If IDA pro detects which compiler suite has been used to link
the EXE,
>it should be "easy" to detect where the s
Could you see if it runs ok when launched with winecfg ?
--- Mike Hearn <[EMAIL PROTECTED]> a écrit :
> A crud.
>
> I wonder if when a program is invoked directly from the wine loader
> app we
> should pretend it's been run from Explorer and pass it the full path.
> Alexandre, would that be
> Perhaps. I'd be willing to bet that virtually all (gui) win32 apps are
> tested by running it from explorer or the shell, which seems to use full
> paths though.
I'd also bet 5 EUROs ;-)
> So the fact that we usually run without a full path seems to
> be problematic. I guess there's a slight c
On Sat, 17 Jan 2004 20:29:00 +, Jason Edmeades wrote:
> I'd be worried this may cause more problems than it solves.
Perhaps. I'd be willing to bet that virtually all (gui) win32 apps are
tested by running it from explorer or the shell, which seems to use full
paths though. So the fact that we
Wow, lots of updates, and rather than reply to each let me try to summarize.
>> The one thing I couldnt answer is how the game 'gets' the command line.
>int WinMain( HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR
lpCmdLine, int nCmdShow ); Perhaps this way?
No, I noticed the difference betwe
On Sat, 17 Jan 2004 15:00:55 +0100, Frank Schruefer wrote:
> * Note that both Start Menu Execute and Explorer start programs with
> * fully specified quoted app file paths, which is why probably the only case
> * where you'll see single file names is in case of direct launch
> * via CreateP
Frank Schruefer wrote:
> But now what to do?
> Suggestions?
Shouldn't the WINE exe loader imitate the behavior of an application
being started by the Explorer in Windows?
I don't know if this is a possible solution, but this seems to be the
most "compatible" one. I think the NT behavior is tha
Frank Schruefer wrote:
(REPOST, somehow this message yesterday didn't go through until now, strange!
Sorry if you may get it twice.)
You are not subscribed to the list as [EMAIL PROTECTED], so
your postings go through moderation.
Frank Schruefer wrote:
Hy Jason
Really cool man!
I was following your posts here in real time and you almost found
solutions faster than
I could try them out, LOL!
I can confirm that the screen switches and a picture shows up when using
full win-path
and the mouse acts weird.
Haven't tried comm
(REPOST, somehow this message yesterday didn't go through until now, strange!
Sorry if you may get it twice.)
Frank Schruefer wrote:
Hy Jason
Really cool man!
I was following your posts here in real time and you almost found
solutions faster than
I could try them out, LOL!
I can confirm that the
Use tools/findfunc rather than grep to find Win32 functions in the Wine
tree.
Cool, that saves me from creating crazy grep constructs. Thanks for the tip.
Think I'll investigate the contents of the tools dir a bit further now ...
--
Regards,
Frank
Frank Schruefer wrote:
Hy Jason
Really cool man!
I was following your posts here in real time and you almost found
solutions faster than
I could try them out, LOL!
I can confirm that the screen switches and a picture shows up when using
full win-path
and the mouse acts weird.
Haven't tried comm
Mike Hearn wrote:
On Fri, 16 Jan 2004 20:02:08 -0500, Vincent Béron wrote:
Use tools/findfunc rather than grep to find Win32 functions in the Wine
tree.
Or better, make tags/make etags - I find this works very well.
Or:
http://source.winehq.org/ident
On Fri, 16 Jan 2004 23:19:33 +, Jason Edmeades wrote:
>> The disassembly of the failure shows we have written to eax, and info
>> regs shows eax of 0x00.
>> dis 0x4e4a20 shows the routine where the return value is set up in
>> eax, and some debugging shows the initial problem is a path proble
On Fri, 16 Jan 2004 20:02:08 -0500, Vincent Béron wrote:
> Use tools/findfunc rather than grep to find Win32 functions in the Wine
> tree.
Or better, make tags/make etags - I find this works very well.
Hello guys,
I'm watching this thread since yesterday.
Perhaps I can give you a clue.
> >I'm trying to investigate that GetCommandLine thing.
> The one thing I couldnt answer is how the game 'gets' the command line.
int WinMain(
HINSTANCE hInstance,
HINSTANCE hPrevInstance,
L
>I was following your posts here in real time and you almost found
solutions faster than I could try them out, LOL!
To be honest these things come down to luck sometimes, depending on what
direction you start debugging! I was very lucky with this one - I ran
them side by side on 2 machines, one
PS Anyone know if MSDEV has the ability to debug pgms under wine yet?
windbg used to run (it was a long time ago, and I didn't check
recently). At least, the debugging API was ok. YMMV.
PPS I really wish the winedbg had a memory dump routine (bytes +
ascii)... is it possible with the cmd set avai
Le ven 16/01/2004 à 19:40, Frank Schruefer a écrit :
> Hy Jason
>
> Really cool man!
> I was following your posts here in real time and you almost found solutions faster
> than
> I could try them out, LOL!
>
> I can confirm that the screen switches and a picture shows up when using full
> win-p
Hy Jason
Really cool man!
I was following your posts here in real time and you almost found solutions faster than
I could try them out, LOL!
I can confirm that the screen switches and a picture shows up when using full win-path
and the mouse acts weird.
Haven't tried commenting out anything yet. I
Note:
wine C:\\DK\\KEEPER95 gets things significantely further (flash
screen) before the next crash.
Thats it for me on this problem, Sorry!
Jason
Bed? Whats that... I just couldnt resist.
The next problem is ddraw surface fails swhen the main surface is
destroyed and it has an attached pale
The disassembly of the failure shows we have written to eax, and info
regs shows eax of 0x00.
dis 0x4e4a20 shows the routine where the return value is set up in
eax, and some debugging shows the initial problem is a path problem.
The routine parses the input path which inder windows is
c:\path
Hope you dont mind, I was bored and its a small download (DK1).
The disassembly of the failure shows we have written to eax, and info
regs shows eax of 0x00.
dis 0x4e4a20 shows the routine where the return value is set up in eax,
and some debugging shows the initial problem is a path problem. Th
Eric, could you please submit that patch? Even if it's not correct, having
the debuggers out of action like this is causing big problems.
I won't submit the patch as it today:
- too hacky
- not correct (we use the debugger thread environment, while we should
use the debuggees environment. This sho
Good luck! Please don't be discouraged if you can't crack this one though,
both me and Lionel have looked at Dungeon Keeper (1 and 2) and couldn't
figure out why it doesn't work. Lionel has been a Wine hacker for 5+ years
now! If you can't get DK to work, or are finding it too
frustrating, perhaps
On Thu, 15 Jan 2004 15:36:17 +0200, Boaz Harrosh wrote:
> Just a long shot. I had a problem with my own program. where I would
> crush on a bug as so:
>
> in the code at global scope I had:
>
> SomeStruct table[] = {
> {1,2,3,4}
> {1,2,3,4}
> .
> {1,2,3,4}
> } ;
> // Note tha
Mike Hearn wrote:
IIRC keeper makes only one or two API calls before crashing, both of those
calls are trivial and succeed (setting a timer or something I think) so
it's more likely to be to do with the layout of an in memory struct or
something. Remember that the TEB is stored in %fs, if you se
On Thu, 15 Jan 2004 01:00:32 +0100, Frank Schruefer wrote:
> Hey list,
>
> I like to learn how to fix wine problems myself and am trying to track down an
> exception
> occuring while starting good old 'Dungeon Keeper'.
Good luck! Please don't be discouraged if you can't crack this one though,
bo
Hy list,
I like to learn how to fix wine problems myself and am trying to track down an
exception
occuring while starting good old 'Dungeon Keeper'.
For now I have two problems:
1. When I invoke the game with 'wine' and with 'winedbg' I get different exception
messages
(traces see below), why
51 matches
Mail list logo
