[reSIProcate] Changing VS.NET projects from C-Runtime Multithreaded (static) to Multithreaded DLL

[Scott Godin]

I'm considering chaning the VS.NET project settings from Multithreaded
(static) to Multithreaded DLL.  This will match the sipX projects and
make it easier to build applications that use libraries from both
products.  There are also some other advantages of using DLL C-Runtime -
see the notes/links below.

 

Let me know if anyone has any issues with this.

 

Thanks,

 

Scott

 

 

http://blogs.msdn.com/larryosterman/archive/2004/04/29/123090.aspx

 

Note: MSFT employee posting:

 


#
<http://blogs.msdn.com/larryosterman/archive/2004/04/29/123090.aspx#1241
63>  re: Choosing a C runtime library 


Friday, April 30, 2004 1:59 PM by Michael Grier [MSFT]
<http://blogs.msdn.com/utility/Redirect.aspx?U=http%3a%2f%2fblogs.msdn.c
om%2fmgrier>  

There are several interesting reasons to use the shared msvcr*.dll: 

1. Page sharing across processes 
2. Fewer heaps in each process 
3. You need to do this is you pass malloc()d or new-d memory across DLL
boundaries 
4. The TLS issue 

The perf team in MS is who pushes us to use the common C runtime mostly
because of 2 - the actual code size issue tends to not be as big an
issue as having a bunch of lurking heaps out there. (Also, if you use
the process heap, there's hope that someday you'll be able to allocate
memory in DLL_PROCESS_ATTACH but if you're using a private heap, you're
forever subject to the deadlocks that happen today.) 

 

 

 

Other info:

http://msdn2.microsoft.com/en-us/library/abx4dbyh

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.resiprocate.org/pipermail/resiprocate-devel/attachments/20051005/9d5947a0/attachment.htm>