I had forgotten about that. That might take a little thought.
On Thu, May 10, 2012 at 1:00 PM, Nicolás Alvarez <[email protected]>wrote: > 2012/5/10, Eric J Korpela <[email protected]>: > > 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. > > How are you going to bridge the IPC? > > The Windows science app inside Wine will expect to read a > <comm_obj_name> element from init_data.xml, and open the global file > mapping in Global\boinc_{some number}. > > Meanwhile the Linux core client will be mmap()ing a file called > "boinc_mmap_file" in the slot directory. Unless api_version is 5.x, in > which case it will use shmget on a shared memory segment ID read from > init_data.xml. > > None of the three mechanisms are compatible... > > -- > Nicolás > > _______________________________________________ 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.
