《真是想不到系列》
每次看大師的東西到了精彩之處，我就會拍案叫絕："哇噻，真是想不到！"。在經(jīng)過很多次這種感慨之后，我發(fā)現(xiàn)只要我們動了腦筋，我們自己也能有讓別人想不到的東西。于是想到要把這些想不到的東拿出來和大家一起分享，希望拋磚引玉，能引出更多讓人想不到的東西。
真是想不到系列之一：VB到底為我們做了什么？
關(guān)鍵字：VB、底層、WIN32、API、COM
難度：中級
要求：熟悉VB，會用VC調(diào)試器，了解WIN32 SDK、COM。
VB一直以來被認為有以下優(yōu)缺點：優(yōu)點是上手快、開發(fā)效率高；缺點是能力有限，運行效率低。這正是有些軟件把VB做為首選語言，而有些軟件肯定不會用VB做的原因。而很多VC，DELPHI的程序員都認為VB里搞開發(fā)不自由，它讓我們做事變?nèi)菀椎耐瑫r，也讓我們發(fā)揮的余地越來越小。的確，簡單和功能強大這兩者本身就是一對矛盾。那怕一行代碼不寫，僅僅起動運行一個空窗體這樣簡單動作，VB在底下就為我們做了大量復(fù)雜的工作（決不僅僅是注冊窗口類、顯示窗口、起動消息循環(huán)這么簡單），這些工作對程序員是透明的。我們在感謝VB開發(fā)小組對我們程序員體貼入微的同時，不禁也要責(zé)怪為什么在文檔中對這些底層的動作只字未提，雖然這些動作對最終的程序也許并無影響，但我們擁有知情權(quán)，更何況這些動作有時的確會影響我們的工作（我將在本系列后面的《VB多線程》中談到這種影響）。
然而，所有希望從本文得到"未公開技術(shù)秘密"的朋友你將會很失望，因為我能夠知道的和你一樣多，我們所能做的一切就是站在外面來猜VB在里面做了什么？所以我決不是要帶大家一起去將VB反向工程，而是想通過猜想VB的內(nèi)部工作來將一些原來比較模糊的概念搞清楚。作為一個系列的第一篇文章，它的目的是為了后面的深入打下基礎(chǔ)，所以我會在需要的時候指出我們必須掌握的知識點，如果你不清楚，請及時地學(xué)習(xí)相關(guān)書籍來補課，具體見《參考書目》。
最后，要聲明我在本文中所做的各種實驗和推斷僅是我個人的觀點，不能保證其正確性，并且不承擔(dān)任何相關(guān)的法律責(zé)任。
好，開始吧！首先準備好我們的武器，我下面要使用的工具主要有：VB6中文企業(yè)版+SP5（廢話），還有SPY++、Dependency Walk和OLE Viewer（以下簡稱SPY和DEPEND和OLEVIEW，SPY在VB光盤的common/tools/vb/下的SPY目錄中，OLEVIEW是其下OLETOOLS目錄中的OLEVIEW.EXE，注意其下還有一個OLE2VW32.EXE功能類似，不過本文所指的是OLEVIEW.EXE，還Denpend在其下的Unsupprt/DEPEND里）。還要用用VC（上面提的工具在VC里有），因為我們還要看看VB生成的代碼，搞VB高級開發(fā)的朋友一定要會用VC調(diào)試器，懂點匯編更好。當(dāng)然，本文的重點不在這兒，所以沒有VC也不要緊。
打開VB6新建一標準EXE工程，在"工程"->"引用"對話框里應(yīng)該已有四個引用，簡單點就是：1、Visual Basic For Application(VBA) 2、VB運行時對象庫 3、VB對象庫 4、OLE自動化。前面三個是任何VB工程都必須的，你想不要都不行，不信你試著去掉對它們的引用。那么這三個核心類型庫各有什么用，在最終生成的可執(zhí)行程序中扮演怎樣的角色，這是本文要分析的第一個問題。
1）VB、VBA、VBS的區(qū)別你搞清楚了嗎？
首先VBS不應(yīng)該和VB、VBA放在一起比較，它是微軟按照自己定義的ActiveX Scripting規(guī)范完全從頭開始寫成的腳本語言，雖然它的語法結(jié)構(gòu)和VB非常相似，但VBS僅僅依靠自動化對象來擴充其功能（只有后期綁定），它不能用implements來實現(xiàn)接口，不可能在VBS里直接使用API，沒有VarPtr這樣能得到指針的函數(shù)，而VBS缺少的這些功能正是VB和VBA所特有的。當(dāng)然，這不是說VBS不如VB或VBA，Windows已經(jīng)為VBS提供了足夠強大的功能，我們可以用VBS來做腳本COM組件，而且借自動化對象的能力VBS可以說能力無限，所以有病毒用VBS來寫，對程序員來說VBS最重要的功能莫過于可以給自己的軟件提供宏功能，就象VC中提供的VBS宏功能那樣。注意，VBS是Free的，這和在Office中使用VBA來提供宏功能不同，要集成VBA需要價格不低的許可證費用，關(guān)于腳本語言可參見MSDN中Platform SDK/Tools and Languages/Scripting。（在本系列后面的文章《腳本功能》中我會實做一個用VBS來提供宏功能的小軟件）
那么VB和VBA又有什么不同呢？好吧，眼見為實，開始我們的實驗吧！
如果裝了Office 2000以上版本，那么打開OLEVIEW，點擊File下的View TypeLib查看位于E:/Program Files/Common Files/Microsoft Shared/VBA/VBA6下的VBE6.dll的類型庫，再用同樣的方法看看MSVBVM60.dll的類型庫，你會發(fā)現(xiàn)它們的類型庫基本上一模一樣，除了VBE6多了一個VBEGlobal接口和實現(xiàn)這個接口的Global對象，這個Global對象我們也可以在VBA編程環(huán)境（比如用WORD的VB編輯器）中用對象瀏覽器看到。它有二個方法Load和UnLoad，還有一個UserForms屬性，這是因為VBA6使用MS Form 2.0 Form設(shè)計器(FM20.dll)來設(shè)計和使用UserForm窗體（而在VB6中，我們可以使用多個設(shè)計器。比如通過使用MS Form 2.0 Form設(shè)計器，我們就能在VB中使用VBA所使用的UserForm用戶窗體）。和VBA的Global對象類似，在VB中也有GLobal對象，從VB的對象瀏覽器中可以知道它在vb6.olb這個類型庫中，這個類型庫就是每個工程都必須引用的VB對象庫，所有的VB內(nèi)置對象都在這里。而VBA的UserForm中使用的對象都在FM20.dll中。
除了上述不同外，VB和VBA還有一個最大的不同，就是VBA不能生成EXE可執(zhí)行文件，但可以猜想在IDE環(huán)境中VBA和VB都要把代碼編譯成p-code來執(zhí)行，后面我將用實驗來證明的確是這樣，雖然在具體的實現(xiàn)上VB和VBA有很大的不同。
從上面的分析上可以看到VB和VBA還是有很大不同的，這種不同主要體現(xiàn)在編程環(huán)境和對象結(jié)構(gòu)上，但在本質(zhì)上它們之間卻有著不可割舍的血源關(guān)系。如果剛才你仔細地觀察了MSVBVM60.dll的類型庫，你就會發(fā)現(xiàn)如下的片斷：
// Generated .IDL file (by the OLE/COM Object Viewer)
[
dllname("VBA6.DLL"),
uuid(35BFBDA0-2BCC-1069-82D5-00DD010EDFAA),
helpcontext(0x000f6ec4)
]
module Strings {
[entry(0x60000000), helpcontext(0x000f665f)]
short _stdcall Asc([in] BSTR String);
[entry(0x60000001), helpcontext(0x000f6e9f)]
BSTR _stdcall _B_str_Chr([in] long CharCode);
……………
}
什么？在MSVBVM60.dll中的對象其方法卻定義在VBA6.DLL中？！VB安裝目錄下不就有個VBA6.DLL嗎？再用OLEVIEW看看它，哇噻，真是想不到它居然和MSVBVM60.DLL的一模一樣。怎么回事？趕快再拿出DEPEND來看看VBA6.dll、MSVBVM60.dll和VBE6.dll這三個DLL的輸出函數(shù)。哈，又有新發(fā)現(xiàn)，我們可以發(fā)現(xiàn)在三個DLL的輸出函數(shù)中從編號512到717絕大部分都是一模一樣的一些以rtc開頭的函數(shù)，比如595的rtcMsgBox（rtc是什么？應(yīng)該是Run Time Component? Control? Code?有誰知道嗎？），這說明三個DLL都有著相同的運行時VBA函數(shù)。
我們再用DEPEND來觀察一下VB6.EXE, 我們可以發(fā)現(xiàn)VB6.EXE引入了VBA6.DLL中一些它特有的以Eb和Tip開頭的函數(shù)，從這些函數(shù)的名稱上可以發(fā)現(xiàn)它們的功能都是IDE相關(guān)的，比如79的EbShowCode和82的TipDeleteModule。VB6.EXE恰恰沒有引入任何rtc開頭的函數(shù)（注意一）。我們再來看看MSVBVM60.DLL，隨便找一個用了MsgBox函數(shù)的編譯后的文件，用DEPEND來觀察它，就會發(fā)現(xiàn)它引入MSVBVM60.DLL輸出的595號rtcMsgBox函數(shù)（注意二）。并且引入MSVBVM60.DLL中很多以下劃線開頭的函數(shù)，比如__vbaVarAbs（注意三）。其實從這個三個"注意"中我們已經(jīng)可以進行一些猜想，無論對錯，你可以先想想。
如果你沒有跟著我做實驗，而僅僅是看這篇文章的話，我猜想你應(yīng)該有點昏了。如果你自己動手做了這些實驗，現(xiàn)在你應(yīng)該充滿了疑問而急侍看到結(jié)論。所以請一定要親手試一試，學(xué)習(xí)研究問題的方法比看結(jié)論更重要。
到這里至少我們可以得出結(jié)論：VB和VBA本就是同宗的姐妹，只不過姐姐VB的功夫要比妹妹VBA歷害些。不過姐姐只會單打獨斗是女強人；妹妹卻只會傍大款。姐姐有生育能力，是真正的女人；妹妹卻不會生崽，但深譜相夫之道，一番教導(dǎo)指揮之下可使她老公增色不少，而VBS呢，也是大戶人家的女兒，不過沒有VB和VBA姐妹優(yōu)秀的血統(tǒng)，嬌小玲瓏干不得粗活只能指揮些自動聽話的對象來干活，她樂于助人品德好不象VBA那樣只認大款，VB、VBA、vbs三個女人我都喜歡。
2)Native Code(本地代碼)到底做了什么？
打起精神，我們再深入一步。用OLEVIEW得到的類型庫還不能正確的反映各對象方法對應(yīng)的DLL中的函數(shù)入口，你應(yīng)該已經(jīng)發(fā)現(xiàn)用OLEVIEW得到的IDL文件中各個方法的entry屬性值都是0x600000XX這樣的假東西。要得到類型庫中各方法在DLL中的真正入口，我們需要自己來寫段程序。
即使在VB中我們也可以非常容易地獲取類型庫信息，再加上點COM初始化和調(diào)用代碼，我們就能用自己的代碼實現(xiàn)VB6才引入的CallByName函數(shù)（在本系列后面的《Hack COM》中我會更深入談?wù)凜OM，作為一名VB程序員對COM的理解非常重要）。由于本文的關(guān)鍵不是指導(dǎo)如何在VB里使用類型庫，所以下面提供的方法盡量從簡。
新建一個標準EXE工程，添加對TypeLib Infomation的引用，在Form中放一個名為lblInfo的標簽，然后添加如下代碼:
´程序1
Private Sub Form_Load()
Dim oTLInfo As TypeLibInfo
Dim oMemInfo As MemberInfo
Dim sDllName As String
Dim sOrdinal As Integer

