No game music in Fire Fight (using cdemu already)

[mkaushik]

I'm running this very old game called "Fire Fight" v1.2 with wine and not getting any in-game music.
This game/patch is marked Platinum in AppDB.
I'm using the version of wine shipped with Ubuntu 18.04. Windows version is set to Win7

Code: Select all

~/.wine/dosdevices/d:$ wine --version 
wine-3.0 (Ubuntu 3.0-1ubuntu1)

I used cdemu to create a virtual CDROM from the game's MDF file image, and mounted the resulting /dev/sr0 device to /mnt/cdrom.

Code: Select all

~/.wine/dosdevices/d:$ cdemu status
Devices' status:
DEV   LOADED     FILENAME
0     True       /home/mkaushik/FireFight/CD/FIREFIGHT.mdf

~/.wine/dosdevices/d:$ mount | grep cdrom
/dev/sr0 on /mnt/cdrom type iso9660 (ro,relatime,nojoliet,check=s,map=n,blocksize=2048)

In winecfg the cdrom shows up correctly as d:. I use the following to run the game:

Code: Select all

~/.wine/dosdevices/d:$ wine ffstart.exe 

The game does not play any music, though sound effects/voices and the game itself work fine.

I'm pretty desperate to complete my childhood nostalgia trip with this game , so I poked around in the game's binaries using Ghidra. I think it uses the win32 API mciSendCommandA() from winmm.dll to play music. So I turned on logging in wine and noticed the following calls:

Code: Select all

:~/.wine/dosdevices/d:$ WINEDEBUG=+relay,+seh,+tid wine ffstart.exe 2>&1 | tee ~/wine_ff.log

~/.wine/dosdevices/d:$ grep mciSendCommandA ~/wine_ff.log 
0033:Call winmm.mciSendCommandA(00000000,00000803,00002002,0033fd9c) ret=00479a43
0033:Ret  winmm.mciSendCommandA() retval=00000000 ret=00479a43
0033:Call winmm.mciSendCommandA(00000001,00000814,00000102,0033fd8c) ret=00479a6e
0033:Ret  winmm.mciSendCommandA() retval=00000000 ret=00479a6e
0033:Call winmm.mciSendCommandA(00000001,00000814,00000112,0033fd78) ret=00479aae
0033:Ret  winmm.mciSendCommandA() retval=00000000 ret=00479aae
0033:Call winmm.mciSendCommandA(00000001,00000804,00000002,0033fd88) ret=00479aea
0033:Ret  winmm.mciSendCommandA() retval=00000000 ret=00479aea
0033:Call winmm.mciSendCommandA(00000001,00000808,00000002,0033f420) ret=00479c39
0033:Ret  winmm.mciSendCommandA() retval=00000101 ret=00479c39
0033:Call winmm.mciSendCommandA(00000001,00000804,00000002,0033f420) ret=00479c4a
0033:Ret  winmm.mciSendCommandA() retval=00000101 ret=00479c4a
0033:Call winmm.mciSendCommandA(00000001,00000808,00000002,0033fdd4) ret=00479c39
0033:Ret  winmm.mciSendCommandA() retval=00000101 ret=00479c39
0033:Call winmm.mciSendCommandA(00000001,00000804,00000002,0033fdd4) ret=00479c4a
0033:Ret  winmm.mciSendCommandA() retval=00000101 ret=00479c4a

From the wine source, the commands the game is sending above are MCI_OPEN (0x803), MCI_STATUS (0x814), MCI_STATUS (0x814), MCI_CLOSE (0x804), etc.
Any suggestions for things to try?

(the full log is too big to attach even when zipped )

Thanks in advance!

[Bob Wya]

I'm running this very old game called "Fire Fight" v1.2 with wine and not getting any in-game music.
This game/patch is marked Platinum in AppDB.
I'm using the version of wine shipped with Ubuntu 18.04. Windows version is set to Win7

Code: Select all

