coapp-developers team mailing list archive

["Rivera, Rafael" <rafael@xxxxxxxxxxxxxxxxx>]

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.

* Runtime explosions: Elizabeth mentioned the idea of using -- for the
lack of a better word -- plugins to extend the engine's capabilities.
For example, we could have a CoApp.Engine.dll and
CoApp.FeedProtocol.FTP.dll. If we statically link the CRT into both,
we'll have to be very very careful with regards to memory management.
(e.g. don't xalloc() memory in one and xfree() in another).


/rafael

On 5/20/2010 4:16 PM, Olaf van der Spek wrote:
> On Thu, May 20, 2010 at 10:14 PM, Rivera, Rafael
> <rafael@xxxxxxxxxxxxxxxxx> wrote:
>   
>> On 5/20/2010 4:03 PM, Trent Nelson wrote:
>>     
>>> I'm perplexed why anyone would want to forgo the advantages of C++ for
>>> C; I can make my C++ DLLs just as small as C ones.  And, like, what if
>>> I want a linked list, or a hash, or a set, are we planning on writing
>>> all of those from scratch?  Even string handling alone seems like a
>>> huge win.
>>>       
>> The major concern was dependencies. If we move to C++, we'd have to then
>> start binding to, redistribute, and service the Microsoft Visual C++
>> runtimes. If we used the latest version of the runtimes, for example,
>> we'd drop support for Windows XP Service Pack 0, 1, and 2 machines plus
>> exclude anyone using the Starter Edition SKU. (The latest runtimes don't
>> install on these platforms.)
>>     
> Static binding...
>
> Olaf
>