mmsystem: Improve 16 bit mapping for MCI_WHERE/PUT/FREEZE/UNFREEZE.

Damjan,

can you recommend any downloadable 16bit app that stresses the MCI?

It's good that you noticed that RECT16 and RECT do not have the same size (whack!).
Yet I'm surprised that you left MCI_WINDOW untouched.  I believe that
the apps that use MCI_WHERE/PUT etc. (i.e. MCIAVI) are likely to use
MCI_WINDOW as well to set the window handle.

Does no FIXME appear in your console?
http://source.winehq.org/source/dlls/mmsystem.dll16/mci16.c#L182
The comment there is obsolete.  dwFlags is available and could be used like I did in
db0df4c067fd6b701905aaef735c4729fca9d73f

Regards,
 Jörg Höhle

mmsystem: Improve 16 bit mapping for MCI_WHERE/PUT/FREEZE/UNFREEZE.

[Damjan Jovanovic]

On Thu, Apr 28, 2011 at 11:27 AM,  <Joerg-Cyril.Hoehle(a)t-systems.com> wrote:
> Damjan,
>
> can you recommend any downloadable 16bit app that stresses the MCI?
>
> It's good that you noticed that RECT16 and RECT do not have the same size (whack!).
> Yet I'm surprised that you left MCI_WINDOW untouched.  I believe that
> the apps that use MCI_WHERE/PUT etc. (i.e. MCIAVI) are likely to use
> MCI_WINDOW as well to set the window handle.
>
> Does no FIXME appear in your console?
> http://source.winehq.org/source/dlls/mmsystem.dll16/mci16.c#L182
> The comment there is obsolete.  dwFlags is available and could be used like I did in
> db0df4c067fd6b701905aaef735c4729fca9d73f
>
> Regards,
>  Jörg Höhle

I am testing apps on magazine CDs from +/- 1997. Some of these are
freeware/shareware so I could redistribute them, but the one that
causes this problem is the autorun application itself, so it's
probably not redistributable :-(. I'll investigate and try find
others.

Yes I get that FIXME, but it doesn't corrupt the stack (as badly?) as
the other MCI calls (I'll have to check later). BTW I've made a patch
to detect Win16 stack corruption for +relay traces on
http://wiki.winehq.org/InterestingPatches, but it only works when the
stack is corrupted so badly that the [ss:bp] value at the top of the
stack is changed during the call to Wine.

In the meanwhile I've found another problem: mciavi32 always deadlocks
when MCI_WAIT is not set:
dlls/mciavi.c function MCIAVI_mciPlay() is called in the UI thread
line 433 calls MCIAVI_mciPlay_async()
line 381 calls CreateThread()
line 389 waits for ack_event
the thread line 360 calls MCIAVI_mciPlay() again, with MCI_WAIT set
the thread line 436 calls ShowWindow()
since ShowWindow() blocks until the UI thread pumps the message loop
and replies, and the UI thread is blocked in line 389 waiting for
ack_event which the thread only calls SetEvent() on later -> deadlock
Unfortunately setting ack_event earlier to avoid the deadlock, still
doesn't get video to play.

Regards
Damjan Jovanovic