> >> In general, if an app works in Wine, installing and > running it would be exactly the same as in Windows: point and > click. Wine normally adds Windows apps to the menu when you > install them, and creates desktop links if the installer > creates Windows shortcuts. It's only when an app doesn't work > out-of-the-box with Wine that it can get tricky. > >> > > Until the occasional regression... > > > > A bundled Wine version has the advantage that you are certain about > > the exact configuration that the program runs on... (Although static > > linking seem to be the only real way of distributing > binaries without > > breakages on different distros... (This might have changed from the > > previous time I tried...)) > > > > Gert > > > > > > That's why you could/should do as Google does with Picasa, and > distribute a tested version of Wine. Install it as > /usr/bin/wine-yourapp/, or /opt/wine-your-app/, etc. You can then use > that version without fear of Wine upgrades breaking it, and the user > can install Wine in /usr/bin/wine, or /usr/local/bin/wine, etc., for > their other applications. Thanks for all the comments, everyone, this was very helpful. In our case, the software doesn't actually get installed - users can run it directly off the CD-ROM or drag it into a folder on their network (this is one of our big selling points). I found it relatively easy to run it by using winefile and navigating to the correct location, but it would be lovely to be able to create a front-end. However, I'm not too worried about these details - now we know the software runs, I'm sure we can solve the minor teething problems and get it smooth. This is a very exciting thing for us, so thanks for the help. Who knows, we may be able to switch to Linux as a development environment too and escape from MS hell altogether... Best Danny
