win32 - windows api是什麼




學習低級WinAPI編程還有意義嗎? (15)

擁有所有C#管理的幸福,回到Petzold的編程Windows並嘗試使用純WinAPI生成代碼是否有意義?

可以從中學到什麼? 是不是太過時了有用?


了解Windows API的可用內容非常重要。 我認為你不需要用它來編寫代碼,但你應該知道它是如何工作的。 .NET Framework包含許多功能,但它不提供整個Windows API的託管代碼等價物。 有時你必須更接近金屬,知道那裡的東西以及它的行為將使你更好地理解如何使用它。


假設您正在構建針對Windows的應用程序:

  • 它可以確保了解系統的較低級別 - 它們如何工作,代碼如何與它們交互(即使只是間接),以及哪裡有更高級別抽像中沒有的其他選項
  • 有時,您的代碼可能無法滿足您的要求,效率,高性能或精確
  • 然而,在越來越多的情況下,像我們這樣的人(他們從未學過“非託管編碼”)將能夠在不“學習”Win32的情況下完成我們正在嘗試的編程。
  • 此外,有很多網站提供工作樣本,代碼片段甚至是功能齊全的源代碼,您可以“利用”(借用,抄襲 - 但檢查您是否遵守任何重用許可或版權!)來填寫在任何未由.NET框架類庫(或您可以下載或許可的庫)處理的空白中。
  • 如果你可以在Win32中完成所需的功能,而且你在開發格式良好,可讀的託管代碼方面做得很好,那麼我認為掌握.NET將是一個比傳播自己更好的選擇超過兩個非常不同的環境。
  • 如果您經常需要利用那些沒有獲得良好的Framework類庫覆蓋率的Windows功能,那麼請務必學習所需的技能。
  • 我個人花了太多時間來擔心編碼的“其他領域”我應該理解為製作“好的節目”,但是有很多的masochists認為每個人的需求和願望就像他們自己的。 苦難喜歡公司。 :)

假設您正在為“Web 2.0”世界構建應用程序,或者對* NIX和MacOS用戶同樣有用/有益:

  • 堅持使用盡可能多的跨平台環境的語言和編譯器。
  • Visual Studio中的純.NET明顯優於Win32,但是針對MONO庫(可能使用Sharp Develop IDE)進行開發可能是一種更好的方法。
  • 你也可以花時間學習Java,這些技能很好地轉移到C#編程(理論上,Java代碼理論上可以在任何具有匹配JRE的平台上運行)。 我聽說它更像是“一次編寫,到處調試”,但這可能和C#一樣真實(甚至更多)。

在學習Win32 API之前,我一直保持標準的C / C ++,並且非常生硬,“學習Win32 API”部分並不是我生命中最好的技術體驗。

一方面Win32 API非常酷。 它就像是C標準API的擴展(當你可以使用CreateFile時需要fopen 。但我猜UNIX / Linux / WhateverOS具有相同的Gizmo功能。無論如何,在Unix / Linux中,它們都有“Everything is a file”。在Windows中,他們擁有“Everything is a ... Window”(不開玩笑!請參閱CreateWindow !)。

另一方面,這是一個遺留API。 你將處理原始C和原始C瘋狂。

  • 就像告訴一個人的結構自己的大小來傳遞一個指向某些Win32函數的void *指針。
  • 消息傳遞也可能非常令人困惑:將C ++對象與Win32窗口混合會產生雞或蛋問題的非常有趣的例子(當你寫一種delete this ;時的有趣時刻delete this ;在類方法中)。
  • 當你更熟悉對象繼承時,必須繼承WinProc是頭分裂而不是最優。
  • 當然,有一種樂趣是“ 為什麼在這個水力壓裂的世界裡他們用這種方式做了這件事? ”當你用頭撞擊你的鍵盤太多並且用額頭上刻有鑰匙回家的時候,只是因為某人認為編寫API以更改“Window”的顏色更合乎邏輯,而不是通過更改其中一個屬性,而是通過詢問它的父窗口。
  • 等等

在最後一手( 三手??? )中,考慮一些使用遺留API的人自己使用遺留代碼樣式。 你聽到“ const is for dummies ”或“ 我不使用命名空間因為它們會降低運行時速度 ”的那一刻,或者甚至更好的“ 嘿,誰需要C ++?我用我自己的面向對象的C代碼編碼! “(不開玩笑......在專業的環境中,結果很明顯......),你會感覺到這種恐懼只會在guillotine面前受到譴責。

所以...總而言之,這是一次有趣的體驗。

編輯

重新閱讀這篇文章後,我發現它可能被視為過度消極。 不是這樣。

知道事情是如何運作的,有時候很有趣(也很令人沮喪)。 你會明白,儘管存在巨大的(不可能的?)約束,但Win32 API團隊確實做了很多工作,以確保從“olde Win16程序”到“最後的Win64 over-the-top應用程序”的所有內容都可以協同工作,在過去,現在和將來。

問題是:你真的想要嗎?

因為在其他更高級別和/或面向對象的API上花費數週時間來做可以完成(並且做得更好)的事情可能會非常缺乏動力(實際體驗:Win API為3週,3為4小時)其他語言和/或圖書館)。

無論如何,你會發現Raymond Chen的博客非常有趣,因為他的內部人員對Win API及其多年來的演變有所了解:

https://blogs.msdn.microsoft.com/oldnewthing/


