維's profileIT : 是工作還是嗜好?PhotosBlogListsMore Tools Help

維 李

There are no music lists on this space.
謝謝您的瀏覽!
Please wait...
Sorry, the comment you entered is too long. Please shorten it.
You didn't enter anything. Please try again.
Sorry, we can't add your comment right now. Please try again later.
To add a comment, you need permission from your parent. Ask for permission
Your parent has turned off comments.
Sorry, we can't delete your comment right now. Please try again later.
You've exceeded the maximum number of comments that can be left in one day. Please try again in 24 hours.
Your account has had the ability to leave comments disabled because our systems indicate that you may be spamming other users. If you believe that your account has been disabled in error please contact Windows Live support.
Complete the security check below to finish leaving your comment.
The characters you type in the security check must match the characters in the picture or audio.
明 李wrote:
李老師,能否談談您對Delphi未來的看法?,目前看到玩Delphi的人比較少了,網絡上的技朮討論也少了,好像都沒太多人去研究技朮了
4 days ago
維 李wrote:
>李老师能否出TOGATHER的书,我真的感觉太困难了。

這是不可能的, 別說沒時間寫了, 我想沒有出版商會冒險出這本書的, 這個書籍市場太小了.
4 days ago
維 李wrote:
>这些技术已经基本上能够完成一个应用服务器框架的要求了。希望有兴趣的朋友们可以试试。

David說的都是Delphi 2010會做出來的功能, 你希望我說什麼呢? 在David說的東西中唯一比較困難的就是

>组件的动态加载和维护,可以将组件编译成为bpl,然后动态加载,并将类注册到一个特定的列表中。然后动态创建一个DSServerClass,并在onGetClass里面将新加载进来的ServerModeler名字发出去

因為要動態的加载和维护, 目的的Server需要先暫停再啟動, 這在實務上有困難, 因為Server可能無法暫停再啟動, 因此開發人員在這方面需要考量一下, 或是使用其他的設計方法來克服.
4 days ago
WESTSKY LIwrote:
李老师能否出TOGATHER的书,我真的感觉太困难了。
June 25
WESTSKY LIwrote:
Delphi2007的TOGATHER生成的语法代码真的让人费解。
能否有这样的数据。
June 25

IT : 是工作還是嗜好?

June 29

Borland最後花落誰家似乎仍有變數!

今年56日根據外電報導英國軟體廠商Micro Focus將收購Borland,雖然我早已離開Borland數年之久,也對後期的Borland實無好感,但從學生時期便建立的感情仍然讓我無法忽略Borland在業界的消息,在57日我得知Borland即將被收購的消息時,心中並無太大的心情波動,因為在離開Borland時我早已預測Borland將會瓦解,因為那時BorlandCEO每天只想著股票的價格,把產品搞得亂七八糟,又要求每個人都做銷售,連技術人員都被送去做銷售的培訓,取消了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
Main Themes
User Experience
Enhance Connectivity
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有如下的特性:
  • 它支援最新的MS SQL Server 2008,因此理論上應該支援SQL 2008新的資料型態和功能
  • 由於它使用MS SQL Server 2008原生用戶端安裝程式來連結MS SQL Server 2008,因此它可向後支援MS SQL Server 2005
  • 使用sqlncli10.dll而不再使用oledb,因此下一版的DBX速度會比以前更快

嗯, 推論了上述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的未來似乎已經漸入佳境,為什麼? 因為:

  • 第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輸出的函式,我們可以得到如下的結果:

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是 :

http://www.sinter.com.tw/codegear/codegear_technique.html

 
和Delphi相關的資訊
C++Builder相關技術
和JBuilder相關的資訊
No list items have been added yet.
結合ECO和VCL For Web開發的相關資訊
No list items have been added yet.
好玩又好用的RoR/XXXX相關資訊
No list items have been added yet.
Photo 1 of 8
More albums (1)