http://bugs.winehq.org/show_bug.cgi?id=21609
--- Comment #23 from Brandon Bergren wine@bdragon.rtk0.net 2010-03-28 00:10:53 --- Created an attachment (id=27074) --> (http://bugs.winehq.org/attachment.cgi?id=27074) Workaround
Here's a workaround.
The problem here I reckon is all the dwFileSize stuff should really be specific to FOURCC_DOS, as other IOProcs may not necessarily use wm->info.adwInfo[0] to hold a file handle. I guess it was working before because Oblivion just happened to store a HANDLE there. Tightening up on the file size probing in c62cf2e049ad37d9561957c47d23fc7ba13adc90 broke it because it now expects an HFILE.
The dwFileSize stuff (and the problematic test) was added in 090629242bfd88d56195ca599817726356b3da09.
For reference, Oblivion's IOProc has a fourcc of 'W','A','V',' ', is registered / unregistered on the fly whenever a sound is played, and the proc itself seems to return 0 for MMIOM_SEEK (but DOES seem to set lDiskOffset correctly, at least for SEEK_SET and SEEK_CUR. I was unable to test SEEK_END.) Maybe when fixing the SEEK_END case of mmioSeek to work correctly for IOProcs installed by programs, it would be a good idea to attempt to detect a bogus return value and switch to using lDiskOffset? (I note that the pre-090629242bfd88d56195ca599817726356b3da09 code had an assert to detect this situation...)