http://bugs.winehq.org/show_bug.cgi?id=15915
Summary: cinepak codec reportedly not installed, FourCC case mismatch Product: Wine Version: 1.1.7 Platform: PC OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: msvfw32 AssignedTo: wine-bugs@winehq.org ReportedBy: hoehle@users.sourceforge.net CC: dmitry@codeweavers.com
The Alien Nations / Die Völker complains that the cinepak codec is not installed. The reason is a lower/upper case mismatch in a FourCC code.
Upper-case FourCC is being supplied, as the log reveals: Call msvfw32.ICOpen(43444956,44495643,00000002) ret=00493baf trace:msvideo:ICOpen (VIDC,CVID,0x00000002) Call winmm.OpenDriver(0032fda8 L"VIDC.CVID", ...) trace:driver:OpenDriver (L"VIDC.CVID", L"drivers32", ...); But dlls/iccvid/iccvid.c implements the check if (icinfo && icinfo->fccType != ICTYPE_VIDEO) where ICTYPE_VIDEO refers to 'vidc', not VIDC.
The same check is in msvidc32/msvideo1.c and msrle32/msrle32.c
Probably a case-insensitive check is required? For instance, msvfw32/msvideo_main.c:ICOpen() uses the case-insensitive helper function compare_fourcc().
OTOH, after the case-insensitive check perhaps wine should fill in the icopen.fccType and .fccHandler slots with the FourCC case it expects (ICTYPE_VIDEO) rather than the argument it received? It seems reasonable to commit to a known character case early on in the code and use that consistently.
What is The Right Thing (TRT), i.e. what to store in fccType?
In any case, a case fix lets "Die Völker" work past this issue (and crash later in ddraw, but that's another issue).
http://bugs.winehq.org/show_bug.cgi?id=15915
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |source
http://bugs.winehq.org/show_bug.cgi?id=15915
--- Comment #1 from Dmitry Timoshkov dmitry@codeweavers.com 2008-11-06 01:36:41 --- (In reply to comment #0)
Call msvfw32.ICOpen(43444956,44495643,00000002) ret=00493baf trace:msvideo:ICOpen (VIDC,CVID,0x00000002) Call winmm.OpenDriver(0032fda8 L"VIDC.CVID", ...) trace:driver:OpenDriver (L"VIDC.CVID", L"drivers32", ...); But dlls/iccvid/iccvid.c implements the check if (icinfo && icinfo->fccType != ICTYPE_VIDEO) where ICTYPE_VIDEO refers to 'vidc', not VIDC. The same check is in msvidc32/msvideo1.c and msrle32/msrle32.c
All the video codec drivers in Wine perform that check.
Probably a case-insensitive check is required? For instance, msvfw32/msvideo_main.c:ICOpen() uses the case-insensitive helper function compare_fourcc().
A test case that calls OpenDriver with upper/lower/mixed cased fccType/fccHandler would help.
http://bugs.winehq.org/show_bug.cgi?id=15915
Jeff Zaroyko jeffz@jeffz.name changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jeffz@jeffz.name
http://bugs.winehq.org/show_bug.cgi?id=15915
--- Comment #2 from Jörg Höhle hoehle@users.sourceforge.net 2008-11-07 07:50:48 --- Created an attachment (id=17128) --> (http://bugs.winehq.org/attachment.cgi?id=17128) trace from ICOpen(VIDC,CVID) upto MessageBox(error)
All the video codec drivers in Wine perform that check.
You mean other applications would have run into this case-sensitivity issue long ago if it really were a problem area?
One difference that may affect "Die Völker" and not others might be how the driver was registered, as ICOpen() contains three paths to open a driver (omitting the 16 bit path): return MSVIDEO_OpenFunction(fccType, fccHandler, wMode, driver->proc, 0); hdrv = OpenDriver(codecname, drv32W, (LPARAM)&icopen); hdrv = OpenDriver(driver->name, NULL, (LPARAM)&icopen);
In the third case, OpenDriver() is called with the internally registered name (in the driver structure): the supplied fccType is ignored after a case-insensitive match, so no case mismatch can ever happen later. This behaviour is different from the two other paths, which preserve the supplied fccType.
Attached is a log snippet from the call to ICopen until the error message is displayed, so as to hopefully be able to follow what happens.
http://bugs.winehq.org/show_bug.cgi?id=15915
--- Comment #3 from Jörg Höhle hoehle@users.sourceforge.net 2008-12-08 15:08:25 --- Created an attachment (id=17760) --> (http://bugs.winehq.org/attachment.cgi?id=17760) testcase with mixed case in ICOpen(fcc,handler)
In wine, the following tests fail, whereas on a MS-w2k system, all combinations succeed. mmio.c:457: Test failed: ICOpen(VIDC.cvid) failed mmio.c:467: Test failed: ICOpen(VIDC.CVID) failed
Please feel free to add the file to the testsuite at an appropriate location (create msvfw32/tests/?).
http://bugs.winehq.org/show_bug.cgi?id=15915
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |testcase
http://bugs.winehq.org/show_bug.cgi?id=15915
--- Comment #4 from Jörg Höhle hoehle@users.sourceforge.net 2008-12-19 06:34:59 --- Test case is now in git, cf. msvfw32/tests/
http://bugs.winehq.org/show_bug.cgi?id=15915
Zhenya Zenitur@yandex.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever Confirmed|0 |1
--- Comment #5 from Zhenya Zenitur@yandex.ru 2009-02-28 23:15:06 --- *** This bug has been confirmed by popular vote. ***
http://bugs.winehq.org/show_bug.cgi?id=15915
--- Comment #6 from Jörg Höhle hoehle@users.sourceforge.net 2009-03-26 06:00:44 --- Update to comment #0: With wine-1.1.17, the quick hack to the fcc check enables the application to start (not crash anymore somewhere later). I.e. this issue prevents its AppDB rating to climb from garbage to silver (as far as I can tell after 2 minutes of playing it).
Sound and music work, resolution change works. The intro video is not played (cf. bug #17836). Instead, one must click twice inside the initially black screen to have the main menu appear. From there on, everything seems fine.
http://bugs.winehq.org/show_bug.cgi?id=15915
Jörg Höhle hoehle@users.sourceforge.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Blocks| |17893
http://bugs.winehq.org/show_bug.cgi?id=15915
--- Comment #7 from Jörg Höhle hoehle@users.sourceforge.net 2009-04-08 04:26:59 --- FourCC Patch was submitted http://article.gmane.org/gmane.comp.emulators.wine.patches/66000 It's invisible in http://www.winehq.org/pipermail/wine-patches/2009-April/071599.html because the e-mail was split at the line starting with "From: " in the body!
http://bugs.winehq.org/show_bug.cgi?id=15915
Jörg Höhle hoehle@users.sourceforge.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED
--- Comment #8 from Jörg Höhle hoehle@users.sourceforge.net 2009-04-27 05:00:50 --- Patch was accepted into wine-1.1.19. Program installs and runs fine now (I still need to perform more tests before updating AppDB).
http://bugs.winehq.org/show_bug.cgi?id=15915
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #9 from Alexandre Julliard julliard@winehq.org 2009-05-08 12:48:22 --- Closing bugs fixed in 1.1.21.
http://bugs.winehq.org/show_bug.cgi?id=15915
Zhenya Zenitur@yandex.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |Zenitur@yandex.ru
--- Comment #10 from Zhenya Zenitur@yandex.ru 2011-04-07 05:59:14 CDT --- I found some fixed bug in Cinepak realization on Windows. Check your patch. http://support.microsoft.com/kb/982665/
-
wine-bugs＠winehq.org