[Bug 23975] New: mcicda wants to open the nth cdrom in the system

http://bugs.winehq.org/show_bug.cgi?id=23975

Summary: mcicda wants to open the nth cdrom in the system
           Product: Wine
           Version: 20020228
          Platform: All
        OS/Version: All
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: winmm&mci
        AssignedTo: [e-mail]
        ReportedBy: [e-mail]
                CC: [e-mail]

Eric,

I wanted to query you about the change you introduced 2002-01-13.
As the subject says, MCI_Open opens the nth drive of type CD-ROM,
where N is the dwDeviceID passed to the command.

Currently Wine passes in the device ID that will be used if Open succeeds, i.e.
the number of open MCI devices (I believe it was 0 at some time in the past).
Therefore
open cdaudio alias c will work, while

open new type waveaudio alias w
open avivideo alias a
open cdaudio alias e
will likely fail in Wine, unless you have 3 CD-ROMs.
This is a bug.  It works in native.

I found no documentation for this N thing in MSDN.  Where does it come from?

My own testing -- as far as it can go with a single drive -- suggests
that there's no such functionality in native.  Quite to the contrary,
using SHAREABLE, I could open a device multiple times using

mciSendCommand(N>0, MCI_OPEN,
  MCI_OPEN_TYPE|MCI_OPEN_TYPE_ID | MCI_OPEN_SHAREABLE,
  (DWORD_PTR)&parm);
(Not using SHAREABLE seems to reveal an interesting bug in native for N>0).

OTOH, perhaps this functionality exists in the driver, i.e. not accessible at
the level of mciSendCommand and the bug is in Wine's MCI that does not pass a 0
as default id (it should pass 0 and stuff the new ID in openparms.wDeviceID)?

BTW, you may be interested by the mcicda patches I recently submitted.

Regards,
 Jörg Höhle.

[Bug 23975] mcicda wants to open the nth cdrom in the system

http://bugs.winehq.org/show_bug.cgi?id=23975

Dmitry Timoshkov  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
           Platform|All                         |Other
            Version|20020228                    |1.3.0
         Resolution|                            |INVALID
         OS/Version|All                         |other

--- Comment #1 from Dmitry Timoshkov   2010-08-12 07:24:55 ---
For a query there is no open a bug report. Bugzilla is for bugs, not for
conversations.

[Bug 23975] mcicda wants to open the nth cdrom in the system

http://bugs.winehq.org/show_bug.cgi?id=23975

Dmitry Timoshkov  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED

--- Comment #2 from Dmitry Timoshkov   2010-08-12 07:25:06 ---
Closing.

[Bug 23975] mcicda wants to open the nth cdrom in the system

http://bugs.winehq.org/show_bug.cgi?id=23975

Jörg Höhle  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|CLOSED                      |UNCONFIRMED
           Platform|Other                       |All
         Resolution|INVALID                     |
         OS/Version|other                       |Linux

--- Comment #3 from Jörg Höhle   2010-08-12 08:10:01 ---
Dmitry, you didn't read what I wrote:
> This is a bug.

I choose to have it here because
a) It's a bug, with a trivial testcase.
b) Here's where discussions about bugs occur, until it is fixed,
   regardless of whether the sole commenters might be Eric and me.

[Bug 23975] mcicda wants to open the nth cdrom in the system

http://bugs.winehq.org/show_bug.cgi?id=23975

Dmitry Timoshkov  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
           Platform|All                         |Other

--- Comment #4 from Dmitry Timoshkov   2010-08-12 08:26:22 ---
Is there an application that is affected by this?

[Bug 23975] mcicda wants to open the nth cdrom in the system

http://bugs.winehq.org/show_bug.cgi?id=23975

--- Comment #5 from Jörg Höhle   2010-08-12 08:40:28 ---
Every app that uses another MCI device beside mcicda could be affected
depending on the order of Open, although I know of none in particular.
There are no logs yet attached to bug #16324, so I don't know whether that
could explain it.

[Bug 23975] mcicda wants to open the nth cdrom in the system

