C/C++圣战篇
偶尔看到这篇文章，引起了很多回忆。记得自己第一个在WINDOWS平台下编制的软件就是BORLAND C++做的，当时确实感觉，世界上没有比它更好的开发工具了。以后又陆续用过几款BORLAND的产品，感觉都很好。然而事过时迁，现在却只能用MS的开发工具。看了这篇文章，或许可以知道点什么！
=== 附录一 ===
李维，中国台湾人，上世纪九十年代于美国取得电脑硕士学位，Borland大中华区CTO。
我之所以知道他，是因为大学时代看到他登在CSDN上的一篇有关C++的文章，
现在来看，该文在程序员中的影响力相当之大。继而后来又出了一本Borland传奇
的书，在国内颇是培养了一批Borland情节的程序员们。尽管Borland在走下坡路，仍然为之叫喊不止。
我想，也许是中国软件业的持续颓废下，以及长期以来对奇技淫巧的蔑视与打压下，
程序员的痛快一次发泄。
不可否认，李维是个很会讲故事的人。
必须指出，Borland以外的世界更加宽广。
=== 附录二：李维代表作品 ===
我的回忆和有趣的故事 --- C/C++圣战篇
李维
(声明以下的这篇文章内容是我个人的回忆以及看法，没有任何特别的偏见，许多的事情是
根据我的记忆以及从许多人的诉说中得知的，也许内容不是百分之百的正确，不过我想这些
内容有一定的可信度到是可以保证的。)。
一直想写一篇我个人在过去10多年来工作中经历的一些事情，以及看着一些我认为是伟大
的工程师在这些日子中对于资讯界的贡献。
和Borland 的缘由
记得我在大学时第一个在PC上使用的软体便是SideKick，至今我仍然无法忘记这个让我津
津乐道的软体，而Borland在当时也就是以SideKick成为全球知名的软体公司。不过
Borland 第一个奠立创业基业的软体却是我大二使用来交作业的Turbo Pascal. 而Turbo
Pascal也是第一个我听到关于Borland 的有趣的故事。
当年Philippe Kahn （Borland 的创使人）和Anders Hejlsberg到美国创业时，便由
Anders以组合语言撰写了Turbo Pascal的编译器，而Philippe则包办了Turbo Pascal
其他的部份。在这两位人兄开发完TurboPascal之后，穷得快连登广告的钱都没有了。但
是Philippe为了在Byte杂志（还记得这个着名的杂志吗？）刊登Turbo Pascal的广告，
因此和Anders商量了一个方法，那就是一天他们约了Byte杂志的人到当时Borland 的办
公室讨论刊登广告的事情。
当Byte的人到了Borland 之后，Philippe，Anders和公司的助理小姐故意忙着接电话，接
受Turbo Pascal的订单，并且告诉Byte杂志的人等一下。过了一阵子之后Philippe才进
入房间向Byte的人道歉，说他们的Turbo Pascal受到市场的热烈欢迎，订单源源不断的到
来，因此可能不需要在Byte杂志刊登广告了，接着Philippe向Byte的人展示Turbo Pascal
这个产品。由于在当时的机器中Turbo Pascal能够在少少的RAM 中常驻执行，又提供闪电
般的编译速度，立刻让Byte杂志的人震惊在当场，凭着专业知识和丰富的经验，Byte的人
立刻知道这将是一个革命性的软体，因此马上希望Philip能够在Byte杂志刊登Turbo Pascal
的广告，并且愿意以半价刊登。当然，Philip也立刻的答应了，于是一个革命性的软体
Turbo Pascal终于在Byte杂志刊登出来了，售价49.99 美元的Turbo Pascal立刻为
Borland带来了大量的财富，Turbo Pascal也立刻的成为PC上除了基本的Basic 之外最
畅销的开发工具，也正式揭开了Borland 影响PC开发工具10几年的序幕。
在Turbo Pascal之后， Borland 接着推出了SideKick这套软体，SideKick可以说是随后名的记忆体常驻软体（TSR ）的始祖，也是让Borland 跨出开发工具界，让几乎所有PC使
用者认识Borlan d的关键软体。当然SideKick也很快的成为了全球的畅销软体，继续的把
Borland 往顶尖的软体公司上推。
而Turbo Pascal也成了我大二，大三撰写作业的最爱，几乎所有的作业都是使用Turbo
Pascal 完成的，当然其时Horowise的Data Structure这门课也是使用Turbo Pascal过关
的，因此从那个时候开始我便非常喜欢Borland 这家公司，慢慢的也开始对Borland 有了
特别的感情。大二时Microsoft 也推出了Microsoft Pascal，但是它和Turbo Pascal的确
是有一段差距，我使用了一次之后便把它丢到垃圾桶。稍后Borland 也推出了TurboBasic ，
我记得这个编译器非常的棒，编译速度就和Turbo Pascal一样，是一个非常有前途的产
品。但是我不知道为什么它只有1.0 ，之后便和Microsoft Pascal一样消失了。我听说
Microsoft 和 Borland 互相交换条件，Microsoft 不进入Pascal的市场，而Borland则
退出Basic 的市场。至于是不是真的我就不得而知了。
在大二初次的接触到C 语言，第一本阅读的书便是王兴隆先生写的C 语言，也从此开始和 语言结下了渊源。平生第一个使用的C 编译器便是Lattice C ，不知道还有没有人记得。
我还记得那个时候使用2 个5又1/4磁片抽换以便编译 C 程式的情景。稍后 Borland 终
于推出了风行天下的 Turbo C 编译器，当然，从此之后Turbo C 便成了不离身的工具，而
Borland 也藉由Turbo C 这第三项畅销产品迈向了世界前10名的项尖软体公司。
当完2 年的兵之后，我在中研院首次使用了C++ 语言，第一个使用的C++ 编译器则是 ortech C/C++，这家公司稍后被Symantec收购成为Symantec C/C++的核心，这个故事稍
后再说。后来 Borland 也推出了 Turbo C/C++ 1.0 这第一个C/C++编译器，但是在我和
Zortech C/C++ 比较之后，还是觉得 Zortech C/C++ 比较好，因此就继续使用Zortech
C/C++。一直到Borland 的Turbo C/C++ 2.0 编译器推出之后，才逐渐成为 C/C++ 语
言的王者，而我也像以往一样把Zortech C/C++ 换成了Turbo C/C++。
在1991年到Georgia Institute Of Technology 念硕士时，终于使用自己的零用钱美金
49.99 购买了生平第一套的正版软体Turbo C/C++ 4.5 ，随后又购买了Borland Pascal.
在毕业前的一个Quarter ，Microsoft推出了Microsoft C/C++ 6.0 以及MFC 1.0 ，由于
是第一个C/C++ 的Framework ，因此也花了一些钱购买了一套以便了解MFC。但是在收到
之后却很失望，因为 Microsoft C/C++ 6.0 仍然没有图形整合发展环境，还是在DOS 下的
整合发展环境，而且MFC 1.0 以我的眼光来看又不好用，而且Microsoft C/C++ 6.0 的
C/C++ 最佳化编译器在其时是一个笑话，不但产生的程式码效率不好，甚至会产生错误的程
式码，许多杂志也称Microsoft C/C++ 6.0 是一个平庸的（Mediocre）产品。因此就把它
丢在一边。在Microsoft C/C++ 6.0 不久之后，Borland 终于推了Borland C/C++ 3.0.而
这套软体也开启了Borland 雄霸C/C++ 编译器常达5 ，6 年之久的序幕。
Borland C/C++ 3.0 推出之后由于拥有第一个在Window下的稳定的图形整合发展环境，而
且它产生的最佳化程式码也是 Microsoft C/C++ 6.0 望尘莫及的，因此很快的几乎所有的
C/C++ 程式师转而使用 Borland C/C++ 3.0.因此在那个时候有一个现象，那就是几乎所有
的公用程式或是Shareware都是使用Borland C/C++开发的，许多硬体厂商的驱动程式也是
使用Borland C/C++ 3.0 来撰写的。 1992年我取得Georgia Institute Of Technology
的硕士学位之后最想进入的公司便是Borland 和Micro-soft，不过最后我还是决定回台湾
工作。在此时Borland也进入了最巅峰的时期，因为Borland 推出了Borland C/C++ 3.1。
Borland 在 Borland C/C++ 3.0 获得空前的胜利之后，并没有松懈下来，因为 Borland 知
道Borland C/C++ 3.0还缺了一个最重要的胜利因子，那就是如同Microsoft 的 MFC 一样
的 C/C++ 的 Framework ，因为Borland 也看出了Framework 将会是未来 C/C++ 产品中最
重要的一环科技。不过 Borland 此时面临了一个重要的十字路口，那就是到底要自己开发
一个和 MFC 抗衡的 Framework，还是要如何做。 因为如果要自己开发Framework，那么势
必要花上一些时间，但是 Borland想趁 Borland C/C++ 3.0 如虹的气势再下一城，以便彻
底击溃Microsoft C/C++。 因此最后 Borland 决定向一家叫 White Water 的公司购买一
套由这家公司开发的一个 Framework，这套 Framework 便是后来鼎鼎大名的 OWL 的源流。
而 Borland 也因为向 White Water 购买了这套Framework，因而也引进了一个日后非常
重要的人物，那就是后来负责开发Delphi的一员大将 - Zack Urlocker。
在Borland 购买下White Water 的C++ Framework 之后，便更命为OWL（Object Window
Library），并且很快的推出了以OWL 1.0 为核心的Borland C/C++ 3.1。由于OWL比当时
的MFC 1.0 封装的更为完整和好用，再加入Resource Workshop 视觉化能力，以及Borland
C/C++ 3.1 自己最强劲的编译器和整合发展环境，因此立刻的风靡了全世界，其受欢迎的
程度更是远远的超过了它的前一版本Borland C/C++ 3.0。
由于Borland C/C++ 3.1 的畅销，立刻让Borland 在C/C++ 市场一举击溃了 Microsoft
C/C++ ，市场占有率超过了50% ，是全球第一的C/C++ 产品，也把Borland推上了最高峰，
成为全世界第三大的软体公司。
很快的，我所工作的开发小组也立刻的以 Borland C/C++ 3.1 来开发系统，Borland C/C++
3.1 也是我使用过Borland 最稳定的C/C++ 版本之一。也由于那个时候一天到晚都使用
C/C++工作，因此就有了一些小心得。稍后我整理了一些东西便投稿到刚出刊不久的RUN ！
PC，也许是运气不错，RUN ！PC 很快的也登出了我的文章。就是这篇文章登出之后，台湾
的Borland 注意到了我，开始和我连络，并且从此展开了和Borland 的互动。而Borland
C/C++ 3.1 也是第一套Borland 免费送我的软体，当然代价就是希望我多写一些Borland
产品的文章。
接着Borland 又计划推出 Windows 版的 Borland Pascal，不过在 Borland 开发Borland
Pascal For Windows时，当时（现在也还是）最具盛名的Charles Petzold （我的第一本
Windows 程式设计的书就是这位仁兄写的，相信许多人也是看他的书一路学来的）就说除了
C/C++ 之外，Borland不可能做出能够在 Windows下执行的Borland Pascal，不过很明显
的，即使是 Windows API 的大师 Charles 也错了。Borland 不但做出来了，而且Borland
Pascal For Windows 还非常的畅销，当然Borland Pascal For Windows也是后来Delphi
的根基。
当时的Borland 可说是不可一世，不但产品大卖，而且日进斗金。Borland在 Scotts
Valley豪华的总部也是在那个时候由 Philippe Kahn 大手笔的花了一亿多美金搭建的
（想想10年前的60多亿台币可以盖什么样的房子？）。不过也许是 Borland 太成功了，
因此也开始让 Philippe Kahn 渐渐的养成了好大喜功，目中无人的态度，也种下了Borland
开始走向衰退的因子。
不过在 Borland 最强盛的时期，当然也就是Microsoft 最想痛宰Borland 的时候，在这
个时候发生了一个着名的事件和一个着名的虚拟人物。话说由于当时Microsoft 的开发工
具一直打不过Borland 的产品，因此在Microsoft 的开发工具刊物上便出现了一个作者
不断的以文章嘲笑Borland ，这个作者的笔名是 Buck Forland。 后来由于这位作者的文
章内容以及他的笔名引起了当时Borland的不满以及大量Borland使用者的强烈抗议，因
此稍后这位作者就突然的消失不见了。因此有许多人就推测这个作者应该是 Microsoft的
工程师，由于一直无法打败Borland 的产品，脑羞成怒，因此才会以这个笔名来发泄。如
果各位看倌到现在还摸不着头为什么这个笔名会引起轩然大波，那么请你试着把Buck
Foland 这两个英文字的第一个字母一对调就知道为什么了。现在各位是否会心一笑了？
在Borland C/C++ 3.1 大获成功之后，Borland 却开始松懈了下去，并且开始走下坡。
当然这有许多的原因，我所知其中最重要的原因有数项：
■Philippe Kahn 和当时Borland C/C++ 的产品经理闹翻了。这位 BorlandC/C++ 的产
品经理的名字是Eugene Wang ，他是一位非常聪明的中国人。他一手把Borland C/C++
带到了世界第一的地位，并且在Borland C/C++ 3.1 成功之后有了更伟大的想法，那就是
Eugene Wang想在下一个Borland C/C++ 版本中完整的以OWL封装所有的 Windows API，
因为OWL 1。0 虽然比MFC 1。0 来得优秀，但是OWL 的隐忧就是OWL 尚未完整的封装
所有Windows 的API。此外Eugene还计划以OWL 为核心，开发一个类似今日Borland
C/C++ Builder 的以视觉化元件为开发方式的开发工具。请各位想一想，如果在当时
Borland能够开发出这种 C/C++ 开发工具，那么将会是一个多么可怕的产品，稍后
Microsoft 的Visual C/C++ 1.0 只是能够在整合发展环境中自动产生 MFC 的程式码就立
刻的轰动了 C/C++ 市场，造成了大量程式师转入 Microsoft 的阵营。即使是目前的
Borland C/C++ Builder使用的Framework 仍然是以Object Pascal 以核心的元件Framework，
而不是纯粹的C/C++ 程式码。如果当时 Eugene Wang能够做出他心中的下一版Borland
C/C++，那么我想到现在Borland C/C++ 可能还是市场中第一的 C/C++ 开发工具。不过很
不幸的是，Eugene Wang 稍后和 Philippe Kahn 发生了争执，Eugene Wang一气之下离开
了Borland。而 Philippe Kahn 则认为 Borland C/C++ 的地位已不可动摇，因此也没有想
立刻的做下一版的Borland C/C++。这样一拖竟然浪费将近2 年的时间。
Microsoft Visual C/C++ 1。0在Borland C/C++ 3.1 2 年之后推出，并且立刻获得市场好
评。不但在编译器方面能够和Borland C/C++ 3.1 相抗衡，在整合发展环境方面更大幅领
先了Borland C/C++ 3.1，还能够自动产生MFC 的程式码，再也不是昔日的吴下阿蒙。直到
此时 Philippe Kahn 才从梦中惊醒而急于开发下一代的Borland C/C++ 4.0 ，但是为时已
晚，C/C++ 的开发工具市场从此就开始逐渐的被Microsoft 蚕食了。
Eugene Wang 在离开 Borland 之后，立刻的被 Symantec 所网罗，稍后Eugene Wang也在
非常短的时间之内为Symantec开发出了着名的Symantec C/C++。 Symantec C/C++ 在当时
被所有的技术刊物评比为拥有最棒的整合发展环境和最有创意的C/C++ 开发工具，从此可
见Eugene Wang 的功力。不过 Symantec C/C++ 稍后也不敌 Microsoft Visual C/C++，这
个故事的原因在稍后四大C/C++ 编译器之争的段落中再详细的说明。
我最后听说 Eugene Wang 跑去做生意了，并且在前几年写了一本教导科技人员如何面试的
书籍。我一直很痛心Borland 失去了这么一位优秀的人材，我常想如果当初 Eugene Wang
没有离开Borland ，那么历史就可能不是现在的这样了，Sign！！！
■Philippe Kahn 大手笔的花了一亿多美金买下了 Ashton-Tate 公司和dBase。在当时许
多人都批评Philippe Kahn 做了不值得的事情，因为 Ashton-Tate 不值这么多钱。但是由
于当时 Borland 多的是钱，因此Philippe Kahn也不多意。不过这并不是Borland 走向逐
渐走向衰败的主因，而是在 Borland 买下了dBase 之后，并没有立刻积极的发展dBase
For Windows ，反而把dBase 丢在一旁。这个原因便是当时Borland 的另外一个和资料库
有关的产品Paradox 卖得也很好，因此Philippe Kahn 并不急着打算开发dBase For Windows。
不过Philippe Kahn 忘记了一件事情，那就是当时在市场大量人口的dBase 程式师需要一
个好的 Window 版dBase ，但是Philippe Kahn 购买了dBase 却不提供Windows 版的解决
方案。因此当稍后Microsoft 以极小的代价买下Fox 这家公司，并且在数年之后推出 FoxPro
For Window，吸引了大量原先的dBase 程式师以及Paradox 的程式师之后，Philippe Kahn
才警觉事情不对而充充忙忙的开发dBase For Windows。但是当dBase For Windows 推出之
后，Microsoft 早已推出了两个FoxPro For Windows的版本，而占据了大部份的市场，
dBase For Windows 其势已不可为了。
Microsoft 开始向Borland 挖角。由于Microsoft在许多的开发工具战役中一直被Borland
打得灰头土脸。更何况Borland C/C++ 3.1 几乎抢占了大部份的市场，因此Microsoft 开
始准备好好的对付Borland。但是由于其时Borland 在编译器的技术领域领先了Microsoft
数年之久，Microsoft无法在短时间之内赶上Borland，因此 Microsoft 决定使用最有效的
方法立刻追上 Borland 技术，那就是直接挖角。因此稍后Microsoft 的Visual C/C++小组
有60 %的成员是从Borland挖来的，这个举动不但立刻的让Borland 流失了大量的优秀技术人
才，也在数年之后造成了Borland 控告 Microsoft 的导火线。不知道各位看到这里有什么
感觉，或是没有感觉。不过我总是觉得 Microsoft使用了不好的手段来竞争，并不是光明
正大的击败Borland，而是使用了不公平的竞争手段。
Philippe Kahn 在这段时间不但让 Borland C/C++ 被 Microsoft Visual C/C++ 反败为
胜，也痛失了几乎所有dBase 的市场，更浪费了大量的金钱，和流失了大量的优秀人员。
在这些重要的原因之下， Borland已经不可避免的开始走下坡了。
我最后一次看到Philippe Kahn 时是在1994年未于亚特兰大（Atlanta ）参加国际
Conference时，还和他打了一声招呼。后来Philippe Kahn 离开了Borland，另外创立了
StarFish这家公司，稍后StarFish也被Motorola并购。虽然Borland由于Philippe
Kahn 一些错误的决策而逐渐的从巅峰开始下降，但是Philippe Kahn也不愧为一个人物。
因为Philippe Kahn 能够和Bill Gates一直周旋数年之久，而同一时期的许多公司，例如
Lotus 都一一的被 Microsoft所击败，因此 Philippe Kahn 还有一套的。此外 Philippe
Kahn 也是唯一一个拥有工程师特性的 Borland CEO ，Philippe Kahn 仍然重视技术产品
和技术人员。但是Borland 随后的CEO几乎都是Marketing ，Finance 或是Sales出身的
人，这真让我怀念以往以产品和技术为优先的CEO 了。
看完了上面这段今人伤心的历史之后，再让我们看看当Borland 在受到Microsoft Visual
C/C++的强大冲击之后，如果思索反击之道。在这段期间也出现了令我敬佩的第一个
Borland 技术工程师，Carl Quinn。
Carl Quinn在Microsoft Visual C/C++ 1。0推出之后，立刻奉命开发一个能够和MFC
相抗衡的全新OWL，而CarlQuinn也是数年后JBuilder的JBCL Framework的灵魂开发人
物。Carl Quinn 不但负责开发OWL ，也为Borland 在元件Framework 的技术领域立下了
重要的贡献。由于 Carl Quinn 的投入，因此开启了 OWL 大战MFC，Borland C/C++缠斗
Visual C/C++数年精彩好戏的序幕。
Borland C/C++的反击
我的小文《DELPHI探索》写作进度很难控制，其间隔的时间可能比较长， 为了在这段间隔
的时间让大家看当Visual C++ 1.0在C/C++开发工具市场获得了空前成果的之后，Borland
才从Borland C/C++ 3.1的胜利梦中惊醒，思考如何面对Visual C++的猛烈功势。事实上当
时的Borland如果脑袋清醒一点，好好看清当时C/C++开发工具的市场，那么Borland应该
会发现虽然Visual C++经过2年多的整军经武，实力已经大不前。
不过Borland C/C++ 3.1仍然在许多方面可以和Visual C++一争长短的。例如其时Visual
C++的最佳化编译器仍然落后Borland C/C++ 3.1一些，第2点是MFC仍然没有完整的封装
Window API，而且MFC是以较低阶的方式封装Window API，并不是很物件导向，也不是很
容易使用。事实上以我的观点来看，我认为就是因为MFC不好用，因此Visual C++才需要
在整合发展环境中提供以视觉化方式产生MFC程序码的功能，第3是Visual C++ 当时并没
有很好的封装资料结构的Container Class，而Borland C/C++却有非常好用的BIDS类别
库。第4，也是最重要的，Borland C/C++ 3.1仍然拥有绝大的市场，而且几乎所有的周边
公用程序，Shareware等都是使用Borland C/C++ 3.1开发的。因此如果Borland不要急，
好好的开发下一代的C/C++开发工具，即使Microsoft Visual C++能够掠夺一些市场佔有
率，但是如果下一代的Borland C/C++能够像Borland C/C++ 3.0一样立刻拉开和Visual
C/C++的距离，那么Borland在C/C++市场仍将拥有王者的地位。
可惜的是，也许Philippe Kahn在和Microsoft的FoxPro For Window一役中被吓到了，因
此急於在Visual C/C++ 1.0之后立刻推出新的Borland C/C++以扳回颜面。但是Philippe
Kahn忘了，在这段时间之内Borland失去了许多的人材，Eugene Wang也离开了，更重要的
是在过去近3年的时间之内，Borland几乎没有持续的开发下一代的Borland C/C++，在短
时间之内如何能够仓促的推出产品呢?
但是Philippe Kahn可管不了这么多了，急忙找来了Carl Quinn等人便要求立刻开发出下
一代的Borland C/C++，於是Borland C/C++ 4.0就在这么鸭子赶上架下匆忙的开发了。
Borland在开发Borland C/C++ 4.0时犯了许多的大忌。首先在这么短的时间内Borland决
定全新发展整合发展环境，第2是把OWL完全重写，第3是大幅修改最佳化编译器，第4是
整合当时棘手的VBX，Borland居然让16位元和32位元的程序能够同时使用16位元丑陋
的VBX。
上面所说的每一项都是大工程，Borland早应该在Borland C/C++ 3.1之后便开始做这些工作
现在要在短短的一年多的时间内重新开发一个这么複杂的C/C++开发工具，几乎是不可能的
工作。但是在Philippe Kahn的要求之下，这些Borland的工程师还是硬着头皮做了出来。
不过我必须很沈痛的说，当时我在Beta测试Borland C/C++ 4.0时便和台湾Borland的人
说，如果Borland仓促推出Borland C/C++ 4.0的话，那么不但不会对Visual C++产生任
何的影响，反而是自杀的行为，因为臭虫实在太多了，整个整合发展环境的反应也很缓慢，
它的最佳化编译器更是笑话，错误百出，真是像当时恶名昭彰的Microsoft C 4.0一样。我
还开玩笑的说，是不是因为Microsoft从Borland挖了大量的Borland C/C++人才，因此好
胜的Philippe Kahn也还以颜色，从Microsoft反挖Microsoft C的人，却不幸的挖到了
Microsoft C 4.0 的人。
但是很显然的Borland并没有听到我的，或是其他Beta测试人的心声，在Visual C++ 1.0
推出后的1年多，Borland C/C++ 3.1后的4年，Borland终於推出了新一代的Borland
C/++ 4.0，这个肩负和Visual C++ 1.0对抗的C/C++开发工具。
在Borland C/C++ 4.0刚推出之际，Borland确实为4.0做了极大的造势，我记得在当时所
有重要的电脑杂志中，例如Byte，PC Magazine，Dr. Bob等，都有4.0整页的广告。这个
广告的内容是以一个巨大的猫头鹰为主，再搭配蓝色底色系的Borland C/C++ 4.0为主，选
用巨大的猫头鹰当然是因为OWL的原因，只可惜我现在找不到那幅广告了。
当时Borland使用了如下的广告用词 : 『Visual Is Only A Facial Facade』来讽刺Visual
C/C++只提供了产生MFC程序码的基本精灵，而Borland除了也提供相对应的AppExpert精灵
能够提供类似的功能以产生使用者选择的OWL程序码之外，Borland C/C++ 4.0的整合发展
环境还提供了视觉化的3面版视窗，能够让程序师完整的掌握整个专案的情形。
下图则是当时Borland C/C++的註册商标，3面版视窗开发环境。看到下图又令我想起当初
使用C/C++写程序的日子，下方程序码面版清楚的显示了我在1995年於鼎新工作时写的智
慧型Window排程系统，时间过得是真快啊。
(图3 令人怀念的Borland C/C++ 4.0整合发展环境，三面版视窗)
当时Borland C/C++ 4.0的3面版整合发展环境真是开创了一个新的局面，因为这个整合发
展环境允许程序师知道每一个应用程序定义的视窗讯息，并且能够立刻的显示在下方的程序
码视窗中，的确是非常的方便，也比当时Visual C/C++的整合发展环境来得先进。再加入
Borland 较为先进的编译器技术和架构更好的C/C++ Framework-OWL，照理说Borland C/C++
4.0应该会获得极大的胜利，那么为什么最后会以失败收场呢？
没错，在Borland C/C++ 4.0刚推出之后订单的确如雪片般飞来，销售情形非常好，因为这
毕竟是Borland 在睽违了数年之后的大作，许多Borland的用户都迫不及待的昇级，就像当
初我也是拚命的要求台湾Borland要第一个给我Borland C/C++ 4.0。但是在Borland C/C++
4.0推出一段时间之后，市场的反应就急速的冷却下来，因为各种负面的批评不断涌现，这
主要的原因当然是因为Borland C/C++ 4.0的品质实在不好，就像前面我在Beta测试时说的
由於Borland太急於推出4.0，因此并没有在最后阶段修正许多的错误，又没有经过最后系统
微调的工作，又太大胆的加入太多先进的技术，造成了整个产品的不稳定，而造成了大错。
下面几点应该是造成当初Borland C/C++ 4.0滑铁卢的主要原因：
*整合发展环境方面-臭虫太多，容易当掉而且反应速度缓慢
*编译器方面-最佳化玩得过火，产生错误的编译程序码
*OWL方面-採用全新的多重继承架构，虽然是正确的做法，却和Borland C/C++ 3.1中的OWL
不相容，造成许多程序师无法昇级C/C++专案
*VBX方面-大胆的採用在16/32位元都能使用VBX的技术，造成一些VBX无法顺利的在Borland
C/C++ 4.0中使用
我想其中最可惜的就是OWL了，因为OWL 2.0在各方面都有一流的表现，实在是MFC强劲的
竞争对手，OWL 2.0 也获得了各方一致的肯定和称讚。无奈的是由於OWL 2.0做了从基本架
构的改变，这是为了解决当初OWL 1.x使用了不标准的C/C++编译器技术的问题，但是这造
成了原本Borland C/C++程序师极大的困扰，因为昇级不易。对於新的C/C++使用者来说又
因为Borland C/C++ 4.0本身不稳定的因素而却步，因此造成了OWL 2.0叫好不叫座的下场.
真是可惜了OWL小组的努力。
我记得当时我的专案有使用FarPoint的SpreadSheet VBX元件，由於一直无法顺利的在
BorlandC/C++ 4.0中使用，并且会造成应用程序的当掉，最后追踪执行程序码却发现应该
是Borland C/C++ 4.0的问题，因此最后只好在咒骂中放弃使用4.0，而回到Borland C/C++
3.1。我当时想，对於我这个长期使用Borland产品的人都无法忍受4.0的品质，其他的程序
师又怎能使用这个产品。我想这就是为什么后来4.0全面溃败的原因，因为Borland推出了
根本不堪用的产品。
在我於Borland工作的时间，有一次在新加坡和现在Borland开发者关系部门的副总裁David
Intersimone谈起这一段往事，David也很感慨这一段往事，David直呼"We screwed it up!"
"It's a mess".David并且说当时整个Borland C/C++开发小组都很混乱，和以往Borland
C/C++ 3.0/3.1的开发小组比起来实在是差太多了，除了因为一些重要的人物相继离开
Borland，而且Microsoft也挖走一大票人之外，Philippe Kahn的直接介入，造成人事不
和也有很大的原因。
在Borland C/C++ 4.0快速失利之后，Borland也体认到问题的严重性，因此立刻的着手开
发Borland C/++ 4.0的Patch，当时是称为Service Pack。但是在稍后的4.01版中并没有
完全的解决问题，一直要到4.02才稍为解决一些严重的问题，无奈时不我予，拖的时间太
长，市场已经起了巨大的变化。在Borland C/C++ 4.0失利之后，立刻造成了严重的后果，
首先是Borland C/C++的市场大量且快速的流失，让Visual C/C++快速的成长。第二点是当
初Borland C/C++3.1在公用程序市场打下的江山也拱手让人，原本许多硬体厂商也使用
Borland C/C++ 3.0/3.1撰写驱动程序也开始转换到Visual C/C++，而严重的是在应用程序
市场方面由於4.0的品质以及稍后OLE的关系，也开始大量的开始转为使用Visual C/C++
来撰写应用程序。
Borland在3个主要的应用市场接连败退，C/C++的江山注定将易主，其势已不可挽。
Borland C/C++，Visual C/C++，Watcom C/C++和Symantec C/C++的缠斗
自Borland C/C++ 4.0一役大败之后，Borland在C/C++市场上建筑的巨大堡垒似乎再也不是
牢不可破了。Visual C/C++固然在不断的接收BorlandC/C++失去的市场，此时在C/C++市场
上也加入了另外两个坚强的对手，那就是Symantec C/C++和Watcom C/C++。
Symantec C/C++的发展史
说起这两个对手也都是个个来头不小，先说Symantec C/C++吧。它的Think C/C++在
Macintosh上便是非常有名的编译器，因此早在C/C++领域便有深厚的基础。在Symantec并购
了PC上第一个C/C++编译器Zortech C/C++之后，Symantec进入PC的开发工具市场也是箭
在弦上了，只可惜的是其时Symantec还未找到一个在PC上有丰富经验的开发工具领导者。
也许是上天注定要引起稍后的C/C++编译器大战吧，此时Borland C/C++ 3.1的幕后支柱
Eugene Wang刚好和Philippe Kahn闹翻，离开了Borland。Symantec见此时不可失，立刻
重金延揽Eugene Wang到Symantec，为Symantec推出第一个C/C++开发工具。在1993年
左右吧，Symantec C/C++在Eugene Wang的掌舵之下推出了第一个Symantec C/C++版本，
立刻便获得了市场的好评。自此之后Symantec C/C++军心大振，不断的继续改善，也逐
渐的获得了不小的C/C++市场，隐然成为可以对抗Borland C/C++，Visual C/C++的另
一山头。当时Symantec C/C++是以最华丽，先进的整合发展环境获得市场的高度认同，在
C/C++编译器最佳化方面的表现也不会输给其他的编译器。
当时我在RUN!PC上写C/C++的文章，因此Symantec C/C++也有和我连络，并且送给我一套
最高档的Symantec C/C++，希望我除了为Borland写C/C++的文章之外，也能够为Symantec
C/C++写一些东西，我想这就是做为写技术文章的一个好处之一，那就是可以拿到许多最Hot
的开发工具。我还记得在当时安装Symantec C/C++之后，的确被它的整合发展环境吸引
的说不出话来，因为实在是太棒了，Borland C/C++和Visual C/C++的整合发展环境和
Symantec C/C++的整合发展环境比较起来，立刻的就变成索然无味，平凡无奇了，到现在我
仍然必须竖起大拇指对Symantec C/C++的整合发展环境说声『讚』。我想Eugene Wang
在这么短的时间内把Symantec C/C++打造的好此之好，除了证明他的不凡功力之外，也有向
Philippe Kahn示警的意思。证明Philippe Kahn让他离开Borland是错误的决定。我之所以
如此说是因为其时Symantec C/C++最喜欢点名挑战的对象便是Borland C/C++了。对我的
感觉而言，Symantec C/C++就像是一个技艺精良，又装备华丽的C/C++军团。
Watcom C/C++的发展史
真是非常有趣的是，Watcom C/C++走的路子和Symantec C/C++几乎是完全相反的。当时出品
WatcomC/C++编译器的是一家加拿大的小公司，不过这家公司却对最佳化编译器有深入的研
究。当时Watcom C/C++是以在DOS下能够产生最好的最佳化程序码闻名於世的，在其时有许
多写游戏和DOS Extender的厂商都是指名要使用Watcom C/C++，因为不论是Borland C/C++
或是Visual C/C++产生的最佳化程序码都比WatcomC/C++的最佳化程序码差上一截。再加入
当时最有名的DOS Extender 厂商PharLap公司也是使用Watcom C/C++，因此Watcom C/C++
在专业的C/C++程序师以及系统程序师心中是第一品牌的C/C++开发工具。
不知道还有多人记得PharLap这家公司，或是有没有人记得Andrew Schulman这位伟大的软
件技术人员。当时Andrew Schulman的Undocumented Windows一书红遍了半边天，也惹得
Microsoft要告Andrew Schulman。而Andrew Schulman便是PharLap公司的首席工程师，也是
当时最着名的『The ANDREW SCHULMAN Programming Series』的总监，例如当时由Matt
Pietrek撰写的Windows Internals也是轰动一时的巨着。而PharLap公司是当时出版DOS
Extender软件最成功的软件公司。
谈到Matt Pietrek，熟悉Window Programming的人应该很少有不知这位大师级人物的.Matt
长期在Microsoft System Journal撰写Under The Hood专栏，专门写一些深入系统的程序
设计技术，在数年前便和Andrew Schulman，David Maxey成为Widow System Programming
的三大巨头之一。Matt也是着名的Window除错工具SoftIce，BoundsChecker的主要研发工程
师。Matt本身也是从Borland出道的，当Matt初至Borland工作时便是在Turbo Debugger小组
中研发除错工具.当时Bor-land的Turbo Debugger是DOS下最强的除错工具，即使是Microsoft
也无法推出能够和TurboDebugger抗衡的除错工具。Matt在这个小组中吸收了大量的知识，
并且快速的成为这个领域的专家。后来Turbo Debugger小组的部份成员被Microsoft挖走，
让Microsoft掌握了Borland的核心除错技术，以致后来也能够推出不错的除错工具。而Matt
也出走到NuMega公司成为开发SoftIce，Bounds Checker的关键人物。写到这里还是不禁
要佩服Borland，因为当今许多名满天下的重量级软件工程师都是由Borland培养出来的。
在Watcom C/C++於DOS市场佔稳了脚步之后，由於Window已经逐渐成为市场的主流，DOS势必
将被逐渐淘汰出局，因此WatcomC/C++要继续的生存下去，也一定要推出Window平台的C/C++
开发工具。大约也是在1993，1994年左右Watcom终於推出第一个Window的开发工具。不过当
时Watcom C/C++在Window推出的C/C++开发工具实在是平凡不已，其整合发展环境和另外三
个对手比较起来简直像是远古的产品，一点特色都没有，不过Watcom C/C++仍然是以它的
最佳化编译器做为号召。因此在当时发生了一个非常有趣的现象，那就是许多软件公司会同
时买Borland C/C++，或是Visual C/C++，Symantec C/C++之一，再搭配一套Watcom C/C++。
在开发应用系统时使用其他三套开发工具之一，最后要出货时再使用Watcom C/C++来编译
以产生最佳的程序码。
在Watcom C/C++推出了Window平台的开发工具之后，仍然吸引了一群使用者，虽然Watcom
C/C++的市场比起其他的三家来说是最小的，但是也在一方撑起了一片天，成为四大C/C++开
发工具之一。稍后WatcomC/C++被Sybase并购，并且成为后来Sybase的Optima++的前身。
对我的感觉而言，Watcom C/C++就像是一个穿着朴素，但是却拥有最佳训练的白色C/C++军团。
关键的时刻-MFC Or Not 在Symantec C/C++和Watcom C/C++逐渐的站稳了脚步之后，四大
编译器决战的时刻也逐渐逼近了。在1994年未的决战之前，Symantec和Watcom同时面对了一
个非常严厉的考验，那就是C/C++Framework的选择。
虽然Symantec和Watcom都以各自的特色佔得了市场，不过在当时对於一个C/C++开发工具来
说，最重要的因素之一就是C/C++Framework。因此Symantec和Watcom也都必须提供使用者一
套C/C++ Framework。不过这对於Symantec和Watcom都是一个难以解决的问题，因为当时的
C/C++ Framework已由Borland的OWL和Microsoft的MFC所佔领，如果要自己发展新的C/C++
Framework，那么Symantec和Watcom并没有如此雄厚的资源，也无法在短时间之内完成。
因此Symantec和Watcom必须下一个决定到底是要使用MFC或是OWL做为它们的开发工具C/C++
Framework。
在1993年初Symantec和Watcom分别和Microsoft签约License MFC做为它们的开发工具的C/C++
Framework。
至此大势以定，在C/C++Framework的市场已经形成三家夹击一家的形式。当时许多人便预估
Borland将成为输家，因为市场已经成为一面倒，MFC看起来已经是胜券在握了。在当时於
Borland的内部也展开了激烈的辩论，讨论是否也要License MFC做为C/C++的Framework，
停止继续开发OWL。不过后来Borland还是决定继续开发OWL，而不使用MFC，因为Borland的
C/C++技术小组认为MFC不论是在架构上或是设计上都比不上OWL。而且由於Visual C/C++
在当时对於C/C++的标准支援不如Borland C/C++，因此在MFC内部使用了大量的Macro以及
不标准的语法，因此如果Borland C/C++要使用MFC，那么还需要修改编译器来编译MFC。
对於这一点我认为Borland还是做了一个正确的决定，因为如果当时Borland也License MFC，
那么不但在气势上便输了一截，而且当MFC的发展是完全掌握在Microsoft的手里，那么就等
於脖子是掐在别人的手里，动弹不得了。可惜的是Symantec和Watcom并没有看清这一点，以
为有了和Microsoft一样的Framework，就可以在其他地方和Micro-soft以及Borland一
决雌雄，Symantec和Watcom却没有想就是这一点决定让后来的决战一败涂地，终究完全出
PC的C/C++开发工具市场。
时序到了1994年未，C/C++开发工具的四大天王决战的日子终於愈来愈近了。
OLE的搅局
-李维
不知道是时运不济或是Microsoft的刻意如此，在1994年Borland C/C++和Visual
C/C++决战的前夕，Microsoft推出了OLE(Object Linking And Embedding)技术。
OLE是Microsoft为了对抗Apple的文件技术以及IBM OS2的Workplace和文件技术应
运而生的。OLE可以让Window平台的文件能够内嵌在不同的应用程序中并且能够让
文件在应用程序中被即地编辑(In-Place Editing)。说实在的，Microsoft的OLE和
Apple以及IBM的技术比较起来实在是差多了，OLE在稍后也被证明是失败的技术，
不过不管是Microsoft的OLE或是Apple/IBM的文件技术也都是失败的技术，都没有
造成巨大的成功。虽然这些文件技术都没有成功，但是OLE却足以成为Borland，
Symantec和Watcom失败的重要因素。
我还记得当时OLE似乎成为了一个令人趋之若鹜的时髦功能，因为Word的文件能够
内嵌在Excel之中，并且可以点选此Word文件，应用程序又立刻成为Word来编辑它
，实在是令人觉得非常的神奇。不过在其时所有的软件厂商中只有Microsoft的应
用程序有如此的功能，其它的厂商例如Lotus，WordPerfect等都无法实作出这种功
能。这造成了不公平的竞争，因为OLE技术是由操作系统厂商Microsoft推出的，但
是却让它的应用程序部门同步拥有这种技术，而其它的软件厂商都无法获得第一手
的OLE技术来实作，这是为什么当时其它的软件厂商如此火大的原因。
虽然后来其它的软件公司在取得了OLE的技术信息之后也推出了具备OLE功能的应用
程序，但是毕竟是慢了Microsoft许久，市场也流失了许多。不过我也很奇怪的是
在当时内建OLE功能的应用程序之中，几乎所有的软件厂商推出的应用程序在激活
数个应用程序而且使用OLE之后，就非常容易的当掉，只有Microsoft的应用程序不
太会发生这种情形，因此许多人便认为Microsoft有隐瞒一些技术没有让其它的厂
商知道。
由于OLE是如此的复杂，因此Borland无法立刻在OWL之中实作出这种功能，于是就
造成了市场上负面的影响。至于Symantec和Watcom虽然是License MFC，但是在其
时它们License的是MFC 1.x的版本，Microsoft并没有把OLE实作在MFC 1.x中，而
是在实作在MFC 2.0之中。在MFC 2.0推出时最重要的功能就是Microsoft加入了
20000多行支持OLE的程序代码，但是MFC 2.0却仅限于Visual C/C++使用，就是这
关键的一点让其它三家厂商吃了亏。
对于OLE这个关键技术的影响，Borland是深知在心的，因此在计划在Borland
C/C++ 4.5的OWL 2.5中支持OLE。当时Borland推出的解决方案便是OCF(Object
Component Framework)。
Borland当初在设计OCF时有几个重大的目标。这些目标包括了: 一、如何能够使得
OLE琐碎 、复杂的接口能够单纯化; 第二、如何能够使得OLE在窗口环境下写程序
的思考方式 一致化--即使用「事件驱动」的方法。第三、如何能够在微软占尽天
时、地利(未必人和) 的情况下使得Borland的产品具备OLE的功能。第四、如何能
够让大多数C++的程序员都能够享受OLE的功能而不局限于OWL的程序员。由于上述
的设计目标, 而造就了典雅而具有弹 性的OCF。由于OCF本身是一完整而独立的
Framework, 因此它可适用于各种应用程序发展Framework。
不晓得各位使用过Borland C/C++的朋友们是否还依稀记得下图OCF的架构图之一，
以及下面的OCF范例程序代码，这些可是我把1994年写的文章挖出来之后找到的，
真是令我感慨，也回想起了当时的情景，也让各位回忆一下OWL和OCF。对于不熟悉
OWL和OCF的朋友，也可以从下图和程序代码中观察一下当时的技术以及设计的概念。
基本上我现在看这些图形架构，会发现它们并没有落后现在太多，可见当时设计
者的功力(Carl Quinn Again)。
//
// Insert an OLE object into the view
//
void TOleWindow::CmEditInsertObject()
{
001 PRECONDITION(OcView);
002 TOcInitInfo initInfo(OcView);
003 if (OcApp->Browse(initInfo)) {
004 TRect rect;
005 GetInsertPosition(rect);
006 SetSelection(new TOcPart(*GetOcDoc(), initInfo, rect));
007 OcView->Rename();
008 InvalidatePart(invView);
}
}
程序1 OWL的TOleWindow支持OLE插入对象之成员函数
//
// Handle left double-click message
//
void TOleWindow::EvLButtonDblClk(uint modKeys, TPoint& point)
{
PRECONDITION(GetOcDoc() && GetOcView());
TOleClientDC dc(*this);
dc.DPtoLP(&point);
TOcPart* p = GetOcDoc()->GetParts().Locate(point);
if (modKeys & MK_CONTROL) {
if (p)
p->Open(true); // Ctrl key forces open editing
}
else {
SetSelection(p);
if (p && p == GetOcView()->GetActivePart()) { // resync the active flag
p->Activate(false);
}
GetOcView()->ActivatePart(p); // In-place activation
}
}
程序2 OWL的TOleWindow支持左键双击之成员函数
虽然Borland及时的在OWL 2.5中加入了OLE的支持，无奈Microsoft随后又在OLE中
加入了许多其它的功能，因此让OCF并无法完整的支持OLE所有的功能，Borland无法不断
的延后Borland C/C++的推出，因此在1994年未，Borland终于推出了决战的4.5版本。
C/C++开发工具的最后圣战
『虽然已经过去了许久的时间，但是我仍然忘不了那场最惨烈的战役!』1994年未, 1995初
Borland在痛定思痛之后，终于清除了Borland C/C++ 4.0中所有的问题，也开发出了自
Borland C/C++ 3.1以来最稳定，最快速的Borland C/C++ 4.5的版本，准备和Microsoft
决一死战。我还记得当时在书籍市场中许多有关Borland C/C++和Microsoft C/C++的书籍
都是使用十字军的封面，而Borland C/C++的系列丛书都是以蓝色为色系，而Microsoft的
则是以红色为色系，仿佛两大军团终将决战似的。
C/C++四大天王决战一役的Borland主将-Borland C/++ 4.5不过这次的战役不光是Borland
的蓝军和Microsoft的红军相对抗，在Symantec的华丽军团经过了经军经武，Watcom的白
色劲旅枕戈待旦，而且都从Microsoft License了MFC之后，蓝，红，花，白四大军团决战
的日子终于到了。首先当Symantec和Watcom分别取得了MFC之后，Symantec便推出了C/C++
7.x的版本，和Watcom C/C++混战了起来。两个使用系出同门的C/C++ Framework产品战得
不亦乐乎，随后Borland C/C++ 4.5和Visual C/C++的新版本也加入了这场最重要的决战。
但是让Symantec和Watcom C/C++大吃一惊的是Microsoft使用的MFC居然比它们的版本高
出了一个版本(1.x对2.x)，而且新版本的MFC包含了完整的OLE支持能力。而Borland虽
然也有OCF，但是仍然不敌新版MFC中的OLE能力。由于当时几乎所有的应用程序都需要支
持OLE，但是却只有使用Visual C/C++最新的版本才能够开发完整OLE能力的应用程序，因
此不管OLE到底有没有用，反正先加入再说。因此市场上的情势很快的就发生了巨大的变化，
几乎大部份的应用程序开发因为OLE的原因都选择使用Visual C/C++，Symantec和Watcom
军团很快的就败阵下来。
至于Borland C/C++ 4.5虽然是一流的产品，如果没有OLE的因素，Visual C/C++新
版本真的并没有比4.5好。虽然4.5也有OCF，但是在市场上只有Borland和Novell，
WordPerfect选择使用OCF，在和Microsoft的Visual C/C++经过将近一年的缠斗之
后，其它大部份的厂商都选择了Microsoft的MFC 2.x版，真是形势比人强。基本上
OCF的架构真的是个好东西，只是OCF无法完整的支持OLE，因为OLE的发展是掌握在
Microsoft手中，因此虽然OCF的架构良好，终究在功能上不及对手。Microsoft结
合操作系统，开发工具和应用程序的手段真是无往不利。击败Lotus，Borland是如
此，歼灭Netscape也是如此。
对于Symantec和Watcom来说，这场战役就如同『长平之战』，秦军坑杀40多万赵军
一样。杀得Symantec和Watcom全军覆没，大败而归，至此Symantec弃受PC的C/C++
开发工具市场，转而开始研发Java开发工具，进而在稍后推出了著名的Visual Cafe, 至
于Eugene Wang则离开了Symantec，自此也离开了PC开发工具的领域。 而Watcom则是更
为凄惨，整个公司在DOS的市场逐渐式微，而Window平台的开发工具又大败而归，两头落
空。不久之后Watcom便被新兴而起的Sybase并购，从此消失于竞争激烈的市场。
归纳Symantec和Watcom失败的原因是C/C++的Framework MFC掌握在Microsoft手中，
在决战时刻Microsoft居然手握比Symantec和Watcom更新的MFC利器，而且在Visual
C/C++精进最佳化的技术并且改善整合发展环境之后，Symantec和Watcom诉求的重点功能
完全被Microsoft封死。因此在产品，技术，市场和气势上完全不如对手的情形下，自然只
能任人宰割了。
对于Borland而言，虽然没有像Symantec和Watcom那么溃不成军，但也是再次败下阵来。
虽然平心而论Borland C/C++ 4.5的确是一个非常好的产品，无论在OWL，最佳化编译器，
整合发展环境方面都有一流的表现，和Borland C/C++ 4.0比较起来简直有如脱胎换骨一
般，到现在Borland C/C++ 4.5仍然是我最喜欢的版本之一。但是无奈当初Borland C/C++
4.0给人挥之不去的负面印象，以及无法完整支持当时如火如荼的OLE技术，因此还是在
决战之中败了下来。好在蓝色的Borland大军毕竟是训练有素的，虽然自此让Microsoft占
据了超过50%的市场，成为C/C++开发工具的老大，但是Borland仍然掌握了超过30%的市场，
稍做喘息，并且支撑Borland 在各重要战役失败之后维持公司的运作，等待Delphi的浴火
重生，再重新出发。
经过这一役之后，Microsoft终于清除了大部份的对手，对于Microsoft而言程序语言开发
工具的战争已经结束，这个市场注定将被Microsoft占据大部份的市场。在Microsoft手握
操作系统，Office软件和开发工具三大获利市场之后，Microsoft也开始将矛头对准下两个
竞争目标，关连数据库以及主从架构开发工具。在Microsoft正式进军这两个市场之后，当
然也展开了连番的好戏，尤其是在主从架构开发工具方面又开启了VB，PowerBuilder，
Gupta/Centura和Delphi的惊天动地大会战。另外一个意外开启的战争则是Microsoft在
1995年和Netscape的挑起的浏览器大战。
对于Borland而言，在C/C++最后一役之后，基本上我认为开发工具的圣战已然结束，Borland
也正式开始走下坡。更严重的是我认为自此之后Borland不但丧失了C/C++的江山，也失去
了对于C/C++开发工具的创意，这是我感觉最遗憾的地方，到现在为止我仍然认为Borland
尚未重拾当初在Borland C/C++ 3.0/3.1时代独领C/C++创意风骚的精神。也许，也许，要
看看C/C++ For Kylix或是C++ Builder 6是否能够重新找回这个失去已久的精神，不要再
让我失望了。
雄霸数年的C/C++的世界冠军-Borland C/C++ 3.1-永远的怀念
永不成气候的C/C++开发工具-IBM Visual C/C++
IBM在C/C++开发工具扮演的角色一直令人啼笑皆非，因为在C/C++编译器战争最激烈的时
刻，IBM这个全球信息大厂却一直是缺席的。一直到了1995之后，C/C++编译器市场大势已
定之后才慢慢的加入战局，推出VisualAge C++ 3.0，企图进攻此市场。但是此时市场早已
由Microsoft的Visual C/C++称雄。IBM的VisualAge虽然以创新的可视化设计家能够定义
对象之间的关系，但是在其它方面却乏善可陈，整个整合发展环境也缓慢如蜗牛，需要非常
高文件的硬件配备才能够顺利的执行，和Visual C/C++以及Borland C/C++等工具比较起来
就像是恐龙一般，因此几乎没有在市场上引起任何的反应。
在IBM推出VisualAge 3.0并没有在PC的C/C++开发工具市场获得任何的明显成果之
后，IBM又再次的集中了许多的资源，开发下一代3.5的版本，希望能够在此市场占
有一定的比率。我知道IBM在VisualAge投注了大量的资源，因为从Beta版开始台湾
的IBM便有人和我接触，希望我也在RUN!PC上为VisualAge 3.5写一些文章。因此在
1996年的6月我写了一篇C/C++编译器的比较文章，下面的资料便是数年前当时还在
Beta版的VisualAge 3.5和其它编译器的比较：
从上面的数据中可以看到其实VisualAge 3.5的表现还不错，只是对于当时还在使用AMD
DX4-100/32M RAM机器的我来说，实在是跑不太动VisualAge 3.5。后来台湾IBM负责
VisualAge的产品经理请我吃饭，在此饭局中这位李经理同时请了贺元(后来为资迅人的总
裁)，薛晓岚(后来为资迅人的副总裁)以及其它两位作者，希望大家在计算机杂志中继续的
为VisualAge 3.5写写东西，一起Promote此产品。在这个饭局中我是第一次和贺元，薛晓
岚见面，当时贺元在中文PC Magazine有一技术专栏。记得当时我向这位李经理提起我的机
器几乎无法跑VisualAge 3.5，他还立刻一口答应愿意借我一台当时IBM最高檔的PC，同时
每写一篇VisualAge的文章，除了RUN!PC原本的稿费之外，IBM会再付一字2.5元的稿费.
乖乖，IBM真是大手笔，我算算当时我的产能，写一篇文章就能够赚2到3万，又有免费的
最高档机器可用，真是太好康了。不过后来我还是觉得IBM在此市场可能不会深耕，在不愿
意违背自己写作习惯和得罪Borland的顾虑下，最后还是没有答应。现在想想当时真是太笨
了，放着好赚的稿费不赚，嘻。
IBM的C/C++开发工具之所以在市场无法成功是一是因为并不了解在此竞争激烈的市场中使
用者到底要什么。另外一个原因则因为IBM并不以PC上的开发工具软件为重要的事业，即
使无法竞争对于IBM来说也没有什么影响，不像Borland这可是生命之争。因此IBM只是兴
起玩玩，随即放下。所以我觉得在PC平台使用IBM的工具是很危险的，因为IBM可能随时
会放弃此市场。例如不知道现在VisualAge C/C++到底如何，是不是还在3.5或是4.0版，
已经数年没有任何的维护和改善了。
稍后IBM为了想在OS2和Window平台上推出能够和Microsoft相抗衡的Basic工具，因
此秘密的研发了一个Object Basic。我也曾看过这个工具，但是Object Basic跑起来慢得
跟乌龟一样．后来不知道是不是一直无法改善这个问题，因此IBM从没有推出此产品，现在
IBM似乎只对Java有兴趣，VisualAge For Java还算发展的不错，希望不会有一天IBM对
VisualAge For Java的态度会和VisuaAge For C/C++以及Object Basic一样才好．
快速殒落的潜力之星－Sybase的C/C++ RAD工具Optima++
在1996年吧，Sybase并购了Watcom之后，终于推出了石破天惊的C/C++开发工具，Optima++。
Optima++是当结合了Watcom的最佳化编译器以及类似Delphi的组件拖曳开发环境的第一个
RAD C/C++开发工具，更棒的是Optima++的组件架构(类似Delphi的VCL)完全是以纯正的
C/C++程序代码撰写的。这可不得了，因为这代表Optima++是一个融合了Visual C/C++和
Delphi两大王者开发工具为一身的超级赛亚人工具。
在我知道这个工具，并且取得实际的使用之后，令我极为震惊。因为这个工具对于我这个使
用了C/C++ 5,6年的人来说，是比Delphi还具有吸引力。因此在当年我立刻的在RUN!PC上
介绍了此不可置信的工具。果然，Optima++很快在开始风卷市场，虽然没有立刻的占据很大
的市场量，但是已经造成了一股气势，开始为VisualC/C++和Delphi带来了压力。
我记得当时台湾Sybase办的产品发表会也吸引了数百人与会，不可一世。在我的RUN!PC文
章出版之后，台湾的Sybase立刻和我连络。由当时的余协理和我见面，也是希望我继续为
Optima++写文章，台湾Sybase也提供额外一字加2元稿费的待遇。但是我告诉余协理，
Optima++ 1.0虽然很棒，但是仍然有一些臭虫，而且和中文环境相冲突，无法处理中文，
需要立刻的解决问题才能够在台湾的市场成功。她答应我立刻的向总公司反应。我也老实的
告诉她在问题没有解决之前我无法写一些不确实的东西。后来台湾Borland的总经理方先生
也找我去询问有关Optima++的事情，我告诉他Optima++是好东西，但是中文有问题。如果
中文问题能够解决，那么将对Borland的产品有很大的影响，当时我还不知道Borland由于
Optima++的影响，已经开始准备发展C++ Builder。
在1996年底左右吧，Optima++ 1.5终于进入Beta的阶段，但是在我拿到Beta版时仍
然非常的失望，因为中文的问题仍然没有解决。后来台湾Sybase又找我去，这次和
我见面的是台湾Sybase总经理郭俊男先生，以及Sybase的新加坡技术总裁，不过我
忘记这位先生的名字了。我们见了面之后，我立刻的把Optima++ 1.5中文的问题以
及许多的臭虫告诉他们，希望他们能够解决，如此Optima++ 1.5才能够在中文市场
成功。可是出乎意我意料的是，他们似乎并不急着这些问题，反而询问我是否有意
愿为Sybase工作，做PowerBuilder的产品经理。
也许是因为我为Delphi写了太多的东西，让PowerBuilder受了很大的影响，因此他
们希望我到Sybase工作，以打击Delphi并且Promote PowerBuilder。当时他们提出
的待遇条件实在是非常，非常的诱人，比我当时的薪水高出一倍左右（我当时在资
策会工作）。不过由于我对PowerBuilder实在没有什么兴趣，因此我告诉他们如果
是做Optima++的产品经理，那么我将会考虑并且接受。
没有想到Sybase的新加坡技术总裁告诉我Optima++在1.5推出之后就可能会停止，
因为Sybase要把资源移去为当时愈来愈红的Java研发一个新的Java RAD开发工具，
那就是后来的PowerJ。于是他问我如果不愿意做PowerBuilder的产品经理，那么是
不是愿意做PowerJ的产品经理？由于当时我已经知道Borland开始了Open
JBuilder的研发，而我对Open JBuilder的兴趣远大于PowerJ，因此并没有答应
Sybase。果然，在Optima++ 1.5推出之后，不但中文的问题没有解决，Sybase也没
有继续的对Optima++研发下去。
一个如此有潜力的产品就这样消失了，真是令人遗憾，Optima++应该有很好的机会
可以成功的，我相信如果当时Sybase知道C++ Builder后来的成果，可能就不会放
弃Optima++了。而C/C++的RAD工具一直要到后来的C++ Builder来完成这个梦，又
是Borland成功的进入这个工具市场。
C/C++的开发工具之争到此算是告一段落了，虽然后来Borland继续推出了Borland C/C++
5.0但是品质仍然不够好，市场反应也不佳，后来Borland终于在Borland C/C++ 5.02之
后宣布停止此条产品线的开发，Borland C/C++的光荣历史也就从此打止，真是令人不胜感
叹，而Visual C/C++从此在C/C++开发工具市场中再也没有对手。不过没有竞争的市场的确
会让人松懈的，后来的Visual C/C++进步的幅度愈来愈小，MFC也数年没有什么大进步，不
像当时和Borland C/C++竞争时每一个版本都有大幅的改善。看来寡占的市场的确是不好的。
=== 附录一 ===
李维，中国台湾人，上世纪九十年代于美国取得电脑硕士学位，Borland大中华区CTO。
我之所以知道他，是因为大学时代看到他登在CSDN上的一篇有关C++的文章，
现在来看，该文在程序员中的影响力相当之大。继而后来又出了一本Borland传奇
的书，在国内颇是培养了一批Borland情节的程序员们。尽管Borland在走下坡路，仍然为之叫喊不止。
我想，也许是中国软件业的持续颓废下，以及长期以来对奇技淫巧的蔑视与打压下，
程序员的痛快一次发泄。
不可否认，李维是个很会讲故事的人。
必须指出，Borland以外的世界更加宽广。
=== 附录二：李维代表作品 ===
我的回忆和有趣的故事 --- C/C++圣战篇
李维
(声明以下的这篇文章内容是我个人的回忆以及看法，没有任何特别的偏见，许多的事情是
根据我的记忆以及从许多人的诉说中得知的，也许内容不是百分之百的正确，不过我想这些
内容有一定的可信度到是可以保证的。)。
一直想写一篇我个人在过去10多年来工作中经历的一些事情，以及看着一些我认为是伟大
的工程师在这些日子中对于资讯界的贡献。
和Borland 的缘由
记得我在大学时第一个在PC上使用的软体便是SideKick，至今我仍然无法忘记这个让我津
津乐道的软体，而Borland在当时也就是以SideKick成为全球知名的软体公司。不过
Borland 第一个奠立创业基业的软体却是我大二使用来交作业的Turbo Pascal. 而Turbo
Pascal也是第一个我听到关于Borland 的有趣的故事。
当年Philippe Kahn （Borland 的创使人）和Anders Hejlsberg到美国创业时，便由
Anders以组合语言撰写了Turbo Pascal的编译器，而Philippe则包办了Turbo Pascal
其他的部份。在这两位人兄开发完TurboPascal之后，穷得快连登广告的钱都没有了。但
是Philippe为了在Byte杂志（还记得这个着名的杂志吗？）刊登Turbo Pascal的广告，
因此和Anders商量了一个方法，那就是一天他们约了Byte杂志的人到当时Borland 的办
公室讨论刊登广告的事情。
当Byte的人到了Borland 之后，Philippe，Anders和公司的助理小姐故意忙着接电话，接
受Turbo Pascal的订单，并且告诉Byte杂志的人等一下。过了一阵子之后Philippe才进
入房间向Byte的人道歉，说他们的Turbo Pascal受到市场的热烈欢迎，订单源源不断的到
来，因此可能不需要在Byte杂志刊登广告了，接着Philippe向Byte的人展示Turbo Pascal
这个产品。由于在当时的机器中Turbo Pascal能够在少少的RAM 中常驻执行，又提供闪电
般的编译速度，立刻让Byte杂志的人震惊在当场，凭着专业知识和丰富的经验，Byte的人
立刻知道这将是一个革命性的软体，因此马上希望Philip能够在Byte杂志刊登Turbo Pascal
的广告，并且愿意以半价刊登。当然，Philip也立刻的答应了，于是一个革命性的软体
Turbo Pascal终于在Byte杂志刊登出来了，售价49.99 美元的Turbo Pascal立刻为
Borland带来了大量的财富，Turbo Pascal也立刻的成为PC上除了基本的Basic 之外最
畅销的开发工具，也正式揭开了Borland 影响PC开发工具10几年的序幕。
在Turbo Pascal之后， Borland 接着推出了SideKick这套软体，SideKick可以说是随后名的记忆体常驻软体（TSR ）的始祖，也是让Borland 跨出开发工具界，让几乎所有PC使
用者认识Borlan d的关键软体。当然SideKick也很快的成为了全球的畅销软体，继续的把
Borland 往顶尖的软体公司上推。
而Turbo Pascal也成了我大二，大三撰写作业的最爱，几乎所有的作业都是使用Turbo
Pascal 完成的，当然其时Horowise的Data Structure这门课也是使用Turbo Pascal过关
的，因此从那个时候开始我便非常喜欢Borland 这家公司，慢慢的也开始对Borland 有了
特别的感情。大二时Microsoft 也推出了Microsoft Pascal，但是它和Turbo Pascal的确
是有一段差距，我使用了一次之后便把它丢到垃圾桶。稍后Borland 也推出了TurboBasic ，
我记得这个编译器非常的棒，编译速度就和Turbo Pascal一样，是一个非常有前途的产
品。但是我不知道为什么它只有1.0 ，之后便和Microsoft Pascal一样消失了。我听说
Microsoft 和 Borland 互相交换条件，Microsoft 不进入Pascal的市场，而Borland则
退出Basic 的市场。至于是不是真的我就不得而知了。
在大二初次的接触到C 语言，第一本阅读的书便是王兴隆先生写的C 语言，也从此开始和 语言结下了渊源。平生第一个使用的C 编译器便是Lattice C ，不知道还有没有人记得。
我还记得那个时候使用2 个5又1/4磁片抽换以便编译 C 程式的情景。稍后 Borland 终
于推出了风行天下的 Turbo C 编译器，当然，从此之后Turbo C 便成了不离身的工具，而
Borland 也藉由Turbo C 这第三项畅销产品迈向了世界前10名的项尖软体公司。
当完2 年的兵之后，我在中研院首次使用了C++ 语言，第一个使用的C++ 编译器则是 ortech C/C++，这家公司稍后被Symantec收购成为Symantec C/C++的核心，这个故事稍
后再说。后来 Borland 也推出了 Turbo C/C++ 1.0 这第一个C/C++编译器，但是在我和
Zortech C/C++ 比较之后，还是觉得 Zortech C/C++ 比较好，因此就继续使用Zortech
C/C++。一直到Borland 的Turbo C/C++ 2.0 编译器推出之后，才逐渐成为 C/C++ 语
言的王者，而我也像以往一样把Zortech C/C++ 换成了Turbo C/C++。
在1991年到Georgia Institute Of Technology 念硕士时，终于使用自己的零用钱美金
49.99 购买了生平第一套的正版软体Turbo C/C++ 4.5 ，随后又购买了Borland Pascal.
在毕业前的一个Quarter ，Microsoft推出了Microsoft C/C++ 6.0 以及MFC 1.0 ，由于
是第一个C/C++ 的Framework ，因此也花了一些钱购买了一套以便了解MFC。但是在收到
之后却很失望，因为 Microsoft C/C++ 6.0 仍然没有图形整合发展环境，还是在DOS 下的
整合发展环境，而且MFC 1.0 以我的眼光来看又不好用，而且Microsoft C/C++ 6.0 的
C/C++ 最佳化编译器在其时是一个笑话，不但产生的程式码效率不好，甚至会产生错误的程
式码，许多杂志也称Microsoft C/C++ 6.0 是一个平庸的（Mediocre）产品。因此就把它
丢在一边。在Microsoft C/C++ 6.0 不久之后，Borland 终于推了Borland C/C++ 3.0.而
这套软体也开启了Borland 雄霸C/C++ 编译器常达5 ，6 年之久的序幕。
Borland C/C++ 3.0 推出之后由于拥有第一个在Window下的稳定的图形整合发展环境，而
且它产生的最佳化程式码也是 Microsoft C/C++ 6.0 望尘莫及的，因此很快的几乎所有的
C/C++ 程式师转而使用 Borland C/C++ 3.0.因此在那个时候有一个现象，那就是几乎所有
的公用程式或是Shareware都是使用Borland C/C++开发的，许多硬体厂商的驱动程式也是
使用Borland C/C++ 3.0 来撰写的。 1992年我取得Georgia Institute Of Technology
的硕士学位之后最想进入的公司便是Borland 和Micro-soft，不过最后我还是决定回台湾
工作。在此时Borland也进入了最巅峰的时期，因为Borland 推出了Borland C/C++ 3.1。
Borland 在 Borland C/C++ 3.0 获得空前的胜利之后，并没有松懈下来，因为 Borland 知
道Borland C/C++ 3.0还缺了一个最重要的胜利因子，那就是如同Microsoft 的 MFC 一样
的 C/C++ 的 Framework ，因为Borland 也看出了Framework 将会是未来 C/C++ 产品中最
重要的一环科技。不过 Borland 此时面临了一个重要的十字路口，那就是到底要自己开发
一个和 MFC 抗衡的 Framework，还是要如何做。 因为如果要自己开发Framework，那么势
必要花上一些时间，但是 Borland想趁 Borland C/C++ 3.0 如虹的气势再下一城，以便彻
底击溃Microsoft C/C++。 因此最后 Borland 决定向一家叫 White Water 的公司购买一
套由这家公司开发的一个 Framework，这套 Framework 便是后来鼎鼎大名的 OWL 的源流。
而 Borland 也因为向 White Water 购买了这套Framework，因而也引进了一个日后非常
重要的人物，那就是后来负责开发Delphi的一员大将 - Zack Urlocker。
在Borland 购买下White Water 的C++ Framework 之后，便更命为OWL（Object Window
Library），并且很快的推出了以OWL 1.0 为核心的Borland C/C++ 3.1。由于OWL比当时
的MFC 1.0 封装的更为完整和好用，再加入Resource Workshop 视觉化能力，以及Borland
C/C++ 3.1 自己最强劲的编译器和整合发展环境，因此立刻的风靡了全世界，其受欢迎的
程度更是远远的超过了它的前一版本Borland C/C++ 3.0。
由于Borland C/C++ 3.1 的畅销，立刻让Borland 在C/C++ 市场一举击溃了 Microsoft
C/C++ ，市场占有率超过了50% ，是全球第一的C/C++ 产品，也把Borland推上了最高峰，
成为全世界第三大的软体公司。
很快的，我所工作的开发小组也立刻的以 Borland C/C++ 3.1 来开发系统，Borland C/C++
3.1 也是我使用过Borland 最稳定的C/C++ 版本之一。也由于那个时候一天到晚都使用
C/C++工作，因此就有了一些小心得。稍后我整理了一些东西便投稿到刚出刊不久的RUN ！
PC，也许是运气不错，RUN ！PC 很快的也登出了我的文章。就是这篇文章登出之后，台湾
的Borland 注意到了我，开始和我连络，并且从此展开了和Borland 的互动。而Borland
C/C++ 3.1 也是第一套Borland 免费送我的软体，当然代价就是希望我多写一些Borland
产品的文章。
接着Borland 又计划推出 Windows 版的 Borland Pascal，不过在 Borland 开发Borland
Pascal For Windows时，当时（现在也还是）最具盛名的Charles Petzold （我的第一本
Windows 程式设计的书就是这位仁兄写的，相信许多人也是看他的书一路学来的）就说除了
C/C++ 之外，Borland不可能做出能够在 Windows下执行的Borland Pascal，不过很明显
的，即使是 Windows API 的大师 Charles 也错了。Borland 不但做出来了，而且Borland
Pascal For Windows 还非常的畅销，当然Borland Pascal For Windows也是后来Delphi
的根基。
当时的Borland 可说是不可一世，不但产品大卖，而且日进斗金。Borland在 Scotts
Valley豪华的总部也是在那个时候由 Philippe Kahn 大手笔的花了一亿多美金搭建的
（想想10年前的60多亿台币可以盖什么样的房子？）。不过也许是 Borland 太成功了，
因此也开始让 Philippe Kahn 渐渐的养成了好大喜功，目中无人的态度，也种下了Borland
开始走向衰退的因子。
不过在 Borland 最强盛的时期，当然也就是Microsoft 最想痛宰Borland 的时候，在这
个时候发生了一个着名的事件和一个着名的虚拟人物。话说由于当时Microsoft 的开发工
具一直打不过Borland 的产品，因此在Microsoft 的开发工具刊物上便出现了一个作者
不断的以文章嘲笑Borland ，这个作者的笔名是 Buck Forland。 后来由于这位作者的文
章内容以及他的笔名引起了当时Borland的不满以及大量Borland使用者的强烈抗议，因
此稍后这位作者就突然的消失不见了。因此有许多人就推测这个作者应该是 Microsoft的
工程师，由于一直无法打败Borland 的产品，脑羞成怒，因此才会以这个笔名来发泄。如
果各位看倌到现在还摸不着头为什么这个笔名会引起轩然大波，那么请你试着把Buck
Foland 这两个英文字的第一个字母一对调就知道为什么了。现在各位是否会心一笑了？
在Borland C/C++ 3.1 大获成功之后，Borland 却开始松懈了下去，并且开始走下坡。
当然这有许多的原因，我所知其中最重要的原因有数项：
■Philippe Kahn 和当时Borland C/C++ 的产品经理闹翻了。这位 BorlandC/C++ 的产
品经理的名字是Eugene Wang ，他是一位非常聪明的中国人。他一手把Borland C/C++
带到了世界第一的地位，并且在Borland C/C++ 3.1 成功之后有了更伟大的想法，那就是
Eugene Wang想在下一个Borland C/C++ 版本中完整的以OWL封装所有的 Windows API，
因为OWL 1。0 虽然比MFC 1。0 来得优秀，但是OWL 的隐忧就是OWL 尚未完整的封装
所有Windows 的API。此外Eugene还计划以OWL 为核心，开发一个类似今日Borland
C/C++ Builder 的以视觉化元件为开发方式的开发工具。请各位想一想，如果在当时
Borland能够开发出这种 C/C++ 开发工具，那么将会是一个多么可怕的产品，稍后
Microsoft 的Visual C/C++ 1.0 只是能够在整合发展环境中自动产生 MFC 的程式码就立
刻的轰动了 C/C++ 市场，造成了大量程式师转入 Microsoft 的阵营。即使是目前的
Borland C/C++ Builder使用的Framework 仍然是以Object Pascal 以核心的元件Framework，
而不是纯粹的C/C++ 程式码。如果当时 Eugene Wang能够做出他心中的下一版Borland
C/C++，那么我想到现在Borland C/C++ 可能还是市场中第一的 C/C++ 开发工具。不过很
不幸的是，Eugene Wang 稍后和 Philippe Kahn 发生了争执，Eugene Wang一气之下离开
了Borland。而 Philippe Kahn 则认为 Borland C/C++ 的地位已不可动摇，因此也没有想
立刻的做下一版的Borland C/C++。这样一拖竟然浪费将近2 年的时间。
Microsoft Visual C/C++ 1。0在Borland C/C++ 3.1 2 年之后推出，并且立刻获得市场好
评。不但在编译器方面能够和Borland C/C++ 3.1 相抗衡，在整合发展环境方面更大幅领
先了Borland C/C++ 3.1，还能够自动产生MFC 的程式码，再也不是昔日的吴下阿蒙。直到
此时 Philippe Kahn 才从梦中惊醒而急于开发下一代的Borland C/C++ 4.0 ，但是为时已
晚，C/C++ 的开发工具市场从此就开始逐渐的被Microsoft 蚕食了。
Eugene Wang 在离开 Borland 之后，立刻的被 Symantec 所网罗，稍后Eugene Wang也在
非常短的时间之内为Symantec开发出了着名的Symantec C/C++。 Symantec C/C++ 在当时
被所有的技术刊物评比为拥有最棒的整合发展环境和最有创意的C/C++ 开发工具，从此可
见Eugene Wang 的功力。不过 Symantec C/C++ 稍后也不敌 Microsoft Visual C/C++，这
个故事的原因在稍后四大C/C++ 编译器之争的段落中再详细的说明。
我最后听说 Eugene Wang 跑去做生意了，并且在前几年写了一本教导科技人员如何面试的
书籍。我一直很痛心Borland 失去了这么一位优秀的人材，我常想如果当初 Eugene Wang
没有离开Borland ，那么历史就可能不是现在的这样了，Sign！！！
■Philippe Kahn 大手笔的花了一亿多美金买下了 Ashton-Tate 公司和dBase。在当时许
多人都批评Philippe Kahn 做了不值得的事情，因为 Ashton-Tate 不值这么多钱。但是由
于当时 Borland 多的是钱，因此Philippe Kahn也不多意。不过这并不是Borland 走向逐
渐走向衰败的主因，而是在 Borland 买下了dBase 之后，并没有立刻积极的发展dBase
For Windows ，反而把dBase 丢在一旁。这个原因便是当时Borland 的另外一个和资料库
有关的产品Paradox 卖得也很好，因此Philippe Kahn 并不急着打算开发dBase For Windows。
不过Philippe Kahn 忘记了一件事情，那就是当时在市场大量人口的dBase 程式师需要一
个好的 Window 版dBase ，但是Philippe Kahn 购买了dBase 却不提供Windows 版的解决
方案。因此当稍后Microsoft 以极小的代价买下Fox 这家公司，并且在数年之后推出 FoxPro
For Window，吸引了大量原先的dBase 程式师以及Paradox 的程式师之后，Philippe Kahn
才警觉事情不对而充充忙忙的开发dBase For Windows。但是当dBase For Windows 推出之
后，Microsoft 早已推出了两个FoxPro For Windows的版本，而占据了大部份的市场，
dBase For Windows 其势已不可为了。
Microsoft 开始向Borland 挖角。由于Microsoft在许多的开发工具战役中一直被Borland
打得灰头土脸。更何况Borland C/C++ 3.1 几乎抢占了大部份的市场，因此Microsoft 开
始准备好好的对付Borland。但是由于其时Borland 在编译器的技术领域领先了Microsoft
数年之久，Microsoft无法在短时间之内赶上Borland，因此 Microsoft 决定使用最有效的
方法立刻追上 Borland 技术，那就是直接挖角。因此稍后Microsoft 的Visual C/C++小组
有60 %的成员是从Borland挖来的，这个举动不但立刻的让Borland 流失了大量的优秀技术人
才，也在数年之后造成了Borland 控告 Microsoft 的导火线。不知道各位看到这里有什么
感觉，或是没有感觉。不过我总是觉得 Microsoft使用了不好的手段来竞争，并不是光明
正大的击败Borland，而是使用了不公平的竞争手段。
Philippe Kahn 在这段时间不但让 Borland C/C++ 被 Microsoft Visual C/C++ 反败为
胜，也痛失了几乎所有dBase 的市场，更浪费了大量的金钱，和流失了大量的优秀人员。
在这些重要的原因之下， Borland已经不可避免的开始走下坡了。
我最后一次看到Philippe Kahn 时是在1994年未于亚特兰大（Atlanta ）参加国际
Conference时，还和他打了一声招呼。后来Philippe Kahn 离开了Borland，另外创立了
StarFish这家公司，稍后StarFish也被Motorola并购。虽然Borland由于Philippe
Kahn 一些错误的决策而逐渐的从巅峰开始下降，但是Philippe Kahn也不愧为一个人物。
因为Philippe Kahn 能够和Bill Gates一直周旋数年之久，而同一时期的许多公司，例如
Lotus 都一一的被 Microsoft所击败，因此 Philippe Kahn 还有一套的。此外 Philippe
Kahn 也是唯一一个拥有工程师特性的 Borland CEO ，Philippe Kahn 仍然重视技术产品
和技术人员。但是Borland 随后的CEO几乎都是Marketing ，Finance 或是Sales出身的
人，这真让我怀念以往以产品和技术为优先的CEO 了。
看完了上面这段今人伤心的历史之后，再让我们看看当Borland 在受到Microsoft Visual
C/C++的强大冲击之后，如果思索反击之道。在这段期间也出现了令我敬佩的第一个
Borland 技术工程师，Carl Quinn。
Carl Quinn在Microsoft Visual C/C++ 1。0推出之后，立刻奉命开发一个能够和MFC
相抗衡的全新OWL，而CarlQuinn也是数年后JBuilder的JBCL Framework的灵魂开发人
物。Carl Quinn 不但负责开发OWL ，也为Borland 在元件Framework 的技术领域立下了
重要的贡献。由于 Carl Quinn 的投入，因此开启了 OWL 大战MFC，Borland C/C++缠斗
Visual C/C++数年精彩好戏的序幕。
Borland C/C++的反击
我的小文《DELPHI探索》写作进度很难控制，其间隔的时间可能比较长， 为了在这段间隔
的时间让大家看当Visual C++ 1.0在C/C++开发工具市场获得了空前成果的之后，Borland
才从Borland C/C++ 3.1的胜利梦中惊醒，思考如何面对Visual C++的猛烈功势。事实上当
时的Borland如果脑袋清醒一点，好好看清当时C/C++开发工具的市场，那么Borland应该
会发现虽然Visual C++经过2年多的整军经武，实力已经大不前。
不过Borland C/C++ 3.1仍然在许多方面可以和Visual C++一争长短的。例如其时Visual
C++的最佳化编译器仍然落后Borland C/C++ 3.1一些，第2点是MFC仍然没有完整的封装
Window API，而且MFC是以较低阶的方式封装Window API，并不是很物件导向，也不是很
容易使用。事实上以我的观点来看，我认为就是因为MFC不好用，因此Visual C++才需要
在整合发展环境中提供以视觉化方式产生MFC程序码的功能，第3是Visual C++ 当时并没
有很好的封装资料结构的Container Class，而Borland C/C++却有非常好用的BIDS类别
库。第4，也是最重要的，Borland C/C++ 3.1仍然拥有绝大的市场，而且几乎所有的周边
公用程序，Shareware等都是使用Borland C/C++ 3.1开发的。因此如果Borland不要急，
好好的开发下一代的C/C++开发工具，即使Microsoft Visual C++能够掠夺一些市场佔有
率，但是如果下一代的Borland C/C++能够像Borland C/C++ 3.0一样立刻拉开和Visual
C/C++的距离，那么Borland在C/C++市场仍将拥有王者的地位。
可惜的是，也许Philippe Kahn在和Microsoft的FoxPro For Window一役中被吓到了，因
此急於在Visual C/C++ 1.0之后立刻推出新的Borland C/C++以扳回颜面。但是Philippe
Kahn忘了，在这段时间之内Borland失去了许多的人材，Eugene Wang也离开了，更重要的
是在过去近3年的时间之内，Borland几乎没有持续的开发下一代的Borland C/C++，在短
时间之内如何能够仓促的推出产品呢?
但是Philippe Kahn可管不了这么多了，急忙找来了Carl Quinn等人便要求立刻开发出下
一代的Borland C/C++，於是Borland C/C++ 4.0就在这么鸭子赶上架下匆忙的开发了。
Borland在开发Borland C/C++ 4.0时犯了许多的大忌。首先在这么短的时间内Borland决
定全新发展整合发展环境，第2是把OWL完全重写，第3是大幅修改最佳化编译器，第4是
整合当时棘手的VBX，Borland居然让16位元和32位元的程序能够同时使用16位元丑陋
的VBX。
上面所说的每一项都是大工程，Borland早应该在Borland C/C++ 3.1之后便开始做这些工作
现在要在短短的一年多的时间内重新开发一个这么複杂的C/C++开发工具，几乎是不可能的
工作。但是在Philippe Kahn的要求之下，这些Borland的工程师还是硬着头皮做了出来。
不过我必须很沈痛的说，当时我在Beta测试Borland C/C++ 4.0时便和台湾Borland的人
说，如果Borland仓促推出Borland C/C++ 4.0的话，那么不但不会对Visual C++产生任
何的影响，反而是自杀的行为，因为臭虫实在太多了，整个整合发展环境的反应也很缓慢，
它的最佳化编译器更是笑话，错误百出，真是像当时恶名昭彰的Microsoft C 4.0一样。我
还开玩笑的说，是不是因为Microsoft从Borland挖了大量的Borland C/C++人才，因此好
胜的Philippe Kahn也还以颜色，从Microsoft反挖Microsoft C的人，却不幸的挖到了
Microsoft C 4.0 的人。
但是很显然的Borland并没有听到我的，或是其他Beta测试人的心声，在Visual C++ 1.0
推出后的1年多，Borland C/C++ 3.1后的4年，Borland终於推出了新一代的Borland
C/++ 4.0，这个肩负和Visual C++ 1.0对抗的C/C++开发工具。
在Borland C/C++ 4.0刚推出之际，Borland确实为4.0做了极大的造势，我记得在当时所
有重要的电脑杂志中，例如Byte，PC Magazine，Dr. Bob等，都有4.0整页的广告。这个
广告的内容是以一个巨大的猫头鹰为主，再搭配蓝色底色系的Borland C/C++ 4.0为主，选
用巨大的猫头鹰当然是因为OWL的原因，只可惜我现在找不到那幅广告了。
当时Borland使用了如下的广告用词 : 『Visual Is Only A Facial Facade』来讽刺Visual
C/C++只提供了产生MFC程序码的基本精灵，而Borland除了也提供相对应的AppExpert精灵
能够提供类似的功能以产生使用者选择的OWL程序码之外，Borland C/C++ 4.0的整合发展
环境还提供了视觉化的3面版视窗，能够让程序师完整的掌握整个专案的情形。
下图则是当时Borland C/C++的註册商标，3面版视窗开发环境。看到下图又令我想起当初
使用C/C++写程序的日子，下方程序码面版清楚的显示了我在1995年於鼎新工作时写的智
慧型Window排程系统，时间过得是真快啊。
(图3 令人怀念的Borland C/C++ 4.0整合发展环境，三面版视窗)
当时Borland C/C++ 4.0的3面版整合发展环境真是开创了一个新的局面，因为这个整合发
展环境允许程序师知道每一个应用程序定义的视窗讯息，并且能够立刻的显示在下方的程序
码视窗中，的确是非常的方便，也比当时Visual C/C++的整合发展环境来得先进。再加入
Borland 较为先进的编译器技术和架构更好的C/C++ Framework-OWL，照理说Borland C/C++
4.0应该会获得极大的胜利，那么为什么最后会以失败收场呢？
没错，在Borland C/C++ 4.0刚推出之后订单的确如雪片般飞来，销售情形非常好，因为这
毕竟是Borland 在睽违了数年之后的大作，许多Borland的用户都迫不及待的昇级，就像当
初我也是拚命的要求台湾Borland要第一个给我Borland C/C++ 4.0。但是在Borland C/C++
4.0推出一段时间之后，市场的反应就急速的冷却下来，因为各种负面的批评不断涌现，这
主要的原因当然是因为Borland C/C++ 4.0的品质实在不好，就像前面我在Beta测试时说的
由於Borland太急於推出4.0，因此并没有在最后阶段修正许多的错误，又没有经过最后系统
微调的工作，又太大胆的加入太多先进的技术，造成了整个产品的不稳定，而造成了大错。
下面几点应该是造成当初Borland C/C++ 4.0滑铁卢的主要原因：
*整合发展环境方面-臭虫太多，容易当掉而且反应速度缓慢
*编译器方面-最佳化玩得过火，产生错误的编译程序码
*OWL方面-採用全新的多重继承架构，虽然是正确的做法，却和Borland C/C++ 3.1中的OWL
不相容，造成许多程序师无法昇级C/C++专案
*VBX方面-大胆的採用在16/32位元都能使用VBX的技术，造成一些VBX无法顺利的在Borland
C/C++ 4.0中使用
我想其中最可惜的就是OWL了，因为OWL 2.0在各方面都有一流的表现，实在是MFC强劲的
竞争对手，OWL 2.0 也获得了各方一致的肯定和称讚。无奈的是由於OWL 2.0做了从基本架
构的改变，这是为了解决当初OWL 1.x使用了不标准的C/C++编译器技术的问题，但是这造
成了原本Borland C/C++程序师极大的困扰，因为昇级不易。对於新的C/C++使用者来说又
因为Borland C/C++ 4.0本身不稳定的因素而却步，因此造成了OWL 2.0叫好不叫座的下场.
真是可惜了OWL小组的努力。
我记得当时我的专案有使用FarPoint的SpreadSheet VBX元件，由於一直无法顺利的在
BorlandC/C++ 4.0中使用，并且会造成应用程序的当掉，最后追踪执行程序码却发现应该
是Borland C/C++ 4.0的问题，因此最后只好在咒骂中放弃使用4.0，而回到Borland C/C++
3.1。我当时想，对於我这个长期使用Borland产品的人都无法忍受4.0的品质，其他的程序
师又怎能使用这个产品。我想这就是为什么后来4.0全面溃败的原因，因为Borland推出了
根本不堪用的产品。
在我於Borland工作的时间，有一次在新加坡和现在Borland开发者关系部门的副总裁David
Intersimone谈起这一段往事，David也很感慨这一段往事，David直呼"We screwed it up!"
"It's a mess".David并且说当时整个Borland C/C++开发小组都很混乱，和以往Borland
C/C++ 3.0/3.1的开发小组比起来实在是差太多了，除了因为一些重要的人物相继离开
Borland，而且Microsoft也挖走一大票人之外，Philippe Kahn的直接介入，造成人事不
和也有很大的原因。
在Borland C/C++ 4.0快速失利之后，Borland也体认到问题的严重性，因此立刻的着手开
发Borland C/++ 4.0的Patch，当时是称为Service Pack。但是在稍后的4.01版中并没有
完全的解决问题，一直要到4.02才稍为解决一些严重的问题，无奈时不我予，拖的时间太
长，市场已经起了巨大的变化。在Borland C/C++ 4.0失利之后，立刻造成了严重的后果，
首先是Borland C/C++的市场大量且快速的流失，让Visual C/C++快速的成长。第二点是当
初Borland C/C++3.1在公用程序市场打下的江山也拱手让人，原本许多硬体厂商也使用
Borland C/C++ 3.0/3.1撰写驱动程序也开始转换到Visual C/C++，而严重的是在应用程序
市场方面由於4.0的品质以及稍后OLE的关系，也开始大量的开始转为使用Visual C/C++
来撰写应用程序。
Borland在3个主要的应用市场接连败退，C/C++的江山注定将易主，其势已不可挽。
Borland C/C++，Visual C/C++，Watcom C/C++和Symantec C/C++的缠斗
自Borland C/C++ 4.0一役大败之后，Borland在C/C++市场上建筑的巨大堡垒似乎再也不是
牢不可破了。Visual C/C++固然在不断的接收BorlandC/C++失去的市场，此时在C/C++市场
上也加入了另外两个坚强的对手，那就是Symantec C/C++和Watcom C/C++。
Symantec C/C++的发展史
说起这两个对手也都是个个来头不小，先说Symantec C/C++吧。它的Think C/C++在
Macintosh上便是非常有名的编译器，因此早在C/C++领域便有深厚的基础。在Symantec并购
了PC上第一个C/C++编译器Zortech C/C++之后，Symantec进入PC的开发工具市场也是箭
在弦上了，只可惜的是其时Symantec还未找到一个在PC上有丰富经验的开发工具领导者。
也许是上天注定要引起稍后的C/C++编译器大战吧，此时Borland C/C++ 3.1的幕后支柱
Eugene Wang刚好和Philippe Kahn闹翻，离开了Borland。Symantec见此时不可失，立刻
重金延揽Eugene Wang到Symantec，为Symantec推出第一个C/C++开发工具。在1993年
左右吧，Symantec C/C++在Eugene Wang的掌舵之下推出了第一个Symantec C/C++版本，
立刻便获得了市场的好评。自此之后Symantec C/C++军心大振，不断的继续改善，也逐
渐的获得了不小的C/C++市场，隐然成为可以对抗Borland C/C++，Visual C/C++的另
一山头。当时Symantec C/C++是以最华丽，先进的整合发展环境获得市场的高度认同，在
C/C++编译器最佳化方面的表现也不会输给其他的编译器。
当时我在RUN!PC上写C/C++的文章，因此Symantec C/C++也有和我连络，并且送给我一套
最高档的Symantec C/C++，希望我除了为Borland写C/C++的文章之外，也能够为Symantec
C/C++写一些东西，我想这就是做为写技术文章的一个好处之一，那就是可以拿到许多最Hot
的开发工具。我还记得在当时安装Symantec C/C++之后，的确被它的整合发展环境吸引
的说不出话来，因为实在是太棒了，Borland C/C++和Visual C/C++的整合发展环境和
Symantec C/C++的整合发展环境比较起来，立刻的就变成索然无味，平凡无奇了，到现在我
仍然必须竖起大拇指对Symantec C/C++的整合发展环境说声『讚』。我想Eugene Wang
在这么短的时间内把Symantec C/C++打造的好此之好，除了证明他的不凡功力之外，也有向
Philippe Kahn示警的意思。证明Philippe Kahn让他离开Borland是错误的决定。我之所以
如此说是因为其时Symantec C/C++最喜欢点名挑战的对象便是Borland C/C++了。对我的
感觉而言，Symantec C/C++就像是一个技艺精良，又装备华丽的C/C++军团。
Watcom C/C++的发展史
真是非常有趣的是，Watcom C/C++走的路子和Symantec C/C++几乎是完全相反的。当时出品
WatcomC/C++编译器的是一家加拿大的小公司，不过这家公司却对最佳化编译器有深入的研
究。当时Watcom C/C++是以在DOS下能够产生最好的最佳化程序码闻名於世的，在其时有许
多写游戏和DOS Extender的厂商都是指名要使用Watcom C/C++，因为不论是Borland C/C++
或是Visual C/C++产生的最佳化程序码都比WatcomC/C++的最佳化程序码差上一截。再加入
当时最有名的DOS Extender 厂商PharLap公司也是使用Watcom C/C++，因此Watcom C/C++
在专业的C/C++程序师以及系统程序师心中是第一品牌的C/C++开发工具。
不知道还有多人记得PharLap这家公司，或是有没有人记得Andrew Schulman这位伟大的软
件技术人员。当时Andrew Schulman的Undocumented Windows一书红遍了半边天，也惹得
Microsoft要告Andrew Schulman。而Andrew Schulman便是PharLap公司的首席工程师，也是
当时最着名的『The ANDREW SCHULMAN Programming Series』的总监，例如当时由Matt
Pietrek撰写的Windows Internals也是轰动一时的巨着。而PharLap公司是当时出版DOS
Extender软件最成功的软件公司。
谈到Matt Pietrek，熟悉Window Programming的人应该很少有不知这位大师级人物的.Matt
长期在Microsoft System Journal撰写Under The Hood专栏，专门写一些深入系统的程序
设计技术，在数年前便和Andrew Schulman，David Maxey成为Widow System Programming
的三大巨头之一。Matt也是着名的Window除错工具SoftIce，BoundsChecker的主要研发工程
师。Matt本身也是从Borland出道的，当Matt初至Borland工作时便是在Turbo Debugger小组
中研发除错工具.当时Bor-land的Turbo Debugger是DOS下最强的除错工具，即使是Microsoft
也无法推出能够和TurboDebugger抗衡的除错工具。Matt在这个小组中吸收了大量的知识，
并且快速的成为这个领域的专家。后来Turbo Debugger小组的部份成员被Microsoft挖走，
让Microsoft掌握了Borland的核心除错技术，以致后来也能够推出不错的除错工具。而Matt
也出走到NuMega公司成为开发SoftIce，Bounds Checker的关键人物。写到这里还是不禁
要佩服Borland，因为当今许多名满天下的重量级软件工程师都是由Borland培养出来的。
在Watcom C/C++於DOS市场佔稳了脚步之后，由於Window已经逐渐成为市场的主流，DOS势必
将被逐渐淘汰出局，因此WatcomC/C++要继续的生存下去，也一定要推出Window平台的C/C++
开发工具。大约也是在1993，1994年左右Watcom终於推出第一个Window的开发工具。不过当
时Watcom C/C++在Window推出的C/C++开发工具实在是平凡不已，其整合发展环境和另外三
个对手比较起来简直像是远古的产品，一点特色都没有，不过Watcom C/C++仍然是以它的
最佳化编译器做为号召。因此在当时发生了一个非常有趣的现象，那就是许多软件公司会同
时买Borland C/C++，或是Visual C/C++，Symantec C/C++之一，再搭配一套Watcom C/C++。
在开发应用系统时使用其他三套开发工具之一，最后要出货时再使用Watcom C/C++来编译
以产生最佳的程序码。
在Watcom C/C++推出了Window平台的开发工具之后，仍然吸引了一群使用者，虽然Watcom
C/C++的市场比起其他的三家来说是最小的，但是也在一方撑起了一片天，成为四大C/C++开
发工具之一。稍后WatcomC/C++被Sybase并购，并且成为后来Sybase的Optima++的前身。
对我的感觉而言，Watcom C/C++就像是一个穿着朴素，但是却拥有最佳训练的白色C/C++军团。
关键的时刻-MFC Or Not 在Symantec C/C++和Watcom C/C++逐渐的站稳了脚步之后，四大
编译器决战的时刻也逐渐逼近了。在1994年未的决战之前，Symantec和Watcom同时面对了一
个非常严厉的考验，那就是C/C++Framework的选择。
虽然Symantec和Watcom都以各自的特色佔得了市场，不过在当时对於一个C/C++开发工具来
说，最重要的因素之一就是C/C++Framework。因此Symantec和Watcom也都必须提供使用者一
套C/C++ Framework。不过这对於Symantec和Watcom都是一个难以解决的问题，因为当时的
C/C++ Framework已由Borland的OWL和Microsoft的MFC所佔领，如果要自己发展新的C/C++
Framework，那么Symantec和Watcom并没有如此雄厚的资源，也无法在短时间之内完成。
因此Symantec和Watcom必须下一个决定到底是要使用MFC或是OWL做为它们的开发工具C/C++
Framework。
在1993年初Symantec和Watcom分别和Microsoft签约License MFC做为它们的开发工具的C/C++
Framework。
至此大势以定，在C/C++Framework的市场已经形成三家夹击一家的形式。当时许多人便预估
Borland将成为输家，因为市场已经成为一面倒，MFC看起来已经是胜券在握了。在当时於
Borland的内部也展开了激烈的辩论，讨论是否也要License MFC做为C/C++的Framework，
停止继续开发OWL。不过后来Borland还是决定继续开发OWL，而不使用MFC，因为Borland的
C/C++技术小组认为MFC不论是在架构上或是设计上都比不上OWL。而且由於Visual C/C++
在当时对於C/C++的标准支援不如Borland C/C++，因此在MFC内部使用了大量的Macro以及
不标准的语法，因此如果Borland C/C++要使用MFC，那么还需要修改编译器来编译MFC。
对於这一点我认为Borland还是做了一个正确的决定，因为如果当时Borland也License MFC，
那么不但在气势上便输了一截，而且当MFC的发展是完全掌握在Microsoft的手里，那么就等
於脖子是掐在别人的手里，动弹不得了。可惜的是Symantec和Watcom并没有看清这一点，以
为有了和Microsoft一样的Framework，就可以在其他地方和Micro-soft以及Borland一
决雌雄，Symantec和Watcom却没有想就是这一点决定让后来的决战一败涂地，终究完全出
PC的C/C++开发工具市场。
时序到了1994年未，C/C++开发工具的四大天王决战的日子终於愈来愈近了。
OLE的搅局
-李维
不知道是时运不济或是Microsoft的刻意如此，在1994年Borland C/C++和Visual
C/C++决战的前夕，Microsoft推出了OLE(Object Linking And Embedding)技术。
OLE是Microsoft为了对抗Apple的文件技术以及IBM OS2的Workplace和文件技术应
运而生的。OLE可以让Window平台的文件能够内嵌在不同的应用程序中并且能够让
文件在应用程序中被即地编辑(In-Place Editing)。说实在的，Microsoft的OLE和
Apple以及IBM的技术比较起来实在是差多了，OLE在稍后也被证明是失败的技术，
不过不管是Microsoft的OLE或是Apple/IBM的文件技术也都是失败的技术，都没有
造成巨大的成功。虽然这些文件技术都没有成功，但是OLE却足以成为Borland，
Symantec和Watcom失败的重要因素。
我还记得当时OLE似乎成为了一个令人趋之若鹜的时髦功能，因为Word的文件能够
内嵌在Excel之中，并且可以点选此Word文件，应用程序又立刻成为Word来编辑它
，实在是令人觉得非常的神奇。不过在其时所有的软件厂商中只有Microsoft的应
用程序有如此的功能，其它的厂商例如Lotus，WordPerfect等都无法实作出这种功
能。这造成了不公平的竞争，因为OLE技术是由操作系统厂商Microsoft推出的，但
是却让它的应用程序部门同步拥有这种技术，而其它的软件厂商都无法获得第一手
的OLE技术来实作，这是为什么当时其它的软件厂商如此火大的原因。
虽然后来其它的软件公司在取得了OLE的技术信息之后也推出了具备OLE功能的应用
程序，但是毕竟是慢了Microsoft许久，市场也流失了许多。不过我也很奇怪的是
在当时内建OLE功能的应用程序之中，几乎所有的软件厂商推出的应用程序在激活
数个应用程序而且使用OLE之后，就非常容易的当掉，只有Microsoft的应用程序不
太会发生这种情形，因此许多人便认为Microsoft有隐瞒一些技术没有让其它的厂
商知道。
由于OLE是如此的复杂，因此Borland无法立刻在OWL之中实作出这种功能，于是就
造成了市场上负面的影响。至于Symantec和Watcom虽然是License MFC，但是在其
时它们License的是MFC 1.x的版本，Microsoft并没有把OLE实作在MFC 1.x中，而
是在实作在MFC 2.0之中。在MFC 2.0推出时最重要的功能就是Microsoft加入了
20000多行支持OLE的程序代码，但是MFC 2.0却仅限于Visual C/C++使用，就是这
关键的一点让其它三家厂商吃了亏。
对于OLE这个关键技术的影响，Borland是深知在心的，因此在计划在Borland
C/C++ 4.5的OWL 2.5中支持OLE。当时Borland推出的解决方案便是OCF(Object
Component Framework)。
Borland当初在设计OCF时有几个重大的目标。这些目标包括了: 一、如何能够使得
OLE琐碎 、复杂的接口能够单纯化; 第二、如何能够使得OLE在窗口环境下写程序
的思考方式 一致化--即使用「事件驱动」的方法。第三、如何能够在微软占尽天
时、地利(未必人和) 的情况下使得Borland的产品具备OLE的功能。第四、如何能
够让大多数C++的程序员都能够享受OLE的功能而不局限于OWL的程序员。由于上述
的设计目标, 而造就了典雅而具有弹 性的OCF。由于OCF本身是一完整而独立的
Framework, 因此它可适用于各种应用程序发展Framework。
不晓得各位使用过Borland C/C++的朋友们是否还依稀记得下图OCF的架构图之一，
以及下面的OCF范例程序代码，这些可是我把1994年写的文章挖出来之后找到的，
真是令我感慨，也回想起了当时的情景，也让各位回忆一下OWL和OCF。对于不熟悉
OWL和OCF的朋友，也可以从下图和程序代码中观察一下当时的技术以及设计的概念。
基本上我现在看这些图形架构，会发现它们并没有落后现在太多，可见当时设计
者的功力(Carl Quinn Again)。
//
// Insert an OLE object into the view
//
void TOleWindow::CmEditInsertObject()
{
001 PRECONDITION(OcView);
002 TOcInitInfo initInfo(OcView);
003 if (OcApp->Browse(initInfo)) {
004 TRect rect;
005 GetInsertPosition(rect);
006 SetSelection(new TOcPart(*GetOcDoc(), initInfo, rect));
007 OcView->Rename();
008 InvalidatePart(invView);
}
}
程序1 OWL的TOleWindow支持OLE插入对象之成员函数
//
// Handle left double-click message
//
void TOleWindow::EvLButtonDblClk(uint modKeys, TPoint& point)
{
PRECONDITION(GetOcDoc() && GetOcView());
TOleClientDC dc(*this);
dc.DPtoLP(&point);
TOcPart* p = GetOcDoc()->GetParts().Locate(point);
if (modKeys & MK_CONTROL) {
if (p)
p->Open(true); // Ctrl key forces open editing
}
else {
SetSelection(p);
if (p && p == GetOcView()->GetActivePart()) { // resync the active flag
p->Activate(false);
}
GetOcView()->ActivatePart(p); // In-place activation
}
}
程序2 OWL的TOleWindow支持左键双击之成员函数
虽然Borland及时的在OWL 2.5中加入了OLE的支持，无奈Microsoft随后又在OLE中
加入了许多其它的功能，因此让OCF并无法完整的支持OLE所有的功能，Borland无法不断
的延后Borland C/C++的推出，因此在1994年未，Borland终于推出了决战的4.5版本。
C/C++开发工具的最后圣战
『虽然已经过去了许久的时间，但是我仍然忘不了那场最惨烈的战役!』1994年未, 1995初
Borland在痛定思痛之后，终于清除了Borland C/C++ 4.0中所有的问题，也开发出了自
Borland C/C++ 3.1以来最稳定，最快速的Borland C/C++ 4.5的版本，准备和Microsoft
决一死战。我还记得当时在书籍市场中许多有关Borland C/C++和Microsoft C/C++的书籍
都是使用十字军的封面，而Borland C/C++的系列丛书都是以蓝色为色系，而Microsoft的
则是以红色为色系，仿佛两大军团终将决战似的。
C/C++四大天王决战一役的Borland主将-Borland C/++ 4.5不过这次的战役不光是Borland
的蓝军和Microsoft的红军相对抗，在Symantec的华丽军团经过了经军经武，Watcom的白
色劲旅枕戈待旦，而且都从Microsoft License了MFC之后，蓝，红，花，白四大军团决战
的日子终于到了。首先当Symantec和Watcom分别取得了MFC之后，Symantec便推出了C/C++
7.x的版本，和Watcom C/C++混战了起来。两个使用系出同门的C/C++ Framework产品战得
不亦乐乎，随后Borland C/C++ 4.5和Visual C/C++的新版本也加入了这场最重要的决战。
但是让Symantec和Watcom C/C++大吃一惊的是Microsoft使用的MFC居然比它们的版本高
出了一个版本(1.x对2.x)，而且新版本的MFC包含了完整的OLE支持能力。而Borland虽
然也有OCF，但是仍然不敌新版MFC中的OLE能力。由于当时几乎所有的应用程序都需要支
持OLE，但是却只有使用Visual C/C++最新的版本才能够开发完整OLE能力的应用程序，因
此不管OLE到底有没有用，反正先加入再说。因此市场上的情势很快的就发生了巨大的变化，
几乎大部份的应用程序开发因为OLE的原因都选择使用Visual C/C++，Symantec和Watcom
军团很快的就败阵下来。
至于Borland C/C++ 4.5虽然是一流的产品，如果没有OLE的因素，Visual C/C++新
版本真的并没有比4.5好。虽然4.5也有OCF，但是在市场上只有Borland和Novell，
WordPerfect选择使用OCF，在和Microsoft的Visual C/C++经过将近一年的缠斗之
后，其它大部份的厂商都选择了Microsoft的MFC 2.x版，真是形势比人强。基本上
OCF的架构真的是个好东西，只是OCF无法完整的支持OLE，因为OLE的发展是掌握在
Microsoft手中，因此虽然OCF的架构良好，终究在功能上不及对手。Microsoft结
合操作系统，开发工具和应用程序的手段真是无往不利。击败Lotus，Borland是如
此，歼灭Netscape也是如此。
对于Symantec和Watcom来说，这场战役就如同『长平之战』，秦军坑杀40多万赵军
一样。杀得Symantec和Watcom全军覆没，大败而归，至此Symantec弃受PC的C/C++
开发工具市场，转而开始研发Java开发工具，进而在稍后推出了著名的Visual Cafe, 至
于Eugene Wang则离开了Symantec，自此也离开了PC开发工具的领域。 而Watcom则是更
为凄惨，整个公司在DOS的市场逐渐式微，而Window平台的开发工具又大败而归，两头落
空。不久之后Watcom便被新兴而起的Sybase并购，从此消失于竞争激烈的市场。
归纳Symantec和Watcom失败的原因是C/C++的Framework MFC掌握在Microsoft手中，
在决战时刻Microsoft居然手握比Symantec和Watcom更新的MFC利器，而且在Visual
C/C++精进最佳化的技术并且改善整合发展环境之后，Symantec和Watcom诉求的重点功能
完全被Microsoft封死。因此在产品，技术，市场和气势上完全不如对手的情形下，自然只
能任人宰割了。
对于Borland而言，虽然没有像Symantec和Watcom那么溃不成军，但也是再次败下阵来。
虽然平心而论Borland C/C++ 4.5的确是一个非常好的产品，无论在OWL，最佳化编译器，
整合发展环境方面都有一流的表现，和Borland C/C++ 4.0比较起来简直有如脱胎换骨一
般，到现在Borland C/C++ 4.5仍然是我最喜欢的版本之一。但是无奈当初Borland C/C++
4.0给人挥之不去的负面印象，以及无法完整支持当时如火如荼的OLE技术，因此还是在
决战之中败了下来。好在蓝色的Borland大军毕竟是训练有素的，虽然自此让Microsoft占
据了超过50%的市场，成为C/C++开发工具的老大，但是Borland仍然掌握了超过30%的市场，
稍做喘息，并且支撑Borland 在各重要战役失败之后维持公司的运作，等待Delphi的浴火
重生，再重新出发。
经过这一役之后，Microsoft终于清除了大部份的对手，对于Microsoft而言程序语言开发
工具的战争已经结束，这个市场注定将被Microsoft占据大部份的市场。在Microsoft手握
操作系统，Office软件和开发工具三大获利市场之后，Microsoft也开始将矛头对准下两个
竞争目标，关连数据库以及主从架构开发工具。在Microsoft正式进军这两个市场之后，当
然也展开了连番的好戏，尤其是在主从架构开发工具方面又开启了VB，PowerBuilder，
Gupta/Centura和Delphi的惊天动地大会战。另外一个意外开启的战争则是Microsoft在
1995年和Netscape的挑起的浏览器大战。
对于Borland而言，在C/C++最后一役之后，基本上我认为开发工具的圣战已然结束，Borland
也正式开始走下坡。更严重的是我认为自此之后Borland不但丧失了C/C++的江山，也失去
了对于C/C++开发工具的创意，这是我感觉最遗憾的地方，到现在为止我仍然认为Borland
尚未重拾当初在Borland C/C++ 3.0/3.1时代独领C/C++创意风骚的精神。也许，也许，要
看看C/C++ For Kylix或是C++ Builder 6是否能够重新找回这个失去已久的精神，不要再
让我失望了。
雄霸数年的C/C++的世界冠军-Borland C/C++ 3.1-永远的怀念
永不成气候的C/C++开发工具-IBM Visual C/C++
IBM在C/C++开发工具扮演的角色一直令人啼笑皆非，因为在C/C++编译器战争最激烈的时
刻，IBM这个全球信息大厂却一直是缺席的。一直到了1995之后，C/C++编译器市场大势已
定之后才慢慢的加入战局，推出VisualAge C++ 3.0，企图进攻此市场。但是此时市场早已
由Microsoft的Visual C/C++称雄。IBM的VisualAge虽然以创新的可视化设计家能够定义
对象之间的关系，但是在其它方面却乏善可陈，整个整合发展环境也缓慢如蜗牛，需要非常
高文件的硬件配备才能够顺利的执行，和Visual C/C++以及Borland C/C++等工具比较起来
就像是恐龙一般，因此几乎没有在市场上引起任何的反应。
在IBM推出VisualAge 3.0并没有在PC的C/C++开发工具市场获得任何的明显成果之
后，IBM又再次的集中了许多的资源，开发下一代3.5的版本，希望能够在此市场占
有一定的比率。我知道IBM在VisualAge投注了大量的资源，因为从Beta版开始台湾
的IBM便有人和我接触，希望我也在RUN!PC上为VisualAge 3.5写一些文章。因此在
1996年的6月我写了一篇C/C++编译器的比较文章，下面的资料便是数年前当时还在
Beta版的VisualAge 3.5和其它编译器的比较：
从上面的数据中可以看到其实VisualAge 3.5的表现还不错，只是对于当时还在使用AMD
DX4-100/32M RAM机器的我来说，实在是跑不太动VisualAge 3.5。后来台湾IBM负责
VisualAge的产品经理请我吃饭，在此饭局中这位李经理同时请了贺元(后来为资迅人的总
裁)，薛晓岚(后来为资迅人的副总裁)以及其它两位作者，希望大家在计算机杂志中继续的
为VisualAge 3.5写写东西，一起Promote此产品。在这个饭局中我是第一次和贺元，薛晓
岚见面，当时贺元在中文PC Magazine有一技术专栏。记得当时我向这位李经理提起我的机
器几乎无法跑VisualAge 3.5，他还立刻一口答应愿意借我一台当时IBM最高檔的PC，同时
每写一篇VisualAge的文章，除了RUN!PC原本的稿费之外，IBM会再付一字2.5元的稿费.
乖乖，IBM真是大手笔，我算算当时我的产能，写一篇文章就能够赚2到3万，又有免费的
最高档机器可用，真是太好康了。不过后来我还是觉得IBM在此市场可能不会深耕，在不愿
意违背自己写作习惯和得罪Borland的顾虑下，最后还是没有答应。现在想想当时真是太笨
了，放着好赚的稿费不赚，嘻。
IBM的C/C++开发工具之所以在市场无法成功是一是因为并不了解在此竞争激烈的市场中使
用者到底要什么。另外一个原因则因为IBM并不以PC上的开发工具软件为重要的事业，即
使无法竞争对于IBM来说也没有什么影响，不像Borland这可是生命之争。因此IBM只是兴
起玩玩，随即放下。所以我觉得在PC平台使用IBM的工具是很危险的，因为IBM可能随时
会放弃此市场。例如不知道现在VisualAge C/C++到底如何，是不是还在3.5或是4.0版，
已经数年没有任何的维护和改善了。
稍后IBM为了想在OS2和Window平台上推出能够和Microsoft相抗衡的Basic工具，因
此秘密的研发了一个Object Basic。我也曾看过这个工具，但是Object Basic跑起来慢得
跟乌龟一样．后来不知道是不是一直无法改善这个问题，因此IBM从没有推出此产品，现在
IBM似乎只对Java有兴趣，VisualAge For Java还算发展的不错，希望不会有一天IBM对
VisualAge For Java的态度会和VisuaAge For C/C++以及Object Basic一样才好．
快速殒落的潜力之星－Sybase的C/C++ RAD工具Optima++
在1996年吧，Sybase并购了Watcom之后，终于推出了石破天惊的C/C++开发工具，Optima++。
Optima++是当结合了Watcom的最佳化编译器以及类似Delphi的组件拖曳开发环境的第一个
RAD C/C++开发工具，更棒的是Optima++的组件架构(类似Delphi的VCL)完全是以纯正的
C/C++程序代码撰写的。这可不得了，因为这代表Optima++是一个融合了Visual C/C++和
Delphi两大王者开发工具为一身的超级赛亚人工具。
在我知道这个工具，并且取得实际的使用之后，令我极为震惊。因为这个工具对于我这个使
用了C/C++ 5,6年的人来说，是比Delphi还具有吸引力。因此在当年我立刻的在RUN!PC上
介绍了此不可置信的工具。果然，Optima++很快在开始风卷市场，虽然没有立刻的占据很大
的市场量，但是已经造成了一股气势，开始为VisualC/C++和Delphi带来了压力。
我记得当时台湾Sybase办的产品发表会也吸引了数百人与会，不可一世。在我的RUN!PC文
章出版之后，台湾的Sybase立刻和我连络。由当时的余协理和我见面，也是希望我继续为
Optima++写文章，台湾Sybase也提供额外一字加2元稿费的待遇。但是我告诉余协理，
Optima++ 1.0虽然很棒，但是仍然有一些臭虫，而且和中文环境相冲突，无法处理中文，
需要立刻的解决问题才能够在台湾的市场成功。她答应我立刻的向总公司反应。我也老实的
告诉她在问题没有解决之前我无法写一些不确实的东西。后来台湾Borland的总经理方先生
也找我去询问有关Optima++的事情，我告诉他Optima++是好东西，但是中文有问题。如果
中文问题能够解决，那么将对Borland的产品有很大的影响，当时我还不知道Borland由于
Optima++的影响，已经开始准备发展C++ Builder。
在1996年底左右吧，Optima++ 1.5终于进入Beta的阶段，但是在我拿到Beta版时仍
然非常的失望，因为中文的问题仍然没有解决。后来台湾Sybase又找我去，这次和
我见面的是台湾Sybase总经理郭俊男先生，以及Sybase的新加坡技术总裁，不过我
忘记这位先生的名字了。我们见了面之后，我立刻的把Optima++ 1.5中文的问题以
及许多的臭虫告诉他们，希望他们能够解决，如此Optima++ 1.5才能够在中文市场
成功。可是出乎意我意料的是，他们似乎并不急着这些问题，反而询问我是否有意
愿为Sybase工作，做PowerBuilder的产品经理。
也许是因为我为Delphi写了太多的东西，让PowerBuilder受了很大的影响，因此他
们希望我到Sybase工作，以打击Delphi并且Promote PowerBuilder。当时他们提出
的待遇条件实在是非常，非常的诱人，比我当时的薪水高出一倍左右（我当时在资
策会工作）。不过由于我对PowerBuilder实在没有什么兴趣，因此我告诉他们如果
是做Optima++的产品经理，那么我将会考虑并且接受。
没有想到Sybase的新加坡技术总裁告诉我Optima++在1.5推出之后就可能会停止，
因为Sybase要把资源移去为当时愈来愈红的Java研发一个新的Java RAD开发工具，
那就是后来的PowerJ。于是他问我如果不愿意做PowerBuilder的产品经理，那么是
不是愿意做PowerJ的产品经理？由于当时我已经知道Borland开始了Open
JBuilder的研发，而我对Open JBuilder的兴趣远大于PowerJ，因此并没有答应
Sybase。果然，在Optima++ 1.5推出之后，不但中文的问题没有解决，Sybase也没
有继续的对Optima++研发下去。
一个如此有潜力的产品就这样消失了，真是令人遗憾，Optima++应该有很好的机会
可以成功的，我相信如果当时Sybase知道C++ Builder后来的成果，可能就不会放
弃Optima++了。而C/C++的RAD工具一直要到后来的C++ Builder来完成这个梦，又
是Borland成功的进入这个工具市场。
C/C++的开发工具之争到此算是告一段落了，虽然后来Borland继续推出了Borland C/C++
5.0但是品质仍然不够好，市场反应也不佳，后来Borland终于在Borland C/C++ 5.02之
后宣布停止此条产品线的开发，Borland C/C++的光荣历史也就从此打止，真是令人不胜感
叹，而Visual C/C++从此在C/C++开发工具市场中再也没有对手。不过没有竞争的市场的确
会让人松懈的，后来的Visual C/C++进步的幅度愈来愈小，MFC也数年没有什么大进步，不
像当时和Borland C/C++竞争时每一个版本都有大幅的改善。看来寡占的市场的确是不好的。