如果您計劃開發跨平台應用程序,如果您使用win32,那麼您的應用程序可以通過WINE輕鬆地在Linux上運行。 這導致高度可維護的應用程序。 這是學習win32的優勢之一。


學習C或低級語言肯定是有用的。 但是,我沒有看到使用非託管WinAPI的任何明顯優勢。


學習Win32 API所獲得的價值(除了從學習機器的螺母和螺栓如何組合在一起的各種一般見解之外)取決於你想要達到的目標。 很多Win32 API已經很好地包裝在.NET庫類中,但不是全部。 例如,如果你想要進行一些嚴肅的音頻編程,那麼Win32 API的那部分將是一個很好的學習主題,因為只有最基本的操作可以從.NET類中獲得。 最後我檢查了託管的DirectX DirectSound庫很糟糕。

冒著無恥的自我推銷的風險......

我剛遇到Win32 API是我唯一的選擇。 我想在列錶框中的每個項目上有不同的工具提示。 我寫了我是如何在這個問題上做到的。


對於桌面上的大多數需求,您不需要知道Win32,但是有很多Win32不在.NET中,但它的結果可能最終不到您應用程序的1%。

USB支持,HID支持,Windows Media Foundation剛剛脫穎而出。 Win32中有許多很酷的Vista API。

如果你進行桌面編程,你會學習如何使用Win32 API進行互操作,這樣你就可以幫到自己了,因為當你需要調用Win32時,你將不會花費數週的時間。


我個人並不喜歡Win32 API,但學習它有價值,因為使用GUI可以比使用Visual Basic這樣的語言提供更多的控制和效率,我相信如果你要以寫軟件為生即使您不直接使用API​​,也應該知道它。 這是出於類似於學習C的原因的原因,比如strcpy如何比複製整數花費更多的時間,或者為什麼你應該使用指向數組的指針作為函數參數而不是值的數組。


我見過低級Windows API代碼......它不漂亮......我希望我能忘掉它。 我認為在C中學習低級水平會有好處,因為您可以更好地了解硬件架構以及所有這些內容的工作原理。 學習舊的Windows API ......我認為這些東西可以留給微軟的人,他們可能需要學習它來構建更高級的語言和API ......他們建立了它,讓他們忍受它;-)

但是,如果你碰巧找到一種情況,你覺得你不能用更高級別的語言(少數和遠程)做你需要做的事情,那麼也許開始危險的潛入那個世界。


打個比方:如果你以生活(編程)為基礎製造汽車,那麼了解發動機是如何工作的(Win32)是非常恰當的。


是的,原因如下:

1).net包裝Win32代碼。 .net通常是一個優秀的代碼編寫系統,但對底層Win32層有一定的了解(oops,WinAPI,現在也有64位代碼),可以增強你對真實情況的了解。

2)在這種經濟形勢下,當你找工作時,最好比其他人有一些優勢。 一些WinAPI體驗可能會為您提供此功能。

3)某些系統方面尚未通過.net框架提供,如果您想訪問這些功能,則需要使用p / invoke(請參閱http://www.pinvoke.net以獲得一些幫助)。 擁有至少一小部分WinAPI經驗將使您的p / invoke開發工作更加高效。

4)(已添加)現在Win8已經存在了一段時間,它仍然建立在WinAPI之上。 iOS,Android,OS / X和Linux都在那裡,但WinAPI仍將存在很多年。


本機API是“真正的”操作系統API。 .NET庫(除了極少數例外)只不過是一個奇特的包裝器。 所以,是的,我會說任何能夠理解.NET複雜性的人都可以理解相對平凡的事情,比如在沒有中間人的幫助下與API交談。

只是嘗試從託管代碼執行DLL注入。 它無法完成。 您將被迫為此編寫本機代碼,用於窗口調整,實際子類化以及其他十幾項操作。

所以是的:你應該(必須)知道兩者。

編輯:即使您打算使用P / Invoke。


絕對。 當沒有人知道低級別時,誰會更新和編寫高級語言? 此外,當您了解低級別的東西時,您可以使用更高級別的語言編寫更高效的代碼,並且還可以更有效地進行調試。


這個問題接近於宗教:)但無論如何我會給出我的想法。

我確實看到了學習Win32 API的價值。 大多數(如果不是全部)GUI庫(託管或非託管)都會導致調用Win32 API。 即使是最徹底的庫也不能覆蓋100%的API,因此總是存在需要通過直接API調用或P /調用來插入的空白。 API調用的一些包裝器名稱與底層API調用具有相似的名稱,但這些名稱並不完全是自我記錄的。 因此,理解底層API以及其中使用的術語將有助於理解包裝器API以及它們實際執行的操作。

此外,如果您了解框架使用的基礎API的性質,那麼您將在給定方案中應該使用哪些庫功能做出更好的選擇。

乾杯!


除了一些非常特殊的情況,當你需要直接訪問API時,我會說不。

學習正確實現本機API調用需要花費大量的時間和精力,返回的值不值得。 我寧願花時間學習一些新的熱門技術或框架,這將使您的生活更輕鬆,編程更少痛苦。 不是幾十年前過時的COM庫,沒有人真正使用它(對COM用戶來說很抱歉)。

請不要因為這個觀點而嘲笑我。 我知道這裡的很多工程師都有很好奇的靈魂,學習如何運作並沒有錯。 好奇是好的,真的有助於理解。 但從管理的角度來看,我寧願花一周時間學習如何開發Android應用程序而不是如何調用OLE或COM。







winapi