http://bugs.winehq.org/show_bug.cgi?id=23975

--- Comment #6 from Dmitry Timoshkov   2010-08-12 09:16:36 ---
(In reply to comment #5)
> Every app that uses another MCI device beside mcicda could be affected
> depending on the order of Open, although I know of none in particular.
> There are no logs yet attached to bug #16324, so I don't know whether that
> could explain it.

So this is either duplicate or pure theoretical issue?

[Bug 23975] mcicda wants to open the nth cdrom in the system

http://bugs.winehq.org/show_bug.cgi?id=23975

--- Comment #7 from Eric Pouech   2010-08-12 10:20:34 ---
according to http://msdn.microsoft.com/en-us/library/dd743441%28VS.85%29.aspx
in the OPEN_TYPE_ID case, the HIWORD is supposed to be the index of the device
(if any)
so, (I haven't tested it) the code in mcicda.c should be changed to cover this
case (and using dwDeviceId is likely wrong as you pointed out)
some other sources also state that for a given device type (like cdaudio),
cdaudioN is also a valid name (cdaudio0 being cdaudio...)
if this is correct (I don't have a dual cdrom setup at hand), the mci string
parser has to be fixed as well
A+

[Bug 23975] mcicda wants to open the nth cdrom in the system

http://bugs.winehq.org/show_bug.cgi?id=23975

--- Comment #8 from Jörg Höhle   2010-08-12 12:26:30 ---
Now I understand the confusion.  The highword refers to the mechanism to select
an MCI driver when there are several ones of the same type.  These are then
numbered something like mpegvideo, mpegvideo2 etc.  As you say, there's no code
to support this in Wine (several places would have to be modified).
As a string: mciSendString "open mpegvideo2"
As a command: mciSendCommand MCI_DEVTYPE_XYZ | number<<16
I never found a need for such support (and hence skipped writing tests for
mciwave about this).  Wine only has one driver per type.

This is entirely different from having one MCI driver support several devices,
which Wine supports (e.g. the one mciseq.dll can access winmm MIDI device #0,
#1 etc., mcicda.dll can open devices D: E: F: etc.)
> so the code in mcicda.c should be changed to cover this case

No.  My understanding is that the individual MCI driver never see (or must
ignore) the highword.  Its treatment happens a layer above, i.e. the WINMM-MCI.
 The latter receives an open call to mpegvideo or mpegvideo2, selects the
corresponding .dll according to windows\system.ini and loads it.  The loaded
driver is not the one to decide "mpegvideo<N> is me/not me".  IIRC I read about
this in MSDN somewhere.

[Bug 23975] mcicda wants to open the nth cdrom in the system

http://bugs.winehq.org/show_bug.cgi?id=23975

--- Comment #9 from Eric Pouech   2010-08-13 02:56:34 ---
I don't agree. The mci driver must be passed by winmm an id to know which
device id has to be opened. I agree that the mci driver doesn't have to know
about the cdaudio1 string parsing.

Therefore, the following scheme has to be implemented:
- mcicda (and all mci drivers) must support (if relevant, ie mciwave is not
relevant) the hiword in mci_open requests, with mci_open_type_id flag set. This
lets the mci driver know which device (if several installed on computer) to
open.
- winmm shall:
   + transfer to mci driver the hiword in case of mci_open request, with
mci_open_type_id flag set (mciOpen function)
   + in string handling (mciSendString function), should also cover the
cdaudio1 (and the like constructs) for device name
   => the full construct (in .ini file, and registry should be the same IMO),
is cdaudio1=mcicda.drv 1 ; which should be managed by winmm as:
      . define a new type of mci driver of name cdaudio1,
      . to be managed by mcicda.drv,
and that should be opened with mci_open_type_id flag set, and hiword of
deviceid to be 1 (which comes after the driver name)

[Bug 23975] mcicda wants to open the nth cdrom in the system

http://bugs.winehq.org/show_bug.cgi?id=23975

--- Comment #10 from Jörg Höhle   2010-08-13 09:11:53 ---
> winmm shall transfer to mci driver the hiword

Ok. Isn't that passed through untouched already?
> in string handling should cover the cdaudio1 for device name

I fully agree.  But as I wrote, I never saw an app need this, because nobody
seems to have several drivers of the same type (save for MPEGVIDEO2).
> cdaudio1=mcicda.drv 1

What's the trailing 1?
http://msdn.microsoft.com/en-us/library/dd797882%28v=VS.85%29.aspx
> From what I understood, the trailing number after cdaudio is the extra index

already.
Perhaps there's no 1. The first string is mpegvideo, the second mpegvideo2. Yet
MSDN above has an example with cdaudio1.
> The mci driver must be passed by winmm an id to know which
> device id has to be opened.

No, see below.
> Therefore, the following scheme has to be implemented

I think you should first test that on a native system with several devices
(which kind of devices? MCI? hardware drivers?).  I can't remember anything in
MSDN like what you describe.  Seriously, I doubt it.
> all mci drivers must support (if relevant, ie mciwave is not
> relevant) the hiword in mci_open requests, with mci_open_type_id flag set. This
> lets the mci driver know which device (if several installed on computer) to
> open.

I don't understand when it's relevant and when not and how winmm could decide.

My conceptual model explains a lot of observations: A provider writes a device
for his HW, let's say a blue ray reader. For the sake of the example he finds
DEVTYPE_CDAUDIO appropriate (not DGV).  The *installer* creates CDAUDIO1 =
mciblue.dll because CDAUDIO is already present.

This can be opened either with "open type cdaudio2", by file extension when it
maps to CDAUDIO1 or with (MCI_DEVTYPE_CDAUDIO|1<<16).  The driver receives the
MCI_OPEN command but it's *not* going to look at the content of
lpstrDeviceType.  That was the job of WINMM-MCI.  If there are several blue-ray
devices from the same manufacturer attached to the system, it's still the one
mciblue.dll hardware driver that manages them all, and likely selects one based
on lpstrElementName (like mcicda) or an extra set command (like mciseq and
mciwave).

[Bug 23975] mcicda wants to open the nth cdrom in the system

http://bugs.winehq.org/show_bug.cgi?id=23975

--- Comment #11 from Jörg Höhle   2010-08-13 09:33:42 ---
To try and express myself clearer:
open cdaudio<N> is strictly equivalent to open MCI_DEVTYPE_CDAUDIO|N<<16
Since the system.ini (undoubtfully IMHO) tells what .dll/drv is attached with
CDAUDIO<N>, that's the driver to load.  The driver does not care whether it was
installed as CDAUDIO1 or CDAUDIO2 on a particular system, nor does it need or
receive any extra parameters.

[Bug 23975] mcicda wants to open the nth cdrom in the system

http://bugs.winehq.org/show_bug.cgi?id=23975

--- Comment #12 from Jörg Höhle   2010-08-26 15:39:44 ---
Open nth device is fixed by commit ecb02ec9b78670152d6672299e856e63d18e90a5

Please decide whether to mark this issue as fixed or to rename the subject and
turn it into an enhancement request for mpegvideo/cdaudio<N> parsing according
to the discussion in comment #7 to comment #11.

BTW, testing (xp) shows that cdaudio != cdaudio0. Only the former works.

[Bug 23975] mcicda wants to open the nth cdrom in the system

http://bugs.winehq.org/show_bug.cgi?id=23975

Jörg Höhle  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |FIXED

--- Comment #13 from Jörg Höhle  2011-01-13 05:59:41 CST ---
The issue the subject is about is fixed.
A possible enhancement request about handling numeric suffices like MPEGVIDEO2
should be a separate issue.

[Bug 23975] mcicda wants to open the nth cdrom in the system

http://bugs.winehq.org/show_bug.cgi?id=23975

Alexandre Julliard  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED

--- Comment #14 from Alexandre Julliard  2011-01-21 13:44:15 CST ---
Closing bugs fixed in 1.3.12.