Hello, there seems to be an odd behaviour regarding the CD-Rom drives in wine depending on whether you run a precompiled version (in my case a Debian package) or compile wine for yourself (same version). Background is that there seems to be a regression in wine which I wanted to debug. The regression is in a game which checks for the CD first and then shows an intro and a menu (which has graphic issues now because of the regression) when the CD is found or no menu and another menu (which does not have graphic issues) when the CD is not found. So in short: CD found? yes: show intro videos and menu (which has issues) no: show no intro videos and a different menu (which does not have issues). I have wine 1.3.29 installed from the official PPA [1] on my Ubuntu 11.04 machine (amd64). To do regression testing I also have a git tree here where I also compiled version 1.3.29 (I did a "git checkout wine-1.3.29" before because this is the latest version and there have already been patches applied). The exact build command I used is this: CFLAGS="-g -O0" ./configure --verbose --disable-tests && make depend && make -j4 The point now is when I run the game with this compiled wine version the game does not find the CD and shows the menu which does not have issues instead. It is also odd that there was the message that the wine prefix gets updated when I first launched the game with my compiled wine version. I thought this was only necessary when I used a different wine version now than the version the wine prefix was created with. So I ensured that my installed wine and the self compiled wine really have the same version which is the case obviously: korn at pc:~/wineprefixes/comanche_3/drive_c/C$ ~/wineprefixes/wine/wine/wine --version wine-1.3.29 korn at pc:~/wineprefixes/comanche_3/drive_c/C$ wine --version wine-1.3.29 It is really odd and I cannot do regression testing this way of course. This is the dosdevices directory in this wine prefix: korn at pc:~/wineprefixes/comanche_3/drive_c/C$ LANG=C ls -la ../../dosdevices/ total 8 drwxr-xr-x 2 korn korn 4096 Oct 2 23:35 . drwxr-xr-x 5 korn korn 4096 Oct 3 13:26 .. lrwxrwxrwx 1 korn korn 10 Jul 29 2010 c: -> ../drive_c lrwxrwxrwx 1 korn korn 13 Jul 29 2010 e: -> /media/cdrom0 lrwxrwxrwx 1 korn korn 43 Oct 2 21:28 e:: -> /home/korn/Games/Comanche 3/COMANCHEGLD.iso lrwxrwxrwx 1 korn korn 10 Jul 29 2010 h: -> /home/korn lrwxrwxrwx 1 korn korn 1 Jul 29 2010 z: -> / I really do not understand this. Please help ;) Kind regards Christoph [1] https://launchpad.net/~ubuntu-wine/+archive/ppa
There are 2 e:\ entries in your ls. Try opening winecfg, go to the drives tab, remove both drives and try adding the .iso file drive again. Also, try that in a clean prefix.
Thanks for the answer. Same games also need a link to the iso to work. This is the e:: link you see. I removed drive E with winecfg in this prefix and also removed the e:: link. However, recreating the drive with winecfg in this prefix did not change the situation. Also a new prefix did not make a difference. I just copied the game directory to the new prefix and created the drive with winecfg (luckily the game does not seem to require registry entries or special dll overrides). It still has the same behaviour there. Also I still find it odd that this dialog about updating my prefix appears although my compiled version has the same version as the wine installed on my system. I do not know what it is doing there but I noticed that the content of the .update-timestamp changes from 1317590139 to 1317086773. Am 03.10.2011 14:05, schrieb Bruno Jesus:> There are 2 e:\ entries in your ls. Try opening winecfg, go to the > drives tab, remove both drives and try adding the .iso file drive > again. > > Also, try that in a clean prefix. >
Christoph Korn wrote:> > Also I still find it odd that this dialog about updating my prefix appears > although my compiled version has the same version as the wine installed on my > system. >It does that on my system, too. Self-compiled Wine is not the same as a distro package; packagers make changes. As for the Wine you compiled not seeing your CD, are you sure you satisfied all dependencies when you compiled it?
I satisfied all build dependencies with: sudo apt-get build-dep wine1.3 wine1.3-dev So I make sure the same packages get installed as when the Debian package of wine was compiled. Also I did not find special changes in the package or special configure options. You find my build log attached. Am 03.10.2011 17:00, schrieb dimesio:> Christoph Korn wrote: >> >> Also I still find it odd that this dialog about updating my prefix appears >> although my compiled version has the same version as the wine installed on my >> system. >> > > It does that on my system, too. Self-compiled Wine is not the same as a distro package; packagers make changes. As for the Wine you compiled not seeing your CD, are you sure you satisfied all dependencies when you compiled it? > > > > > >-------------- next part -------------- A non-text attachment was scrubbed... Name: build_log.txt.xz Type: application/x-xz Size: 86376 bytes Desc: not available URL: <http://www.winehq.org/pipermail/wine-users/attachments/20111003/2acb308a/attachment.bin>
Christoph Korn wrote:> > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: build_log.txt.xz > Type: application/x-xz > Size: 86376 bytes > Desc: not available > URL: <http://www.winehq.org/pipermail/wine-users/attachments/20111003/2acb308a/attachment.bin>Attachments get scrubbed by the mailer. In the future, please use a site like pastebin and post a link. Someone mentioned in another thread that they've found Wine behaves differently when compiled with --disable-tests. Try compiling without disabling tests.
Maybe Matching Threads
- Bug#385308: Please provide way to run xend in the foreground, without daemonizing
- Real sh? Or other efficient shell for non-interactive scripts
- Real sh? Or other efficient shell for non-interactive scripts
- Windows 10
- Network play in Command & Conquer: Red Alert 2