~/.wine/dosdevices/d:$ wine --version 
wine-3.0 (Ubuntu 3.0-1ubuntu1)

...

Code: Select all

:~/.wine/dosdevices/d:$ WINEDEBUG=+relay,+seh,+tid wine ffstart.exe 2>&1 | tee ~/wine_ff.log

...
(the full log is too big to attach even when zipped )
...

@mkaushik

Wine 3.0 is considered obsolete, and has been for months now.
See: WineHQ Wiki: Ubuntu: Installing WineHQ packages.
Please update to at least Wine 5.0 ...

You could trim the terminal log file down a bit, with:

Code: Select all

WINEDEBUG=+winmm,+mci,+module,+loaddll,+seh,+tid

If this will fit, then a pastebin site, like a Github Gist is ideal.
You can post this anywhere sensible, if it's too big. E.g. a personal Google Drive account.

Ta
Bob

[mkaushik]

Installing wine 5.0 made things far worse. While previously I was able to install and run the patch executable and the game itself, now both steps fail.

Code: Select all

:~/Downloads$ wine --version 
wine-5.0

Like before with wine-3.0, I first tried to install the patch for this game:

Code: Select all

~/Downloads$ wine ff12up.exe 
Segmentation fault (core dumped)

The game won't work unless the patch file above is installed (even the AppDB entry for this game says so), but I tried it anyway, and it fails silently

Code: Select all

:~/.wine/dosdevices/d:$ wine ffstart.exe 
:~/.wine/dosdevices/d:$ 

My wine installation has no symbols so the stack trace from the segfault has no information.

"Windows version" is set to Windows 7 in winecfg, which worked with wine-3.0

Attaching the log from the segfault above with

Code: Select all

WINEDEBUG=+winmm,+mci,+module,+loaddll,+seh,+tid

Thanks!

[mkaushik]

Some probably not very useful information from the core file that's generated after the segfault:

Code: Select all

:~/.wine/drive_c/users/mkaushik$ wine ff12up.exe 
Segmentation fault (core dumped)

:~/.wine/drive_c/users/mkaushik$ gdb -q `which wine` core
Reading symbols from /usr/bin/wine...(no debugging symbols found)...done.

