4
分發Windows本機應用程序時，我們還需要打擾vcredist.exe嗎？這些中的任何一個是否與Win-7捆綁在一起？CRT，我們還需要重新分配嗎？
如果沒有，是否有任何技術上的原因，這些不會通過例如Windows更新 - 而不是讓我們爲客戶帶來另一件事 - 那就是工作？ （好吧，這可能聽起來很有爭議，但我真的很想知道這些庫不是在Windows機器上默認安裝/更新的原因）
A
回答
2
我認爲這取決於你如何/你鏈接到什麼。如果你直接鏈接到kernel32.dll等，那當然沒關係（即嵌入c運行時庫），但微軟不建議這種分發方法。
如果通過msvcr80/90/whatever 2010 is.dll鏈接，那麼您可能需要將該運行時庫作爲XP發佈，因爲它不符合標準。 msvcr80在Vista上，但msvcr90不，我不認爲 - 雖然它可能會通過Windows更新添加。不過，你不能依靠它在那裏，因此故障安全是有一個副本，以防萬一。
據我所知msvcrt.dll（即mingw鏈接）與所有> xp分配。 vc6鏈接到此？那時我沒有VC++。
從Windows SDK中查看可執行文件depends.exe，並找出它在Windows API上下部分的含義。
+0
C運行庫是msvcrt.dll。它與kernel32.dll無關。不過對於depends.exe來說+1。 – 2010-04-14 20:58:09
+0
這是，但msvcrt.dll鏈接到kernel32.dll。如果您鏈接到靜態庫版本的msvcrt，則直接鏈接到kernel32.dll。無論哪種方式，無論您是否喜歡，您都可以鏈接到kernel32.dll。我的觀點是，你所依賴的（即你的程序要求加載的）取決於你如何鏈接。它將通過msvcrt，msvcrXX.dll或直接通過靜態鏈接到API。 – 2010-04-14 21:01:45
+0
啊 - 從你的回答中並不清楚 - 你沒有通過C運行庫鏈接。即使您使用C運行庫的DLL版本，您仍然與kernel32.dll鏈接。 – 2010-04-14 21:04:52
1
是的，你這樣做。否則當你嘗試運行它時，你的程序會非常壯觀地崩潰。許多用戶沒有運行Win7，即使這樣也沒有辦法確保他們已經安裝了運行時，而沒有將其包含在安裝程序中。
或者，您可以鏈接到運行時的靜態構建，避免使用C運行時可再發行組件打擾。
+0
微軟不鼓勵使用運行時進行靜態鏈接，原因是如果他們發現運行時存在漏洞，他們可以更新dll，並且您的應用程序也受到保護 - 否則您需要重新構建。我不知道msvcrt運行時中有任何漏洞，但是他們明顯有理由發出這樣的建議，所以它就是這樣。 – 2010-04-14 21:30:45
+0
@Ninefingers：是的，但我們有些人不能強迫用戶安裝〜20MB的redist軟件包。如果您需要單個EXE XCOPY部署，那麼您沒有多少選擇。 – 2010-04-14 22:57:38
0
與GCC編譯時，我總是鏈接到MSVCRT.DLL，它始終存在於XP和更新的版本中。
+0
你必須鏈接微軟的C運行時才能使用GCC？奇。 – 2010-04-14 20:56:06
+0
@比利你好，但不是，但它是一個stdio.h，等等是在mingw發行版中設置的。 – Joshua 2010-04-14 20:57:53
+0
我相信這是默認行爲，並且有意義 - 您在Linux上與glibc鏈接。爲什麼不在Windows上使用微軟的「libc」？就是這樣，它保證會在那裏，作爲獎金。 – 2010-04-14 20:59:13
0
這是爲了應對日4月14日拉里·奧斯特曼的評論在23:29：
你說：
MSVCRT.DLL不是C運行時。它是Windows的內部組件，不應該是由第三方應用程序使用的 。你會注意到你在MSDN上找不到任何引用 使用這個DLL。曾幾何時，第三方應用程序使用了這個功能，但這並不是 大約10年的情況。拉里 - 奧斯特曼4月14日在23:29
這似乎違背MinGW的系統的整個前提是基於訪問MSVCRT.DLL和您的評論讓我更好地瞭解如何MinGW的作品。事實證明，mingw仍然使用1998年發佈的msvcrt.dll！請參閱此鏈接：
謝謝
託德
不是每個人都運行Windows更新。 – RichieHindle 2010-04-14 20:54:21