最佳化程序代码差上一截。再加上当时最有名的DOS Extender厂商PharLap公司也是
使用Wat C/C＋＋，因此Wat C/C＋＋在专业的C/C＋＋程序员以及系统程序员心中是
第一品牌的C/C＋＋开发工具。
不知道还有多少读者记得PharLap这家公司，或是有没有读者记得Andrew Schulman这
位伟大的软件技术人员。当时Andrew Schulman的Undocumented Windows一书红遍了
半边天，也惹得Microsoft要告Andrew Schulman。而Andrew Schulman便是PharLap公
司的首席工程师，也是当时最著名的〃The ANDREW SCHULMAN Programming Series〃的
总监。而PharLap公司是当时出版DOS Extender软件最成功的软件公司。
当时由Matt Pietrek撰写的Windows Internals也是轰动一时的巨著。谈到Matt
Pietrek，熟悉Windows Programming的读者应该很少有不知这位大师级人物的。Matt
长期在Microsoft System Journal撰写Under The Hood专栏，专门写一些深入系统的
程序设计技术，在数年前便和Andrew Schulman、David Maxey成为Windows System
Programming的三大巨头之一。Matt也是著名的Windows除错工具SoftIce、
BoundsChecker的主要研发工程师。Matt本身是从Borland出道的，他初至Borland工作
时便是在Turbo Debugger小组中研发除错工具。当时Borland的Turbo Debugger是DOS
下最强的除错工具，即使是Microsoft也无法推出能够和Turbo Debugger抗衡的除错工
具。Matt在这个小组中吸收了大量的知识，并且快速成为这个领域的专家。后来Turbo
Debugger小组的部分成员被Microsoft挖走，让Microsoft掌握了Borland的核心除错技
术，以致后来也能够推出不错的除错工具。而Matt也出走到NuMega公司，成为开发
SoftIce、Bounds Checker的关键人物。
写到这里还是不禁要佩服Borland，因为当今许多名满天下的重量级软件工程师都是
由Borland培养出来的。
Wat C/C＋＋在DOS市场站稳了脚跟之后，由于Windows已经逐渐成为市场的主流，DOS
势必将被逐渐淘汰出局，因此，Wat C/C＋＋如果要继续生存下去，也就…定要推出
Windows平台的C/C＋＋开发工具。大约是在1993、1994年左右，Wat终于推出第一个
Windows下的C/C＋＋开发工具。
不过，当时Wat C/C＋＋在Windows推出的C/C＋＋开发工具实在是平淡无奇。其集成开
发环境和另外三个对手比较起来简直像是远古的产品，…点特色都没有。不过Wat
C/C＋＋仍然是以它的最佳化编译器作为号召。因此当时发生了一个非常有趣的现象，
那就是许多软件公司会同时买Borland C/C＋＋，或是Visual C/C＋＋，Symantec C/C＋＋
之一，再搭配一套Wat C/C＋＋。在开发应用系统时使用其他三套开发工具之一，最
后要出货时再使用Wat C/C＋＋来编译以产生最佳的程序代码。
在Wat C/C＋＋推出了Windows平台的开发工具之后，也吸引了…群使用者。虽然Wat
C/C＋＋的市场比起其他的三家来说是最小的，但是总算撑起了一片天，成为四大C/C＋＋
开发工具之一。稍后Wat C/C＋＋被Sybase并购，成为Sybase Optima＋＋的前身。
对我的感觉而言，Wat C/C＋＋就像是一个穿着朴素、但是却拥有最佳训练的白色
C/C＋＋军团。
关键的时刻MFC Or Not
在Symantec C/C＋＋和Wat C/C＋＋逐渐站稳了脚跟之后，C/C＋＋四大编译器决战的时
刻也逐渐逼近了，一些其他出产C/C＋＋工具的软件公司早已自动退出了这个在当时竞
争最为激烈的软件市场。在1994年末的决战之前，Symantec和Wat同时面对了一个
非常严厉的考验，那就是C/C＋＋ Framework的选择。
虽然Symantec和Wat都以各自的特色占得了一定的市场，不过在当时对于一个C/C＋＋
开发工具来说，最重要的功能之一就是C/C＋＋ Framework。因此Symantec和Wat
也都必须为使用者提供一套C/C＋＋ Framework。不过这对于Symantec和Wat来说都
是一个难以解决的问题，因为当时的C/C＋＋ Framework已由Borland的OWL和Microsoft
的MFC所占领，虽然市场上也存在一些跨平台的C/C＋＋ Framework，例如ZApp和Zinc等，
但是这些C/C＋＋ Framework终究没有产生很大的影响。如果Symantec和Wat要自
己发展新的C/C＋＋ Framework，那他们还没有如此雄厚的资源，也无法在短时间之内
完成。因此Symantec和Wat必须决定，到底是要使用Microsoft的MFC还是使用Borland
的OWL来作为他们开发工具的C/C＋＋ Framework。
1993年初，Symantec和Wat分别和Microsoft签约授权使用MFC作为他们的开发工具
的C/C＋＋ Framework，至此大局已定，在C/C＋＋ Framework的市场已经形成三家夹击一
家的形势。当时许多人便预测Borland会成为输家，因为市场已经成为一面倒的现象，
MFC看起来已经是胜券在握了。当时，Borland的内部也展开了激烈的辩论，讨论是
否也要授权使用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，那么还需要修改Borland的C/C＋＋编译器来编译MFC。
对于这一点，我认为Borland是做了一个正确的决定。因为，如果当时Borland也授权
使用MFC，那么不但在气势上输了一截，而且，由于MFC的发展完全掌握在Microsoft
的手里，采用MFC就等于脖子被掐在别人的手里，动弹不得。可惜的是Symantec和Wat
并没有看清这一点，以为有了和Microsoft一样的Framework，就可以在其他地方和
Microsoft以及Borland一决雌雄，Symantec和Wat却没有想到，就是这一点决定让
自己在后来的决战中一败涂地，最终完全退出了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可以让Windows平台的文件内嵌在不同的应用程序中，并且能够让文件在应用
程序中被即地编辑（In Place Editing）。说实在的，Microsoft的OLE和Apple以及IBM
的技术比较起来实在是差多了，在稍后也被证明是失败的技术。不过，Microsoft的OLE
和Apple/IBM的文件技术都是失败的技术，都没有造成巨大的成功。虽然这些文件技
术都没有成功，但是OLE却足以成为Borland、Symantec和Wat失败的重要因素。
我记得当时OLE似乎成为了一个令人趋之若鹜的时髦功能。Word的文件能够内嵌在Excel
之中，而且使用者可以点选此Word文件，应用程序又立刻成为Word来编辑它，实在令
人觉得非常的神奇。不过，在其时所有的软件厂商中，只有Microsoft的应用程序有
如此的功能，其他的厂商例如Lotus、WordPerfect等都无法实现这种功能。
这明显地造成了不公平的竞争，因为OLE技术是由操作系统厂商Microsoft推出的，但
是却让它的应用程序部门同步拥有这种技术，而其他的软件厂商都无法获得第一手的
OLE技术来编写应用程序，这也是为什么当时其他的软件厂商如此火大的原因。
虽然后来其他的软件公司在取得了OLE的技术资料之后，也推出了具备OLE功能的应用
程序，但毕竟是慢了Microsoft许久，市场也流失了许多。不过，我觉得很奇怪的是，
在当时内建OLE功能的应用程序之中，几乎所有软件厂商推出的应用程序在激活数
个应用程序而且使用OLE之后，就非常容易死机，只有Microsoft的应用程序不太会发
生这种情形，因此许多人便认为Microsoft隐瞒了一些技术没有让其他的厂商知道。
由于OLE是如此的复杂，因此Borland无法立刻在OWL之中实现这种功能，于是就造成
厂市场上负面的影响。至于Symantec和Wat虽然授权使用MFC，但是在其时它们授
权使用的是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的OWL2。5中支持OLE。当时Borland推出的对应解决方案便是OCF（Object ponent
Framework）。
Borland当初在设计OCF时有几个重大的目标，这些目标包括：第一、如何使OLE琐碎、
复杂的接口单纯化。第二、如何使OLE在窗口环境下写程序的思考方式一致化即
使用〃事件驱动〃的方式来开发。第三、如何在微软占尽天时、地利（但未必人和）的情
况下使Borland的产品具备OLE的功能。第四、如何让大多数C/C＋＋的程序员都能够享
受OLE的功能而不局限于OWL。由于上述的设计目标，从而造就了典雅而具有弹性的
OCF。由于OCF本身是一完整而独立的Framework，因此它可适用于各种C/C＋＋
Framework之中，包含了OWL、MFC以及ZApp/Zinc等Framework。
不知道各位使用过Borland C/C＋＋的朋友们是否还依稀记得下图所示的OCF架构图之一，
以及下面的OCF范例程序代码？这些可是我把1994年写的文章挖出来之后找到的，
真是令我感慨，不禁回想起了当时的情景，在此也让各位回忆一下OWL和OCF。对于不
熟悉OWL和OCF的朋友，也可以从下图和程序代码中观察一下当时的技术以及设计的概
念。我现在看这些图形架构，会发现基本上它们并没有落后现在太多，可见当时设计
者的功力（当然又是Carl Quinn定义的佳作之一）。
程序1 OWL的TOleWindow支持OLE插入对象的成员函数
//
// 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）；
｝
｝
程序2 OWL的TOleWindow支持左键双击的成员函数
//
// Handle left double…click message
//
void TOleWindow：：EvLButtonDblClk（uint modKeys； TPoint& point）
｛
PRECONDITION（GetOcDoc（） && GetOcView（））；
TOleClientDC dc（*this）；
dc。DPtoLP（&point）；