It's best to prefix the executable name with "wine" or "wine64" even though there are some plaforms that will detect and run windows apps under wine. That's something that I think we could add to client (if it doesn't exist already) just to allow support for interpreted, emulated, locally compiled or bytecode platforms in the future without requiring that projects use a wrapper.
Thus far I've only tried it with SETI@home and it's graphics app. Works fine, but then again I think the seti@home graphics still run on Windows 98, maybe even 95. On Thu, May 10, 2012 at 10:15 AM, Rom Walton <[email protected]> wrote: > With wine do you have to prefix the Windows executable with 'wine' or > something of that nature? Or does Linux automatically detect that it is > a Windows executable and handle the appropriate process create activity? > > I would probably go with the second idea. We already do something > similar with FreeBSD and specify Linux as an alt platform. > > If we do that we should also add a project config flag that can disable > sending Windows binaries to Linux machines even if it is specified as an > alt platform. > > I think for the majority of applications it'll work. The place where I > would expect to see issues would be with graphics applications. > > ----- Rom > > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On Behalf Of Eric J Korpela > Sent: Thursday, May 10, 2012 12:46 PM > To: [email protected] > Subject: [boinc_dev] (no subject) > > I'm thinking about the possibility of adding client support wine/wine64 > on > i686 and x86_64 platforms. But the current platform choice mechanism > causes problems. > > The easiest, and probably safest is to add "i686-wine" and "x86_64-wine" > as alternate platforms. That means projects would need to deliberately > make their windows apps into wine apps. But it means that people > running wine don't have the option of trying to join projects that don't > do so. > > The more dangerous road would be to have machines with wine report > "windows_x86_64" or "windows_i686" as platforms. The problem with that > would be that on projects that have linux32, linux64, window32, and > windows64 applications, an x86_64-linux host with wine installed would > get all four applications, until the scheduler determined which one was > fastest. Maybe that would be a good thing. Maybe the windows32 app is > the fastest. The other problem would be for apps that don't work on > wine. > S@Hruns fine, but maybe apps that require window7 wouldn't. > > Thoughts? > _______________________________________________ > boinc_dev mailing list > [email protected] > http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev > To unsubscribe, visit the above URL and > (near bottom of page) enter your email address. > > _______________________________________________ boinc_dev mailing list [email protected] http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev To unsubscribe, visit the above URL and (near bottom of page) enter your email address.
