問題篇
寫這篇文章的初衷源自2003年12月11日在玉笛書生兄所建C++Builder的QQ群中，與書生、令狐蟲、ccrun等幾位BCB版的老朋友的一次聊天（聊天記錄見《一次關于C++BuilderX的討論》）。主要就是聊了一下BCB/BCBX的現狀以未來可能的發展方向，因為覺得對各位用BCB的朋友也許有幫助，故在令狐兄的支持下，整理成文。本文的內容如題目所言，先說說BCBX現在的問題（包括Borland在此次產品轉型中的一些不太合適的做法），然后就我們幾個的個人觀點來談談對它的展望雖然說是BCBX的展望，當然這些都是我們的一些一孔之見，Borland未來會怎么做，那是由不得我們的。
兩年多以前我曾經設想Borland會推出一個高度集成的開發工具，我當時稱之為Borland Studio（參見拙作《Borland Studio?》），后來又聽李維說，Borland正在研發的代號為Galileo的開發工具將是一個比我設想的Borland Studio更為強大的東東。然而很不幸，所謂計劃沒有變化快。時至今日，這些東東終成泡影，不知道什么時候Borland才能給我們這樣的驚喜。（補充：現在看來似乎又有一點希望，C#Builder是BDS1，Delphi8是BDS2，這個BDS據說便是Borland Develop Studio，也許BDS3會給我們一個驚喜吧）
就現在的情況來看，Microsoft已經是鐵了心要把Windows操作系統向.net上轉移，未來的Windows操作系統將不再提供新的Win32API，而會以.net的方式提供。原來的Win32API也只是為了兼容性而保留。這很像當年從MS SQL 6.5向MS SQL 7.0遷移的情況，在MS SQL 7.0中的DBLIB只提供與6.5兼容的部分，新增功能都是以OLE-DB方式提供，而到了MS SQL 2000時，DBLIB幾乎已經不能用了。MS SQL的這次轉移成功地實現了一次飛躍，并完全擺脫了Sybase的陰影，所以Microsoft在.net中應該還是會故伎重演的。
在這種情況下， Windows平臺下的原生開發工具日漸式微，這對于Borland來說，無疑是要作出重大的抉擇。所以Borland在今年(2003年)先后推出了四個主要產品：C#Builder（Sidewinder），C++BuilderX（Tomahawk），JBuilderX（Reveille）以及剛剛在BorCon2003上發布的Delphi8（Octane）。從表面上看，除了C#Builder是全新推出的與Microsoft的Visual Studio.net 2003競爭的產品以外，其它的似乎都是原有產品的延續，特別是Delphi 8延用了Delphi的產品名稱，而繼JBuilder9之后推出的JBuilderX的那個X也很容易被理解為羅馬數字的“10”，那么C++BuilderX是否會是C++Builder 7呢？為什么不叫C++Builder 7或C++BuilderVII而要叫C++BuilderX？會不會是傳說中的Borland Studio甚至是Galileo的原型呢？
所謂希望越大，失望也越大。當C++BuilderX還在測試版階段時，許多C++Builder用戶都迫不及待地下載了Tomahawk來先睹為快，我也一樣，但結果卻令人大失所望。這在BCB用戶群中造成了極大的反響，其中比較有名的就有如CSDN BCB版的Aweay兄的文章《Borland聽我對你說》等。
雖然Borland中國的左輕侯很快就撰文為BCBX作了一番辯解，但還是難以令人接受。BTW：按左兄的說法，Galileo已經成了Borland在.net平臺下的開發工具（C#Builder和Delphi8）所用的統一的IDE的名稱，看來是不用對Borland Studio抱什么希望了。
不可否認Borland在C++開發工具中的這次轉型從未來發展的角度上說是必要的，也是正確的做法，具體請參見左兄的文章（《關于Borland C++BuilderX的一些問題的回答》或《程序員》2003年第十二期）。但還是要指出Borland在此次轉型中的錯誤做法及可以改進的方面。我們幾個雖然不能說代表Borland的用戶，但至少也算是Borland的鐵桿用戶，我們的意見應該來說還是比較有代表性的，可以毫不夸張地說：如果Borland不能在未來作相應的改進，恐怕是難有機會在C++領域里再翻身了。
首先說說BCBX推出的方式是非常不合適的。最主要的就是沒有提供一個從BCB到BCBX的平滑過渡。Borland一向標榜自己的特色是：為客戶帶來新技術，創造新價值，同時保護客戶已有投資。過去她也一向是這么做的，然而這一次卻沒有做到。這是一個非常嚴重的錯誤。
從歷史上說（參見李維的《Borland傳奇》一書），這種錯誤Borland曾經犯過多次，每一次都是造成用戶的大量流失。以C++開發工具為例，第一次發生在BC4的OWL2與BC31的OWL1不兼容，加之BC4本身品質不佳，造成Borland用戶的第一次大規模流失，這次事件最終使Borland從一流的軟件公司墮落成為二流的軟件公司。雖然后來推出了相當不錯的BC451，然而已經為時太晚，回天乏力。直到BCB的出現，作為第一個RAD C++工具搶回了一部分用戶，然而由于種種原因（其中一個當然是因為BCB使用的VCL讓它始終籠罩在DELPHI的陰影之下），已經無法重現當年BC31的輝煌了。
讓人無法想象的是Borland在花了這么大的代價買來的教訓，卻還不知吸取，才過了不到十年，再次犯同樣的錯誤。當我第一次看到BCBX時的感覺就像若干年前第一次看到BC4或BCB1一樣：起初是新鮮，大喜，接著就是失望（完全是中看不中用），然后開始盼望下個版本能解決（當然這兩次都盼到了，一個是BC451—可惜來得太晚了，另一個是BCB3—這個比較好玩的就是，當時我們都在盼望的是BCB2，結果卻盼到了BCB3，大概是Borland為了和Delphi的版本號一致，跳過了BCB2）。
其實Borland要避免這種窘境并不困難。有兩個方法：一個是在BCBX中暫時嵌入一個BCB的IDE的簡化版，讓它能繼續支持VCL的RAD開發，因為對C++開發工具來說，即使在開始時犧牲少量的跨平臺特性（BCB是不能跨平臺的），問題并不大，因為這部分特性本來就是為了繼承Windows平臺下的東西，更何況像Jbuilder這樣對跨平臺要求很高的產品，在早期版本里一樣不是純JAVA的；另一個方法就是像DELPHI那樣，提供一個BCB7作為過渡。因為從某種角度上說，Delphi7對Delphi6的改進，實在是非常之少，所以有人戲稱Delphi7其實是Delphi6.5。就現在的情況來看，Delphi的轉型無疑要比BCB成功得多，Delphi8提供了.net開發和兼容VCL開發（通過VCL.net）。而從BCB的情況來看，唯一的解釋就是Borland對BCB不夠重視。其實在這兩個方法中，個人認為后面一個方法更好一些。因為雖然現在.net大行其道，但可以肯定是的Windows下的原生開發還要持續幾年，在這段時間里讓BCB7和BCBX并行（因為在大多數情況下，二者的沖突不是很大）對Borland占領C++開發工具領域非常有利，而且有一個BCB7這樣一個填補這個空白的產品（因為那時大多數開發工具都到.net下了）還能帶來一定的收益。
雖然說Borland作為一個不能算太大的公司，沒有足夠的資源維持一條過長的產品線，如果要在BCBX中加入BCB或同時開發BCBX和BCB7，會有困難。但作為一個全新領域的產品（在平臺中立的C++開發工具中，暫時還沒有像BCBX這樣的產品，即使是傳說中的Eclipse+CDT，也暫時不能成什么氣候），略為延后一些發表并不會造成太大的影響，反而是推出不夠成熟的產品會造成嚴重的反面后果，在這點是Borland也是吃過大苦頭的，最典型的莫過于Delphi4。而且如果有BCB7作為緩沖的話，BCBX的延后發表，對市場來說也不會有太大的影響。
但是現在Borland已經這么做了，要想挽回的話，只有在產品上作文章了，這樣反而把Borland自己逼上了一條無法回頭的路了—必須盡快推出一個“可用”的BCBX。而這個“可用”的要求就要比通過BCB7緩沖后要高得多了。
然后來具體說一下BCBX這個產品。
它不能說沒有優點，先從IDE說起吧。BCBX采用了一個全新的IDE—PrimeTime，這個IDE來自于JBuilder，而且后來的JBuilderX也是采用這個IDE（只是在JBuilderX中用的新版本PrimeTime具有更多的優點，如代碼折疊等）。這個JAVA寫的IDE可以跨平臺，看上去也很美，使用上雖然與BCB/DELPHI不太一樣，但至少還是保持了Borland的一貫風格，特別是對JBuilder用戶來說會很自然。
這個IDE除了具有BCB原有的一些特性，如Code Template等功能以外，特別值得一提的是，它還具有原來在BCB上沒有的版本控制功能（見Editor的History頁面），這個功能我前兩年就在JBuilder上看到了，眼饞的不行，現在終于也可以在C++中享受到了。此外它還可以像JBuilder一樣集成多種源碼版本控制工具（CVS，ClearCase，VSS）。
對于編輯器，BCBX還有一個很好用的功能就是Sync Edit，通過選擇一段文本，可以方便地修改其中相同的標識符等，在進行代碼重構時非常有用。
還有就是提供了一個類似Class Explorer的Structure View功能，可以在這里立即跳轉到各個類/函數的定義或實現處。另外它的Editor支持嵌入源碼的ToDo Item功能，并且能在Structure View中立即顯示出來，而且也可以從Structure View中跳轉，比BCB中的ToDo List功能要強大。
另外，對Project的管理功能也略有加強，可以定義和調整Project Group中的編譯順序（相當于一種Project依賴關系）。這一點也是BCB曾經被人垢病的一個方面。
BCBX還有一個特性是與BCB一樣的：支持基于VisiBroker的CORBA應用開發。特別是它比BCB有一個很大的改進，在BCB中用CORBA向導默認生成的CORBA應用是使用BOA的，而這是早在五年前就被CORBA2.2規范制定的POA所代替了（當然BOA也可以用，但基于移植性考慮，OMG建議使用POA），在BCBX中終于用POA代替了（而且好像不能再用BOA了）。
至于很多人認為BCBX這個用JAVA寫的IDE速度太慢，我倒不覺得，只是啟動速度略有些慢，不過BCB的啟動也不能算很快，比起VS.net來說慢太多了。也許是因為我的機器內存比較大的緣故，雖然是PIII-733的CPU，但有512M內存。看來要跑BCBX要先準備好內存了。
BCBX除了這些IDE方面的好處外，還有一個好處就是帶有dbExpress這個跨平臺的通用數據庫訪問技術，所以用BCBX做跨平臺數據庫應用會比較方便，并且目前dbExpress支持的數據庫種類還是比較多的。
雖然BCBX有上述的優點，但也不能改變它是一件“粗糙”的產品的本質，簡直就和當年的BCB1如出一轍。
首先最大的敗筆莫過于不支持VCL了。據說不支持VCL還有理由了：因為它的目標用戶不是BCB用戶，而是更為廣大的非VCL的C++用戶，如其它平臺的C++用戶及VC的用戶等，VCL是BCBX2的目標。而且不支持VCL就算，也沒有提供一個別的GUI開發的Framework，比如傳說中的wxWindows（據說要在BCBX2里提供）。
其次來說這個IDE，作為IDE技術的發明者，Borland應該很了解開發人員要的是一個什么樣的IDE，它應該能夠在其中很方便地完成大部分的開發工作，但BCBX明顯達不到要求。雖然它帶有很多BCB不支持的功能，但同樣的，有很BCB中具備的功能，在BCBX中還沒有提供。特別是非常重要的Code Insight功能居然都沒有，而且它的Structure View，雖然在某些方面比Class Explorer強大（如ToDo），但它的功能還是太弱，比如不能在Structure View里創建類成員等。還有BCBX的Editor中不支持跳轉到定義的功能，不支持Open file at cursor等。而且個人認為BCB6中將只將單元放在Editor上面的Tab中，而將CPP文件和H文件放在下面的Tab中是一個好辦法，但BCBX卻還是像BCB5一樣都放在上面，這樣文件一多就要卷來卷去。
還有一個足以說明它“粗糙”的理由是：BUG。我曾經試過在一個很簡單的應用里只是更換了一下編譯器，正要保存設置時，IDE無響應，CPU占用100%。
其實Borland提出BCBX這個策略是沒有錯的，只是策略的實施上有些問題。
BCBX的產品定位是定位于非VCL的C++用戶。在這點上，就會讓Borland目前的C++產品用戶，基于VCL的BCB用戶非常不滿，特別是沒有提供像BCB7這樣的過渡產品，可能導致用戶流失。其次，對于非VCL的C++用戶來說，也未必吸引人。這部分C++用戶主要有兩派：一派是用VC的用戶，一派是用GNU C++的用戶。對VC用戶來說，跨平臺特性對他們完全沒有吸引力，而在Windows平臺下，VS.net還是非常好用的，并且他們可以很方便地進行.net應用開發，BCBX提供的多編譯器支持對他們來說也是沒用的功能，所以在這里BCBX基本上沒有什么市場。
估計BCBX更主要的目標市場在GNU C++。用GNU C++的用戶中，很大一部分是開源社團，而對他們來說，根本不屑于使用像BCBX這樣的東東，特別是自從Danny.Thorpe當年因為開發Kylix，與Linux社團有一次大的沖突，Borland在開源社團的影響并不好。而且就BCBX本身來說，它雖然說支持ACE、Boost、Loki這些庫，但是事實上這些庫本來就是通用庫，支持很多的編譯器，其中也包括BCB，所以這根本不能算什么特性。而且雖然BCBX對Project管理功能有所增強，但比VS.net還有差距，更別提跟開源社團習慣使用的Make文件相比了（雖然Make文件用起來比較復雜，但對于大項目來說，它是最好的解決方案，即使是項目管理功能好如VS.net，跟Make文件相比還是差得太多了）。
縱觀整個BCBX，其中提供的有價值的東西非常有限：一個是還不能算是很完善的IDE，另一個可能就算是dbExpress了。至于像CORBA向導之類的并不算很特別，用命令行編譯IDL一樣可以實現它的功能，雖然沒有向導那么方便，但更加自由，不用受制于VisiBroker，可以選擇各種ORB產品。版本控制也可以用CVS等專門的軟件，只是要多一些手工操作，沒有集成起來這么方便而已。其它像編譯器一類的更沒什么好說的，BCBX還是用的BCB6的編譯器：BCC5.6。BCBX集成了Together（據說，我用的Enterprise版是沒有的）卻沒有提供相應的企業應用開發的Framework,，如C#Builder/DELPHI8中的ECO，或是像BCB/DELPHI那樣的MIDAS/DataSnap。
當年Kylix 1.0甫一堆出，就有人評論它是一個“玩具”，直到Kylix 3才基本有了一個產品的樣子（可惜看樣子它注定是要夭折的了）。然而今天的BCBX卻連當年的Kylix 1都不如。
按Borland在中國一向的產品定價，一般開發工具的企業版都是定在29950元人民幣的天價（相對于MS來說完全可以說是天價，因為三萬多元定一年的MSDN宇宙版，可以得到MS的所有產品），BCBX應該也不會例外，說句不客氣的話，這樣乏善可陳的產品定這樣一個價格真是與搶錢無異。
展望篇
說了BCBX這么多的問題，該來談談我們的展望了。
首先從產品定位說起。大家都知道，每種語言都有其適用的領域，沒有什么語言能通吃所有的開發工作，C++也一樣，雖然從某種程度上說，C++可算是目前開發領域最廣的語言，幾乎可以用于絕大多數的應用或系統的開發，但在不少情況下，它僅僅是“可以”而已。比如在企業應用開發領域，C++并不是一個很好的選擇（雖然借助于VCL，BCB基本上做到了），但通常選擇Java或.net可以更快更好地解決問題。
就目前情況來說，C++最常用的開發領域有兩個大的方面，一個是系統級應用開發，如操作系統，驅動程序（這兩種應用更主要的是用C和匯編，但也有部分可以用C++），編譯器，虛擬機，工業數據采集，通信，系統服務等；另一個是一般應用開發，主要是指非企業應用或者說是非數據庫應用方面，如一般GUI應用程序，工具軟件，圖像處理，多媒體等（雖然這些應用有些也可以用.net等虛擬機技術開發，但是在一些關鍵性部分基于性能上的要求，還是需要C++等原生開發語言的）。
基于這些原因，作為定位于通用C++開發工具的BCBX要想在C++開發工具領域占有一席之地（暫且先不說它是不是有希望重振當年BC31的聲威），就應該結合C++語言的實際情況，這兩方面的應用開發上有獨到之處。。
首先說系統級應用開發。對于系統級應用開發來說，GUI通常不是很重要的方面，它對開發工具的要求更側重于性能和調試等方面。即要求編譯器能生成高度優化的代碼，并且目標程序要很穩定，要提供方便的底層調試功能。而且一般這樣的軟件都相對比較龐大，對項目管理的要求比較高。
對應這些要求，未來的BCBX應該加強在編譯器，調試器及項目管理方面的功能。比如在編譯器方面，現在BCBX用的BCC5.6是肯定不能滿足要求的，雖然BCBX支持使用其它的編譯器，但作為一個完整的開發工具而不僅僅是一個IDE，BCBX中不能沒有Borland自己的編譯器。不過據說Borland正在開發一個全新的跨平臺C++編譯器—BCCX，讓人拭目以待；在調試器方面，這曾經是Borland的強項之一，現在已經沒落了，不過也可以考慮跟別的公司合作或通過集成第三方產品來實現；至于項目管理一直是Borland的弱項之一，而且對這樣的復雜項目來說，即使實現了像VS.net那樣的管理還是不夠的，這個可以考慮提供一個MakeFile管理工具來實現，畢竟這方面的應用還是MakeFile最好，但它的編寫維護都是比較麻煩的，如果能提供一個能生成MakeFile的向導及一個能方便地管理MakeFile的工具，也是相當不錯的。
再來看一般應用開發。對于這方面的應用開發來說，一個好的GUI開發工具是非常重要的，此外對編譯器，調試器，項目管理同樣也有一定的要求。因為這類應用的最終用戶通常都是一般電腦用戶，不同于系統應用面對的都是專業用戶，所以對界面要求通常都很高，不但要通做出標準的GUI界面，常常還需要能實現一些花哨的界面功能。這就對GUI Framework提出了較高的要求：它不但要好用，簡單，還要能很方便地擴充。VCL就是一個很好地實現了這個要求的GUI Framework，但是很遺憾的是，它不是跨平臺的，雖然后來Borland又推出了跨平臺的CLX，但是它用基于QT庫的，而QT庫的License對商業應用不是免費的，這又限制了CLX的應用，特別是現在Borland已經暫停（也許是停止）了Kylix這條產品線，對CLX來說無異于雪上加霜。
既然VCL和CLX兩條路都走不通，BCBX未來唯一的出路就是采用一個新的GUI Framework，目前看來Borland是會選擇wxWindows。但這帶來了一個問題：因為BCB的產品線已經停掉了，BCBX未來必須接下BCB的用戶，而如何從VCL向wxWindows過渡是未來BCBX面臨的一大問題。不過有消息說Borland已經提供了解決方案，在新的BCBX中將采用一個開放的GUI Desgner，支持多種GUI Framework，已知的就有wxWindows和JavaBean，而對于非跨平臺的VCL，在新的BCBX中將通過一個被稱為“VCL Bridge”的東西實現。這樣看來，在未來的BCBX中將能比較完美地實現這一功能。
再來看企業應用開發。雖然就目前的情況看，基于虛擬機平臺的開發技術（JAVA或.net）已經成為企業應用開發的主流，而C++不是一種適用于虛擬機的語言（雖然MS將所謂的Managed C++加入.net，但情況不并好，不過C++適用于開發虛擬機倒是真的），無論在開發效率和產品品質方面，用C++做這方面的應用都是不合算的，即使是在產品性能方面，C++所能取得的優勢也日趨減少。
但是這個市場仍然存在。首先，在一些情況下，企業應用系統還是需要和一些底層應用（如硬件驅動或其它原生代碼程序等）進行交互，這時用基于虛擬機的技術并不方便（.net相對做得較好）；另一方面，則是在一些對性能有較苛刻要求的應用中，用基于虛擬機的技術可能不能滿足要求。這也就是為什么像BEA的TUXEDO這樣的原生代碼應用中間件仍然有相當大的市場的原因所在。
在較好的實現了滿足前面兩種應用的開發要求后，BCBX也完全可以進軍這一領域。對于BCBX這樣一個跨平臺開發工具來說，所用的中間件技術當然也必須是跨平臺的，MIDAS/DataSnap所支持的COM技術是肯定不行的，而只能用JAVA開發的EJB當然也不行，唯一剩下的就是CORBA。雖然現在BCBX提供了VisiBroker的CORBA應用向導，但相對于MIDAS/DataSnap來說，功能還是太弱。即使加上Together，BCBX距離一個像樣的企業應用開發工具還是比較遠的。還有一個問題是：雖然Borland的VisiBroker（現在已經改名叫Borland Enterprise Server—BES之VisiBroker版了）曾經是全球市場占有率排名第一的CORBA產品，即使現在它也是數一數二的，然而畢竟還有很多其它的CORBA產品可以選擇，比如現在占有率第一的IONA的Orbix以及Open Source的ACE/TAO和MICO等（只考慮支持C++的）。如果BCBX不能以一種開放的姿態來接受它們，依然很難在CORBA領域取得大的成就。
在這一點上，Borland應該是有經驗的，當年JBuilder正是因為能與BEA的WebLogic很好地結合起來，才得以取得如今的勝利。逼得IBM不得不放棄Visual Age for JAVA（就是后來成為Open Source的Eclipse），雖然在一些方面，VAJ還是比JBuilder有優勢的，并且IBM的WebSphere在各方面的表現也不比WebLogic差，然而Borland和BEA的強強聯手實在太強大了。如果當年JBuilder只抱著IAS（Inprise Application Server即現在BES的前身）不放的話，實在很難能在JAVA開發工具領域有什么大的作為，因為在WebLogic和WebSphere面前，IAS還差得太遠了。所以現在JBuilder支持的EJB Container是越來越多了，除了前面說的這些商用產品外，Open Source的JBoss也同樣在支持之列。
BCBX完全可以借鑒JBuilder的這一經驗，支持集成包括IONA Orbix，ACE/TAO等多種CORBA產品開發，相對來說，這一點比集成不同的GUI Framework要容易很多，因為CORBA規范是由OMG定義的標準，不同產品之間的差異相對較小。所以問題的關鍵就在于Borland是否愿意這么做了，畢竟這可能影響到BES這條產品線的市場。老實說，Borland在企業中間件市場中一直是很失敗的，從早年通過收購OEC取得Entera，卻很快因為COM和CORBA的崛起而被迫放棄；通過收購VisiGenic取得了VisiBroker后，雖然在跟Netscape的合作中曾取得一定的成功，但隨著NetScape的沒落，VisiBroker的領先地位也很快被IONA的Orbix所取代；后來從IAS開始做JAVA中間件，也一直是只能在沒有WebLogic和WebSphere的市場角落里分一點殘羹而已。與其讓BCBX的企業開發與BES一起沒落，還不如像JBuiler一樣犧牲BES換來BCBX的成功，畢竟對Borland來說，開發工具才是真正的主營業務。
當然，光有對CORBA的支持還是不夠的，畢竟企業應用開發是一個大問題，需要的支持還是很多的。雖然現在BCBX有DBX這個方便的數據庫訪問技術，但是還缺乏一個系統的Framework，一個類似于MIDAS/DataSnap的東西。另外要結合Together的MDA開發，還必須有一個類似于ECO的數據持久化技術。
還有對SOAP/WebService的支持是不能少的。雖然它并不是一個像MS所吹噓的那樣，是一個萬能的技術，但還是有很多地方需要它的。特別是當需要與其它應用溝通時，雖然與JAVA應用溝通可以通過RMI over IIOP，但要與.net應用或其它的應用溝通，SOAP還是一個比較好的解決方案。
有了這樣一個強大的企業開發環境，就像我前一段向朋友“太可怕”（CSDNID：comanche）推薦ACE/TAO時說的：“這個世界沒有MS，沒有SUN，一樣可以很美好。”
正如我前面所說，現在的BCBX是乏善可陳的，然而如果未來的BCBX真的可以加入我前面所說的這些Feature，包括一個完善的IDE，一個優秀的編譯器，一個方便高效的GUI開發環境，以及一個功能強大的企業開發Framework等，那么BCBX才真正像一個Powerful的C++開發工具（讓我想起Borland當年拍的BC31廣告片^_^），重拾BC31當年的風光也不是不可能的。
本來寫到這里就差不多完了，不過Borland大概是為了安撫用戶對BCBX的不滿情緒，最近推出了一個BCBX Preview包（在Borland網站有提供下載），通過將這個包安裝到BCBX中，可以大致了解一下未來版本的BCBX會是什么樣子。我簡單地試用了一下，所以在最后要補充一些對這個Preview的看法。
這個Preview包括兩個部分：一個是集成了wxWindow的GUI開發環境，另一個是全新的C++編譯器BCCX的預覽版。下面分別作一個說明：
首先來看這個GUI Designer。在IDE的New wizard里增加了兩頁，其中一頁就是wx framework（另一頁是preview），里面有兩項：New wx framework project和New wx framework form。用前者創建一個新的wx應用，可以看到它生成的代碼中包括一個XRC文件，這是一個XML風格的界面資源文件，類似于DFM/XFM。在頁面下部有一個Design的Tab，點擊即可打開GUI Designer。
這個GUI Designer和以前的BCB的GUI Designer還是很相似的，包括控件欄，設計區和Object Inspector三個部分。其中控件欄也是在頁面上方，只是控件少得多了，只有三頁共18個控件。設計區和BCB不同，不再是獨立的Form Design，而是像Visual Studio/Galileo那樣嵌在頁面里，而且控件的定位也不是用以前的八點框，而是一個藍色的粗框，也沒有Grid定位。Object Inspector也有不同，首先是位置改在頁面右邊，跟JBuilder一貫的風格相同，當然內容就更不同了，畢竟現在的Framework是wxWindow而不是VCL了。
再來看BCCX編譯器。同樣是在IDE的New wizard里有一頁Preivew，其中包括三個項目，其實這里生成的代碼與Project頁中的相應項目并無太大不同，只是所用的Include目錄（Preview帶有一套新的Include文件和啟動代碼）和編譯器設置略有不同而已。另外，在IDE的編譯選項中也增加了一項：“Borland® C++ Compiler Preview for Windows (IA-32) Tools”。看BCCX命令行提示可以看到，它的版本信息為：Borland C++ Compiler 6.0 Preview。可見這是Borland的一個全新版本的C++編譯器，同樣還有與之配套的Incremental Link，也是6.0版的。
不知道是不是因為新的編譯器配置有所不同，我只在IDE中編譯通過很簡單的程序，還未能成功編譯過wxWindow應用，看來還需要再研究研究。
當然這個畢竟只是Preview，問題還是有的。除了上面說的編譯器的問題外，GUI Designer也是有問題的，最大的問題就是速度慢。在我的512M的機器上，BCBX跑起來也只占到300多M的內存，還未將物理內存用盡，但做GUI Design時的速度卻比用JBuilder做GUI還要慢上許多，這實在讓人難以忍受。其次一個問題是它不支持中文，在控件的屬性中輸入中文會變成亂碼，估計跟XRC文件使用UTF-8編碼時對中文（應該其它DBCS也有同樣的問題）沒有能夠正確處理有關。
這篇文章斷斷續續寫了一個多月，終于可以告一個段落了。最后還是要給Borland提點意見：Borland在2003年里出的幾個產品，完成度都不算高，其中除了JBuilderX我不是太了解以外，C#Builder、C++BuilderX和Delphi8我都試用過，基本上都未達到可用的程度。希望今年Borland能夠吸取教訓，推出一個令人比較滿意的BCBX新版本。
