How far to push behavioural compatibility with native?

Joerg-Cyril.Hoehle at t-systems.com Joerg-Cyril.Hoehle at t-systems.com
Thu Jul 8 04:32:20 CDT 2010


Hi,

Unlike mciwave, the native mciseq MIDI player does not know the
MCI_RESUME command.  It instead returns MCIERR_UNSUPPORTED_FUNCTION.
Tests with notification suggest that MCI_PAUSE actually aborts the
player, much like MCI_STOP.  It's a different behaviour than mciwave.
(You can always "resume" a paused player using MCI_PLAY without
 arguments.  MCI_RESUME is superfluous, except that "resume all" is
 different from "play all".)

OTOH, Wine implements MCI_RESUME and MCI_PAUSE functionality for the
MIDI sequencer as one would expect it to work (and mciwave does),
according to the MCI specification.

As I'm currently thinking about how to rewrite the players to avoid
various race conditions (e.g. bug #22978), I'm left wondering whether
I should drop the extra functionality that was written for Wine and
replace it with something which behaves as closely as possible like
the native player, or whether it's nice to have something more evolved
in Wine, e.g. working PAUSE and RESUME commands (and some apps issue
PAUSE ALL or RESUME ALL commands).

What do you think?
A) Bug compatibility => Behavioural compatibility => drop existing
   code and try to mimic native's behaviour as closely as possible.
B) PAUSE and RESUME is a useful extension not present in native, keep it
   as long as no app is affected by this difference in behaviour.

Regards,
	Jörg Höhle



More information about the wine-devel mailing list