李维：C++圣战

李维：C++圣战 Borland C/C++的反擊

當Microsoft 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 C/C++ 4.0

當時Borland使用了如下的廣告用詞 :

『Visual Is Only A Facial Facade』

來諷刺Visual C/C++只提供了產生MFC程式碼的基本精靈，而Borland除了也提供相對應的AppExpert精靈能夠提供類似的功能以產生使用者選擇的OWL程式碼之外，Borland C/C++ 4.0的整合發展環境還提供了視覺化的3面版視窗，能夠讓程式師完整的掌握整個專案的情形。

例如在下圖中便是當初令人眼睛為之一亮的AppExpert：

還記得Borland提供的AppExpert嗎?

下圖則是當時Borland C/C++的註冊商標，3面版視窗開發環境。看到下圖又令我想起當初使用C/C++寫程式的日子，下方程式碼面版清楚的顯示了我在1995年於鼎新工作時寫的智慧型Window排程系統，時間過得是真快啊。

令人懷念的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元件，由於一直無法順利的在Borland C/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的直接介入，造成人事不和也有很大的原因。

David I.說『We Screwed it up!』，『It’s a mess』

在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++固然在不斷的接收Borland C/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++幾乎是完全相反的。當時出品Watcom C/C++編譯器的是一家加拿大的小公司，不過這家公司卻對最佳化編譯器有深入的研究。當時Watcom C/C++是以在DOS下能夠產生最好的最佳化程式碼聞名於世的，在其時有許多寫遊戲和DOS Extender的廠商都是指名要使用Watcom C/C++，因為不論是Borland C/C++或是Visual C/C++產生的最佳化程式碼都比Watcom C/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小組中研發除錯工具。當時Borland的Turbo Debugger是DOS下最強的除錯工具，即使是Microsoft也無法推出能夠和Turbo Debugger抗衡的除錯工具。Matt在這個小組中吸收了大量的知識，並且快速的成為這個領域的專家。後來Turbo Debugger小組的部份成員被Microsoft挖走，讓Microsoft掌握了Borland的核心除錯技術，以致後來也能夠推出不錯的除錯工具。而Matt也出走到NuMega公司成為開發SoftIce，Bounds Checker的關鍵人物。寫到這裡還是不禁要佩服Borland，因為當今許多名滿天下的重量級軟體工程師都是由Borland培養出來的。

在Watcom C/C++於DOS市場佔穩了腳步之後，由於Window已經逐漸成為市場的主流，DOS勢必將被逐漸淘汰出局，因此Watcom C/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++開發工具之一。稍後Watcom C/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，就可以在其他地方和Microsoft以及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 VisualAge 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++很快在開始風捲市場，雖然沒有立刻的佔據很大的市場量，但是已經造成了一股氣勢，開始為Visual C/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++競爭時每一個版本都有大幅的改善。看來寡佔的市場的確是不好的。

As Promised-李維

Edited by - Gordon Li on 11/01/2001 18:53:06