问题篇
写这篇文章的初衷源自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新版本。
