維's profileIT : 是工作還是嗜好?PhotosBlogListsMore  |  Tools Help |
|
謝謝您的瀏覽！
IT : 是工作還是嗜好?June 29 Borland最後花落誰家似乎仍有變數!今年5月6日根據外電報導英國軟體廠商Micro Focus將收購Borland，雖然我早已離開Borland數年之久，也對後期的Borland實無好感，但從學生時期便建立的感情仍然讓我無法忽略Borland在業界的消息，在5月7日我得知Borland即將被收購的消息時，心中並無太大的心情波動，因為在離開Borland時我早已預測Borland將會瓦解，因為那時Borland的CEO每天只想著股票的價格，把產品搞得亂七八糟，又要求每個人都做銷售，連技術人員都被送去做銷售的培訓，取消了Borland優良傳統的深度產品和技術培訓，那時我被強迫送去參加了數次的銷售培訓，最後我心中只想著Borland還要技術人員做什麼，這樣下去乾脆大家都轉做銷售人員不就好了，我只覺得那時的Borland實在是@!$#@%#$&^$%&。 沒想到最近又有消息指出在Micro Focus出了收購價之後，似乎又有不具名的對象也出價想要收購Borland，看來在Borland的股東沒有正式投票之前，Borland花落誰家似乎仍有變數。 May 19 CodeGear大幅揭露Delphi和C++Builder未來的發展方向!WoW，在這次的Delphi Live 2009的大會中CodeGear可以說是精銳盡出，透露了許多Delphi和C++Builder開發人員關心的產品發展方向，從這個次的大會中也終於看出Embarcadero在併購了CodeGear之後的確是真的投入研發資源讓Delphi和C++Builder放手發展，這對比於Borland在日前被Micro Focus併購，讓Borland這個昔日的金字招牌也蒙塵於競爭激烈的IT界，想必當初的Borland董事會在夜深人靜的時候也會深切懊惱不該斷送當初大好的開發工具江山吧。 在這次的Delphi Live 2009中CodeGear揭露了目前正在開發的專案，下面是這些專案的列表: Project Weaver User Experience Documentation IDE usability Team Productivity Touch IDE – Insight (easy Keyboard access to almost everything) Improvements to DataSnap Firebird Support .NET AOP SCM Support Enhanced RTTI Support Attribute Support Seamless .NET <> Native communication Windows 7 APIs and Direct 2D Full Support of SOAP 1.2 Clients Project X Cross-platform Windows, Mac OS, and Linux Cross-platform component library DataSnap on all platforms Project Chromium, Quality, Quality Quality, Quality, Quality Pascal Code Formatter Documentation of the OTA New Data binding model allowing binding to almost any property on a control More integration with the database tools. Project Commodore 64 Bit native Full compiler, RTL and VCL support for 64 native Multi-Core. Multi-threaded applications. 光從這些專案的列表就非常令人興奮了，因為很快的我們就可以在Delphi和C++Builder中看到這些技術實作出來，如果您不太瞭解其中的一些技術，沒有關係，在下面我將簡單的說明一下，因為既然Delphi Live 2009已經公開揭露了大部份的資訊，我也就可以說明一下今年年初我參加Embarcadero大會聽到的一些東西了。 Project Weaver就是即將推出的Delphi 2010和C++Builder 2010，雖然上面的列表主要是和Delphi相關的，但C++Builder 2010也將有許多新的功能。Project Weaver令人期待的就是支援Windows 7和Touch這個所謂的觸碰技術了，由於Windows 7已經獲得了業界好評因此Weaver將是第一個支援Windows 7開發的原生工具，此外Weaver也將觸碰技術實作在VCL框架之中，這代表Delphi和C++Builder的開發人員將可以非常簡單就能夠開發觸碰式的應用程式了，這實在太cool，更棒的是我聽說Weaver的觸碰技術不局限於Windows 7，似乎XP等不支援觸碰技術的OS也將由VCL框架來支援，只要您擁有觸碰設備即可，WoW，我等不及來玩玩這個功能了。 另外Weaver在編譯器方面將有大幅的強化，CG準備為Delphi和C++Builder提供類似Java和.NET的Reflection技術，這也就是Enhanced RTTI Support，因為Enhanced RTTI Support技術將做為稍後我即將說明的Delphi和C++Builder下一世代的資料存取技術New Data binding model的基石。 另外Weaver的DataSnap技術將有重大的進步，因為CG也即將把DataSnap帶入到Linux和Mac環境，DataSnap也終於開始實現它在跨平台方面的優勢。Weaver的DataSnap將支援更強大的JSON分散式架構，除了提供tcp/ip之外，也支援http/https，REST，資料加密，資料壓縮，非同步呼叫和伺服器回叫用戶端等強大的功能，我對DataSnap特別感到興趣，特別是想到DataSnap能夠提供跨平台的分散式開發時就令人高興。 Project X是跨平台Delphi的專案，我們也可以稱它為DelphiX，它將讓開發人員可以在Windows，Linux和Mac環境下使用Delphi，CG也在考慮開發一個跨平台的元件框架(VCLX? CLX?, 這個目前我也不清楚)，而且會把DataSnap移植到Linux和Mac中，仔細看看下面這張由Robert Love提供的照片，CG已經快完成了Delphi在Mac下的編譯器，這張照片顯示CG的人使用Delphi For Mac的編譯器編譯一個簡單的文字程式並且實際執行在Mac OS中。  今年年初時CG便透露Delphi For Mac的編譯器可能在2009年的夏天可以完成，呵呵，想想當初Delphi 1.0即是用Delphi編譯器開發的模型，那麼Delphi For Mac 1.0似乎也即將…. Project Commodore是Delphi 64的專案，Commodore應該會在2011年出現，它即將把Delphi全面帶入64位元的世界，類似當年Delphi 2.0把Delphi從16位元帶入32位元世界的里程碑一樣，Commodore將在Delphi的發展史中再次設定另外一個里程碑，而且Commodore也將提供多核心，多執行緒開發的新技術/新函式庫。 Project Chromium應該是一個Delphi/C++Builder的再進化專案，其中最關鍵的技術是New Data binding model，這個技術是我早已等待多年的技術，因為它將提供類似MS Entity Framework，RoR的ActiveRecord，或是Hibernate等的功能，其實我應該說它是Chuck在離開Borland之前於Borland內部進行的秘密計劃Apollo的實現，早在數年前Chuck便想為Delphi加入這些先進的資料存取技術，看看Borland浪費多少年，又浪費了多少當年這些技術精英的眼光和技術(其實還有許多非常棒的秘密計劃到現在還未見曙光，包括了Chuck的Z語言，Danny的編譯器和除錯器先進技術等以及Anders早在Delphi 2就想做的Delphi Garbage Collector)。 由於我的時間不多，不能再把更多比較詳細的資訊和大家分享，很抱歉，不過各位可以到下面的URL中仔細看看Robert Love提供的照片，您會看到許多的秘密，有機會的話我再解釋它們好了，Have Fun! http://picasaweb.google.com/LovePhotoStore/DelphiLive2009?feat=directlink#5336279721373168578 April 29 對今年的NBA季後賽沒有多大的興趣了!Kevin Garnett是我個人自Michael Jordan之後最喜歡的球員，看Garnett打球也是我最喜歡的休閒活動之一，但今年Garnett深受受傷之苦，到現在季後賽開打也一直沒有回來，因此今年我也沒什麼興致看NBA季後賽了，希望Garnett能夠儘快康復，再打幾年的好球吧。 不過心底卻有一種說不出來的淡淡憂愁 : 『狼王似乎漸老矣』。 April 28 也許我不應該說的!自從不再是CG的正式員工之後，我也必須申請參加CG產品的Beta，獲得批准之後我才能拿到Beta的產品來測試。因此前一陣子我也和一些我的朋友一樣申請參加下一版C++Builder/Delphi的Beta，很幸運的我獲得了許可，也終於在最近拿到了Beta版來玩一玩，以便填補一下Diablo 3出來之前苦苦等待的真空時期。 下一版的C++Builder/Delphi在進行Beta測試早已不是新聞了，因為Delphi的產品經理Nick已經公開的討論了許多次，CG現在也在她的網站上公開歡迎有興趣的人申請參加，申請的URL如下: https://beta.embarcadero.com/callout/default.html?callid={56DB5BD1-6DD9-40EF-8743-7C3E293085E9} 事實上我也是在上述的URL中申請參加的。 那麼這篇文章到底是討論呢? OK，除了我希望把申請參加Beta的資訊和尚不知道的朋友分享之外，主要的原因就是我有許多已經參加Beta的朋友在測試新版Delphi時發現他們無法在XP下連結到MS SQL Server 2005或是2008，一旦新版Delphi在XP下試著連結2005或是2008時就會出現代號為340的錯誤:  我也在大陸的一些網站上看到許多人就開始批評下一版Delphi的DBX驅動程式有大臭蟲，又不穩定，連MS SQL Server都連不上，但我覺得很奇怪的是既然現在是Beta版那當然有臭蟲，否則進行Beta測試是做什麼的呢?不過我想說的是這個340錯誤並不是DBX的臭蟲，而是我的朋友們並不瞭解新的DBX對於MS SQL Server的驅動程式進行了大幅的改變，因此在使用下一版Delphi連結MS SQL Server 2005/2008之前，開發人員需要安裝一個軟體。那麼是什麼軟體呢? 在回答之前，我想順便談談如何進行有效的Beta測試並且以這個例子做為說明，一旦讀者掌握了之後就做個更好的Beta測試人員了。 事實上在我朋友告訴我並且詢問我這個問題之後，我也親自測試了一下，我果然也是遇到錯誤340，無法連結MS SQL Server 2005，但在我確定它是DBX的臭蟲之前，我決定再啟動RAD Studio 2007看看有什麼不同，結果我發現在RAD Studio 2007中，DBX4是使用oledb用戶端函式庫來連結MS SQL Server，如下所示:  但是在下一版Delphi中卻改變了使用的用戶端函式庫，DBX4改用了sqlncli10.dll，如下所示:  而sqlncli10.dll是MS SQL Server 2008的原生用戶端程式(Native Client)，而這也就是為什麼會出現340錯誤的原因，因為在下一版Delphi的DBX是改用了Native Client來連結MS SQL Server而不再使用oledb，出現340錯誤是因為我們的機器中沒有安裝MS SQL Server 2008的原生用戶端程式的原因。 因此，我到下列的URL中下載MS SQL Server 2008的原生用戶端程式: http://www.microsoft.com/downloads/details.aspx?FamilyId=C6C3E9EF-BA29-4A43-8D69-A2BED18FE73C&displaylang=en 下載Microsoft SQL Server 2008原生用戶端安裝程式 : sqlncli.msi並且安裝它之後，就可以使用下一版Delphi來連結MS SQL Server 2005/2008了，也不會再出現340的錯誤了。 從上面的討論我們可以推論出下一版Delphi的DBX對於MS SQL Serevr有如下的特性:
嗯, 推論了上述3點之後我更喜歡新的DBX了。 April 21 善用C++Builder 2009的Pre-Compiled header精靈也許是我的記憶已經很模糊了，我記得在C++Builder 5時能夠提供了背景編譯的能力，允許BCB的開發人員在IDE中編譯專案時能夠啟動在背景編譯，如此一來BCB的開發人員就可以在等待BCB編譯專案的同時在IDE中執行一些其他的工作，BCB之所以提供這個功能實則是因為C++是一個3-pass的編譯器，因此需要遠多於One-Pass的Delphi編譯器更多的編譯時間。但當時BCB 5的背景編譯有許多的限制，例如開發人員無法異動正在編譯中的專案，也無法異動編譯專案的圖形使用者介面設計等，因此大部份BCB開發人員使用背景編譯編譯BCB專案時，大都是在BCB的IDE中對其他的專案進行同時開發的工作。 另外一個BCB非常重要的功能就是Code Insight，這個功能能夠幫助開發人員大幅減少需要撰寫打字的程式碼，進而增加開發的生產力。但是我知道很多BCB的開發人員關閉了這項功能，因為在早期的BCB版本中這個功能實在太慢了，導致許多BCB的開發人員抱怨為什麼BCB無法像Delphi的Code Insight一樣那麼的快速。其實BCB的Code Insight太過緩慢的問題我個人也是感同身受，因為我記得每次在做BCB的活動時，為了避免在BCB編輯器中撰寫程式碼反應太過緩慢的問題，我也都是關閉了BCB的Code Insight功能。  最後一個我要討論的問題就是BCB的Pre-Compiler Header了，雖然BCB很早就提供了Pre-Compiler Header功能以加快編譯速度，但老實說早期BCB提供的Pre-Compiler Header雖然的確能夠幫助開發人員加快編譯速度，但這個Pre-Compiler Header在C++Builder 2009之前已經有數年沒有改善了，因此仍然有很大的進步空間。 OK，看到這裡您可能會想，為什麼同時敘述上述的三個問題呢?是它們有什麼共點嗎?不然這篇文章到目前看起來是令人摸不著頭緒的。OK，現在就讓我們回到本篇文章的正題。 下圖是我在RAD Studio 2009中的一個範例BCB專案，在沒有使用新的Pre-Compiled header精靈之前，在第一次編譯這個C++Builder專案時RAD Studio仍然會為這個專案建立Pre-Compiled header，如此一來當開發人員稍後再次編譯這個專案時，編譯速度就會加快。例如如果我修改下圖中的 this->Button1->Caption = "test"; 為 this->Button1->Caption = "測試"; 接著再次編譯，那麼此時C++Builder 2009需要再次編譯21281行的程式碼，雖然整個編譯速度算是相當快速，但仍然令人奇怪，為什麼只是修改一行的程式碼卻需要編譯21281行。  其實仔細觀察原始程式就可以發現問題所在，因為在原始程式中存在如下的程式碼: #include <vcl.h> #pragma hdrstop #include "SecondForm.h" #include "MainForm.h" 舊的BCB Pre-Compiled header精靈只把VCL.H相關的程式碼預先編譯，但再看看原始程式的表頭檔，我們卻發現了下面的程式碼: #include <Classes.hpp> #include <Controls.hpp> #include <StdCtrls.hpp> #include <Forms.hpp> #include <DB.hpp> #include <DBCtrls.hpp> #include <DBGrids.hpp> #include <ExtCtrls.hpp> #include <Grids.hpp> 問題似乎就出現在這裡，因此我們需要一個能夠分析整個專案的Pre-Compiled header精靈幫助我們產生最佳的預先編譯表頭資訊，並且能夠讓開發人員進行客製化的調整。 C++Builder 2009新的Pre-Compiled header精靈就可以幫助我們完成這些工作，讓我們現在就來看看它的功效如何。 首先點選Tools|Pre-Compiled header Wizard…功能表啟動精靈，如下圖所示，如果你是第一次使用這個精靈，那麼請選擇第一個選項為專案進行一次完整的分析:  在精靈成功分析之後，它會顯示如下的對話盒，詢問你客製化的設定，例如你可以設定要包含那些表頭檔或是排除特定的表頭檔。  點選『Next>>』按鈕之後會顯示最後精靈進行的設定，它決定了預先編譯表頭檔中包含的資訊:  繼續點選『Next>>』按鈕，最後BCB會產生一個新的表頭檔pch1.h，例如在我的範例中最後的pch1.h包含如下的資訊: /* This precompiled header include file was generated on 2009/4/21 下午 03:00:09 by the RAD Studio Precompiled Header Wizard with the following settings: Project: G:\MyBogs\20090421\Demos\pBCBDemo.cbproj AllowUnguarded = 0 ExcludeProjectFiles = -1 IncludePathsOn = -1 IncludePaths = ExcludePaths = IncludeCount = 1 ManageHeader = -1 */ #ifndef pch1_H #define pch1_H #include <vcl.h> #include <tchar.h> #include <DB.hpp> #include <DBClient.hpp> #include <DBGrids.hpp> #include <DBXMsSQL.hpp> #include <Provider.hpp> #include <SqlExpr.hpp> #include <DBXInterbase.hpp> #endif 在精靈產生了pch1.h並且加入到專案之中後，請先進行一次完整的專案Build讓BCB編譯器建立新的預先編譯表頭檔。有了新的預先編譯表頭檔之後如果我再回到前面修改: this->Button1->Caption = "測試"; 為 this->Button1->Caption = "第2次測試"; 接著選擇make專案，那麼現在BCB只會編譯86行的程式碼，比使用舊的預先編譯方式快了好幾倍的速度。 更棒的是，使用新的Pre-Compiled header精靈之後由於它會產生最佳化的表頭資訊，因此此時如果你再使用BCB的Code Insight，你會發現Code Insight快速的不得了，例如在我的機器中此時再使用BCB的Code Insight功能，它的反應速度幾乎和Delphi的Code Insight一樣快了，現在我再也不需要關閉BCB的Code Insight功能了。 BTW，RAD Studio 2009的Update 3不但修改了許多的臭蟲，IDE的速度又加快了不少，例如對於相同的BCB專案，使用Update 3的編譯速度硬是比Update 1和Update 2又快了許多，絕對建議您儘快昇級到Update 3。 OK，解決了預先編譯和Code Insight的問題之後，最後就是BCB的背景編譯了，在C++Builder 2006/2007/2009中背景編譯都被移除了，因為舊的背景編譯限制太多，在BCB 5那時沒有多核CPU的時代，舊的背景編譯架構也無法利用現在最新的多核CPU，不過我知道下一版的BCB也許將提供全新的背景編譯技術，不但速度快，限制又少，甚至可以讓開發人員在背景編譯專案的同時又進行相同專案的持續開發，這對於大型的BCB專案來說實在太棒了。 試著想想，未來在BCB中我們將可結合預先編譯表頭，背景編譯和快速的Code Insight，那麼使用BCB來進行C++專案的開發將會非常的愉快，因為如此一來BCB即可讓C++的開發人員享受類似Delphi，C#和Java等快速開發的環境了。 February 06 2009開年動動腦!在2009的大年初一終於去了花蓮一遊，應該有2, 3年沒有到花蓮了吧，當我走在海岸路之際乾涸許久的心靈仿佛立刻久旱逢甘霖，滋潤了起來，連腦筋似乎都活絡了起來。隔天騎著自行車沿著海岸路一路南行的路程中，封塵已久的思緒也逐漸的脫繭而出，回想這1,2年的變化可真大啊，不但在我個人的小世界中工作劇烈的改變中，世界的經濟狀況的變化更是令人瞠目結舌，對於5年級世代的人來說，在40多歲遇上這些巨大的衝擊應該是相當大的打擊吧。 回想這幾年來，從Borland，到DevCo，CodeGear最後到Embarcadero，我個人認為C++Builder，Delphi和JBuilder的未來似乎已經漸入佳境，為什麼? 因為:
http://dn.codegear.com/article/39174 在這篇文章中Nick說明了Delphi編譯器的歷史以及Delphi編譯器即將發展的方向，在其中Nick說Delphi64位元的編譯器將在2010年中才大概會準備好，因此合理的判斷Delphi 64最早應該會在2010底或是2011年初才可能出現，那麼在2009年C++Builder和Delphi會做什麼呢? 這也得從為什麼原生Delphi 64會從2009年底延遲到2010或2011年分析起。 在Nick的文章中說明了，CodeGear因為決定為C++Builder和Delphi開發一個共同的後端編譯器(Compiler Back End)，因此延遲了原生BCB 64和Delphi 64，所謂共同的後端編譯器是指BCB 64和Delphi 64將使用一個共用的最佳化和機械程式碼產生器，如此一來不但日後在維護和發展上比較方便，由於BCB是使用由Object Pascal撰寫的VCL框架，因此當這兩個產品使用相同的後端編譯器之後，可讓BCB和Delphi的相容性更高。而且現在BCB在C/C++程式語言方面開始率先支援CPP0X標準，而Delphi又開始進入增加新的程式語言功能的階段，這個新的後端編譯器可以讓BCB和Delphi同時在程式語言方面大幅增加新的功能，因此非常讓人期待，更重要的是CodeGear可以在這個新的後端編譯器中加入更多最佳化的功能，在編譯器最佳化方面從Borland後期開始就很久沒有著墨了，因此我個人非常期待這個機會。 更有趣的是，在CodeGear中已經有許多人提倡混合編譯和跨平台編譯許多年了，但Borland/DevCo/CodeGear一直都沒有朝混合編譯和跨平台編譯發展，直到現在這個機會。在說明什麼是混合編譯和跨平台編譯之前，讓我們看看現在的BCB和Delphi這兩個產品如何編譯Delphi和C/C++原始程式。 在BCB和Delphi的BIN目錄下，BCC32和DCC32分別是BCB和Delphi的前端編譯器(Front End Compiler)，目前BCB和Delphi分別是使用各自的後端編譯器，它們是comp32x.dll和dcc120.dll(我是使用RAD Studio 2009)，如果我使用TDump來檢查這兩個dll輸出的函式，我們可以得到如下的結果: 2009開年動動腦! 在2009的大年初一終於去了花蓮一遊，應該有2, 3年沒有到花蓮了吧，當我走在海岸路之際乾涸許久的心靈仿佛立刻久旱逢甘霖，滋潤了起來，連腦筋似乎都活絡了起來。隔天騎著自行車沿著海岸路一路南行的路程中，封塵已久的思緒也逐漸的脫繭而出，回想這1,2年的變化可真大啊，不但在我個人的小世界中工作劇烈的改變中，世界的經濟狀況的變化更是令人瞠目結舌，對於5年級世代的人來說，在40多歲遇上這些巨大的衝擊應該是相當大的打擊吧。 回想這幾年來，從Borland，到DevCo，CodeGear最後到Embarcadero，我個人認為C++Builder，Delphi和JBuilder的未來似乎已經漸入佳境，為什麼? 因為: 第1， 2008年底Borland傳來非常不好的訊息，整個公司巨幅虧損不說，CEO等高階主管相繼離職，看來Borland出售開發工具之後不但沒有轉運，反而愈來愈糟糕，更證實了數年前 Borland決定放棄開發工具走向ALM是嚴重的錯誤，C++Builder，Delphi和JBuilder能夠離開Borland是最好的結果。 第2， 在2009年年初Embarcadero邀請我去舊金山參加全球大會，在Embarcadero的全球大會上我終於聽到了類似早年Borland全球大會的良好慣例，Embarcadero的CEO除了在銷售方面的強調之外，更強調了產品和品質的重要性，整個Embarcadero的全球大會也提供了許多產品和技術方面的訓練，而不像後期的Borland全球大會，Borland CEO只有滿嘴的空談和股票經，根本沒有公司和產品的發展計劃，整個Borland全球大會只有銷售訓練，產品和技術的內容一點都沒有。因此我在Embarcadero的全球大會上看到了C++Builder，Delphi和JBuilder在Embarcadero將有完全不一樣的未來。 第3， 全世界經濟狀況的改變讓許多人瞭解到簡單，好用的東西是最好的，因此許多人從昂貴的Java/.NET世界回到了原生Win32的開發世界中，準備迎接足夠未來數年使用的原生Win64開發平台的到來，這給了C++Builder，Delphi一個絕好的機會，因為原生Win64開發正是C++Builder，Delphi未來的發展道路。 第4， 這正是我想深入一點討論的內容，從許多跡象分析中可以發覺C++Builder，Delphi和JBuilder正在進行巨大的發展中，這些變化將帶來重大的改變，也將會激勵Win32和Win64開發工具的市場，對於C++Builder，Delphi和JBuilder的開發人員來說也將會覺得振奮不已。那麼C++Builder，Delphi和JBuilder會什麼樣的巨大改變呢? 讓我們一一的從一些蛛絲馬跡中分析一下，順便做為2009開年的腦筋體操，其實這些分析正是當我在花蓮海岸路一邊騎自行車一邊思考的結果。 首先我們知道從2年前開始DevCo和CodeGear便一直有公佈C++Builder，Delphi和JBuilder的發展路線圖，雖然後來DevCo和CodeGear的命運坎坷，以致C++Builder，Delphi和JBuilder的發展路線圖不斷的延後和改變，但在C++Builder，Delphi和JBuilder最終進入Embarcadero之後C++Builder，Delphi和JBuilder的發展路線也終於開始穩定下來。在前一陣子Delphi的產品經理Nick Hodges寫了一篇有關未來Delphi編譯器的文章: http://dn.codegear.com/article/39174 在這篇文章中Nick說明了Delphi編譯器的歷史以及Delphi編譯器即將發展的方向，在其中Nick說Delphi64位元的編譯器將在2010年中才大概會準備好，因此合理的判斷Delphi 64最早應該會在2010底或是2011年初才可能出現，那麼在2009年C++Builder和Delphi會做什麼呢? 這也得從為什麼原生Delphi 64會從2009年底延遲到2010或2011年分析起。 在Nick的文章中說明了，CodeGear因為決定為C++Builder和Delphi開發一個共同的後端編譯器(Compiler Back End)，因此延遲了原生BCB 64和Delphi 64，所謂共同的後端編譯器是指BCB 64和Delphi 64將使用一個共用的最佳化和機械程式碼產生器，如此一來不但日後在維護和發展上比較方便，由於BCB是使用由Object Pascal撰寫的VCL框架，因此當這兩個產品使用相同的後端編譯器之後，可讓BCB和Delphi的相容性更高。而且現在BCB在C/C++程式語言方面開始率先支援CPP0X標準，而Delphi又開始進入增加新的程式語言功能的階段，這個新的後端編譯器可以讓BCB和Delphi同時在程式語言方面大幅增加新的功能，因此非常讓人期待，更重要的是CodeGear可以在這個新的後端編譯器中加入更多最佳化的功能，在編譯器最佳化方面從Borland後期開始就很久沒有著墨了，因此我個人非常期待這個機會。 更有趣的是，在CodeGear中已經有許多人提倡混合編譯和跨平台編譯許多年了，但Borland/DevCo/CodeGear一直都沒有朝混合編譯和跨平台編譯發展，直到現在這個機會。在說明什麼是混合編譯和跨平台編譯之前，讓我們看看現在的BCB和Delphi這兩個產品如何編譯Delphi和C/C++原始程式。 在BCB和Delphi的BIN目錄下，BCC32和DCC32分別是BCB和Delphi的前端編譯器(Front End Compiler)，目前BCB和Delphi分別是使用各自的後端編譯器，它們是comp32x.dll和dcc120.dll(我是使用RAD Studio 2009)，如果我使用TDump來檢查這兩個dll輸出的函式，我們可以得到如下的結果: Exports from comp32x.dll 44 exported name(s), 44 export addresse(s). Ordinal base is 1. Sorted by Name: RVA Ord. Hint Name -------- ---- ---- ---- 0016E65C 32 0000 ASMFILENAME 0016E664 34 0001 ASMOPTIONS 0010C008 44 0002 BCCGETINTERFACE 00005A44 25 0003 BREAKCOMPILE 000FFAB8 14 0004 BROWSERFILEINDEXTONAME 000FCE90 1 0005 BROWSERFINDDECLARATION 000FE48C 6 0006 BROWSERFINDSYMBOL 000FD1D0 4 0007 BROWSERGETAUTORESULTTYPE 000FD1C4 3 0008 BROWSERGETAUTOTYPE 000FF9DC 13 0009 BROWSERGETBASETYPE 000FE4B8 7 000A BROWSERGETOBJTYPE 000FD0D0 2 000B BROWSERGETREFERENCES 000FF82C 11 000C BROWSERGETRESULTTYPE 000FE5F8 8 000D BROWSERGETSYMBOLFLAGS 000FDCE0 5 000E BROWSERGETSYMBOLS 000FF070 9 000F BROWSERGETSYMBOLTEXT 000FF0EC 10 0010 BROWSERGETTYPECODE 000FF940 12 0011 BROWSERGETTYPESYMBOL 000054F4 28 0012 COMPILE 00005528 29 0013 COMPILEANDBROWSE 00005568 30 0014 COMPILEANDKIBITZ 000055E0 31 0015 COMPILEWITHOPTIONS 0014110C 36 0016 COMPMESSAGES 0014A0F3 24 0017 CONFIG 0016E7C0 27 0018 CUMLINENO 0010CCEC 22 0019 DbEval32InitProc 00141BC4 40 001A ERRBREAK 001CAD28 26 001B FILENAME 00141BC0 37 001C FIRSTERROR 00141BB8 38 001D FIRSTWARNING 00004B2C 42 001E FLUSHPCH 0011C0AC 43 001F GetCompilerListeners 00100888 16 0020 KIBITZGETARGINDEX 0010087C 15 0021 KIBITZGETKIND 00100D20 21 0022 KIBITZGETOVERLOADS 00100CEC 20 0023 KIBITZGETVALIDSYMBOLS 00100898 17 0024 KIBITZRESULTGETFLAGS 001008D0 19 0025 KIBITZRESULTGETNAME 001008B0 18 0026 KIBITZRESULTSETFLAGS 0016E660 33 0027 OBJFILENAME 00005614 41 0028 TOTALERRORCOUNT 00141BBC 39 0029 WARNINGCOUNT 00149C70 35 002A WARNINGS 0013E0F8 23 002B ___CPPdebugHook Exports from dcc120.dll 105 exported name(s), 112 export addresse(s). Ordinal base is 8. Sorted by Name: RVA Ord. Hint Name -------- ---- ---- ---- 0000ECA0 73 0000 BrowserFindDeclaration 0000F54C 84 0001 BrowserFindSymNamespace 0000CC24 58 0002 BrowserFindSymSource 0000F4FC 83 0003 BrowserFindSymUnit 0000CBA0 57 0004 BrowserFindSymbol 0000F4C8 82 0005 BrowserFindUnit 0000F660 89 0006 BrowserGetAncestor 0000F738 93 0007 BrowserGetArrayIndex 0000F6FC 92 0008 BrowserGetArrayIndexSymFromType 0000F7CC 96 0009 BrowserGetArrayOfSym 0000F7A8 95 000A BrowserGetArrayOfSymFromType 0000F7E8 97 000B BrowserGetArrayOfType 0000F754 94 000C BrowserGetArrayOfTypeFromType 0000F974 102 000D BrowserGetAssemblyLocation 0000F27C 78 000E BrowserGetAutoResultType 0000F21C 77 000F BrowserGetAutoType 0000EC64 72 0010 BrowserGetBaseType 0000E468 64 0011 BrowserGetCallingConvention 0000F620 88 0012 BrowserGetClassHelpers 0000F5A4 85 0013 BrowserGetClassRef 0000FAB0 104 0014 BrowserGetContainsList 0000F804 98 0015 BrowserGetDefaultProperty 0000E3C8 63 0016 BrowserGetDefaultValue 0000F2E0 79 0017 BrowserGetDirectlyUsedUnits 0000F6D8 91 0018 BrowserGetHelpedType 0000F6A0 90 0019 BrowserGetImplementedInterfaces 0000F5F0 87 001A BrowserGetInheritedScope 0000F0D0 75 001B BrowserGetObjType 0000D900 61 001C BrowserGetOverloads 0000F948 101 001D BrowserGetPointedType 0000F010 74 001E BrowserGetReferences 0000EB84 69 001F BrowserGetResultType 0000EBCC 70 0020 BrowserGetResultTypeType 0000F4B0 81 0021 BrowserGetSymbolDocumentation 0000DB5C 62 0022 BrowserGetSymbolFlags 0000FA88 103 0023 BrowserGetSymbolNameOffset 0000F3F4 80 0024 BrowserGetSymbolPath 0000E480 65 0025 BrowserGetSymbolText 0000E4B0 66 0026 BrowserGetSymbolTextBuff 0000F5CC 86 0027 BrowserGetSymbolValue 0000D7D0 60 0028 BrowserGetSymbols 0000F888 100 0029 BrowserGetSymbolsFromUnit 0000EB58 68 002A BrowserGetTypeCode 0000E9C8 67 002B BrowserGetTypeCodeType 0000F200 76 002C BrowserGetTypeFromSymbol 0000EC10 71 002D BrowserGetTypeSymbol 0000F874 99 002E BrowserGetUnitSymbol 0008852C 108 002F BuildPackages 0007A994 107 0030 CallNextUnitFreeHook 0000B4BC 52 0031 ClearAllStates 0000B4CC 53 0032 ClearCompState 00002868 20 0033 ClearPackageCache 00002854 19 0034 ClearUnitCache 000021BC 13 0035 CompilerCompile 000021E0 14 0036 CompilerCompileCmdLine 0000219C 12 0037 CompilerCompileUnit 00001FA8 11 0038 CompilerDone 00002738 18 0039 CompilerFindError 0000237C 15 003A CompilerGetUnit 000024B0 16 003B CompilerGetUnitSymbol 00001F2C 10 003C CompilerInit 00002B2C 26 003D CompilerShouldCompile 00002B70 27 003E CompilerVerifyCodePageOption 0001673C 8 003F DbEval32InitProc 00001754 9 0040 DccInitialize 000084F8 43 0041 DoneEvaluate 000084C0 41 0042 DoneProcess 00006D2C 30 0043 EvalCondition 000068A8 28 0044 Evaluate 00007C64 34 0045 FindLineCode 00007D1C 35 0046 FindLineCodes 00007DF0 36 0047 FindSourceLine 000088A8 44 0048 FreeCompile 00007428 31 0049 GetCallCount 000079CC 33 004A GetCallHeader 00007438 32 004B GetCallPos 000083C4 39 004C GetCodePosRanges 00008154 38 004D GetCodeRanges 0000A60C 48 004E GetFileCount 0000A8AC 51 004F GetFileIndex 0000A61C 49 0050 GetFileName 0000A27C 47 0051 GetNearestSymName 00008968 46 0052 GetPropertyInfo 000080AC 37 0053 GetSrcLines 000084E4 42 0054 InitEvaluate 00008474 40 0055 InitProcess 0000250C 17 0056 KibitzCompiler 000A19B0 112 0057 KibitzGetOverloads 0008C068 109 0058 KibitzGetValidSymbols 00090F5C 111 0059 LoadCompState 000088BC 45 005A LookupProc 0000CDF8 59 005B MakeSureUnitIsLinked 00006CFC 29 005C Modify 0000B588 54 005D NewCompState 000908F0 110 005E SaveCompState 0000B604 56 005F SetCompState 0000B5E4 55 0060 SetCompStateFast 0000A64C 50 0061 SetFileName 0007A974 106 0062 SetUnitFreeHook 00002974 23 0063 UIDiscardUnit 00002924 22 0064 UIGetExplicitUnitImports 000029A0 24 0065 UIGetPackagesUsed 00002878 21 0066 UILoadUnit 00002A08 25 0067 UISetDebugDir 001150FC 105 0068 ___CPPdebugHook 各位看到上面許多的輸出函式都和編譯工作有關的嗎? 從上面的結果我們可以使用下列簡化的圖形來呈現:  等到新的後端編譯器出來之後，BCB和Delphi的編譯架構會形成如下的狀態:  OK，那麼混合編譯和跨平台編譯是什麼? 動腦想想如果我們再把機械碼產生器抽離出來形成如下的架構:  你看到了什麼? 現在回到BCB和Delphi本身，現在BCB/Delphi中的dbExpress是跨平台的架構，RTL在擁有了跨平台編譯之後也就可以跨平台了， If begin Delphi程式語言 + VCL + RTL + dbExpress ~= Delphi 而且 C/C++程式語言 + VCL + RTL + dbExpress ~= BCB 的話， end then begin Delphi程式語言 + RTL + dbExpress + 跨平台編譯 = ? C/C++程式語言 + RTL + dbExpress +跨平台編譯 = ? end 剩下的問題就是VCL了，VCL在原生Win32/Win64不是問題，但在Linux或是其他平台怎麼辦? 還記得CLX嗎? 本來Borland說要開放CLX，但現在CodeGear又似乎踩剎車了，為什麼? 我也不知道, 但我想如果我們把CLX帶入上面的公式: Delphi程式語言 + 新的CLX + RTL + dbExpress + 跨平台編譯 = ? C/C++程式語言 + 新的CLX + RTL + dbExpress +跨平台編譯 = ? 真是令人好奇啊，希望我猜的都能成真，那麼C++Builder和Delphi將進化成最佳的”跨平台原生開發工具”, 也別忘記現在由Delphi Prism建立的應用程式已經可以執行在Window, Linux和Mac等 3個平台之上了。 我知道現在BCB 2009/Delphi 2009的Patch 3和Patch 4都在開發之中，從目前的測試版來看CodeGear修正了許多多年的臭蟲，整個速度和穩定性更勝RAD Studio 2009，所以我猜想2009年CodeGear會再推出一個BCB/Delphi 2010的32位元版本，這個版本將會是最穩定，最快速的32位元版本，而且應該會支援Vista和Window 7等和其他許多最新的PC技術，CodeGear在離開Borland之後決心再把C++Builder/Delphi打造成最好的Win32/Win64開發工具看來是非常認真的。 好了，大過年的寫到這裡文章也夠長的了，我也該去打打Wii和Wii Fit了，下次再讓我們繼續的動動腦吧(後註, 這篇文章我在大年初四就寫完了, 只是忘了Post出來, 看來記性愈來愈差了)。 最後祝各位 新年快樂，2009年心想事成。 February 02 興德開始提供CodeGear技術文章如果您還不知道的話，興德資訊開始在興德的網站上提供我寫的一些技術文章的和書提供有需要的朋友下載使用，這個小小的園地希望能夠提供一些中文的CodeGear技術資料給有需要的朋友。
我們希望一開始至少在這個小小的技術網提供技術文章，我以前舊的書籍和技術研討會相關的slides和範例程式，我們更我們希望日後擁有更多的資源可以提供更多的東西，而且能夠繼續的維護下去，當然我們更需要您的支持，謝謝! 這個技術網目前的URL是 :
和Delphi相關的資訊
C++Builder相關技術
和JBuilder相關的資訊
結合ECO和VCL For Web開發的相關資訊
好玩又好用的RoR/XXXX相關資訊
|
||||||||||||||||||||||||||||||||
|
|
