現在發現，就是這麼帥

3、本篇將是VB背景系列的最後一篇，僅試圖站在機器硬體和系統的背景上，更客觀的講述VB的適用場景，以幫助大家更正確地使用VB。除了VB使用者外，也適合C#，Python，Delphi等使用者觀摩。

一、理解VB的歷史，仍是把握VB適用場景的關鍵

1、BASIC的初衷，適用無處不在

如果你理解Kemeny在1962年的DOPE中連字串型別都不願意給的時候，那麼請停止對後來的VB說三道四。正是BASIC當年對Fortran 66、Algol60等進行了足夠多的精簡，才有今天計算機教育的廣度和深度，這是BASIC及其繼任者，犧牲專業性背後的擔當。

正是立身於教育的Kemeny和Kurtz教授，不取分文，才讓BASIC越走越遠，更是為後來開源的做派提供了範本。其寬廣的胸懷賦予BASIC和其繼任者寬容的做派，仍是理解這門開發語言及其繼任者的核心。

BASIC的願景在於，開啟普通人探索計算機的熱情，這也為後繼的VB奠定了最基本的適用人群和存世的意義。

擔當、寬容、分享、普通人、探索的熱情，是VB家族最大的適用場景。

2、微軟接棒後的BASIC並非小兒科，簡單易用的背後，卻是極具創新和技術含量

BASIC對BOIS和其他硬體的操作能力，不僅勝任了早期計算機的作業系統，更是催生了檔案系統，為後續磁碟和個人PC系統的誕生貢獻了不可磨滅的力量。

從1980年到1991年，在與DOS系統長達十餘年磨合下，BASIC不斷蓄積力量。最終，以一己之力，讓微軟與IBM分道揚鑣，獨立支撐起微軟的生態。在僅有64k的空間裡，由普通人就能寫出經典的星際旅行，彰顯的可不僅是易用和好玩。此後VB又經歷了與Windows的10餘年的磨合，幫助微軟打下了個人PC的天下。

在BASIC後近半個世紀裡，林林總總的開發語言層出不窮，但再也找不到像BASIC那樣一脈相承的簡單易用。基於事實的平鋪直敘容易，但富有哲學的提煉，卻是難上加難。在繼任者VB簡單易用的背後，秉承的正是BASIC開創性的底層能力。

VB從1998年停更至今已二十幾年，從停更後被繼續維護至今的VBA，僅做了極少的改動。這不是說微軟放棄了，而是的確沒有什麼需要改的了。這就是為什麼VB的程式碼滿天飛，VB本身卻連隻言片語，都是鳳毛麟角。在專業人士當道的Linux裡，至今也沒有像VB那樣的工具。要說沒有東西，誰又會相信呢。

所以，VB最大的適用問題，恰恰在於深藏了自己。

3、VB的轉身，成了功成名就後的幕後主使

Vb4.0時，計算機的世界格局已基本確定，VB對於微軟系統的歷史使命已完成。VB投入到VBA的懷抱，完成了華麗的轉身。基於COM的Office和COM語言的VB，天造地設地走到了一起。

為Office服務，才是VB的戰略核心。所以後續的5.0到6.0，其實更多的是磨合完善VB的服務能力，企業級快速開發只不過是繼續保護生態罷了。6.0以後，Office站穩了，VB再次完成歷史使命。

6.0時代，網際網路已是下一個要角逐的市場。VB有太厚重的歷史包袱，如果VB繼續作為獨立開發工具，是不利於競爭的。所以，.NET出現了，最後帶有VB名字的VB.NET都未能倖免。這無關技術，從當年COM的名稱的演替中，就可見一斑。

等所有生態，都穩了，微軟終於官宣，不再支援VB的更新。而這時，已是VB6.0釋出後第10個年頭。奇怪的是，VB的真身VBA.dll，只經微小更新，就從32位時代，跨入64位時代。就如32位的PE結構，幾乎原封不動的，就到64位的地界。32位與64位之間的那層窗戶紙，誰也沒有捅破。

VB的適用困境，在於戰略轉向下的市場宣傳，而顯得迷霧重重。

二、VB的止步，恰到好處

1、VB需要跨平臺嗎？

前面也說了，跨平臺的事，交給VB就不合時宜了。是VB跨平臺很難嗎？回顧BASIC當年，從大型機、到小型機，再到微機，都是如何霸屏的！從1973年開始就擁有自己的直譯器，這比1989年誕生的Python，和1995誕生的JAVA，早的可不是一星半點。要跨平臺，你以為VB技術上做不到？那你以為.NET是哪來底氣！只不過換陣地，也需要換名稱罷了。

VB不需要跨平臺，他只需要守好Windows上Office生態，就足夠萬夫莫開。跨平臺的事，他的替身早就去幹了。

2、VB需要面向物件嗎？

1992年的VB3.0就有物件變量了，VB使用者熟悉的”.”後面那些自動化，這物件還不夠漂亮？那時就支援的VBX和OLE，類模組，那叫瞎啊！竟然還有人說，VB不是面向物件的。JAVA誕生的那年，VB4.0就擁抱了COM，竟然也有人說VB不能做大型專案。

