coapp-developers team mailing list archive

[Geoffroy Couprie <geo.couprie@xxxxxxxxx>]

On Fri, May 21, 2010 at 10:34 AM, William A. Rowe Jr. <wmrowe@xxxxxxxxx> wrote:
> On 5/21/2010 2:38 AM, Geoffroy Couprie wrote:
>> On Thu, May 20, 2010 at 10:54 PM, William A. Rowe Jr. <wmrowe@xxxxxxxxx> 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.