On Fri, May 21, 2010 at 10:34 AM, William A. Rowe Jr. <wmr...@gmail.com> wrote: > On 5/21/2010 2:38 AM, Geoffroy Couprie wrote: >> On Thu, May 20, 2010 at 10:54 PM, William A. Rowe Jr. <wmr...@gmail.com> >> wrote: >>> On 5/20/2010 3:35 PM, Rivera, Rafael wrote: >>>> Two issues come to mind immediately: >>>> >>>> * Servicing: If Microsoft pushes out a QFE for some CRT vulnerability >>>> (http://is.gd/chWRN), users will be stuck with a vulnerable CoApp engine >>>> until recompile/update. We haven't even talked about how we're going to >>>> service the CoApp engine... eek. >>> >>> Agreed. We are architecting a schema to provide a full compliment of ported >>> apps *and dynamic libraries*. Why wouldn't these depend on the shipping, >>> supported, system assembly installed msvc*10 shared libraries? >> >> Because you don't know if they're installed on the user's system. So >> you have to ship them with the CoApp engine, which will increase the >> size. > > > Of course. Will also likely need to ship them zlib, openssl and a host of > other > libraries which are considered 'core', almost straight off the bat. Of course > these are built on MSVCR##, so requiring/distributing this with the jumpstart > distribution tool (engine, or what have you) is completely sensible. > >> A compromise would be to have a very small bootstrapping CoApp engine >> with no dependencies, that downloads the necessary components, and >> eventually, the runtime libraries, and then runs the whole CoApp >> engine.
_______________________________________________ Mailing list: https://launchpad.net/~coapp-developers Post to : coapp-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~coapp-developers More help : https://help.launchpad.net/ListHelp
