作爲擁有30多年行業經驗的軟件開發人員，其中25年投資於Microsoft Windows，因此選擇開發工具至關重要。對於我們的開發人員而言，正確的工具實際上可以成就或破壞您的職業。所以這是一個很重要的話題。
“超過25年的數百萬開發人員是不會錯的。
如果Delphi沒有 積極地將其作爲開發平臺，
那麼今天我們都不會在這裏。”
試圖評估我使用的語言和框架（跨越數十年之久）超出了本文的範圍。可以肯定地說，我至少使用了10種不同的開發工具。從適用於嵌入式的本機Basic編譯器，到各種機制下的C，Java，Pearl和C＃。我可以說出六個Pascal編譯器（我最喜歡的語言）：TMT，HiSoft，Turbo Pascal，Freepascal，Oxygene Pascal和Delphi。
早在2010年，我什至與Delphi社區的成員一起創建了自己的開發平臺。因此，編程語言和編譯器作爲一個主題，是我花費了大量時間進行研究的內容。
但是，儘管替代方案可能充滿異國情調，但即使在按時按預算交付可靠軟件的精打細算方面，Delphi也無濟於事。
上圖：與WinAPI緊密集成的好處之一是超快速，輕便的可視控件
您可能會以旋轉或市場營銷的方式來取消它，但如果您關注我的博客或在Facebook上經常訪問我的一個用戶組，那麼我對Delphi的奉獻無疑是毫無疑問的。多年來，我曾使用過許多編程語言和技術，但是Delphi一直是開發人員的一生。
在本文中，我想概述爲什麼Delphi對於Windows開發來說很棒。從Delphi開發人員的角度來看，Windows開發是什麼？它涉及什麼，您的標準是什麼？
找到你的路
我必須承認，我不一定羨慕今天正在涉足本機軟件開發的年輕男女。作爲70年代和80年代的孩子，我過着奢侈的生活，比彎道領先一英寸。無論採用哪種標準或技術，當它發生時我都在那裏。最新的東西始終是您已經在做的下一步工作，因此，我不必追趕或沉迷於過去的技術即可找到自己的立足點。
“ [Delphi]通過
優雅且易於理解的線性繼承和連續繼承來做到這一點”
想要在2020年編寫高性能本機應用程序的年輕開發人員面臨着令人困惑，甚至令人生畏的標準和框架。我可以想象，要分辨WinAPI，UWP和WinRT之間的區別並不容易。那是在我們進行ActiveX，COM，COM +，DirectX，GDI，GDI +（僅舉幾例）之前。過去所有具有其名稱的技術都進行了多次更改。
現在，我不會窮盡所有主題，而是考慮以下內容：今天我們稱爲ActiveX的最初稱爲COM（最初在可見對象和不可見對象之間沒有明顯的區別），在此之前，它是完全相同的系統以Microsoft OLE的形式銷售（注意：從技術上講ActiveX 是COM，因爲COM是組件對象模型和實現標準）。
我確定你明白我的意思。如果您在OLE爆炸時就在那裏，那麼向COM過渡以及ActiveX在可視對象方面的進一步區分是自然的。
值得慶幸的是，我們擁有可以大大簡化所有這些工作的開發系統。這是Delphi脫穎而出的第一選擇。
爲什麼選擇本機編程？
我上面提到的這種混亂是每個人都必須經歷的。編程的奇妙方面之一是，您永遠不會學完；在我們的工作中，沒有人能說“現在我沒有什麼要學的了”。總會有新技術，新思想，解決問題的新方法-以及與之配套的新語言。
但是，自第一臺家用計算機問世以來，本地軟件的開發一直沒有真正改變過。這是我要教的最重要的事情之一，因爲一旦您瞭解了原因，您就能做出更好的選擇。您還將發現紮實的基礎和暫時流行之間的區別（涉及語言和技術時）。
上圖：Delphi和C ++ Builder是在許多平臺上進行本機軟件開發的理想選擇，但是Windows上沒有什麼比Delphi更好的了。
一臺計算機是100％受物理學支配的。它是一臺電動的，邏輯綁定的機器。物理定律充斥着處理器和存儲器的工作方式，進而影響指令（機器代碼）的表達方式。這聽起來可能很複雜，但是您要做的只是擺脫這個問題，原因就是事情是出於某種原因。
語言來來往往，但是遵守基本計算法則的語言（本機編程語言）將永遠不會消失。之所以存在它們，是因爲這些語言負責其他所有事情。
換句話說，學習Object Pascal或C / C ++將爲您帶來好處，因爲您使用這些語言積累的知識和技能是通用的，永恆的，並且可以直接轉換爲軟件開發的其他各個方面。
Windows：技術層面
那麼，對於Windows開發人員而言，標準究竟應該是什麼？Windows是一個涵蓋數百甚至數千種技術的大型系統。爲了編寫出色的Windows軟件，您需要掌握哪些對象和實體？
簡而言之，它們如下：
- 桌面應用
- 系統服務
- 系統庫
- COM和Active X模塊
Microsoft Windows有幾層，每層都公開了不同的功能，因此讓我們直接進入並簡要地逐一介紹一下。
內核級驅動程序
在Windows生態系統的最底層，您具有關鍵任務技術，例如內核級驅動程序。我個人認爲C ++ Builder更適合處理這種類型的編碼。
並不是因爲無法使用Object Pascal，而是因爲大多數驅動程序都是用C / C ++編寫的，所以可用的源材料數量大部分將採用C源代碼的形式。
Delphi主要是爲系統軟件而設計的，而內核級別的驅動程序也不是憑空想象的。我在這裏純粹出於上下文提及它，因爲它代表了Windows體系結構的基本層次。
因此，儘管我有需要此類驅動程序的項目，例如直接與內核集成的自定義文件系統，但此類任務很少見。在我的情況下，我們使用C ++ Builder編寫了驅動程序，並在Delphi中使用了該驅動程序。
共享庫
下一層是Delphi發揮作用的地方，即庫（dll文件）。作爲原型的本機開發系統，Delphi可以生成快速而可靠的代碼。使它最適合構建共享庫（dll文件）。Delphi也有自己的對象模型（VCL的一部分，Delphi運行時庫），這意味着您可以充分利用成千上萬的非可視組件。因此，儘管庫最終是低級實體，泰山老父但使用庫中的組件來爲應用程序提供複雜而精緻的功能沒有任何辦法。
庫通常用於隔離應用程序可以使用的常見行爲或唯一行爲。將庫中的工作分開可以節省時間，如果與紀律一起使用，則可以幫助您編寫易於維護的軟件。
服務棧
在服務層的正上方是服務層（由於服務以垂直方式相互依賴，因此通常稱爲“堆棧”）。Windows服務應用程序是沒有視覺輸出的特殊程序。不涉及任何表單，按鈕或用戶界面元素。這種程序旨在在後臺靜默運行，並且通常爲桌面應用程序或其他服務提供特殊功能。
毫無疑問，Delphi是服務創作的最佳解決方案之一。由於Delphi的運行時庫與Windows緊密集成，但提供了靈活成熟的組件模型-實際上，您可以編寫的服務類型沒有限制。
需要網絡服務器嗎？將服務器組件拖放到項目數據模塊上，瞧，您已經創建了自己的Web服務器。需要數據庫連接性嗎？一樣。將組件放在服務項目的數據模塊上，現在您的服務可以連接到數據庫了。
甚至有從頭開始編寫的數據庫都只不過是Delphi，這意味着您的服務將不依賴於外部庫或驅動程序。這在以網絡爲中心的大型環境中非常強大，在該環境中其他地方的錯誤可能會帶來災難性的後果。軟件的依賴性越少，影響其運行的因素就越少。
桌面環境
在所有這些技術層之上都是實際的用戶體驗，即桌面環境。這就是Delphi真正首屈一指的地方。
Delphi使創建快速，現代和美觀的桌面應用程序變得如此容易。當然，還有其他系統-但是Delphi的RAD（快速應用程序開發）公式，與WinAPI（中央Windows API）直接接口的方式，經過數十年的生產，已經過如此精緻和完善，以至於我還沒有找到任何東西可以匹配它。
爲了理解原因，讓我們看一下幫助將Delphi變成家喻戶曉的框架，即VCL。
VCL
我對Delphi鍾愛的一件事是，它使用自己的獨立組件模型運行，通常稱爲VCL（可視組件庫）。VCL是一個精巧設計，易於使用且功能強大的面向對象的框架。它從彙編語言一直延伸到可視化組件，您可以在表單上進行拖放。正是這種深度最終使它變得如此強大。其他語言可能具有某些組件功能-但是使這一切發生的潛在機制和代碼通常被屏蔽或隱藏。
上圖：VCL的好處之一是主題支持。就像Delphi的平臺獨立框架FireMonkey一樣，VCL允許您爲Windows應用程序提供獨特的外觀，而不會損失行爲或集成。
因此，在學習Delphi並探索其選項時，您可以從自己的位置開始，然後隨着瞭解的增長逐漸完善技能。
VCL很棒，因爲它包裝了Windows的整個範圍，從庫到服務再到服務再到桌面，所有這些都來自一個框架。它通過優雅且易於理解的線性和連續繼承來做到這一點。它實際上爲每個後代建立了越來越複雜的行爲和功能。
VCL從最基本和最基本的非可視類和組件開始，然後進入可見光譜。最終是TCustomControl，這是大多數視覺元素所源自的祖先。
手動爲所有內容調用WinAPI或使用VCL之間的區別（或優勢）是VCL可以爲您處理所有事情。或者我應該說，只要您希望它處理即可。從處理字體，顏色編碼，縮放選項，與設備無關的圖形，構圖和佈局-這些非常細膩的步驟非常耗時。但最令人敬畏的功能是VCL不會強迫您。如果需要更改行爲，則可以覆蓋功能並編寫自己的改編。VCL作爲Delphi的一部分以源代碼形式提供，因此您可以快速找到需要更改的方法。提供源代碼也很適合學習，因爲您不必經常搜索文檔。VCL使本地Windows編程變得理智。乾淨利落。
VCL方法或配方（如果您願意的話）已經有效使用了25年。
在它的長壽命中，它已經（並將繼續被）完善，改進和調整；與Windows並存。VCL直接負責的產品數量以百萬計。Delphi開發了一些最大，最成功的應用程序。他們可能沒有宣傳這一事實，但是您會驚訝於Windows平臺上的工具Delphi和C ++ Builder多麼出色（！）。
每當Microsoft向WinAPI添加有趣的新功能時，Embarcadero都會將這些功能吸收到VCL中並使其易於使用（將它們包裝爲類或易於使用的功能，或者將該功能應用於Delphi隨附的衆多組件之一）。RAD（快速應用程序開發）是數百萬開發人員所依賴的獨特方法，該方法經受了時間的考驗。
我想不出一個面向Windows的框架，該框架是專門爲已經經歷了很多年的Windows生態系統編寫的，但是它今天的效果和25年前一樣有效。原因是它沒有像其他語言和框架那樣受到更改的影響-因爲它直接與Windows對話。這與我在本文開頭提到的原理相同，即在視覺表面之下，計算與20年前大致相同。
就其本身而言，這是一項了不起的成就。
與世界對話
我從來不喜歡限制我的選擇。有許多開發人員只承諾一種語言，一種平臺而第四種。但我相信所有開發人員都應保留儲備充足的工具箱。在某些業務部門中，腳本將發揮重要作用，而在其他部門中，字節碼可能更爲重要。我認爲重要的是選擇一種能夠與鄰國良好配合，與基礎基礎設施接口併爲所有人帶來明顯利益的語言。
Windows是一個了不起的平臺。但是重要的是要了解Windows不僅僅是視覺桌面應用程序。在可視表面之下是大多數活動發生在服務層中的位置，或者在庫級別的更下方。
能夠直接與這些層進行對話非常重要，並且應用程序和基礎API之間的樣板代碼越少越好。我覺得Delphi作爲一種語言和開發系統都在我的清單上最多。我還沒有找到Delphi無法與之交流或合作的技術。
Delphi還擁有一個豐富而高效的第三方組件社區，該社區提供了一些令人印象深刻的擴展包。您可以毫無問題地與COM和Active X庫連接（也可以編寫此類庫）。與Active Directory集成同樣容易和直接，就像使用FHIR這樣的醫學標準一樣。FHIR標準實際上是由著名的Delphi發燒友Graham Grieve 在Delphi中發明的。
如果使用像CrossTalk這樣的包（由AToZed Software生產），您甚至可以加載並直接使用.Net程序集。因此，您可以享受本機代碼的速度和性能，而不會損失與其他技術的集成。
感言
Delphi是一種深度很深的產品。我可能已經汲取了各種技術，技巧以及免費提供的軟件包和附加組件，但是Delphi最終還是站在了自己的優點上。像C / C ++一樣，Object Pascal是一種原型語言，這意味着它旨在與計算機交互-在計算機運行時（即，您完全像在C中一樣使用內存，指針和地址）。原型語言的數量很少，但是它們代表了計算的基本方面，它負責其他所有事情。Delphi作爲一種產品可以提供這種範圍和深度，但是可以讓您從頭開始。您不會受到基礎層的遮擋，但可以按照自己的步調進行處理。
通常，我想分享有關Delphi和Windows開發的太多內容，並且我無疑會一遍又一遍地回到這個主題，因爲幾乎沒有取之不盡的用之不竭的材料。
25年內成千上萬的開發人員不會錯。如果Delphi不能積極地將其用作開發平臺，那麼今天我們都不會在這裏。
使用RAD Studio，Delphi或C ++ Builder減少開發時間並更快地推向市場。設計。編碼。編譯。部署。