Set oTLInfo = TLI.TypeLibInfoFromFile("MSVBVM60.DLL")

lblInfo = "MATH模塊包含以下方法：" & vbCrLf

For Each oMemInfo In oTLInfo.TypeInfos.NamedItem("Math").Members
With oMemInfo
.GetDllEntry sDllName, vbNullString, sOrdinal

lblInfo = lblInfo & .Name _
& "定義在" & sDllName & "中，" _
& "其編號為" & sOrdinal _
& vbCrLf
End With

Next
End Sub
運行以后我們就可以知道MATH模塊中的Abs方法定義在VBA6.DLL中，其編號為656。在DEPEND中查看VBA6.DLL中編號為656的函數(shù)，果然就是rtcAbsVar，用VBE6.DLL試試結(jié)果相同。
還記得前面的注意一吧，VB6.EXE沒有引入rtc開頭的函數(shù)這說明在IDE環(huán)境中執(zhí)行的VBA方法實際上是通過COM調(diào)用VBA對象庫中的方法（跟蹤p-code是噩夢，所以我無法驗證它用的是什么綁定方式）。而注意二中提到的最終可執(zhí)行程序中引入了rtcMsgBox，如我們所料最終的程序會直接調(diào)用它，這要比COM調(diào)用快一點，但在跟蹤最終程序時，我發(fā)現(xiàn)rtcMsgBox內(nèi)部卻是經(jīng)過了二萬五千里長征后才會去調(diào)用MessageBoxA這個API，其間有多次對其它對象的COM調(diào)用，慢！可能是因為顯示的是模態(tài)對話框，在多進程多線程環(huán)境有很多需要考慮的因素吧，如果你是瘋狂在意效率的程序員，你應(yīng)該試試用API來重寫MsgBox，絕對快不少。再來看看注意三，讓我們把以下的程序編譯成使用本地代碼的"程序2.EXE"（為了后面的實驗，可以在工程屬性的編譯選項卡中將它設(shè)成"無優(yōu)化"和"生成符號化調(diào)試信息"程序2.EXE""）：
´程序2
Private Declare Sub DebugBreak Lib "kernel32" ()
Private Sub Main()
Dim i As Long, j As Long
Dim k
i = &H1234
DebugBreak
k = 1234
j = Abs(k)
j = Abs(i)
MsgBox "ss"
j = VarPtr(i)
End Sub
用DEPEND觀察"程序2.EXE"，我們可以發(fā)現(xiàn)"程序2.EXE"并沒有如我們預(yù)期的一樣在引入595的rtcMsgBox的同時引入656的rtcAbsVar，相反它引入了__vbaVarAbs和__vbaI4Abs，看看函數(shù)名就知道一個針對的是Variant，一個針對的是long。這說明VB在最終生成的代碼中對象Abs這樣的可以進一步針對不同類型優(yōu)化的VBA函數(shù)進行了相應(yīng)的處理，觀察一下所有以__vba開頭的函數(shù)絕大部分都是那些最基本最常用的VBA函數(shù)，可以說__vba開頭的VBA函數(shù)是rtc開頭的VBA函數(shù)的優(yōu)化版本，它們基本上是VB開發(fā)小組重新寫的，絕大多數(shù)在函數(shù)內(nèi)部實現(xiàn)自身功能，而rtc開頭的函數(shù)大多數(shù)是調(diào)用COM服務(wù)對象來完成工作。從這么多__vba開頭的函數(shù)上可以看出VB小組在Native Code（本地代碼）的優(yōu)化上下了不少功夫，這決對不是吹牛。它的確高度優(yōu)化了不少科學(xué)計算相關(guān)的函數(shù)，以ABS為例Native Code要比p-code快4倍以上。但是并不是所有的計算函數(shù)都經(jīng)過了這樣的優(yōu)化，比如Rnd函數(shù)，它就沒有對應(yīng)的__vba開頭的優(yōu)化函數(shù)，而是直接對應(yīng)到rtcRandomNext函數(shù)上，雖然rtcRandomNext也已經(jīng)優(yōu)化過，但內(nèi)部依然用了COM調(diào)用，還是不如自己重寫的快，我不明白為什么VB開發(fā)小組沒有考慮為它寫一個對應(yīng)的__vbaRnd。
不要以為上面的分析沒有意義，因為我們可以從現(xiàn)象看本質(zhì)，也可以從本質(zhì)來解釋現(xiàn)象。比如我們再做一個實驗，給你的代碼加入一個類模塊，你可以試試聲明一個和內(nèi)部方法同名的公有的方法（這是一個很有用的技術(shù)，在本系列后面的《錯誤處理》中我們會用到這種方法），比如我們可以聲明一個Public Function Rnd(x) as single，同樣我們可以自己寫一個同名的MsgBox。但是你試試能不能聲明一個Public Function abs(x) ，這時VB肯定會彈出一個莫名其妙的編譯錯誤提示框告訴你"缺少標識符"，這種錯誤發(fā)生在你的函數(shù)名和VB關(guān)鍵字沖突的時候。但是為什么同樣是MATH模塊中的函數(shù)，abs是關(guān)鍵字，rnd卻不是，VB文檔里是不會告訴你為什么的，但如果你認真的看了我上面的實驗分析，我們就能猜想這是因為VB對需要進一步優(yōu)化的函數(shù)已經(jīng)做了高度優(yōu)化處理，VB開發(fā)小組為了保護他們的勞動成果，并顯示他們對自己優(yōu)化技術(shù)的自信，而禁止我們重寫這些函數(shù)，同時VB開發(fā)小組也承認還有些函數(shù)有待進一步優(yōu)化，所以準許我們重寫之。在這里我要提出一個偉大的猜想：凡是能夠被重寫的函數(shù)就能夠被優(yōu)化，就象凡是大于2的偶數(shù)就能夠被分解成兩個質(zhì)因數(shù)的和一樣。
說到優(yōu)化，還應(yīng)該談?wù)勚苯覣PI調(diào)用和使用API類型庫的差別，還必須談?wù)刅B所使用的后端優(yōu)化器（和VC用的是一樣的優(yōu)化器），還想談?wù)勅绾伪M最大可能來使用vTable綁定……（準備在本系列中另寫一篇《優(yōu)化》來談這些問題）。
看了本地代碼，我們再來看看p-code，要是你看了MSDN中關(guān)于p-code的原理，你肯定會頭大。平心而論p-code真是一個了不起的技術(shù)，代碼大小平均可以縮小50%。我們把程序2編譯成p-code看看，還是用DEPEND來觀察，發(fā)現(xiàn)它并沒有引入__vba開頭函數(shù)（沒有使用優(yōu)化的VBA函數(shù)？），卻引入了CallEngine這樣的東西（肯定是為了調(diào)用p-code偽碼解釋引擎），而且和Native Code一樣都引入了rtcMsgBox（編譯生成的p-code在調(diào)用MsgBox時應(yīng)該比在IDE環(huán)境中運行的p-code快）。
如果你迫不及待地運行了程序2，你就會發(fā)現(xiàn)它將彈出一個應(yīng)用程序錯誤對話框，說程序發(fā)生異常。別怕，這是因為調(diào)用了DebugBreak這個API的緣故，這個API其實就是產(chǎn)生一個Int 3中斷，使得我們能夠中斷程序執(zhí)行。如果你裝了VC這樣的支持即時調(diào)試的調(diào)試器，你可以在錯誤對話框中點擊"取消"，這樣可以起動調(diào)試器來調(diào)試程序。我就是這樣跟蹤程序運行的。如果你想看看VB生成的程序反匯編代碼可以自己試試，我們可以用同樣的技術(shù)在VB或VBA的IDE中來中斷程序執(zhí)行，比如我們完全可以在Word的VB編輯器中運行上面程序2的代碼，從而中斷于Word的進程中，并可觀察到VBA生成的p-code代碼。比如VB和VBA在IDE中生成的p-code代碼就會發(fā)現(xiàn)它們這間有很大的不同。
所以，IDE中運行的程序和最終生成的程序是完全不同的。用SPY++看看你在IDE中運行的窗體，你會發(fā)現(xiàn)它在VB的主線程下，也就是說在IDE中你用程序做出的窗體和VB IDE工作窗口一樣屬于VB IDE，你的程序在IDE中運行時申請的資源也屬于VB IDE。有些程序在IDE中運行會讓IDE死掉（在VB5中寫純API多線程就千萬別在IDE中運行，定死無疑，相比之下VB6的IDE健壯得多）。還有些程序可能在IDE中能正常工作，但生成EXE后就工作不了?？傊?，在寫系統(tǒng)程序時要考慮到這種不同可能引起的問題。

