http://bugs.winehq.org/show_bug.cgi?id=4427
------- Additional Comments From vitaliy(a)kievinfo.com 2006-14-02 21:11 -------
That backtrace has nothing to do with what crashed. That is a crash after the
crash. Steam tries to get all the info for their memdump and crashing on not
implemented function dbghelp.dll.SymGetSymFromAddr64.
To get any usefull information here one would need to get a huge huge huge relay
trace and go through it. Or possibly try to run under a debugger (if that will
work). Or just pock around and see what might be wrong.
Also make sure that you have OSS device available when you start CS:S. I've
found that no sound leads to the crash.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=4567
tkho(a)ucla.edu changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |tkho(a)ucla.edu
------- Additional Comments From tkho(a)ucla.edu 2006-14-02 20:37 -------
I've implemented EM_SCROLLCARET in this patch:
http://www.seas.ucla.edu/~kho/wine/patches/riched20_20060209-2-2.patch
It'll apply cleanly if you remove the changes to the conformance test. I'm
waiting for the acceptance of another patch before I re-submit this.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=4458
------- Additional Comments From tkho(a)ucla.edu 2006-14-02 17:39 -------
Created an attachment (id=1895)
--> (http://bugs.winehq.org/attachment.cgi?id=1895&action=view)
Possible fix for bug 4458
This patch solves the problem at hand, stopping the client area from focusing
the caret on EM_SETSEL when rich edit 1.0 emulation is turned on. However, the
effects of ME_Repaint() are far-reaching, and I'm not 100% sure this is the
best fix.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=4436
------- Additional Comments From J.A.Gow(a)furrybubble.co.uk 2006-14-02 17:26 -------
Created an attachment (id=1894)
--> (http://bugs.winehq.org/attachment.cgi?id=1894&action=view)
Further updated patch to fix one of ole32 issues
I found some errors in the code I included in the earlier patch. This patch
corrects these errors. Furthermore this patch results in the storage object now
properly cleaning up after itself if it is deleted ahead of streams within it.
This now correctly implements the algorithm I had in mind (I hope)
There is one issue with it that needs to be corrected: I need to call the
destructor for the IStream objects from the code but I am not sure where best
to place the prototype - would it be better to create a stg_stream.h file and
dump it in there, or to place it elsewhere, say in storage.h. At the moment it
is unprototyped which throws a warning, but will be OK in 32-bit code. I'd
rather not leave it like this. Any suggestions?
Re style - I take your points Mike, however I always thoroughly clean up the
patch just before actual submission when development of it is complete in order
to remove any redundant changes, alter style etc. During development when the
code is being functionally tested it is a lot easier to spot my changes in a
several-thousand-line source file when they look different, and it is quicker
to code in a style I am used to.The "standard" list implementation is nice and
simple, though. Thanks for the pointers here (no pun intended) I didn't
immediately realize this existed within the Wine codebase.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=4458
tkho(a)ucla.edu changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |tkho(a)ucla.edu
------- Additional Comments From tkho(a)ucla.edu 2006-14-02 17:13 -------
I believe the problem is that Wizmo uses rich edit 1.0 (in riched32), which has
a different effect for EM_SETSEL.
We're seeing this because Wine's rich edit 1.0 is a wrapper around rich edit
2.0+. The specific problem is that when you select text via EM_SETSEL, rich edit
1.0 *does not* move the caret into view, while rich edit 2.0 *does* move the
caret into view.
I think this explains both the "caret at the bottom" problem and the "scroll
back" problem. I'll look into fixing this.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=4576
Summary: winecfg not creating first dos drive
Product: Wine
Version: 0.9.7.
Platform: PC
OS/Version: other
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: wine-tools
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: pub(a)zvyozdochkin.ru
WineCfg can describe dos drives (c:...) ONLY if I manually created
~/.wine/dosdevices directory BEFORE it. If ~/.wine/dosdevices not exists, and
winecfg is running under terminal, message "unable to define devicename of 'C:',
targetpath of '/usr/share/wine-c'" appear in terminal window.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=4575
xerox_xerox2000(a)yahoo.co.uk changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Component|wine-binary |wine-directx-ddraw
Ever Confirmed| |1
Keywords| |download
------- Additional Comments From xerox_xerox2000(a)yahoo.co.uk 2006-14-02 15:20 -------
Confirming. Probably a ddraw bug. If you move the window downwards up to the
point that it is about to dissapear from the screen, the program also throws up
an error box (which is unreadable--> no text) and then crashes
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=4570
moz(a)liebesgedichte.siteware.ch changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution| |INVALID
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=2351
------- Additional Comments From mkh01(a)earthlink.net 2006-14-02 14:27 -------
I see this behavior using Notes 5.0.13 in wine 0.9.7 when configured as Windows
2000. Titles are displayed correctly when wine is set to Windows 98. This is a
fresh installation - nothing but wineprefixcreate, a few MS fonts, and the Notes
installer run within wine.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=4570
------- Additional Comments From hans(a)it.vu.nl 2006-14-02 14:16 -------
> Should we mark this bug INVALID?
Yes. I don't have the powers but you should be able to do so because
you are the submitter of this bug.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.