c++ - Quais são algumas das razões para não vincular estaticamente para o VC CRT? - CoreDump.pt
Quais são algumas das razões para não vincular estaticamente para o VC CRT?
Eu estou achando que, com a ligação dinâmica, mesmo com SxS, Windows Update vai vir e bater em uma versão do VC8 CRT (por exemplo, ele tem uma falha de segurança) e, em seguida, meu aplicativo vai deixar de funcionar com versões mais antigas.
Quais são algumas das razões importantes para ficar com a ligação dinâmica com VC CRT, que não seja aumentar o tamanho de seus binários?
Publicado 26/08/2009 em 23:40 2009-08-26 23:40
fonte usuário Leeks and Leaks
Manter-se atualizado sobre as correções de segurança é uma boa razão. Caso contrário, você é responsável por reconstruir o seu aplicativo com um CRT fixa e implantá-lo aos seus clientes.
Usando um CRT compartilhada deve resultar em menor consumo de memória para o sistema, já que a maioria das páginas da DLL podem ser compartilhados entre processos.
Eu prefiro vinculação estática. Segurança não é realmente um grande problema desde hackers alvo aplicações que muitos usuários têm instalados em seu sistema. Então, a menos que seu aplicativo tem mais de 1 milhão de usuários, eu não me preocuparia com isso sendo explorada por hackers.
Eu não gosto de ligação dinâmica. Ele só se sente muito frágil para mim.
EDIT: E se você quiser ter certeza de que seus usuários tenham uma versão up-to-date de sua aplicação, em seguida, também escrever um aplicativo atualizador que é automaticamente instalado junto com seu aplicativo principal. No Windows isso poderia ser implementado como um serviço.
Respondeu 27/08/2009 em 01:23 2009-08-27 01:23 share
Se feito corretamente não deve haver absolutamente nenhum problema com a ligação dinâmica ea aplicação não deve deixar de funcionar. A única parte difícil é mudar para a construção de seu instalador de qualquer método que você usar agora para a forma suportada pela Microsoft (módulos de mesclagem redistribuíveis - MSM, MSI, ligação dinâmica). Veja neste link para o conselho extremamente precioso direito da fonte. Algumas citações interessantes do blog:
A fim de redistribuir as bibliotecas do Visual C ++, tudo que você precisa fazer é incluir o arquivo .msm adequado e a sua política de acompanhamento .msm para distribuir a biblioteca que você precisa.
Mais uma vez, apenas para enfatizar - não use VCRedist * .exe a menos que você estiver usando clicar uma vez para implantar seu aplicativo.
No entanto, posso pensar em nenhum cenário em que esta (minha nota: vinculação estática) é realmente a coisa certa a fazer quando enviar seu produto para os clientes.
Eu concordo que você pode precisar fazer um trabalho não-trivial para implementar esta (talvez você não está usando MSI agora etc), mas eu acho que, se os recursos permitirem, você deve tentar mudar para os métodos recomendados descritos acima.
E se você não fizer isso da maneira descrita acima de sua aplicação vai realmente parar de trabalhar em algum ponto. E os desenvolvedores culpar Microsoft enquanto eles realmente não estavam seguindo o caminho suportado descrito acima. Talvez a Microsoft é a culpa, porque não fazer o link com o blog acima mais frequentemente no MSDN para espalhar a palavra, mas que é sobre ele.
Respondeu 14/10/2009 em 21:15 2009-10-14 21:15 share
fonte usuário Catalin Iacob
veja http://people.redhat.com/drepper/no_static_linking.html
É sobre linux, mas algumas das idéias se aplicam.
fonte usuário Chris Hamons
Você tem sorte lá fora, no Windows. E Linux literalmente consiste de bibliotecas, e você tem esses problemas com todos eles. :-)
Tanto quanto eu entendo, fornecedores de biblioteca sempre manter a compatibilidade com versões anteriores, especialmente se for Microsoft. Assim, a solução possível é a de construir a sua aplicação em uma máquina antiga, tendo em mente que a Microsoft desenvolve biblioteca CRT na maneira que seu aplicativo será executado em todas as outras versões.
Quando o programa está usando algo do CRT que é um dos 'vazamentos de segurança' que você menciona. Se você vincular estaticamente os usuários não sabem que eles estão sujeitos a uma falha de segurança, e são talvez em perigo de um vírus. Por outro lado, se o seu programa não funciona porque está ligado dinamicamente eles serão obrigados a atualizar para a nova versão segura.