很多人，只被光鮮的術語所吸引，而不去思考技術的本質問題。OO的本質是什麼？從01機器碼，到助記彙編，再到高階語言，核心解決的是什麼？計算機的發展歷史可以告訴我們，是更便捷的人互動。

VB具有良好的封裝性，物件變數又可以很好的傳遞這種封裝，VB還有條件編譯，這怎麼看，VB都已擁有了OO的精髓。但在事件驅動機制下，VB更側重於面向過程而已，這才是VB實用的精髓。有高效互動的視窗和事件驅動，我整那沒用的類，不是吃飽撐著了麼！

3、VB需要多執行緒嗎？

很多人說VB是單執行緒的，多執行緒太不穩定，覺得很可惜。拜託，看看任務管理器的程序頁裡，線上程數一列裡，VB產品的程序的執行緒數是1？談論VB多執行緒的，連執行緒是什麼，估計都是雲裡霧裡吧。

大概你不知道，VB服務的Office，她的GUI執行緒需要安全。所以，VB將多執行緒藏了起來，不讓你用而已。很多人在抱怨，同樣是API建立執行緒，其他都很OK，唯獨VB打死都不穩定。它沒有健全的執行環境，能穩定才是怪事。

4、VB需要指標嗎？

你要說VB沒有指標，是可笑的。執行時的VarPtr函式，AddressOf運算子，就是指標顯行的照妖鏡。在VB任性的程式碼下，處處都躲藏著指標，僅僅不讓頑皮的傢伙找到而已。因為指標對VB的戰略目標而言，實在太危險了。這跟JAVA一個道理，如果允許用指標，那培訓幾個月就上崗的貨，給你埋的雷，JAVA專案輸不起。但VB又比JAVA好，VB最終還是允許責任自負的人使用指標。

5、VB能搭上C/C++的車麼？

很多人說VB的DLL是個冒牌貨，不是標準的DLL。

首先，需要明白什麼是標準的？有匯出函式的那種？還是支援C調約的那種？其次，VB的DLL都是COM的，都有COM介面了，你還要什麼匯出函式！”.”後面的自動化，它不香麼！最後，VB的調約都是標準調約。VB連變數都可懶得申明，C調約這種需要自己平衡堆疊的活，怎麼可能入得了VB的法眼。更何況Win32API中絕大部分都是標準調約，非此調約的，也基本上是執行緒不安全的。

VB編譯時設定匯出引數即可匯出函式， VB預設情況下關閉了該配置，因為有COM介面方便又安全。匯出函式好看麼？VB預設也不給你用指標啊！諸如很多Shell32.dll這樣的系統元件，就是既有COM介面，又有匯出函式，不知道算不算標準DLL！

6、在個人PC的Windows（X86）環境下，VB從不缺材料，VB有寬敞任性的客廳，也有Win32Api明亮的視窗

很多人說VB沒有函式指標，很多系統未文件化的，未匯出的函式不能使用，大大限制了VB的應用。AddressOf那個小短腿除了給回撥API跑路外，而且還只能在標準模組中，VB使用者是得不到一點實惠。

是的，VB對函式指標諱莫如深，對使用者做的是很絕，因為MSVBVM60.DLL它自己要用。未文件化和未匯出的系統函式，本來就不讓你用，這是系統對所有語言一視同仁的隱藏。如同VB的指標，它最終還是允許責任自負人士使用的。為了保證任性的使用者，提交給系統的引數，不危及到系統安全，它必須檢查提交的引數。這也是很多破解VB的人，老是會在MSVBVM60.dll中打轉的原因。

那VB也不能呼叫很多C調約的API呀，這個問題就有點深度了，跟函式指標一樣，需要揭開VB的層層迷霧才能回答，這不是一句兩句能夠說的清楚的了。總之VB能使用系統提供的所有API，VB的適用性問題，其實就是WIN32API的問題。

7、VB編譯的效能

8、VB的IDE堪稱獨領風騷

VB的IDE雖然外觀花樣不如現在很多編輯器，但是其解釋執行的功能，已獨領風騷好多年。原始碼級逐句除錯修正的功能，對於寫程式碼、除錯程式碼而言，簡直不要太爽。好用與否，自不必多說，誰用誰知道，這是其他IDE無法企及的高度。

從1973年第1代BASIC直譯器，到1998年停更，歷經25年的錘鍊，後期維護至今又有20餘年，這是其他直譯器無法企及的臨床實戰經驗。VBA語言經過針對性改造後，其IDE以整個Office的GUI為GUI，進行事件驅動，所有程式碼都執行在該GUI執行緒上，所以效能遠勝其他解釋機制。

三、VB/VBA請讓我點名表揚你

夜深了，暫時想起的就是這些，其他的以後在技術細節中介紹吧。我相信，這些點已足以說明，VB簡單任性背後的不簡單。看似沒落背後，是強大的生命原力。這些應該足以讓喜歡VB的人們，繼續保持探索的熱情，做出有價值的產品來。所以，VB/VBA，請讓我點名表揚你！