warning: core file may not match specified executable file.
[New LWP 5035]
[New LWP 4998]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `C:\windows\syswow64\winevdm.exe --app-name C:\users\mkaushik\ff12up.exe C:\user'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x7bcb408c in call_exception_handler () from /opt/wine-stable/bin/../lib/wine/ntdll.dll.so
[Current thread is 1 (Thread 0x9c3b40 (LWP 5035))]
(gdb) t a a bt

Thread 2 (Thread 0xf7b60700 (LWP 4998)):
#0  0xf7f72059 in __kernel_vsyscall ()
#1  0xf7c5b3a7 in syscall () from /lib/i386-linux-gnu/libc.so.6
#2  0x7bc5965f in RtlpWaitForCriticalSection () from /opt/wine-stable/bin/../lib/wine/ntdll.dll.so
#3  0x7bc5a4f4 in RtlEnterCriticalSection () from /opt/wine-stable/bin/../lib/wine/ntdll.dll.so
#4  0x7e62445b in _EnterSysLevel () from /opt/wine-stable/bin/../lib/wine/krnl386.exe16.so
#5  0x7e624880 in RestoreThunkLock () from /opt/wine-stable/bin/../lib/wine/krnl386.exe16.so
#6  0x7e62599d in DirectedYield16 () from /opt/wine-stable/bin/../lib/wine/krnl386.exe16.so
#7  0x7e619ed2 in LoadModule16 () from /opt/wine-stable/bin/../lib/wine/krnl386.exe16.so
#8  0x7effafe3 in main () from /opt/wine-stable/bin/../lib/wine/winevdm.exe.so
#9  0x7effc7f6 in ?? () from /opt/wine-stable/bin/../lib/wine/winevdm.exe.so
#10 0x7b454d52 in call_process_entry () from /opt/wine-stable/bin/../lib/wine/kernel32.dll.so
#11 0x7b455211 in start_process () from /opt/wine-stable/bin/../lib/wine/kernel32.dll.so
#12 0x7b454d5e in __wine_start_process () from /opt/wine-stable/bin/../lib/wine/kernel32.dll.so
#13 0x00000000 in ?? ()

Thread 1 (Thread 0x9c3b40 (LWP 5035)):
#0  0x7bcb408c in call_exception_handler () from /opt/wine-stable/bin/../lib/wine/ntdll.dll.so
#1  <signal handler called>
#2  0x000000ae in ?? ()
Backtrace stopped: Cannot access memory at address 0xfe96
(gdb) 

[mkaushik]

I downloaded the wine5 source and built it locally (the WoW64 version) For whatever reason, this locally built wine5 is able to run the patch and the game (unlike the winehq-stable 5.0 package which caused it to segfault). Still no music though

I generated a log with the following debug flags:

Code: Select all

WINEDEBUG=+winmm,+mci,+module,+loaddll,+seh,+tid wine ffstart.exe 2>&1 | tee ~/wine5_ff.log

Looking at the mci messages in particular:

Code: Select all

:~/.wine/dosdevices/d:$ grep mci ~/wine5_ff.log 
0031:trace:mci:mciSendCommandA (00000000, MCI_OPEN, 00002002, 0032fe0c)
0031:trace:mci:mciSendCommandW (00000000, MCI_OPEN, 00002002, 027ba2b4)
0031:trace:mci:MCI_Open (00002002, 027BA2B4)
0031:trace:mci:MCI_Open devType=L"cdaudio" !
0031:trace:mci:MCI_LoadMciDriver wDevID=0001
0031:trace:module:load_dll looking for L"mcicda.dll" in L"C:\\users\\mkaushik\\Temp;C:\\windows\\system32;C:\\windows\\system;C:\\windows;.;C:\\windows\\system32;C:\\windows;C:\\windows\\system32\\wbem;C:\\windows\\system32\\WindowsPowershell\\v1.0"
0031:trace:module:get_load_order looking for L"C:\\windows\\system32\\mcicda.dll"
0031:trace:module:get_load_order got hardcoded default for L"mcicda.dll"
0031:trace:module:load_dll L"\\??\\C:\\windows\\system32\\mcicda.dll" is a fake Wine dll
0031:trace:module:load_builtin_dll Trying built-in L"mcicda.dll"
0031:trace:module:load_so_dll loading L"\\??\\C:\\windows\\system32\\mcicda.dll" from so lib "/usr/local/bin/../lib/wine/mcicda.dll.so"
0031:trace:module:load_builtin_callback loaded mcicda.dll 0x27bda10 0x7d4c0000
0031:trace:loaddll:load_so_dll Loaded L"C:\\windows\\system32\\mcicda.dll" at 0x7d4c0000: builtin
0031:trace:module:load_dll Loaded module L"\\??\\C:\\windows\\system32\\mcicda.dll" at 0x7d4c0000
0031:trace:module:process_attach (L"mcicda.dll",(nil)) - START
0031:trace:module:MODULE_InitDLL (0x7d4c0000 L"mcicda.dll",PROCESS_ATTACH,(nil)) - CALL
0031:trace:module:process_attach (L"mcicda.dll",(nil)) - END
0031:trace:module:load_dll looking for L"mcicda.dll" in L"C:\\users\\mkaushik\\Temp;C:\\windows\\system32;C:\\windows\\system;C:\\windows;.;C:\\windows\\system32;C:\\windows;C:\\windows\\system32\\wbem;C:\\windows\\system32\\WindowsPowershell\\v1.0"
0031:trace:module:load_dll Found L"C:\\windows\\system32\\mcicda.dll" for L"mcicda.dll" at 0x7d4c0000, count=2
0031:trace:mci:mciSetDriverData (0001, 027bd9b0)
0031:trace:mci:MCI_LoadMciDriver Loaded driver 027BD988 (L"CDAUDIO"), type is 516, cmdTable=0000ffff
0031:trace:mci:MCI_LoadMciDriver mcidev=1, uDevTyp=0204 wDeviceID=0001 !
0031:trace:mci:mciGetDriverData (0001)
0031:trace:mci:MCI_Open wDevID=0001 wDeviceID=1 dwRet=0
0031:trace:mci:mciSendCommandW => 00000000
0031:trace:mci:mciSendCommandA (00000001, MCI_STATUS, 00000102, 0032fdfc)
0031:trace:mci:mciSendCommandW (00000001, MCI_STATUS, 00000102, 0032fdfc)
0031:trace:mci:mciGetDriverData (0001)
0031:trace:mci:mciSendCommandW => 00000000
0031:trace:mci:mciSendCommandA (00000001, MCI_STATUS, 00000112, 0032fde8)
0031:trace:mci:mciSendCommandW (00000001, MCI_STATUS, 00000112, 0032fde8)
0031:trace:mci:mciGetDriverData (0001)
0031:trace:mci:mciSendCommandW => 00000000
0031:trace:mci:mciSendCommandA (00000001, MCI_CLOSE, 00000002, 0032fdf8)
0031:trace:mci:mciSendCommandW (00000001, MCI_CLOSE, 00000002, 0032fdf8)
0031:trace:mci:MCI_Close (0001, 00000002, 0032FDF8)
0031:trace:mci:mciGetDriverData (0001)
0031:trace:mci:mciGetDriverData (0001)
0031:trace:mci:mciGetDriverData (0001)
0031:trace:mci:mciSetDriverData (0001, 00000000)
0031:trace:mci:mciGetDriverData (ffffffff)
0031:warn:mci:mciGetDriverData Bad uDeviceID
0031:trace:module:LdrUnloadDll (L"mcicda.dll") - START
0031:trace:module:MODULE_DecRefCount (L"mcicda.dll") ldr.LoadCount: 1
0031:trace:module:LdrUnloadDll (L"mcicda.dll") - START
0031:trace:module:MODULE_DecRefCount (L"mcicda.dll") ldr.LoadCount: 0
0031:trace:module:MODULE_InitDLL (0x7d4c0000 L"mcicda.dll",PROCESS_DETACH,(nil)) - CALL
0031:trace:module:free_modref  unloading L"C:\\windows\\system32\\mcicda.dll"
0031:trace:mci:mciSendCommandW => 00000000
0031:trace:mci:mciSendCommandA (00000001, MCI_STOP, 00000002, 0032f540)
0031:trace:mci:mciSendCommandW (00000001, MCI_STOP, 00000002, 0032f540)
0031:trace:mci:mciSendCommandW => 00000101
0031:trace:mci:mciSendCommandA (00000001, MCI_CLOSE, 00000002, 0032f540)
0031:trace:mci:mciSendCommandW (00000001, MCI_CLOSE, 00000002, 0032f540)
0031:trace:mci:MCI_Close (0001, 00000002, 0032F540)
0031:trace:mci:mciSendCommandW => 00000101
0031:trace:mci:mciSendCommandA (00000001, MCI_STOP, 00000002, 0032fe44)
0031:trace:mci:mciSendCommandW (00000001, MCI_STOP, 00000002, 0032fe44)
0031:trace:mci:mciSendCommandW => 00000101
0031:trace:mci:mciSendCommandA (00000001, MCI_CLOSE, 00000002, 0032fe44)
0031:trace:mci:mciSendCommandW (00000001, MCI_CLOSE, 00000002, 0032fe44)
0031:trace:mci:MCI_Close (0001, 00000002, 0032FE44)
0031:trace:mci:mciSendCommandW => 00000101

So the game just opens the device, queries the status and probably doesn't like what it receives, then closes the device
I'll try building winmm.dll.so with debug information and then maybe gdb can show me the contents of the status it's sending.

The full log is attached.

[mkaushik]

Some new info. Running the game with +mcicda shows the following:

Code: Select all

0031:trace:mcicda:MCICDA_Open (0001, 00002002, 027BA9C4);
0031:trace:mcicda:MCICDA_Status (0001, 00000102, 0032FDFC);
0031:trace:mcicda:MCICDA_Status dwItem = 3
0031:trace:mcicda:MCICDA_Status MCI_STATUS_NUMBER_OF_TRACKS = 1
0031:trace:mcicda:MCICDA_Status (0001, 00000112, 0032FDE8);
0031:trace:mcicda:MCICDA_Status dwItem = 4001
0031:trace:mcicda:MCICDA_Status MCI_CDA_STATUS_TYPE_TRACK[1]=1089
0031:trace:mcicda:MCICDA_Close (0001, 00000002, 0032FDF8);
0031:trace:mcicda:MCICDA_Stop (0001, 00000002, 00000000);

So the disk image seems to have one track, and that track type is "other" as opposed to "audio". The game should have 8 tracks.
I double checked this with cdparanoia, that shows only one track as well.

At this point this isn't really a Wine problem. But I'd appreciate advice/hints.
The disk image is 360MB, whereas the game itself (from the no-music ripped image) is only 48MB. The README that came with it claims that the image comes with CD music.

[mkaushik]

Eureka!
Typing the the last message made me realize the problem. The game came with a .iso, a .mdf and a .mds file.
I read up on the .mdf and .mds file formats, and realized that .mds is where all the metadata for the tracks was written. I had been mounting either the mdf or the iso file directly, but the magic is all in the .mds file. It's supposedly the proprietary format for the Alcohol 120% program, but cdemu also supports loading it.
So this time I loaded the mds file directly with cdemu:

Code: Select all

cdemu load 0 FIREFIGHT.mds

cdparanoia now shows 8 tracks!

Code: Select all

cdparanoia -d /dev/sr0 -Q -v
cdparanoia III release 10.2 (September 11, 2008)

Using cdda library version: 10.2
Using paranoia library version: 10.2
Checking /dev/sr0 for cdrom...
	Testing /dev/sr0 for SCSI/MMC interface
		SG_IO device: /dev/sr0

CDROM model sensed sensed: CDEmu CD-ROM 1.0 

Checking for SCSI emulation...
	Drive is ATAPI (using SG_IO host adaptor emulation)

Checking for MMC style command set...
	Drive is MMC style
	DMA scatter/gather table entries: 1
	table entry size: 131072 bytes
	maximum theoretical transfer: 55 sectors
	Setting default read size to 27 sectors (63504 bytes).

Verifying CDDA command set...
	Expected command set reads OK.

Attempting to set cdrom to full speed... 
	drive returned OK.

Table of contents (audio tracks only):
track        length               begin        copy pre ch
===========================================================
  2.     4030 [00:53.55]    25187 [05:35.62]    no   no  2
  3.    21088 [04:41.13]    29217 [06:29.42]    no   no  2
  4.    23744 [05:16.44]    50305 [11:10.55]    no   no  2
  5.    25472 [05:39.47]    74049 [16:27.24]    no   no  2
  6.    26288 [05:50.38]    99521 [22:06.71]    no   no  2
  7.    21056 [04:40.56]   125809 [27:57.34]    no   no  2
  8.    19680 [04:22.30]   146865 [32:38.15]    no   no  2
  9.    17430 [03:52.30]   166545 [37:00.45]    no   no  2
TOTAL  158788 [35:17.13]    (audio only)

Then I mounted it as before:

Code: Select all

sudo mount /dev/sr0 /mnt/cdrom

And then I ran it with wine; the music plays!

So this was a very elaborate journey towards discovering a simple mistake. Hope you enjoyed reading as much as I enjoyed debugging
Brb, reliving my high-school days from almost two decades ago (though I'll probably get bored of the game in 10 mins )