C++ BuilderX的问题与展望
猛禽[Mental Studio]
(之一，问题篇-上)
写这篇文章的初衷源自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缓冲后要高得多了。
(待续)
