Fwd: Re: [Wine]DC++ crashes with current CVS wine

[Pavel Troller]

Hi!
  I've sent the message below to wine-users mailing list and nobody has replied
until now. So I subscribed do wine-devel and I'm posting the message here.
Of course I cannot distinguish whether this problem is important enough to be
fixed, but I think it's some problem with wine dlls so it can help other
apps too.. 
  With regards, Pavel Troller

- Forwarded message from Pavel Troller <[EMAIL PROTECTED]> -

> Hi!
>  I have a problem, that DC++ client now crashes in wine. The problem is that 
> it
> crashes using its own exception handler, from the wine's point of view the app
> is running OK. The client simply pops up a dialog box saying that it just
> crashed and the debug info is placed in a file called exceptioninfo.txt. OK, 
> the
> file is really there and it really shows something important:
> 
> Code: c005
> Version: 0.4034
> Major: 4
> Minor: 10
> Build: 67766446
> SP: 0
> Type: 0
> Time: 2004-11-21 08:09:57
> TTH: EJEUEI5NYOW2OQOXRJC7OHZ2ZUSLA5JF6IPD6TI
> 
> c:\documents\vcprojects\dcplusplus\windows\transferview.cpp(195): ?
> c:\documents\vcprojects\dcplusplus\windows\transferview.h(50): ?
> c:\program files\vs.net 2003\vc7\atlmfc\include\atlwin.h(3017): ?
> user32!0x666BABF7: ?
> user32!0x666BAF39: ?
> user32!0x666C0D29: ?
> user32!0x666ED284: ?
> user32!0x666EE099: ?
> user32!0x666EE2D5: ?
> comctl32!0x57758097: ?
> comctl32!0x5775D2C5: ?
> comctl32!0x5775DFAE: ?
> comctl32!0x5775E518: ?
> comctl32!0x577666D7: ?
> comctl32!0x577675C7: ?
> user32!0x666BABF7: ?
> user32!0x666BAF39: ?
> user32!0x666C0D29: ?
> c:\program files\vs.net 2003\vc7\atlmfc\include\atlwin.h(3020): ?
> user32!0x666BABF7: ?
> user32!0x666BAF39: ?
> user32!0x666C0D29: ?
> user32!0x666A3996: ?
> c:\documents\vcprojects\include\wtl-7.5.4196\atlapp.h(499): ?
> c:\documents\vcprojects\dcplusplus\windows\main.cpp(270): ?
> 0x1F83D6C8: ?
> 
> Because user32 and comctl32 are both mentioned in the backtrace, I tried to
> switch them to native, but the program then crashed in a much worse way,
> ending at a wine-dbg> prompt.
>   This exception info is shown, when win98 is emulated. Normally I'm emulating
> nt40, in which case the backtrace is missing but the crash is looking very
> similar from the user's point of view.
>   No important information (like unimplemented call etc.) is shown in the
> wine's stdout/stderr.
>   Is there a developer which can help with this problem ?
>   With regards, Pavel Troller

Hi!
  I have a lot of news in this case: I've downloaded sources for DC++ unstable
and looked onto them to see in which place the program crashes. I've found that
it occurs when the download/upload progress bar is about to be drawn. I've also
found that progress bar drawing can be disabled in advanced setting (oh yes,
source is the best user's manual You can have :-) ). I did so and DC++ started
to work for me.
  I think that it is a good starting point for a wine developer to find, what's
happening there, it should be easy to find when the source code which exhibits
the bug is available and exact location of bug invocation is known. Because I
know windows at a zero level, I cannot help with this, but I hope that others
can, and fixing this bug may help other apps too (and, even in DC++, the bars
are a nice eye-candy :-) ).
  Should I post this message to wine-devel, or is it enough to post it here,
in wine-users ?
   With regards, Pavel Troller

- End forwarded message -

Re: Poor performance when using Texas Instruments code generation tools in Wine

[Pavel Troller]

> Hi !
> 
> We have some performance problems with Wine that we could use some help on..
> 
> Here's the story:
> 
> We have been using TI code generation tools (compiler and linker) on 
> Wine, and it has worked well. However, when we started evaluating newer 
> versions of the codegen tools, the linking time was dramatically 
> increased (from 20 sec to 30 minutes...).
> 
> We have done some profiling using oprofile, and found that most of this 
> time (96%) is spent in the HEAP_FindFreeBlock* *function in the ntdll 
> module. The time needed to locate a free heap block increases gradually, 
> from a few iterations up to about 15000 in the project we are building. 
> We suspect that this may be due to fragmentation caused by the heap 
> allocate/free algorithms.
> 
Hi!
  Maybe this can also explain the slowdown of long-running apps under wine ?
For example, DC++ runs perfectly when started, but after 12 hours of operation
the window updates, search and other program functions are so incredibly slow,
that it's better to kill it and restart.
   With regards, Pavel Troller

Reporting "Unknown EXE OS version" and a non-functioning program

[Pavel Troller]

Hi!
  Because my kids are obsessed by trains and everything about them, I've 
decided to download them a train simulation game. Because I refuse to use
anything from M$ and I didn't find any train simulator for Linux, I've found
and downloaded a free "miniature train simulator", available for download at
http://jeanmichel.kerdal.free.fr/Train/train.zip . I've unzipped the package
and tried to run the Install.exe file. But the only I get is
[EMAIL PROTECTED]:~/train$ wine Install.exe
fixme:ver:VERSION_GetLinkedDllVersion Unknown EXE OS version 4.0, please report 
!!
fixme:ole:CoRegisterMessageFilter stub
fixme:ole:OleLoadPictureEx 
(0x7f9bdd4c,326,0,{7bf80980-bf32-101a-8bbb-00aa00300cab},x=0,y=0,f=0,0x720dfb0c),
 partially implemented.
fixme:ole:OLEPictureImpl_SaveAsFile (0x767bd768)->(0x767bffd0, 0, (nil)), 
hacked stub.
The program then simply runs and waits fot the rain (or maybe train :-) ?)
without any visible activity and should be killed. 
  Normally I wouldn't report this because there is still a lot of programs which
are incompatible with wine (oh these windows programmers... :-) ). But this
one explicitly asked for reporting, so I'm just doing what it asked for :-).
  This is with a fresh wine CVS update, which reports itself as wine-20050310.
  
     With regards, Pavel Troller