偶爾看到這篇文章，引起了很多回憶。記得自己第一個在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++競爭時每一個版本都有大幅的改善。看來寡佔的市場的確是不好的。
