C庫vs WinApi

Question

許多標準c庫（fwrite，memset，malloc）函數在windows API（WriteFile，FillMemory/ZeroMemory，GlobalAlloc）中有直接的等價物。

除了可移植性問題，應該使用什麼，CLIB或Windows API函數？

C函數會調用winapi函數還是相反？

感謝您的幫助

Answer 1

C庫沒什麼神奇的。它只是一個用於訪問操作系統公共服務的標準API。這意味着它使用OS提供的API在OS之上實現。

在您的情況下使用任何有意義的。 C庫是可移植的，Win32不是。另一方面，Win32通常更靈活，並且提供更多的功能。

Answer 2

這些函數並不等同於ZeroMemory等一些簡單的東西。

GlobalAlloc例如爲您提供內存，但它也用於win16下的共享內存傳輸。該功能的部分功能仍然存在。

WriteFile不僅會寫入文件，還會寫入（除其他外）命名管道。 fwrite或write的東西不能直接做。

如果可能的話，我會說使用c庫函數，只有當您需要額外的功能或如果您得到性能改進時才使用windows函數。

這將使得移植到其他平臺更容易。

Answer 3

C函數將調用系統API，標準運行時C庫（或CRT）是用於在系統間標準化的API。

在內部，每個系統都使用系統調用或驅動程序直接設計自己的API。如果你有一個Visual C++的商業版本，它用來提供CRT源代碼，這是有趣的閱讀。

Answer 4

C函數會調用winapi函數還是相反？

C函數（在用戶模式庫中實現）調用WINAPI函數（在O/S內核中實現）。

Answer 5

上一些實例中有幾個附加分：

FillMemory，ZeroMemory

無論這些也不是C函數是系統調用，所以任一個可能在另一個的頂部來實現，或他們甚至可以有不同的實現，來自一個共同的源代碼或不是。

的GlobalAlloc

由於malloc（）函數是建立在通過其API提供的操作系統原語的頂部，它會如果malloc（）和這種分配器直接使用愉快地共存沒有問題有興趣知道。我可以想象爲什麼malloc可能默默地認爲它訪問的堆是連續的，即使我稱之爲設計錯誤，即使它被記錄下來，除非安全性的額外成本是無關緊要的。

Answer 6

如果您要將應用程序移植到多個平臺上，我會說您應該創建自己的一套包裝，即使您使用標準C函數。這將爲您提供切換平臺時的最佳靈活性，因爲您的代碼將以更好的方式與底層系統隔離。

當然，這意味着如果您只打算爲Windows平臺編程，那麼只需使用Windows功能，並且不要使用相同類型的標準C庫函數。

最後你只需要保持與你的選擇一致，你會沒事的。

Answer 7

它可能比您要查找的信息更多（也可能不是您要求的），但Catch22.net有一篇文章，標題爲「Techniques for reducing Executable size」，可能有助於指出Win32 API調用和c運行時調用的差異。

Answer 8

那麼，我目前正試圖避免包括fstream，sstream，iostream和許多C標準庫文件，並使用winAPI代替，因爲包括這些庫中的任何一個都會將輸出可執行文件的大小從大約10 KB增加到大約500 KB 。 但有時候最好使用C標準庫來使代碼跨平臺。 所以我認爲這取決於你的目標。