Jaké jsou některé důvody, proč staticky odkazující na VC CRT?

hlasů
2

Já jsem k závěru, že s dynamickým propojení, a to i s SxS, Windows Update bude přijít a dupnout na verzi VC8 CRT (například že má bezpečnostní chybu), a pak moje app se nepodaří spustit se staršími verzemi.

Jaké jsou některé z důležitých důvodů, aby zůstali s dynamickou propojení s VC CRT, kromě zvýšení velikosti binárních souborů?

Položena 26/08/2009 v 23:40
zdroj uživatelem
V jiných jazycích...                            


6 odpovědí

hlasů
4

  1. Zůstat až do dnešního dne bezpečnostních záplat je dobrý důvod. V opačném případě, že jste zodpovědný za přestavbu vaší žádosti s pevnou CRT a nasazení ji svým zákazníkům.
    • Použití sdílené CRT by mělo vést k nižší nároky na paměť pro systém, protože většina stránek DLL mohou být sdíleny mezi procesy.
Odpovězeno 26/08/2009 v 23:51
zdroj uživatelem

hlasů
2

Dávám přednost statické propojení. Bezpečnost není opravdu velký problém, protože hackeři cílit na aplikace, které mnoho uživatelů nainstalované ve svém systému. Takže pokud vaše aplikace obsahuje více než 1 milion uživatelů, tak bych si starosti o to využívána hackery.

Nemám rád dynamické propojení. To mi prostě připadá příliš křehká na mě.

EDIT: A pokud chcete, aby se ujistil, že uživatelé mají verze up-to-date vaší žádosti pak rovněž napsat aplikaci pro aktualizaci, která je automaticky nainstalován společně s vaší hlavní aplikace. Ve Windows toto by mohl být realizován jako služba.

Odpovězeno 27/08/2009 v 01:23
zdroj uživatelem

hlasů
1

Pokud se to udělá hned by měla být absolutně žádný problém s dynamické propojování a žádosti by neměla nepodaří spustit. Jedinou nejtěžší je přejít na budování svého instalačního od toho, co metodu, kterou lze nyní použít ke způsobu podporován společností Microsoft (redistribuovatelné Merge Modules - MSM, MSI, dynamické linkování). Viz tento odkaz pro extrémně drahých radu od samého zdroje. Některé zajímavé citace z blogu:

  • Za účelem přerozdělení C ++ knihoven Visual, vše , co potřebujete udělat, je zahrnout příslušnou .msm soubor a průvodní politiku .msm distribuovat knihovny, kterou potřebujete.
  • Opět platí, že jen zdůraznit - nepoužívejte VCRedist * .exe , pokud používáte jedním kliknutím nasazení aplikace.
  • Nicméně, mohu myslet na žádné scénáře , ve kterých tento (moje poznámka: statické propojení) je vlastně ta správná věc dělat, když budou přepravovat svůj produkt pro zákazníky.

Souhlasím, že možná budete muset provést netriviální práce nutné k uskutečnění tohoto (možná ho zrovna nepoužíváte MSI hned atd.), Ale myslím, že pokud to umožní zdroje, měli byste zkusit přejít na doporučené výše popsaných metod.

A pokud nechcete dělat to tak, jak je popsáno výše vaší žádosti bude skutečně přestane fungovat v určitém okamžiku. A vývojáři vinu Microsoft, zatímco oni byli opravdu není po podporované výše popsaným způsobem. Možná, že Microsoft je na vině, protože to není odkaz na blogu výše častěji na MSDN šířit slovo, ale to je asi tak všechno.

Odpovězeno 14/10/2009 v 21:15
zdroj uživatelem

hlasů
1

viz http://people.redhat.com/drepper/no_static_linking.html

Je to o Linuxu, ale některé myšlenky platí.

Odpovězeno 26/08/2009 v 23:53
zdroj uživatelem

hlasů
0

Máte štěstí, že tam v systému Windows. A Linux doslova se skládá z knihovny, a máte takové problémy, se všemi z nich. :-)

Pokud tomu dobře rozumím, dodavatelé knihovny vždy zachovat zpětnou kompatibilitu, zvláště pokud je to Microsoft. Takže z možných řešení je sestavení aplikace na starém stroji, přičemž má na paměti, že Microsoft vyvíjí CRT knihovny tak, že vaše aplikace poběží na všech dalších verzích.

Odpovězeno 26/08/2009 v 23:55
zdroj uživatelem

hlasů
0

Když váš program používá něco z CRT, který je jedním z ‚úniky zabezpečení‘, které jste zmínil. Pokud propojíte staticky uživatelé nebudou vědět, že se na ně vztahují na bezpečnostní chybu, a jsou možná v nebezpečí viru. Na druhou stranu, pokud váš program nefunguje, protože je dynamicky spojeno budou nuceni provést aktualizaci na novou verzi bezpečné.

Odpovězeno 26/08/2009 v 23:50
zdroj uživatelem

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more