3)VB的編譯技術(shù)，要我怎么夸你，又要我怎么罵你。
看了上面對Native Code的高度評價，你可能會對VB做出的東西更有信心了，腰板更直了。是的，作為VB程序員沒有什么需要害羞的，一個功力深厚的VB程序員理應(yīng)拿比普通VC程序員更多的工資，因為他的生產(chǎn)力是VC程序員的好幾倍，而做出的程序在質(zhì)量上和VC做的相差無幾。
甚至有大師開玩笑說VB的內(nèi)置對象就是用VB寫出的，比如我們可以自己寫Form.cls、Label.ctl，呵呵，我們還真不能排除這種可能性（雖然用VB不可能直接生成vb6.olb）。如果真是這樣，看來VB小組自己都對自己的編譯優(yōu)化技術(shù)非常有信心。
實際上我們看看VB安裝目錄下的C2.exe的屬性，再看看VC的C2.DLL的屬性，就會發(fā)現(xiàn)它們是同一個東西，同樣Link.exe也是VC的，所以我們完全可以對VB程序的后端優(yōu)化編譯器以及聯(lián)結(jié)放心了。它們根本就是VC開發(fā)小組東西，或者VB、VC都是同一個編譯器開發(fā)小組在做編譯模塊。總之，我們可以壯著膽說我們VB做的程序其二次優(yōu)化和聯(lián)結(jié)用的是和VC一樣的技術(shù)，嘿嘿，你有的我也有，我有的你沒有的（純屬詭辯）。
還有，沒有任何編譯器比VB編譯器更快，因為在IDE中VB就是一種解釋型語言，這才是VB開發(fā)效率高的關(guān)鍵，快得幾乎感覺不得編譯過程。其請求時編譯，后臺編譯技術(shù)更是一只獨秀，厲害啊！想想看，別的語言的程序員有多少時間花在了等待代碼編譯和重新聯(lián)結(jié)上啊！
不要高興得太早，因為最終的目的還是要生成可執(zhí)行文件。在VB中沒有分塊編譯和增量聯(lián)結(jié)的功能，VB在生成可執(zhí)行程序時總是編譯所有模塊并完全重新聯(lián)結(jié)，而在別的編譯語言中我們可以僅編譯最近修改過的文件（分塊編譯），聯(lián)結(jié)時將新生成的代碼附在可執(zhí)行程序的后面，并將原來的代嗎標記為作廢（增量聯(lián)結(jié)，最終的可執(zhí)行程序會越來越大，但聯(lián)結(jié)時間大大縮短）。做實驗看看，會發(fā)現(xiàn)在VB中每次生成可執(zhí)行文件所花時間都是相同的。我不知VB開發(fā)小組為什么不提供分塊編譯和增量聯(lián)結(jié)的功能，可能VB開發(fā)小組認為生成可執(zhí)行文件在VB中不是經(jīng)常要做的工作。但是實際上這種理由是說不過去的，因為如前面所說IDE中運行程序和最終程序有很大不同，如我們要經(jīng)常編譯出可執(zhí)行文件才能真正對它進行Profile，又如我們要調(diào)試多線程程序不能在VB IDE中做，在這些情況下每次修改后都要重新生成可執(zhí)行文件，我們浪費了不少時間去編譯已編譯過的代碼，聯(lián)結(jié)已聯(lián)結(jié)過的程序。我猜想這是因為VB生成可執(zhí)行程序時進行了全局優(yōu)化，所以必須得全部重新編譯聯(lián)結(jié)。但提供一個新的功能讓我們能夠生成不進行全局優(yōu)化的可以分塊編譯的調(diào)試版本，對Vb開發(fā)小組應(yīng)該不是難事吧?。ㄎ矣幸粋€變通的解決方案，還在試驗中）
　　在來看看VB6安裝目錄下的VBAEXE6.lib，怎么只有1k大一點，可以猜想里面應(yīng)該不會有代碼，多半是些象vTable這樣的函數(shù)地址跳轉(zhuǎn)表，或者是些全局常量，我也不知道。但至少說明VB可以用靜態(tài)聯(lián)結(jié)庫了，為什么不把這個功能提供給我們，讓我們有更多的選擇。
再做個實驗看看，做一個標準EXE工程，里面只有一個標準模塊，模塊里面只一個Sub Main，Sub Main里面什么也沒有，將它生成為EXE文件?？纯矗耄?6k多。你要是有時間跟蹤這個什么也不做的程序看看，就會知道它要做很多事，初始化Err和App對象，準備COM調(diào)用，準備VB、VBA對象庫，甚至為使用ActiveX控制也做了準備，嘿嘿，看服務(wù)多周到。你必須得用VB對象庫中的控制，不用也不行。你再多找?guī)讉€EXE工程看看，有很多東西相同，都是一個模子做出的，而且你沒有選擇模子自由。ActiveX工程也是一樣，都是Dual雙接口，你做的ActiveX控制都必須要躲在一個Extender Object后面。是的，在VB里有很多東西你沒有選擇的自由。如果需要這種自由要么不用VB，要么就得采取一些未公開的非官方的古怪的技巧（本系列文章最重要的目的之一，就是介紹這樣的非官方技巧）。
這又到文章開頭說的，VB讓我們做事情變得容易的同時也讓我們失去了不少自由。在最終代碼的生成上則也采取了公式化的做法。當(dāng)然，我們應(yīng)該全面地來看待這個問題，如同生產(chǎn)線上生產(chǎn)的東西不一定比手工的精致，群養(yǎng)的家禽不如野味好吃的道理一樣，如果需要精致的野味，意味著更多的勞動和更大的成本，這和VB所追求的更容易更便宜的目標是相違背的。

4)VB程序員也得有HACK精神。
本文的最后這個標題是嚴重離題了，但我想在此為本系列文章定下一個充滿HACK精神的基調(diào)。HACK精神是什么？沒有準確的定義，我的理解是：HACK精神 = 總想探尋未知領(lǐng)域的好奇心 + 凡事總想知道為什么的研究欲 + 總想拿出自己的東西的創(chuàng)新精神 + 解決問題的耐心和恒心。 VB的程序員也一樣需要這種精神。

最后，我們都知道VB開發(fā)小組已經(jīng)達上.NET的快車飛起來了，不能不說VB6以后再沒有VB的新版本了。微軟已經(jīng)用.NET為我們劃出了新的圈子，VB.NET是這個新圈子里的新產(chǎn)物。在圈子里面我們能夠飛得更高，但是圈子外面的天空更大，所以我依然樂意站在圈子外，虔誠地祈禱真正的VB7的誕生，阿門。