Check this out. Hanusz Leszek just posted a patch implementing part of https://wiki.ubuntu.com/autorun It's at http://launchpadlibrarian.net/8292130/gnome-volume-manager-autorun-inf-02.pa...
Are we ready for prime time, kids? :-)
On Tuesday 03 July 2007 17:47:18 Dan Kegel wrote:
Check this out. Hanusz Leszek just posted a patch implementing part of https://wiki.ubuntu.com/autorun It's at http://launchpadlibrarian.net/8292130/gnome-volume-manager-autorun-inf-02.p atch
Are we ready for prime time, kids? :-)
I'm not entirely sure if that's a good thing. However, given that e.g. Sony rootkits probably won't work in Wine, I think this is a step towards lowering the access barrier to wine.
Cheers, Kai
I'm not entirely sure if that's a good thing. However, given that e.g. Sony rootkits probably won't work in Wine, I think this is a step towards lowering the access barrier to wine.
Well, I managed to get infacted by W32.Parite some time ago, remember? :-)
Am Dienstag, 3. Juli 2007 17:47 schrieb Dan Kegel:
Check this out. Hanusz Leszek just posted a patch implementing part of https://wiki.ubuntu.com/autorun It's at http://launchpadlibrarian.net/8292130/gnome-volume-manager-autorun-inf-02.p atch
Are we ready for prime time, kids? :-)
On a technical sidenote, instead of hardcoding the wine path he should test some common wine locations, perhaps including cedega and crossover(/usr/local/bin/wine, ~/cxoffice/bin/wine /opt/cxoffice/bin/wine come to my mind). Or perhaps just parse the autorun.inf and then pass the .exe to the normal gnome / kde file opening methods to have whatever app is associated with the mime type run the app.
Otherwise I like the idea. I tried to so something like that a long time ago, but I failed.
Hi,
I agree with stefan's views. We should not hard code the wine path, but should search for it. If it fails only then only we should resort to it. The searching should be done first using the package managers like rpm,deb. Inorder to search for wine path by searching for standard app installations like wine,cxoffice,cedega in this order) If it fails then it should search for it using the 'which wine' ouptut. If that too fails we should use hardcoded paths. (as last resort).
Thanks, VJ
On 7/3/07, Stefan Dösinger stefandoesinger@gmx.at wrote:
Am Dienstag, 3. Juli 2007 17:47 schrieb Dan Kegel:
Check this out. Hanusz Leszek just posted a patch implementing part of https://wiki.ubuntu.com/autorun It's at http://launchpadlibrarian.net/8292130/gnome-volume-manager-autorun-inf-02.p atch
Are we ready for prime time, kids? :-)
On a technical sidenote, instead of hardcoding the wine path he should test some common wine locations, perhaps including cedega and crossover(/usr/local/bin/wine, ~/cxoffice/bin/wine /opt/cxoffice/bin/wine come to my mind). Or perhaps just parse the autorun.inf and then pass the .exe to the normal gnome / kde file opening methods to have whatever app is associated with the mime type run the app.
Otherwise I like the idea. I tried to so something like that a long time ago, but I failed.
Hi,
Thanks for your constructives criticisms.
I was thinking more about putting the wine path in a gconf key so that you can specify it directly. Trying to search the path using the methods you described can be used then as a fallback when the key is not present or invalid.
I would say that please have a look at wine module code in guidance. for checking whether wine has been installed or not. and to get its path.
What is "wine module code" ? I tried grepping the wine source code for cedega and cxoffice but found nothing. Please point me in the good direction.
Regards, Hanusz Leszek
Le mardi 03 juillet 2007 à 12:54 -0400, Vijay Kiran Kamuju a écrit :
Hi,
I agree with stefan's views. We should not hard code the wine path, but should search for it. If it fails only then only we should resort to it. The searching should be done first using the package managers like rpm,deb. Inorder to search for wine path by searching for standard app installations like wine,cxoffice,cedega in this order) If it fails then it should search for it using the 'which wine' ouptut. If that too fails we should use hardcoded paths. (as last resort).
Thanks, VJ
What is "wine module code" ? I tried grepping the wine source code for cedega and cxoffice but found nothing. Please point me in the good direction.
I think whats meant here is one of the 3 wine flavors installed in the package manager. You don't find any trace of cedega or crossover in wine itself. However, inside crossover you will find a wine binary in crossover_install_dir/bin/wine, which you can use like normal wine to run a .exe in the default bottle in crossover. There are some additional environment variables to configure crossover specific things like the bottle to run the app in. No idea about cedega, but I'd expect it to work simmilarly.
Hi,
Thanks for your constructives criticisms.
I was thinking more about putting the wine path in a gconf key so that you can specify it directly. Trying to search the path using the methods you described can be used then as a fallback when the key is not present or invalid.
I would say that please have a look at wine module code in guidance. for checking whether wine has been installed or not. and to get its path.
What is "wine module code" ? I tried grepping the wine source code for cedega and cxoffice but found nothing. Please point me in the good direction.
In KDE there is a configuration gui for wine in the guidance.(http://www.simonzone.com/software/guidance/) Similar to winecfg, I think its a product of Google SoC. Check the source code of wineconfig.py. I feel that I am a bit vague here, but the download the source for guidance in the website mentioned and see the wineconfig.py. To see how they check whether wine is installed or not. Thanks, VJ
-
Dan Kegel -
Kai Blin -
leszek -
Stefan Dösinger -
Vijay Kiran Kamuju