[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: wine-bugs(a)winehq.org ReportedBy: hoehle(a)users.sourceforge.net CC: eric.pouech(a)orange.fr 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. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=23975 Dmitry Timoshkov <dmitry(a)codeweavers.com> 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 <dmitry(a)codeweavers.com> 2010-08-12 07:24:55 --- For a query there is no open a bug report. Bugzilla is for bugs, not for conversations. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=23975 Dmitry Timoshkov <dmitry(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #2 from Dmitry Timoshkov <dmitry(a)codeweavers.com> 2010-08-12 07:25:06 --- Closing. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=23975 Jörg Höhle <hoehle(a)users.sourceforge.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|CLOSED |UNCONFIRMED Platform|Other |All Resolution|INVALID | OS/Version|other |Linux --- Comment #3 from Jörg Höhle <hoehle(a)users.sourceforge.net> 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. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=23975 Dmitry Timoshkov <dmitry(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Platform|All |Other --- Comment #4 from Dmitry Timoshkov <dmitry(a)codeweavers.com> 2010-08-12 08:26:22 --- Is there an application that is affected by this? -- 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.
http://bugs.winehq.org/show_bug.cgi?id=23975 --- Comment #5 from Jörg Höhle <hoehle(a)users.sourceforge.net> 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. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=23975 --- Comment #6 from Dmitry Timoshkov <dmitry(a)codeweavers.com> 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? -- 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.
http://bugs.winehq.org/show_bug.cgi?id=23975 --- Comment #7 from Eric Pouech <eric.pouech(a)orange.fr> 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+ -- 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.
http://bugs.winehq.org/show_bug.cgi?id=23975 --- Comment #8 from Jörg Höhle <hoehle(a)users.sourceforge.net> 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.
-- 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.
http://bugs.winehq.org/show_bug.cgi?id=23975 --- Comment #9 from Eric Pouech <eric.pouech(a)orange.fr> 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) -- 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.
http://bugs.winehq.org/show_bug.cgi?id=23975 --- Comment #10 from Jörg Höhle <hoehle(a)users.sourceforge.net> 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). -- 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.
http://bugs.winehq.org/show_bug.cgi?id=23975 --- Comment #11 from Jörg Höhle <hoehle(a)users.sourceforge.net> 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. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=23975 --- Comment #12 from Jörg Höhle <hoehle(a)users.sourceforge.net> 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. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=23975 Jörg Höhle <hoehle(a)users.sourceforge.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |FIXED --- Comment #13 from Jörg Höhle <hoehle(a)users.sourceforge.net> 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. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=23975 Alexandre Julliard <julliard(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #14 from Alexandre Julliard <julliard(a)winehq.org> 2011-01-21 13:44:15 CST --- Closing bugs fixed in 1.3.12. -- 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.
participants (1)
-
wine-bugs＠winehq.org