http://bugs.winehq.org/show_bug.cgi?id=17518 Dan Kegel <dank(a)kegel.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |9916 Jörg Höhle <hoehle(a)users.sourceforge.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |hoehle(a)users.sourceforge.ne | |t --- Comment #6 from Jörg Höhle <hoehle(a)users.sourceforge.net> 2010-05-28 16:10:01 --- Dan's patch became commit ea5a6f2db5e6f05acf38f9257278cbcad58ab898 There's no more crash. Let's keep this bug open as a remainder that not all relevant places are patched. 1. TRACE(... "%s", debugstr_w(lpstrRet)) seems just as problematic. http://www.winehq.org/pipermail/wine-devel/2010-May/083747.html 2. MCI_HandleReturnValues is called even in case of error, which is at least inconsistent with Dan's commit (the buffer is left as Wchars, not 8bit). E.g. winmm logs of MCI_OPEN show that a MCI device id is placed in the buffer even when open fails. Actually, we'd IMHO first need more than that one test formerly marked todo_wine to analyse if/how the supplied buffer ever gets modified in case of error (actually mciSendStringW sets *lpstrRet = '\0' -- quite late in the code, i.e. not always, bug #3?). The question is whether some apps can expect particular contents in some error situations (e.g. partially filled buffer with MCIERR_PARAM_OVERFLOW?). -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email Do not reply to this email, post in Bugzilla using the above URL to reply. ------- You are receiving this mail because: ------- You are watching all bug changes.