Vikings

李维-我的回忆和有趣的故事

文章出处：台湾“深度历险”BBS论坛

                               《我的回忆和有趣的故事》
　　　　　　　                   
　　　　　　　                      李维（台湾）

   聲明  
  以下的這篇文章內容是我個人的回憶以及看法，沒有任何特別的偏見，許多的事情是根據我的記憶以及從許多人的訴說中得知的，也許內容不是百分之百的正確，不過我想這些內容有一定的可信度到是可以保證的。當然有一些事情確定的發生時間和順序不一定都和我的記憶一致，不過我想大部份應該是相去不遠的。當然各位如果知道確定的事件而我的記憶有誤，那麼我將非常歡迎您糾正我，我希望這些故事的經歷能夠一直陪我走下去，謝謝。  
   
  一直想寫一篇我個人在過去10多年來工作中經歷的一些事情，以及看著一些我認為是偉大的工程師在這些日子中對於資訊界的貢獻。如果你和我的年齡差不多，那麼你可能會對於這些內容很有興趣，因為它們說明了當時許多軟體的興起和沒落的過程以及原因。雖然這些事情已經距離我們很遙遠了，但是我相信許多人仍然對於背後的故事有興趣。如果你沒有經歷過那段美好的回憶，那麼就把這些內容當成是一個有趣的故事來看吧。但是我想更重要的是讓我們一起認識一些偉大的人物，我對於其中的許多人都非常的佩服，也非常的羨慕。我常常在想，如果我也有他們的環境，我是不是也能夠和他們一樣這麼有成就呢?這些人對於以往都有重要的貢獻，在未來也將仍然有重要的影響，因為他們都有一身不凡的技術。對於許多重要的人我都儘量的收集了他們的照片，讓各位也能夠看看這些優秀的工程師和傑出的人物。當然，如果各位也能夠從這些內容中學習到失敗的原因以及成功的經驗，那麼這篇文章就更有價值了。  
   
   
  和Borland的緣由  
   
   
  記得我在大學時第一個在PC上使用的軟體便是SideKick，至今我仍然無法忘記這個讓我津津樂道的軟體，而Borland在當時也就是以 SideKick成為全球知名的軟體公司。不過Borland第一個奠立創業基業的軟體卻是我大二使用來交作業的Turbo   Pascal。而Turbo   Pascal也是第一個我聽到關於Borland的有趣的故事  
   
  當年Philippe   Kahn   (Borland的創使人)和Anders   Hejlsberg到美國創業時，便由Anders以組合語言撰寫了Turbo   Pascal的編譯器，而Philippe則包辦了Turbo   Pascal其他的部份。在這兩位人兄開發完Turbo   Pascal之後，窮得快連登廣告的錢都沒有了。但是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使用者認識Borland的關鍵軟體。當然SideKick也很快的成為了全球的暢銷軟體，繼續的把 Borland往頂尖的軟體公司上推。  
   
  而Turbo   Pascal也成了我大二，大三撰寫作業的最愛，幾乎所有的作業都是使用Turbo   Pascal完成的，當然其時Horowise的Data   Structure這門課也是使用Turbo   Pascal過關的，因此從那個時候開始我便非常喜歡Borland這家公司，慢慢的也開始對Borland有了特別的感情。  
   
  大二時Microsoft也推出了Microsoft   Pascal，但是它和Turbo   Pascal的確是有一段差距，我使用了一次之後便把它丟到垃圾桶。稍後Borland也推出了Turbo   Basic，我記得這個編譯器非常的棒，編譯速度就和Turbo   Pascal一樣，是一個非常有前途的產品。但是我不知道為什麼它只有1.0，之後便和Microsoft   Pascal一樣消失了。我聽說Microsoft和Borland互相交換條件，Microsoft不進入Pascal的市場，而Borland則退出 Basic的市場。至於是不是真的我就不得而知了。  
   
  在大二初次的接觸到C語言，第一本閱讀的書便是王興隆先生寫的C語言，也從此開始和C語言結下了淵源。平生第一個使用的C編譯器便是Lattice   C，不知道還有沒有人記得。我還記得那個時候使用2個5又1/4磁片抽換以便編譯C程式的情景。稍後Borland終於推出了風行天下的Turbo   C編譯器，當然，從此之後Turbo   C便成了不離身的工具，而Borland也藉由Turbo   C這第三項暢銷產品邁向了世界前10名的項尖軟體公司。  
   
  當完2年的兵之後，我在中研院首次使用了C++語言，第一個使用的C++編譯器則是Zortech   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和Microsoft，不過最後我還是決定回台灣工作。在此時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。  
   
   
  C/C++的光榮戰役  
   
   
  在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++的產品經理鬧翻了。這位Borland   C/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，而Carl   Quinn也是數年後JBuilder的JBCL   Framework的靈魂開發人物。Carl   Quinn不但負責開發OWL，也為Borland在元件Framework的技術領域立下了重要的貢獻。由於Carl   Quinn的投入，因此開啟了OWL大戰MFC，Borland   C/C++纏鬥Visual   C/C++數年精彩好戲的序幕。   
   
  Carl Quinn 到现在我还记得和敬佩的人物，让我再一次的向他致敬，并且介绍他让大家认识。

   Carl Quinn ---- 我第一个佩服的Borland 工程师

火线全开

Borland在开发工具市场和Microsoft激战之时，Microsoft和Lotus也正在电子表格工
具以及文字处理工具市场进行大战。这时Borland不思好好地集中资源开发新的开发
工具和数据库工具(稍后本书会详细说明Borland在数据库市场的战役)，也不甘寂寞
地投入了大量的资源进入这个惨烈的市场。也许是当时Borland太有钱了，或者是
Philippe Kahn的脑袋出了问题，居然决定进入这个Borland陌生的市场，更何况在
Borland投入时Lotus已现败象，Office市场已经慢慢地被Microsoft所一步一步地掌
握了。

Borland进入Office市场的第一个产品是著名的Quattro Pro电子表格。虽然Quattro
Pro是一个相当不错的产品，而且当时，由Borland C/C++编译器所开发的Quattro
Pro在执行效率上几乎是最好的，但是Borland没有想到使用电子表格的使用者是一般
的办公室人员，这些人注重的是方便性和功能性，而不是执行速度，这和开发人员是
不一样的。Borland以开发者的心态来开发电子表格工具基本上是走错了方向。因此
我记得在那段时间中，杂志评比Microsoft的Excel、Lotus的1-2-3和Borland的
Quattro Pro时，在功能方面领先的都是Excel和Lotus，在执行效率方面领先的则是
Excel和Quattro Pro。到了电子表格热战的末期，1-2-3甚至比不上Quattro Pro，因
此Lotus败走电子表格市场已是不可避免的结果了。

不过Borland虽然赢了1-2-3，但是和Excel仍然有一大段的距离，Microsoft一统电子
表格江山之势已不可动摇，因此最后Borland在损失了大量的资源之后，Quattro Pro
只能卖给Novell。

除了Quattro Pro之外，Borland也投入了很多的资源秘密地开发一个代号为Spring的
文字处理程序(Word Processor)准备和Microsoft的Word以及WordPerfect竞争，这可
能是许多人不知道的。但是这个产品最后仍然无法问市而胎死腹中，在文字处理市场
Borland不但浪费了时间，更虚掷了大量的资源。

Philippe Kahn在Office产品方面消耗了Borland大量的金钱和时间，却落得铩羽而归，
更连累了开发工具市场以及最有可能成功的数据库产品市场。

另外一个和Borland无关的故事是关于Microsoft Excel是如何兴起的。话说当Lotus
1-2-3最盛的时期，Microsoft一直在觊觎这个市场，但是苦于无法开发出一个能够
和1-2-3相竞争的产品。有一次Lotus举办了一个Lotus 1-2-3的技术研讨会，由当时
Lotus 1-2-3的首席工程师主讲。Microsoft知道了这个技术研讨会之后，立刻派出了
最好的程序设计师，现场询问Lotus是如何开发1-2-3的，并且趁机询问这位首席工程
师如何克服1-2-3在许多技术方面的难点，而这些困难处正是Microsoft的工程师无法
克服的。

当时，在现场中的Lotus首席工程师虽然知道这些人是Microsoft派来的，而且询问的
问题正是1-2-3许多关键的技术点。但是这位首席工程师凭借着多年的开发经验，认
为Microsoft不可能在短期之内追上1-2-3，因此就没有多作保留地回答了许多重要的
问题。没有想Microsoft的这些程序员也是非常聪明的人才，一经指点之后，立刻畅
然全通，在短短的1、2个版本之后不但马上追上了1-2-3，许多功能方面更是青出于
蓝，1-2-3便逐渐失去优势了。我想这位1-2-3的首席工程师一定很后悔当时回答了关
键的技术问题吧。

结论：千万不要小看Microsoft，他们是非常精于模仿的。也永远不要小看你的竞争
对手。

数据库市场的失误

Borland全盛的时期，事实上也是开发数据库产品最好的机会。因为在当时Borland手
握DOS最畅销的Paradox，并购了Ashton-Tate而拥有世界大部分dbase的市场，又取得
了Ashton-Tate从HP购买的真正关系数据库(RDBMS)--InterBase，可以说是当时全世
界数据库工具实力最雄厚的厂商。

当时的Oracle和Borland比起来，简直是小巫见大巫，而Sybase更不知道在哪里。如
果Borland能够好好地掌握这个机会，极力开发数据库产品，那么现在Borland就算不
是世界第一的软件公司，也将是世界第二的软件厂商。可惜Philippe Kahn并没有看
到这个从80年代末到90年代成长最快速的产品市场。说句笑话，如果当时Philippe
Kahn的死对头Bill Gates早一点说出"Information At Your Finger-Tip"这句话，点
醒Philippe Kahn数据库市场的重要性，那么Borland就可能是现在的Oracle了。

说到数据库市场，就不得不对Microsoft的眼光佩服，也不得不佩服Microsoft行销能
力的强悍。当Microsoft以FoxBASE For Windows强占了Windows开发者的数据库工具
市场之后，又了解到一般计算机使用者也需要使用简易好用的数据库管理工具，因此
开发出了更简易的Access。但是当时在类似的市场中，Borland的Paradox占有开发者
数据库大部分的江山，而一般使用者的数据库管理工具市场则由Lotus的Approach博
得先机。

Microsoft为了进入由Lotus Approach主宰的市场，采取了很多方法。我还记得在当
时Visual Basic 3的软件包中Microsoft附了一张优惠卷，只要800新台币就可以买一
套Access。这简直就是流血大拍卖。不过它的目标很明显，就是击败当时卖1万多元
的Lotus Approach。果然，Microsoft此招一出，Approach便被Access打得落花流水，
很快失去了市场，也很快地退出了市场。从此一般使用者的数据库管理工具市场便由
Access所独占。

但是Borland并没有警觉到Access会继续往开发者市场进攻，因此仍然没有加紧在
Paradox产品上的开发。Borland总觉得Paradox的市场地位是无法轻易撼动的，而且
Access的目标市场也不是Paradox的市场。

但是Borland忘记了Microsoft非常擅长模仿。在随后的Access版本中，Microsoft不
断地加入可程序设计的功能，因此也逐渐地吸引了一些Paradox入门使用者的市场。
再加上FoxPro For Windows又持续地强攻开发者数据库市场，Paradox终于在腹背受
敌之下逐渐败下阵来。虽然在末期Philippe Kahn对Paradox投下重兵，希望能够挽回
劣势。奈何时不我予，Paradox在奋斗了Paradox 6和Paradox 7的2个版本之后，终究
难逃失败的命运。

当时在看到Microsoft如何打击竞争对手时，我就和朋友开玩笑说，Microsoft有天下
无敌的三大绝招，那就是"打不过你就模仿你(这让我想起电影秘密客)。再打不过就
和你比流血，看谁流得久(这让我想起吸血鬼)。最后如果再不行的话，那就挖光你的
人(这让我想起电影Other People's Money)"。Lotus就在Microsoft的前两个绝招下
倒地不起，而Borland还算是功力深厚，连中三大绝招，虽然不像Lotus和许多其他公
司一样从此Bye-Bye，但也是受伤极重的了。

ODBC和IDAPI之争

当Microsoft逐渐地击败竞争对手、并且拥有了大部分PC数据库市场之后，便慢慢地
了解到掌握标准的重要性。此外，Microsoft为了统一各应用程序之间不同数据的存
取，开始制定存取数据的统一标准--ODBC。Microsoft更大的目的是为了准备和瞄准
下一场的大战，那就是PC上的关系数据库产品的市场。

当然，Microsoft要一统数据存取的江山，除了Borland不会同意之外，其时一心想从
Microsoft扳回一城的IBM也不同意。而Novell更是害怕，因为Novell怕Microsoft成
功之后，Netware会消失得更快。于是IBM、Novell和Borland以及一些其他的小厂便
聚集在一起，决定也制定一套存取数据的标准接口来和Microsoft对抗，这个制定的
数据存取标准便是IDAPI。这正式揭开了ODBC和IDAPI竞争的序幕。

不过IBM、Novell和Borland的结合很快就被证明是失败的，因为就像稍后说明的一样，
IBM在PC软件上的开发一直是三心二意，反反复复。因此当IDAPI 1.0的规格出来之后，
IBM这位老兄又失去了和Microsoft对抗的兴趣，于是退出了IDAPI联盟。至于Novell
就更不用说了。Novell对于和Microsoft竞争一向是"说说可以，真打不行"，一定要
找到一群厂商才敢和Microsoft对抗。Novell眼看IBM退出之后，也马上不战而降，很
快地就也退出IDAPI联盟，这个现象和稍后Novell对于和Borland秘密合作的
Appware/AppBuilder计划如出一辙，都是虎头蛇尾，草草收场。

在两个大同盟临阵脱逃之后，Philippe Kahn仍然不畏惧Microsoft的竞争，还是以
IDAPI 1.0的规格实现数据存取引擎，这就是我们现在使用的BDE/IDAPI和SQL Links的
前身。当时IDAPI 1.0的功能规格比ODBC 1.0好得多了。我记得Delphi 1.0使用的
BDE/IDAPI和SQL Links驱动程序也比当时慢得像乌龟的ODBC快得太多了。只可惜在
IBM和Novell退出之后，其他的小厂也是一哄而散。因此Borland只能靠自己独自和
Microsoft对抗。Borland能够以少量的资源一直对抗到Delphi 3的BDE/IDAPI才逐渐
地被ODBC追过，也算是非战之罪了，怪就只能怪Borland意志不坚的盟友们。

当然，由于IBM和Novell的行事作风如此，所以在稍后许多能够和Microsoft一较长短
的机会也因为如此而消逝，最后自食恶果，逐渐失去了PC的软件市场，再也无力和
Microsoft抗衡了。

发贴心情
第二章  C／C++的圣战

"在惨烈的、大规模的C/C++战役中，注定只有最强者才能生存下来!"

Borland C／C++的反击

当Visual C++1.0在C/C++开发工具市场获得空前的成功之后，Borland才从Borland
C/C++3.1的胜利梦中惊醒，思考如何面对Visual C++的猛烈攻势。事实上，Borland
如果脑袋清醒一点，好好看清当时C/C++开发工具的市场，那么Borland应该会发现虽
然Visual C++经过两年多的整军经武，实力已经大胜以前。但是，Borland C/C++3.
1在许多方面仍然是可以和Visual C++一争长短的。首先，当时Visual C++的最佳化
编译器仍然落后Borland C/C++3.1；第二，MFC仍然没有完整地封装Windows API，而
且MFC是以较低阶的方式封装Windows API的，面向对象做得并不好，也不是很容易使
用。事实上以我的观点来看，正是因为MFC不好用，所以Visual C++才需要在集成开
发环境中提供以可视化方式产生MFC程序代码的功能。第三是Visual C++当时并没有
很好的封装数据结构的Container Class，而Borland C/C++却有非常好用的BIDS类别
库。第四，也是最重要的，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 Windows一役中被吓着
了，因此急于在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决定全新升级集成开发环境；第二是把OWL完全重写；第三是大幅修改
最佳化编译器；第四是整合当时棘手的VBX，Borland居然让16位和32位的Windows程
序同时使用16位的、丑陋的VBX。

上面所说的每一项都是大工程。Borland早应该在Borland C/C++3.1之后便开始进行
这些工作，现在要在短短的一年多时间内重新开发这么复杂的一个C/C++开发工具，
几乎是不可能的。但是在Philippe Kahn的强力要求下，这些Borland的工程师还是硬
着头皮做了出来。

不过我必须很沉痛地说，当时在Borland C/C++4.0 Beta测试时，我便和台湾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/C++ 4.0，这个肩负和Visual C++1.0对抗的新一代C/C++开发工具。

在Borland C/C++4.0刚推出之际，Borland确实为4.0做了极大的造势，我记得在当时
所有重要的计算机杂志中，例如Byte、PC Magazine、Dr. Dobb's等，都有4.0整页的
广告。这个广告的内容是以一个巨大的猫头鹰为主，再搭配蓝色底系的Borland
C/C++4.0，选用巨大的猫头鹰当然是因为OWL的原因，只可惜我现在找不到那幅广告
的画面了。

当时Borland C/C++4.0使用了如下的广告用词：

Visual Is Only A Facial Facade

来讽刺Visual C/C++只提供了产生MFC程序代码的基本精灵，而Borland除了提供相对
应的AppExpert精灵(能够提供类似的功能，以产生使用者选择的OWL程序代码)之外，
Borland C/C++4.0的集成开发环境还提供了可视化的三面版窗口，能够让程序员完整
地掌握整个项目的情形。

下图便是当初令人眼睛为之一亮的AppExpert：

下图则是当时Borland C/C++的注册商标，三面版窗口开发环境。看到此图又令我想
起当初使用C/C++撰写程序的日子，下方程序页面清楚地显示了我1995年在鼎新工作
时写的智能型Windows排程系统，时间过得真快啊。

当时Borland C/C++4.0的三面版集成开发环境真正开创了一个新的局面，因为这个集
成开发环境允许程序员知道每一个应用程序定义的窗口信息，并且能够立刻把它显示
在下方的程序代码窗口中，的确是非常的方便，也比当时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的品质实在不好，就像前面我在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 l.x使用了不标准的C/C++编译器技术的问题，但是
这造成了原来Borland C/C++3.x程序员极大的困扰，因为升级不易。对于新的C/C++
使用者来说，又因为Borland C/C++4.0本身不稳定的因素而却步，因此造成了OWL
2.0叫好不叫座的下场，真是可惜了OWL小组的努力。

还记得当时我的项目使用了FarPoint的SpreadSheet VBX组件，由于一直无法顺利地
在Borland C/C++4.0中使用，并且会造成应用程序的当机，最后追踪执行程序代码却
发现应该是Borland C/C++4.0的问题，因此最后只好在咒骂中放弃使用Borland
C/C++4.0，而回到Borland C/C++3.1。当时想，对于我这个长期使用Borland产品的人
都无法忍受4.0的品质，其他的程序员又怎能使用这个产品呢？我想这就是为什么后来
4.0全面溃败的原因，因为Borland推出了根本不堪使用的产品。

我在Borland工作时，有一次在新加坡和现任Borland开发者关系部门副总裁的David
Intersimone谈起这一段往事，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/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在三个主要的应用市场接连败退，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++和Watcom 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推出第一个Windows上的C/C++
开发工具。1993年左右，在Eugene Wang的掌舵之下，Symantec推出了第一个
Symantec C/C++版本，立刻便获得了市场的好评。自此之后Symantec C/C++军心大振，
不断地继续改善，也逐渐获得了不小的C/C++市场，俨然成为可以对抗Borland C/C++、
Visual C/C++的另一山头。当时Symantec C/C++是以最华丽、先进的集成开发环境获
得了市场的高度认同，在C/C++编译器最佳化方面的表现也不输给其他的编译器。

当时我正为《RUN!PC》撰写有关C/C++的文章，因此Symantec台湾分公司的人也和我
联络过，并且送给我一套最高档的Symantec C/C++版本，希望我除了为Borland写C/
C++的文章之外，也能够为Symantec C/C++写一些东西。我还记得，在当时安装
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"的
总监。而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培养出来的。

Watcom C/C++在DOS市场站稳了脚跟之后，由于Windows已经逐渐成为市场的主流，DOS
势必将被逐渐淘汰出局，因此，Watcom C/C++如果要继续生存下去，也就-定要推出
Windows平台的C/C++开发工具。大约是在1993、1994年左右，Watcom终于推出第一个
Windows下的C/C++开发工具。

不过，当时Watcom C/C++在Windows推出的C/C++开发工具实在是平淡无奇。其集成开
发环境和另外三个对手比较起来简直像是远古的产品，-点特色都没有。不过Watcom
C/C++仍然是以它的最佳化编译器作为号召。因此当时发生了一个非常有趣的现象，
那就是许多软件公司会同时买Borland C/C++，或是Visual C/C++，Symantec C/C++
之一，再搭配一套Watcom C/C++。在开发应用系统时使用其他三套开发工具之一，最
后要出货时再使用Watcom C/C++来编译以产生最佳的程序代码。

在Watcom C/C++推出了Windows平台的开发工具之后，也吸引了-群使用者。虽然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++逐渐站稳了脚跟之后，C/C++四大编译器决战的时
刻也逐渐逼近了，一些其他出产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，例如ZApp和Zinc等，
但是这些C/C++ Framework终究没有产生很大的影响。如果Symantec和Watcom要自
己发展新的C/C++ Framework，那他们还没有如此雄厚的资源，也无法在短时间之内
完成。因此Symantec和Watcom必须决定，到底是要使用Microsoft的MFC还是使用Borland
的OWL来作为他们开发工具的C/C++ Framework。

1993年初，Symantec和Watcom分别和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和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可以让Windows平台的文件内嵌在不同的应用程序中，并且能够让文件在应用
程序中被即地编辑(In Place Editing)。说实在的，Microsoft的OLE和Apple以及IBM
的技术比较起来实在是差多了，在稍后也被证明是失败的技术。不过，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虽然授权使用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 Component
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);                                       

      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             
    }                                                 

虽然Borland及时地在OWL2.5中加入了OLE的支持，无奈Microsoft随后又在OLE中加入
了许多其他的功能。因此让OCF还是无法完整地支持OLE所有的功能，Borland又无法
不延后Borland C/C++的推出，因此直到l994年末，Borland才终于推出了决战性的
Borland C/C++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的则是以红色为色系，仿佛两大军团终将决战似的。

不过，这次的战役不仅仅是Borland的蓝军和Microsoft的红军相对抗。在Symantec的
华丽军团经过了整军经武，Watcom的白色劲旅枕戈待旦，而且都从Microsoft授权使
用了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居然比他们使
用的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++
新版本真的并不比Borland C/C++4.5好：虽然4.5也有OCF，但是在市场上只有Borland
和Novell、WordPerfect选择使用OCF。在和Microsoft的Visual C/C++经过将近一年
的缠斗之后，其他大部分的厂商都选择了Microsoft的MFC 2.x版，真是形势比人强。
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的市场逐渐式微，而Windows平台的开发工具又
大败而归，两头落空。不久之后，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的浏览器大战。

在C／C++最后一役之后，我认为开发工具的圣战已然结束，Borland也正式开始走下
坡路。更严重的是我认为自此之后Borland不但丧失了C/C++的江山，也失去了对于
C/C++开发工具的创意，这是我感到最遗憾的地方，到现在为止我仍然认为Borland尚
未重拾当初在Borland C/C++3.0/3.1时代独领C/C++创意风骚的精神。也许，也许，
要看看C/C++ For Kylix或是C++Builder的后继产品是否能够重新找回这个失去已久
的精神，不再让大家失望了。

永不成气候的C/C++开发工具：IBM VisualAge C/C++

IBM在C/C++开发工具市场扮演的角色一直令人啼笑皆非，因为在C/C++编译器战争最
激烈的时刻，IBM这个全球信息大厂却一直是缺席的。一直到了1995年之后，C/C++编
译器市场大势已定后才慢慢地加入战局，推出VisualAge C/C++ 3.0，企图进攻此市
场。但是此时市场早已由Microsoft的Visual C/C++称雄。IBM的VisualAge虽然能够
以创新的可视化设计家定义对象之间的关系，但是在其他方面却乏善可陈，整个集成
开发环境也缓慢如蜗牛，需要非常高的硬件配置才能够顺利运行，和Visual C/C++以
及Borland C/C++等工具比较起来就像是恐龙一般，因此几乎没有在市场上引起任何
的反应。

在推出的VisualAge C/C++3.0并没有在PC的C/C++开发工具市场获得任何的明显成果
之后，IBM又再次集中许多资源，开发下一代3.5版本，希望能够在此市场占有一定的
比率。我知道IBM在VisualAge投注了大量的资源，因为从Beta版开始台湾的IBM便有
人和我接触，希望我也在《RUN!PC》上为VisualAge C/C++3.5写些文章。因此在1996
年的6月我写了一篇C/C++编译器的比较文章，下面的资料便是数年前当时还是Beta版
的VisualAge 3.5和其他编译器的比较结果(见下页)。

从图中的数据可以看到，其实VisualAge C/C++3.5的表现还不错，只是对于当时还在
使用AMD DX4-100/32M RAM机器的我来说，实在是跑不动。后来台湾IBM负责VisualAge
的产品经理请我吃饭，在此饭局中这位李经理同时请了贺元(后来成为资迅人的总裁)、
薛晓岚(后来成为资迅人的副总裁)以及其他两位作者，希望大家在计算机杂志中继续
为VisualAge C/C++3.5写写东西，一起Promote此产品。在这个饭局中我是第一次和
贺元、薛晓岚见面，当时贺元在中文PC Magazine有一技术专栏。记得当我向这位李
经理提起我的机器几乎无法跑得动VisualAge C/C++3.5时，他还立刻一口答应借我一
台当时IBM最高档的PC。同时每写一篇VisualAge C/C++3.5的文章，除了《RUN!PC》
原本的稿费之外，IBM会再付一字2.5元的稿费。乖乖，IBM真是大手笔。我算算当时我
的产能，写一篇文章就能够赚2到3万，又有免费的最高档机器可用，真是太好了。不
过后来我还是觉得IBM在此市场可能不会深耕。在不愿意违背自己写作习惯和得罪
Borland的顾虑下，最后还是没有答应。现在想想当时真是太笨了，放着好赚的稿费不
赚，嘻。

IBM的C/C++开发工具之所以在市场无法成功，是因为IBM并不了解在此竞争激烈的市
场中使用者到底要什么。另外一个原因则是IBM并不以PC上的开发工具软件为重要的
事业。即使无法竞争和获利，对于IBM来说也没有什么影响，因为IBM主要是靠硬件和
大型软件为主，不像Borland这可是生命之争。因此IBM只是兴起玩玩，随即放下。所
以我觉得在PC平台使用IBM的工具是很危险的，因为IBM随时都可能会放弃这个市场。
不知道现在VisualAge C/C++到底下场如何?是不是还在3.5或是4.0版？IBM已经数年
没有任何的维护和改善了。

快速殒落的潜力之星：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》6上发表之后，台湾的Sybase立刻和我联络，由当时的余协理和我见面，
也是希望我继续为Optima++写文章，台湾Sybase也提供额外一字加2元稿费的待遇。
但是我告诉余协理，Optima++1.0虽然很棒，但是仍然有一些臭虫，而且和中文环境
相冲突，无法处理中文，需要立刻解决这个问题才能够在台湾的市场成功。她答应我
立刻向总公司反应。我也老实地告诉她，在问题没有解决之前，我无法写一些不确实
的东西。后来台湾Borland的总经理方先生也找我去询问有关Optima++的事情，我告
诉他Optima++是好东西，但是中文有问题。如果中文问题能够解决，那么将对Borland
和Microsoft的产品有很大的影响，当时我还不知道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++一个如此有潜力的产品就这样消失了，真是令人遗憾。Optima++应该有很好
的机会可以成功的。我相信，如果当时Sybase知道C++Builder后来的成果，可能就不
会放弃Optima++了，而C/C++的RAD工具一直要到后来的C++Builder来完成这个梦。

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++竞争时每一个版本都有大幅的改
善。看来寡占的市场的确是不好的。

第三章  传奇的开始--Delphi

"是惊世之作的Delphi让Borland重新站了起来，没有当初的Delphi，就没有今日的
Borland！"

"是Turbo Pascal诞生了Borland，但却是Object Pascal给予了Borland重生的机会！"

创造传奇故事的主角--Delphi

没有人会知道在两年后Borland C/C++会遭遇到这么大的失败，也没有人会预料到
Borland又会再次因为Pascal而东山再起。Borland奋斗史精彩的地方就在于每当似乎
要不支倒地之际，Borland的R&D人员就会创造出一个明星级的产品来拯救Borland。
在其他和Microsoft对抗的软件公司纷纷消失的时候，Borland却一次又一次地站了起
来。"打不死的勇者"这句话贴切地形容了Borland的韧性。Borland靠Pascal起家，通
过C/C++绽放光芒，进而达到了巅峰的状态，随后又再次靠着Pascal浴火重生。Borland
这个从C/C++跌倒，再通过明星工具Delphi重回战场的过程可以说是惊心动魄，其中更
牵涉到了Borland两位创始人Philippe Kahn以及Anders Hejlsberg相继离开Borland
的密闻，也激活了Borland逐渐转型的历史轮轴。对于Borland来说，这段发展史可以
算是非常关键的里程碑，更重要的是，Delphi的崛起也在软件工具业界产生了巨大的
影响。Delphi不但激活了Windows平台上RAD战争的序幕，开启了Windows平台主从架
构的改变，同时也对组件技术做出了巨大的贡献。直到现在，Delphi创造的组件技术
仍然深深地影响了JavaBeans以及.NET的组件思想和技术，这在稍后的内文中读者可
以逐渐地了解。而故事的起源便在1993年左右……

Delphi的发展起源

当Borland以Turbo Pascal获得了成功，并且令Charles Petzold等人跌破眼镜之后，
到了1992/1993年的Borland Pascal 7.x，Borland似乎已经把传统的Pascal开发工具
发展到了极限，再往下还能做什么呢？Borland Pascal在销售了数百万套之后，程序
语言的焦点已经从Pascal转移到了C/C++，Borland Pascal无法继续快速成长，进而
转入了递减的状况，Borland必须做些新的东西才能够延续这条产品线。

当时Borland Pascal产品的Architect，即Anders Hejlsberg，眼看Microsoft Visual
Basic的成功，觉得当时Visual Basic是比较初级的开发工具，是一个学习Windows
程序设计的好工具，但是尚无开发真正应用系统的能力。因此，Anders和Borland
Pascal的小组决定展开一个规模前所未有的项目计划，这个开发工具项目在一开始便
设定了数个目标，希望能够达成并且超越Visual Basic。这些初始的目标是：

●  延续Borland Pascal的传统，提供一个快速编译的开发环境
    ■  Borland/Turbo Pascal的高明之处便是由Anders使用汇编语言撰写的Pascal
编译器不但编译快速，而且能够产出极为有效率的机器码。当时的Visual Basic只是
解译器(Interpreter)，无法产生真正的执行机器码，因此在这一方面Borland决定要
远远地超过VB，但是Borland的挑战是要开发出一个编译速度能够媲美解译器速度的
新一代编译器。

    ■  Anders另外一个重要的决定便是改善Borland Pascal程序语言，让这个新的
开发工具程序语言具备面向对象的功能。这在当时是非常重要的决定，因为不但需要
大幅修改编译器，也正式将Borland Pascal超越Pascal之父对Pascal定义的结构，让
Pascal拥有现代语言最新的功能。虽然这个决定有很大的因素是因为Borland决定通过
面向对象的方式建立新一代的Framework和组件架构，因此需要程序语言方面的支持。
不过，这在当时整个信息界对于面向对象技术还很陌生的阶段，的确是一个很大胆的
决策。这个程序语言的决策虽然可以吸引专业人士的激赏，不过也可能会让许多程序
员无法跨越这个障碍。后来的发展也证明了这一点。

●  建立一个新的Windows Framework组件架构
    ■  当时VB使用的组件是VBX。不过VBX架构非常的复杂，只能使用在16位的环境，
并且在可视化拖曳设计方面又不是很方便。因此Borland希望在OWL之后建立一个全新
的Framework，这个Framework能够让程序员快速开发Windows应用程序，并且完整地封
装Windows操作系统中的对象。此外，Borland也希望定义一个标准的组件架构，让使
用这个开发工具的程序员能够通过Framework和组件架构来开发各种组件，包括可视
化和非可视化组件。这个Framework就是后来的VCL(Visual Component Library)。在
这方面，Borland做得非常成功。如果各位读者有VBX的经验，就会知道当时，Microsoft
定义的VBX规格简直是一团混乱，根本像是拼凑出来的东西。在当时开发VBX组件痛苦
不堪，后来Microsoft也彻底放弃了VBX。

●  拖曳、可视化的开发环境
    ■  Borland的想法是开发一个全新的集成开发环境，在这个开发环境中程序员可
以使用可视化的方法拖曳Framework的组件来设计图形界面，再在其中的编辑器中使用
面向对象程序语言来撰写应用程序。

这个开发工具项目的名称就是：Delphi！

Delphi的核心成员

在Delphi决定开工之后，Philippe Kahn还不放心动用太多的资源来开发这个产品，
因为当时Borland正集中所有的资源，希望能够打赢C/C++开发工具一役。因此
Philippe Kahn一开始只答应拨给Anders四个开发人员，先进行产品雏型的开发工作。
因此，Delphi在当时被笑称为像Apple计算机一样，是在地下室开发的。

当时加入Delphi开发小组的当然就包含了Anders，第二人是Chuck Jazdzewski。其中
Anders负责撰写新的Object Pascal编译器以及核心程序，而Chuck则负责设计Delphi
使用的组件Framework，即VCL。在经过了6个月的初始雏型阶段之后，当Anders把开
发的结果呈现给Philippe Kahn看时，Philippe立刻被它所吸引。因为当时在Borland
内部也希望为Borland C/C++开发一个类似这样能够以可视化拖曳方式开发应用系统
的C/C++开发工具。没有想到在短短不到一年的时间内，Anders已经从基本的构想开
发出了雏型产品。于是Philippe马上批准了这个产品的开发计划，并且投入研发资源。
许多后来举足轻重的人才便是从开发Delphi项目培养出来的。当时在这个项目中，各个
重要的部分分别由下面的重要人员负责：

●  Anders Hejlsberg：编译器，Object Pascal程序语言，产品架构

●  Chuck Jazdzewski：Framework，组件架构设计/实现

●  Allen Bauer：集成开发环境的开发工具，Open Tools API

●  Danny Thorpe：RTL (Run-Time Library)

●  Zack Urlocker：产品开发方向，产品规划

有兴趣的读者可以打开下面的链接，这篇文章是由Danny Thorpe(现在是Borland .NET
的Architect)撰写的，详细地说明了Delphi这个名称的由来以及开发的缘由。

http://community.borland.com/article/0,1410,20396,00.html

而批准Delphi的开发，则是Philippe Kahn在因为Borland营运不佳而辞去Borland CEO
之前做出的最重要而且正确的决策。没有Philippe Kahn的同意，便不会有两三年后
浴火重生的Borland。

大规模的开发行动和Philippe Kahn的下台

在Borland如火如荼地进行C/C++最后决战的同时，Delphi也在快速的开发之中。1994
下半年，Delphi 1.0几乎已经开发完毕，最后剩下的工作就是Beta测试的阶段。同年，
Borland决定为Delphi展开一项从未进行的尝试计划，因为Borland对于Delphi信心
满满。这个计划就是为Delphi进行前所未有的大规模测试，以确保Delphi的品质，避
免重蹈Borland C/C++发生的覆辙。Borland为Delphi发出了成千上万的测试版本，邀
请了广大的程序员为Delphi进行长期的测试。这可是空前绝后的，因为自Delphi 1.0
之后Borland再也没有任何的产品能够拥有这种气魄和规模。我记得在1994年底左右，
收到了来自当时Borland台湾产品经理张书良先生寄来的神秘圣诞节礼物。当时打开包
裹一看，是六七片磁盘，没有任何的文件和说明。张书良先生请我安装看看这个"东
西"，并且请提供一点意见。

在安装了这些"磁盘"之后，映入眼帘的是一个陌生的软件。"这是什么啊？"这是我当
时的第一个想法。后来玩玩此软件，发现乖乖不得了。不但大部分的Windows对象都
可以拉拉就产生程序代码，更绝的是编译应用程序的速度比使用Borland C/C++的编
译器快了数十倍，而且产生的是一个体积不大的原生EXE文件，执行速度更是媲美
C/C++的程序代码。这让我这个惯用C/C++的程序员当场傻眼。

"这怎么可能?"在我发出呓语般的声音之后，旁边的同事也觉得怪怪的，于是一个一
个地跑到我的计算机旁，看看我到底在做什么？其中当然包括了《Delphi学习手册》
的作者、也是笔者的好友李增坤先生。在大家玩了之后，每个人都急着拷贝我的
Delphi Beta版以便回家继续玩。后来李增坤先生更是玩得出神入化，还能够让Delphi
连接到当时相当封闭的Informix数据库(因为他们的开发小组是使用Informix的)，真
是厉害。他是我所知的第一个Delphi好手。

"这绝对是一个Super Star！"，当时我这样对张书良先生说。"真的?那么你可不可以
在杂志上帮Borland写一些介绍它的文章？"张书良先生对我这么说。就是因为这段对
话，让我开始和Delphi结下了不解之缘。至于我开始写Delphi书籍的缘由也是无心插
柳造成的。在台湾Borland准备力推Delphi 1.0之际，张书良先生准备亲自下海，也
亲自出面找到了旗标出版社合作出书，以推广Delphi。后来由于张先生工作太忙，因
此又找了我和李增坤先生帮忙。本来的约定是我和李增坤先生只负责一小部分，其他
的部分都由张先生完成。没有想到，签约之后张书良先生完全没有时间投入，因此只
好由我和李增坤先生完成《Delphi 1.0学习手册》。由于我和李增坤先生以前没有写
书的经验，投入撰写书籍的时间也不多，因此《Delphi 1.0学习手册》是台湾所有有
关Delphi 1.0书籍中最晚出的一本书，远远超过当时我们规划的时程。好在当时
Delphi 1.0的气势简直如星火燎原般的炙手可热，因此这本书还是卖得不错的。

1995年对于Borland来说是悲喜交加的一年。1995年1月11日，Philippe Kahn正式因
为经营不善而辞去Borland CEO的职位，不过Philippe Kahn仍然是Borland董事会的
成员之一。接任的Gary Wetsel的任务是大幅删减Borland的员工数，开始进行瘦身计
划。因为当时Borland的员工数是为营收500M美金的Borland所打造的，但是在1995年
Borland的营收已经下滑为不及200M美金的公司，而且一直在亏损之中，当时许多业
界人土都认为Borland已经撑不过1995年。不过1995年2月14日的情人节似乎一夜之间
改变了Borland的命运。

一炮而红的Delphi 1.0

1995年2月14日，是Borland永远会记得的日子，因为这一天是Delphi正式诞生的日子，
也是Borland扭转命运的转折点。由于Delphi先前大规模的Beta测试计划已经在全
球吸引了极大的兴趣和好评，信息业界也知道了Borland正准备推出一个跨时代的新
开发工具产品。当然，更重要的是全信息界也都在静观，这个产品是否真的好到能够
拯救Borland免于破产或是被并购的命运。决定生与死的日子终于在这一天揭晓。

1995年2月14日，也就是Borland在全球发表Delphi 1.0当天，我在Scott Valley会见
了当时的Delphi主舵手，产品经理Lance Devin先生。Lance是一位非常亲切、有活力
的人。Delphi在他的主掌之下，立刻在全球吸引了所有的焦点，当时媒体甚至称
Delphi l.0是VBK(Visual Basic Killer)。

Delphi 1．0发表之后，立刻造成了全球的狂卖。由于Borland并没有预料到Delphi的
反应会如此的好，因此一时造成了Delphi的全球大缺货。Borland从Borland C/C++3.1
之后已经很久没有享受过这么美好的滋味了。

在台湾，由于早已预料到Delphi将会是一个成功的产品，因此，台湾几乎和美国同一
时间发表了Delphi 1.0。而且台湾Borland不惜血本，直接从美国空运了少数的
Delphi，而台湾能够取得的Delphi的数量也只是从美国抢破头才拿到的少量货。台湾
Borland是在信义路的震旦行2楼会议室发布Delphi的。当天整个会议室几乎被塞爆了，
因为有太多急于想一睹Delphi庐山真面目的软件人员。我还清楚地记得在发布会结束
之后，会议室的门口排满了抢购Delphi的人潮。很快，所有的Delphi都被抢光了。记
得当时李匡正先生没有抢到Delphi 1.0，一直到2个多礼拜之后才取得。而我呢？很幸
运的是在Delphi 1.0发表之前，张书良先生就已经送了一套正式的Delphi 1.0
Client/Server版让我玩。当然我也迫不及待地把Delphi介绍给我当时的老板，希望
我们的软件包能够赶快使用Delphi来写Windows的版本，但是我的老板还是坚持使用
Visual Basic来写。后来我就离开这家公司，找寻愿意使用Delphi开发的软件公司。

当时Delphi在台湾书市造成的旋风真可用"洛阳纸贵"来形容，任何和Delphi 1.0有关
的书籍都立刻大卖，看得每一个出版社都眼红不已。我也还记得当时第一本Delphi
1.0的书是由波全出版社推出的。根据台湾最有名的天珑书局老板彭先生说，最热门
的时候一天几乎可卖500本的数量。我想这一本Delphi书籍应该是台湾有史以来销量
最好的Delphi书了，估计当时这本波全的书有数万本的销量。更夸张的是后来我居然
在天珑书局看到由2本影印的合集Delphi书籍，由塑料套包起来，要价是"1500"块台
币，居然也很快卖完，真是令人不可思议。这即使不是绝后，也绝对是空前的。

Delphi 1.0的成功也许早在信心满满的Anders的预料之中，看看下面在Delphi 1.0中
秘密内藏的Easter Egg中，Anders笑得如此的灿烂似乎就已经预见了Delphi光明的未
来。

Delphi 1.0有多成功呢？根据非正式的统计，Delphi 1.0当时在全球狂卖了50多万套，
这实在是一个惊人的数字。读者如果没有什么概念的话，那么我可以举一些例子来
比较一下。Borland最成功的Borland/Turbo C/C++系列卖到了3.1最巅峰的时候，全
球的销量才超过100多万套，这可是累积了数年、数个版本后才达到的套数。而Delphi
一个版本就到达了C/C++几乎一半的销量，从这就可以知道当时Delphi有多成功了。

Delphi 1.0的大卖，立刻拯救了财务困难的Borland。Delphi的收入不但让Borland立
刻再投入更多的资源到Delphi开发小组，以准备下一个版本的开发，也让当时Borland
内部的Latte(就是后来的JBuilder)小组获得了更多的研发资源，成就了数年后JBuilder
再次接棒；把Borland推向另一个高峰。

再见了，Borland创始人，Philippe Kahn

1995下半年，Borland发生了一件重大的事情，那就是Philippe Kahn正式被逐出他一
手创建的Borland。这真是令人震惊又难过的事情，相信许多关心Borland的读者都知
道这件事情。但是为什么Philippe Kahn会被踢出Borland董事会、又离开Borland呢？
这可是一个秘密。

事情都是从Philippe Kahn辞下Borland的CEO后开始发生的。在Philippe Kahn被逼下
CEO之后，他觉得Borland的一些开发方向他并不是很认同，因此在外面又开了一家新
的公司StarFish，从Borland买走了SideKick、DashBoard等产品，并且开始研发移动
和无线等方面的软件。

1995年Java兴起之后，Philippe Kahn觉得Java很有前途，并且希望结合Java以及移
动和无线软件技术。其时Borland内部也在开始研发Java的产品，包含了代号是Latte
的Java开发工具以及Java的JIT编译器等技术。而Borland没有预料到，由于Java的萌
萌芽竟会造成Philippe Kahn和Anders的离开以及Borland Visual dBase小组的解体。

话说在Borland于Java方面逐渐有了成果之后，Philippe Kahn的StarFish公司也开始
步上轨道。1995年，Philippe Kahn眼看Borland内部Java的人才素质精良，于是就开
始想挖一些好手到自己的StarFish公司。在Philippe Kahn的挖角动作愈来愈大之后，
Borland的董事会终于无法忍受Philippe Kahn这种挖Borland墙角的做法。于是，
Borland的董事会成员一致投票决定，将Philippe Kahn逐出Borland的董事会和
Borland。这对于Philippe Kahn是一个极为重大的打击，Philippe Kahn被迫离开了他
一手创办和心爱的Borland。即使后来Philippe Kahn的StarFish经营得不错，以致后
来由Motorola以数千万美金并购了StarFish，让Philippe Kahn大大地赚了一笔，但是
他仍然无法释怀，也永远无法忘记Borland给他的成功、光荣、骄傲和屈辱。虽然
Philippe Kahn一直想像苹果计算机的Steve Jobs一样有朝一日能够重返Borland，但
是，很显然Philippe Kahn没有Steve Jobs那样的运气，Philippe Kahn一直无法完成
这个愿望。

Anders的计划以及Zack的想法

在Delphi 1.0大获成功、如日中天之后，雄心勃勃的Anders立刻开始了下一版Delphi
的开发计划。此时Delphi研发小组的资源更多，因此可以做更多的东西。不过，在1995
年Delphi 1.0推出之后，信息业界有了几项重要的改变，那就是随着Microsoft
Windows 95的成功，企业使用Windows平台开发应用系统已经成为既定的趋势，再加上
当时数据库市场的快速发展，因此许多企业开始在Windows平台寻找Client/Server的
解决方案。正由于这些需求快速而大量的兴起，造成了当时PowerBuilder和Gupta这两
个主从架构开发工具的盛行。当时，PowerBuilder是Window平台下占有率超过50％的
主从架构开发工具，而Gupta则拥有超过30％的市场。这真是可怕，因为光是两个工具
就占据了80％多的市场。由于当时主从架构几乎由这两个工具所寡占，因此，
PowerBuilder和Gupta的价格相当昂贵，我记得当时一套PowerBuilder要价40几万新台
币，而Gupta也要30几万，真是令人无法相信。

在Microsoft方面，由于Delphi 1.0的成功，给了VB相当大的压力。因此Microsoft在
Delphi 1.0推出之后立刻也推出VB 4.0正面迎战。VB 4.0强调的重点是VB应用程序也
可以编译成可执行文件，不过，由于VB 4.0的编译器品质尚不成熟，编译出来的效果
并不好。再加上它的臭虫非常多，因此VB4.0算是一个相当不成功的产品。正由于这
些因素，在当时也传出了VB双数版本品质不如奇数版好的传闻。不过，在当时由于
PowerBuilder和Gupta的获利非常丰富，而Microsoft也看到了主从架构将会是未来数
年重要的信息架构，因此VB 4.0开始，Microsoft也开始逐渐为VB加入更多开发数据库
以及主从架构的能力，并且搭配Microsoft的ODBC规格向主从架构市场进攻。

Anders在Delphi 1.0成功之后，曾经接受媒体的访问，叙述他心中的Delphi 2.0想做
的功能。当时Anders就说他希望为Delphi加入Garbage Collection的功能，因为
Object Pascal在建立对象方面是使用Heap-Based的方式，因此为了减少Delphi程序员
可能发生的错误并简化Delphi程序代码的撰写，他希望加入Garbage Collection。现
在的Microsoft的．NET就内建了Garbage Collection的功能，而这个想法在7年前便已
经存在于Anders的脑中了。

除了Garbage Collection之外，Anders也想为Delphi加入更多Stack-Based的能力(是
巧合吗？.NET的IL也是Stack-Based的语言)，并且持续地改善Delphi的编译器，加入
更多的编译器最佳化功能，让Delphi的程序代码执行速度能够超越C/C++。

从Anders的想法中，读者应该可以感觉到Anders想做的都是属于比较语言、系统和低
阶方面、影响层面较大的功能。但是，由于信息市场是逐渐走向主从架构，因此
Zack Urlocker等人则希望Delphi 2.0能够在主从架构方面进行大幅的强化，再搭配
Borland力倡的BDE/IDAPI技术，以便和PowerBuilder/Gupta等竞争，进入获利较为丰
富的工具市场，这是第一次Anders和Zack意见分歧的时间点。

后来Delphi研发小组达成了共识，那就是下一个版本的Delphi将由Anders在编译器方
面主导，为Delphi开发一个真正的32位编译器，而且具备最佳化的功能(因为
Delphi 1.0是16位的开发工具)。但是Delphi 2.0也将大幅加入主从架构的功能，并且
通过BDE/IDAPI提供连接各种RDBMS的驱动程序，再由Chuck改善VCL架构，提供更为强
劲的数据感知组件能力，让Delphi 2.0正式具备和PowerBuilder/Gupta竞争的本钱。
这也埋下了日后PowerBuilder/Gupta这两个工具备受VB和Delphi强大的压力、终至快
速衰退的命运。

由于Delphi 2．0开始确定走向主从架构和具备开发大型系统能力的方向，因此Anders
没有多余的资源可以实现他的理想，再加上和Zack在产品发展方面日渐出现歧见，这
些都是间接造成日后Anders离开Borland的因素。

Delphi 2.0，进入32位世界的开发工具

在Anders完成了Delphi 32位的编译器而且BDE/IDAPI小组也实现更多连接RDBMS的驱
动程序之后，Delphi 2.0便已经准备好出征了。Delphi 2.0在推出之后果然也非常成
功，Anders亲手打造的32位编译器不但编译速度奇快，编译出的应用程序品质更是无
话可说。在当时，Delphi 2.0产生的执行程序代码屡获专业媒体和实验室的评比大奖，
尤其在整数运算方面，更是比VC++执行得还好。在一般应用程序方面，也和VC++的
程序代码不相上下。整体来说，只有在浮点数方面落后VC++。这也是后来Borland编
译器小组和Anders激活Borland下一代编译器项目的原因之一，目的是为C++Builder
和Delphi开发一个共享的后端最佳化编译器。不过很可惜的是，Anders稍后离开了
Borland，没有参与完成这个最佳化编译器，否则Borland的编译器应该会比现在更具
威力。

Delphi 2.0如同Delphi l.0一样大获成功，因为当时许多想在Windows NT下开发纯32
位应用系统的程序员都愿意使用Delphi 2.0，更不用说一些企业的开发者，在不愿意
忍受PowerBuilder/Gupta等使用脚本语言执行应用程序的缓慢情形下，许多
PowerBuilder/Gupta使用者都转而使用Borland的Delphi，这是Borland继当初
Borland C/C++3.1之后再次打入企业市场。Delphi 2.0和Delphi 1.0的总销量也超过
了一百万套。在全球的市场中，Delphi在欧洲、亚洲和中南美洲都非常的成功，反而
在北美的市场表现平平。由于Delphi表现得非常抢眼，给予了VB和PowerBuilder巨大
的压力，因此Microsoft和Sybase在Delphi 2.0推出之后，也纷纷地准备推出VB 5.0和
PowerBuilder 6.0，正式揭开了RAD工具最后的生死战。

在Delphi 2．0顺利推出之后，很不幸的是Lance也离开了Borland。接手Delphi产品
经理的是Ben Riga。要怎么说这位加拿大的仁兄呢？Ben Riga也是很亲切的人，但是
我当时向他建议的许多Delphi发展方向，这位仁兄都没有反映在Delphi的产品中。

例如我在3.0时便强烈建议Delphi应该在Web方面投入更多的努力，在Delphi中实现类
似当时IntraBuilder的能力，提供可视化的方式开发Web应用系统，也就是像现今的
Developer Express的ExpressWeb Objects组件组，或是IntraWeb组件组。如果在当
时的Delphi 3或是Delphi 4便能够有这种组件组，那么Delphi的Web能力将是No.1，
更不用说对于Delphi的销量会有多大的帮助。可惜笔者人微言轻，Ben并没有把这个
重要的功能放人Delphi的产品开发规格中。一直到现在，Delphi 6/7才认真地考虑这
个需要，虽然时间已经晚了，但是如果真的做得好的话，也比没有好。

RAD殊死战

在Delphi和VB相继进入主从架构的世界之后，便和PowerBuilder有了更激烈的竞争。
在Delphi 2.0出版之后，PowerBuilder面临了更大的挑战。因为VB在易于使用和
Microsoft的努力之下仍然呈现成长的趋势，但是PowerBuilder在许多场合却是直接和
Delphi竞争。在Delphi 2.0推出之后，Borland也很快查觉到许多Delphi的使用者是从
PowerBuilder转来的，于是当时Borland内部便拟定了置换PowerBuilder计划，希望能
够持续从PowerBuilder手中抢得更多的市场占有率。

Delphi 2.0的纯32位编译器以及执行速度一直是许多人喜欢的，这也对PowerBuilder
带来了压力，因为许多PowerBuilder的使用者，特别是软件公司对于PowerBuilder使
用的语言PowerScript执行缓慢而不悦，但是却喜欢PowerBuilder的DataWindow。因
此在当时Sybase便宣告将为PowerBuilder开发一个编译器，以增加PowerBuilder应用
程序的执行速度。不过Sybase并没有在Delphi 2.0之后的PowerBuilder 5.0实现出来，
一直要到PowerBuilder 6.0才推出PowerBuilder编译器，不过问题仍然多多。

当时我曾经仔细地观察台湾参加Delphi发布会的使用者以及参加PowerBuilder的使用
者，发现了一个很有趣的现象，那就是一开始参加Delphi(1.0/2.0)的使用者几乎都
是工程师，很少有DB Center的信息人员或是信息经理。而去PowerBuilder的使用者
则甚少工程师，大部分都是穿着体面的DB Center的信息人员或是信息经理。不过这
个情形在Delphi 2.0之后逐渐改变，因为当Delphi慢慢地被企业接受成为开发工具之
后，也有愈来愈多的信息主管人员出现在Delphi的发布会中。

下图是我早在1999年便绘制的资料，从这个Slide中读者可以发现Delphi、VB和
PowerBuilder的竞争是一个版本对应一个版本的。每当竞争对手推新的版本之后，另
外的竞争对手都会立刻推出相对应的竞争版本。但是在Delphi 2.0之后，PowerBuilder
便开始逐渐无法同步跟上Delphi和VB的竞争脚步，差距也愈拉愈大。

基本上Delphi、VB和PowerBuilder的竞争在Delphi 2.0时期是最为激烈的，在Delphi
3.0和VB 5.0之后大势已定。PowerBuilder已经定位成数据库开发工具，无法像Delphi
和VB一样成为Windows平台中通用的开发工具。因此PowerBuilder的使用者群组便逐
渐缩减到DB Center或是信息室的使用者。这个现象当时在台湾非常的明显，因为大
多数的软件开发厂商、软件包厂商或是项目厂商逐渐地舍弃PowerBuilder，不是选择
使用VB就是选择使用Delphi。在Delphi 3.0之后，Windows平台的主从架构开发工具
市场已经是VB第1，Delphi第2，而PowerBuilder退到第3，并且和Delphi/VB的差距愈
来愈大。经过了3年的激斗，传统主从架构开发工具PowerBuilder和Gupta仍然不是
Microsoft和Borland的对手，即使PowerBuilder曾经拥有超过世界50％的占有率。当初
Sybase也没有预料到在并购了PowerBuilder之后，这么快就损失了大片的江山。不过
比起Oracle和Informix来说，Sybase下的本钱还是比较划算的，因为同时竞争的Oracle
Developer 2000早已只能送给Oracle数据库的使用者。而Informix的主从架构开发工具
Neon更是凄惨，在出了一个版本之后，由于体积庞大，执行缓慢，又臭虫成堆，还没上
场竞争，就被丢人垃圾桶了。这对当时所有投入大量资源开发主从架构开发工具的软件
厂商来说，都是受伤不轻，当然除了Borland和Microsoft之外。

PowerBuilder和Gupta数年辛辛苦苦建立起来的主从架构王国，只经过短短的1、2年
就被VB和Delphi所鲸吞蚕食是有许多原因的。PowerBuilder和Gupta着重在高价、专
有的主从架构市场，却不知主从架构已经逐渐成为一般信息架构应用主流，大量的程
序员需要的是价格合理、功能齐全的开发工具。PowerBuilder和Gupta价格的奇高和
功能的缺失，在VB和Delphi加强主从架构的功能之后便逐渐地浮现出来。此外
PowerBuilder和Gupta当初风行的一个重要因素是提供了连接到各种RDBMS的驱动程序，
以提供开发数据库和主从架构应用系统的能力。但是当VB和Delphi都分别提供了ODBC和
BDE/IDAPI技术连接更多的数据库服务器之后，PowerBuilder和Gupta的优势也就不再
了。另外一个关键性的因素是PowerBuilder和Gupta一直无法成为大众化的开发工具。
除了DB Center和企业之外，PowerBuilder和Gupta无法被大量的ISV、商业软件包厂商、
一般工程师、甚至是学生使用来开发各种不同的应用系统。因此PowerBuilder和Gupta
只能在特定的软件族群中使用，限制了可能成长的潜力市场。

最后我认为最重要的原因是Sybase和Gupta在面对Microsoft和Borland这两个非常精
于实现开发工具的厂商时过于轻心，反应的速度太过于缓慢，以致PowerBuilder和
Gupta除了在数据库和主从架构功能之外，其他的功能都太过阳春。特别是在Java逐渐
兴起之后，PowerBuilder和Gupta最后跨平台的诉求也在瞬间瓦解，因此失去市场也是
不可挽回的命运了。

Borland C++Builder的诞生

在Delphi l.0/2.0大获成功并且对Borland产生了巨大的收益之后，来自Borland
C/C++使用者的需求，即要求Borland也推出一个C/C++版本的呼声也愈来愈强烈，到了
Borland无法忽视的地步。不过这对Borland来说，却是一个相当伤脑筋的事，因为
Delphi是用Object Pascal写的，如何转成C/C++？如果要开发C/C++版的Delphi，那么
Borland C/C++的产品线要如何处理？因此这也在Borland内部起了极大的争议，这又
是另外一个故事了。不过不可否认的是，Delphi 1.0/2.0的成功正是促成了Borland
C++Builder面世的主要动力。

争执的开始

Delphi 2.0的再次重大成功仿佛为Delphi研发小组注入了一支巨大的强心剂。Delphi
研发小组迫不及待地要开发Delphi3.0，以便趁胜追击，进一步的拉近和VB的距离，
并且再次给予PowerBuilder/Gupta重击，以便从PowerBuilder/Gupta取得更多的市场。
在Delphi 2.0推出之后，根据当时Gartner Group的调查，主从架构开发工具的第
一名仍然是PowerBuilder，第二名是VB，而第三名则是Delphi。Gupta的市场占有率
快速地下滑，已经无法进入前三名的占有率了。不久之后Gupta改名为Centura，希望
力挽狂澜，但是仍然无法改变市场的现实，并且逐渐淡出主从架构的开发工具市场。
这对于VB和Delphi来说都是重大的胜利，因为VB和Delphi在短短的一两年之内就几乎
瓦解了PowerBuilder/Gupta在主从架构市场数年经营的优势。虽然PowerBuilder还暂
时维持第一的占有率，但是已经从50％几萎缩到了40％，而且还在不断的下滑之中。
PowerBuilder在VB和Delphi的强烈进攻下岌岌可危，产品价格也在快速地滑落之中。

不过在Delphi 3.0的功能会议中，Anders和Zack却再次发生了强烈的争执，因为这两
个Delphi的灵魂人物对于Delphi 3.0的走向出现了不同的看法。其时由于Microsoft
的COM/DCOM等技术逐渐成熟和受到愈来愈多的使用，因此Anders希望Delphi 3能够充
分地支持开发COM/DCOM的技术，并且提供比VB更方便、比VC更强大的能力。为了实现
这个想法，Anders力邀Alain Lino Tadros加入Delphi的研发小组。为什么Anders会
找上Alain呢?这是因为Alain曾在1996年BorCon的研讨会上以惊人的技术写了5000多
行的程序代码，把VCL组件直接变成COM对象。Anders在BorCon上知道之后，立刻有一
个想法，那就是如何能够延伸Alian的技术，如果通过一种方法便能够把所有或是大
部分的VCL组件变成COM对象以及COM Container的话，那将是多奇妙的事情。如此一
来Delphi的研发小组也不需要为实现COM/DCOM的功能而大费周折了。而Anders的这个
想法也促成了后来Delphi 3中IVCLComObject接口和技术的诞生，直接把VCL转换为COM
对象的神奇功能。

除了邀请Alian之外，Anders也计划直接修改Delphi的编译器，让编译器能够直接处
理COM的参考计数值(Reference Count)，免除Delphi程序员的麻烦，并且提供有效的
执行码。如果依照当时Anders的想法并且把Delphi 3依此实现出来的话，那么Delphi
将会是一个比Microsoft工具更好的COM开发工具。

不过Zack却不认为Delphi 3应该把这么多的资源花在支持COM/DCOM上。虽然Zack同意
Delphi 3必须对COM/DCOM有好的支持，但是他认为Delphi 3应该在Delphi 2的主从架
构获得了胜利之后，继续往更高阶的方向努力，那就是分布式架构，以便把Delphi塑
造成能够开发大型企业的开发工具，把Delphi打入获利丰富的企业市场。因此Zack和
当时Borland开发工具部门的负责人Paul Gross激活了所谓的Golden Gate计划，希望
提供Delphi强大的中介引擎功能，因此Borland并购了出版Entera中间件的公司，让
Delphi能够通过Entera连接到后端大型的系统，希望大型企业能够使用Delphi开发客
户端的应用程序。

由于Golden Gate计划得到了Borland高层的支持，因此Delphi 3的发展方向很快便朝
向分布式技术前进。虽然COM/DCOM的支持也在产品的计划之中，但是并无法做到像
Anders所想要的境界。由于Anders的理想无法被接受，因此在Delphi 3的发展中后期
阶段，Anders并没有介入太多Delphi 3的开发工作。

在Delphi 3正式发表之际，Delphi的研发小组很巧妙地平衡了COM/DCOM和分布式技术
的功能，也让Delphi 3成为Windows平台中第一个提供分布式开发的开发工具。而
Delphi 3当时使用的Marketing Slogan以及产品诉求的重点也是"Component Foundry"，
意谓Delphi 3可以轻易地建立VCL组件以及COM/DCOM/ActiveX组件。

Delphi 3推出之后，Delphi应该算是到达了巅峰的状态，销售数字也非常的亮丽，已
经超过了Borland C/C++3.1的销量，而Borland也有了稳定的收入。但是人无远忧必
有近虑，后来发生的数件大事几乎让Delphi重演当初Borland C/C++4．0的历史覆辙。

不知道读者看到这里有什么想法？我认为COM/DCOM和分布式技术都是重要的，后来的
事实也证明分布式技术是Delphi的强项之一，而应用系统架构也逐渐走向分布式多层。
不过没有像Anders的想法把Delphi塑造成无敌的COM/DCOM组件开发工具相信也是许
多人的遗憾。

在Anders逐渐不介入Delphi 3的开发之后，随后发生的两件关键的事情便注定了
Anders Hejlsberg继Philippe Kahn离开Borland的命运。

天才的损失和新英雄的接棒

在Anders和Zack对于Delphi的走向逐渐出现了歧见之后，Anders便没有再主导
Delphi 3.0的开发，反之Zack在Delphi开发小组中的角色却日益重要，后来几乎是
Delphi 3和Delphi 4的主要领导人。为什么Delphi的Architect Anders会慢慢地淡出
Delphi的核心呢？这和Philippe Kahn离开Borland也有重要的关系。

英雄落难

Philippe Kahn和Anders共同创造了传奇的Borland，两人之间有着浓厚的感情。在
Borland工作时，对于Anders任何的想法和计划，Philippe Kahn都是不遗余力地支持。
也正是这个重要的支持力量，才有随后极为成功的Borland Pascal以及Delphi的问世。

但是在Philippe Kahn离开Borland之后，Anders再也没有了这股来自最亲密战友的强
力支援。1997年，Borland新的CEO Delbert Yocam在掌握了大权之后，Borland整个
公司开始走向第二个重要的转变，Delbert对于Borland产品的开发和趋势也有了不同
于Philippe Kahn的看法。当Java在1996年逐渐快速发展之后，睿智的Anders也看到
了Java成功的未来。因此在Anders不再积极参与Delphi 2/3的开发工作之后，他非常
希望能够主导Borland Java开发工具的开发，期望能够像当初的Delphi 1.0一样，为
Borland再次开发出全世界一级的Java开发工具。

不过，由于当时Delphi是Borland最重要的收入来源，高层仍然希望Anders继续在
Delphi产品线上投入全力，因此当时的Borland CEO Delbert Yocam并没有批准Anders
的请求。Borland的下一个重要的开发工具JBuilder，当时的产品开发名称为Latte，
仍然交由其他小组负责。依据我的推想，由于当时Anders对于Java已经有许多的想法，
因此才会有后来的VJ++以及C#，这些产品和程序语言的许多特性想必已经在Anders的脑
中存在了一段时间了。

Delbert没有允许Anders带领Latte开发小组，但Anders仍然没有放弃他的新计划。也
许是Anders注定和Borland的缘分已经到了尽头，这个时候正好Microsoft展开了有史
以来对Borland最大的挖角行动。在Anders无法在Borland取得满意的支持之后，
Microsoft提供的优厚条件顿时对Anders产生了致命的吸引力，从而造成了Borland无
法挽回的遗憾。

虽然Anders没有显赫的学历，无法获得Turning Awards(即图灵奖，信息科学界最高
荣誉的奖项，等同于诺贝尔奖)。但是我认为Anders的实力和贡献绝不输于任何一位
Turning Awards的得奖人。Anders是最好的信息实践型人物，在2001年，他终于获得
了信息界最具权威的信息刊物Dr. Dobbs' Journal颁发的Excellent Programming
Awards，以表彰Anders为信息界做出的卓越贡献。我想Anders应该是许多本身没有高
学历或不是计算机信息科系出身的优秀程序员最好的效仿对象。

Anders Hejlsberg这位不世出的软件天才，是目前全世界最顶尖的软件技术人员之一。
论实现技术，Anders可能是目前的第一高手，因为他精通程序语言、编译器技术、开发
工具、Framework以及系统架构。我虽然知道许多软件界重要的人物和好手，但是尚
不知有任何人能像Anders一样在这么多领域都能成为大家。下面是笔者整理出
Anders Hejlsberg到目前为止重要的功绩、贡献以及获颁的重要大奖：

"   和Philippe Kahn共同创办Borland

"   开发出Turbo Pascal，当时首创的In-Memory Compiler震惊了全世界

"   开发出全世界最畅销的Pascal产品，Turbo Pascal(这是许多信息人员学习Pascal
和Data Structure使用的经典产品)以及Borland Pascal。Turbo/Borland Pascal合
计销售超过了数百万套。Dr. N. Wirth(Pascal语言的创始人员)也应该向Anders致敬，
表达Anders对于Pascal语言的贡献

"   Anders使用汇编语言撰写编译器，其功力无人能出其右。创造出了全世界速度最快、
品质也是一流的Pascal编译器。在Anders离开了Borland之后，几乎没有人能够修改
Anders的编译器

"   开发出影响深远的Delphi这个伟大的RAD工具

"   开发出VJ++语言

"   Microsoft .NET的Architect

"   Microsoft颁授Microsoft Distinguish Engineer大奖

"   发明C#这个又将造成重大影响的语言

"   获颁2001年Dr. Dobbs' Journal的Excellence In Programming大奖

一个人一生能够做出几件让全世界都津津乐道的事业呢？Anders却成就了无数PC界伟
大的功绩，并且在程序语言、编译器、开发工具以及Framework方面都有重要的贡献。
PC软件界因为有了Anders而精彩、丰富了许多，也创造了许多令人惊叹的故事。更
棒的是Anders现在仍然在继续贡献他惊人的天分，就让我们拭目以待，看看Anders还
能创造什么功迹吧。不过，不管以后如何，相信Anders应该是大部分软件人员希望学
习的目标。Anders的功力也是大部分软件人员一生企望能够达到的境界。

在2002年Borland Developers' Conference中，Anders Hejlsberg是排名第一的
Keynote Speaker，尚在Java的创始人James Gosling之前。根据现场同时聆听这两场
Keynote Speech的听众报道，Anders的Keynote Speech是非常精彩的，而James的
Keynote Speech则相对的枯燥，许多人因此而提前离席。而且Anders在开始进行
Keynote Speech之时，便获得了现场所有听众起立鼓掌致敬，看来，在大多数Borland
开发工具使用者的心中，Anders Hejlsberg是永远的巨星。

Microsoft的挖角和Anders的离开

Anders在不介入Delphi的开发、并且无法主导Borland Java开发工具开发的情况下充
满了挫折感。没有了Philippe Kahn的强力支援，Anders虽然是Borland最顶尖的技术
人才，却也无法对抗Borland管理阶层的力量。当然这也是从Philippe Kahn离开了
Borland之后、Bodand开始转型有关，这在稍后Borland的转变一文中，我会作详细的
说明。

虽然Anders在Borland遇到了挫折，但是对于Microsoft来说这却是千载难逢的好机会，
在此时Microsoft展开了大规模的挖角行动，而且是明目张胆地进行，正是由于
Microsoft如此大胆的行动，因此也造成了不久之后Borland对于Microsoft的法律控诉。

这次的挖角行动中，Microsoft同时锁定了数个Borland最杰出或是重要的人物，当然
Anders是名列第一的挖角对象。时值1996年，Microsoft终于展开了行动，使用的方
式是最直接的攻击。Microsoft直接派遣加长型的大轿车到Borland大门口找Anders吃
饭，第一次Microsoft开出了年薪百万美元以上的条件。不过在Borland知道了这件事
情之后，也很快进行了加码的动作，因此Anders并没有对Microsoft进行响应。
Microsoft在苦等无应、按捺不住之下，很快就再次用大轿车找Anders。这次Microsoft
提出了两百万美元以上的条件，希望Anders能够首肯。对于这次的喊价，Borland可有
点为难了，因为两百万美元不是笔小数目，这已经比当时Borland许多副总裁的年薪还
高。此外，如果Borland答应也加到两百万以上，那么是不是Chuck也要如此加码？其
他的Delphi R&D小组要如何调整？这些都是非常棘手的问题。

不过Borland很快找到了解决的方案，那就是允许Anders从每一套卖出的Delphi版本
中抽取一定数量的版权费。如此一来Delphi卖得愈好，Anders便能取得愈多的回馈。
不过就我的了解，Anders注重的并不是金钱上的问题，因为在Borland创立的初期，
由于Turbo Pascal的编译器都是Anders撰写的，因此当时Anders也是卖一套Turbo
Pascal就可以抽取版税的。依照Turbo/Borland Pascal全世界销售数百万套来算，
Anders早就是富翁了。薪水多一点，少一点并无所谓，Anders心中想的是自由发展的
空间。在Borland提出了Delphi的随版抽税，再加上Microsoft并不知道Anders真正想
要的东西，因此Anders仍然没有响应Microsoft提出的优厚条件。

不过，Anders实在是太重要的人物，而且Microsoft在面对Java与日俱增的威胁下，
非常渴望能够有像Anders这样的人才带领Microsoft开发下一代的开发工具，这当然
也是由于Microsoft以前向Borland挖来的人都做出了不小的贡献所致。Microsoft食
髓知味，当然希望能够得到Borland的镇山之宝。在Anders两次不为所动之后，
Microsoft决定祭出最后的王牌，由Bill Gates亲自找Anders吃饭，进行最终的挖角
行动。

不管读者喜不喜欢Bill Gates，不可否认的是Bill也是一个天才。自古英雄惜英雄，
在Anders和Bill相谈甚欢的情形下，Microsoft开出了年薪三百万以上、数万股的
Microsoft股票这个超高的条件，再以当时Microsoft高贵的股价来计算，真是一笔庞
大的数字，也许对于搞软件技术的人来说，这已经是不可能的天文数字了。不过这些
条件并不是打动Anders的主要原因，Bill最后提出的条件是"答应给Anders一个小组
和极多的资源，让Anders尽情地发挥"。这个条件可说是打到了Anders的心底，因为
Anders正渴望有人能够支持他完成新的计划和想法。我想，在软件产业中大概也只有
Microsoft能够拥有这种雄厚的资源可以挖角任何人吧。

在Bill Gates提了这样的条件之后，Borland再也没有本钱能够和Microsoft进行比价
了，只好眼睁睁地看着Anders离开Borland前往Microsoft再开创下一个人生的高峰。
在Anders到了Microsoft之后，Bill Gates果然重用Anders，也立刻让Anders负责激
活Microsoft的下一拨开发工具计划，当然这个计划也是Microsoft对抗SUN/Java的整
体计划之一。Anders到了Microsoft之后立刻展现了实力，让Microsoft的编译器技术
又精进不少，最明显的例子就是Microsoft后期的Java Virtual Machine是PC上执行
效率最好的，而且在2、3年后，VJ++编译出来的虚拟机械码的执行效率不但比任何的
Java开发工具还快，在某些方面甚至比原生的Windows开发工具，例如Delphi、VB、
甚至是VC++还有效率。这真是令人震撼，当然Anders为VJ++打下的基础现在也展现在
NET的C#编译器以及.NET的JIT(Just In Time)编译器之上，.NET的JIT在许多程序代
码最佳化方面比Delphi还先进。因此在2、3年前当VJ++即将推出之际，在Borland内
部也引起了非常大的骚动，并且严阵以待，当然这又是另外一个故事了。

对于Anders来说，到了Microsoft之后不久又再次登上了生涯的另一个巅峰。因为当
初Anders在Borland之时，就有如孙子兵法中叙述的"藏于九地之下"，虽然是不世出
的天才，但是仅为少数的人所知，即使是使用Borland产品的人在当时可能也不知道
Anders这号人物。因为Anders和Borland的作风很像，都是行事低调，不到最后绝不
随意出手。但是Anders被挖角到Microsoft之后，由于Microsoft的企业文化向来是前
进、积极的侵略性方式，因此Anders也就转变为"动于九天之上"，负责Microsoft开
发工具大军的核心大将，不但广为人知，成为许多软件人员效法的对象，而且屡获大
奖。他不但获得了信息软件业界的推崇，最后也终于获得了信息学术界的认可，可说
是实至名归。

Anders的离开对于Borland来说是一个很大的损失，不过对于Delphi R&D小组来说却
是有好有坏，因为Delphi开发小组虽然失去了最重要的支柱，但是也给Danny Thorpe
一个快速崛起的机会，在1年后，Danny果然立刻成为了Delphi/C++Builder/Kylix中
最杰出的人物之一(另外一个当然就是Anders的老搭挡Chuck Jazdzewski了)，Danny
也是我认为目前在Borland RAD(注)部门中功力最厉害的人物。在稍后的内文中我会
对Danny进行比较详细的说明。

注：Borland RAD部门是指Borland的Rapid Application Development部门，RAD负责
的产品包含了C++Builder、Delphi、Kylix以及未来的.NET以及Mobile的新产品。

巅峰之作和最后的胜利者

在Zack于Delphi 3开发的后期和Paul Gross逐渐取得了主控权之后，Delphi的发展方
向也偏向了Zack希望的Multi-Tier的技术以及由Paul Gross稍后主导的Borland
Golden Gate计划。1997年，Delphi还是像Delphi 1/2一样以强劲的生命力，以一年
一个大版本的速度准时推出了。当时Delphi 3也称为Delphi 97。Delphi 97和
Delphi l/2一样有一个最重要的战略目标以及主要的革新技术，那就是Multi-Tier和
COM/DCOM的支持。因此，当时97推出之际使用的行销术语是"Component Foundry"，
意指Delphi 97能够开发任何的软件组件(事实上是指VCL、COM/DCOM以及ActiveX组
件)，而且使用组件来开发Multi-Tier的应用系统。

Delphi 97无论是在品质、功能或是市场和销售上都是非常成功的。也许是为了证明
即使是没有了Anders，Borland的Delphi R&D小组仍然有实力开发出优秀的Delphi产
品，因此Delphi 3一推出的品质就在高水平的地步，后来Delphi 97销售的结果也证明
了它没有令人失望，Delphi 3的推出让Delphi一举突破了150万套的销售大关，也几
乎成为Borland有史以来最畅销的单一系列开发工具，我也认为Delphi 3是Delphi所
有版本中最好的一个。

不过，Delphi 97在即将推出之时也令一些人感到忧虑，因为在当时几乎没有任何开
发工具强调Multi-Tier的开发，大多数的开发工具仍然着重在Client/Server的功能。
Delphi 97将许多新功能集中在Multi-Tier的开发的确是一个不小的冒险，因为在当
时Multi-Tier的观念还非常的新颖，许多人对于Multi-Tier是什么？能够用来开发什
么？为什么要使用Multi-Tier等等问题都不是很清楚。更重要的是，在那个时候
Multi-Tier的基础工程都尚未完全准备好，使用者要如何使用Multi-Tier技术来开发
应用系统、甚至是学习Multi-Tier的技术呢？

我所谓的"Multi-Tier的基础工程都尚未完全准备好"，是指在那个时候Microsoft的
DCOM技术都还没有推出。那么，Borland该如何在Windows平台上提供Multi-Tier应用
系统需要的分布式技术呢？说到这里，我们也不得不佩服当时Borland这些Delphi
R&D小组的眼光，他们几乎已经精确地看到了未来的软件计算世界将会由网络和分布式
技术主导，因此，即使是在操作系统平台尚未准备好的情形下，Borland也决定快速
向前出发。

另外一个驱使Delphi 97走向Multi-Tier的重要原因便是当时Borland已经准备走向组
件技术的领域，准备在中间件(Middle-Tier Software)中成为一个关键的软件开发厂
商，这就是Paul Gross和Zack Urlocker激活的Golden Gate Strategy。而Paul Gross
也就是由于Golden Gate计划扬名立万、进而成为当时Borland整个研发部门的副总裁
(Vice President)，后来又成为Microsoft下一个挖角的对象。

为了配合Golden Gate计划并且成为分布式技术的领导厂商，Borland由Paul Gross主
导并购了Boston一家有名的顾问公司，这家顾问公司拥有一个颇为知名的中间件
"Entera"。Entera是一个以RPC(Remote Procedure Call)通信协议为骨干的中间件，
Borland希望通过Entera快速进入中间件的市场。由于Entera的客户端能够执行在
Windows的操作系统中，因此，Entera在Windows平台上拥有基础的分布式技术支持
能力，这刚好提供了Delphi 97需要的技术，所以Delphi的R&D小组立刻使用VCL封装
了Entcra的底层API，提供了一个称为OleEnterpriseConnection的VCL组件，让
Delphi 97能够和以RPC为基础的中间件连接。

因此在Delphi 97中Borland提供了三种分布式连接组件，分别是使用DCOM技术的
DCOMConnection、使用TCP/IP技术的SocketConnection以及OleEnterpriseConnection。
在那个时候最成熟的技术应该是OleEnterpriseConnection，而使用DCOM技术的
DCOMConnection在Microsoft本身DCOM尚不成熟的背景之下，表现得并不好。至于
SocketConnection，我认为Borland一直没有很认真地地实现SocketConnection，因此
最好只可以用来作为学习的对象，尚未到达可以真正应用的水准。不过稍后随着时间
和技术的进步，OleEnterpriseConnection逐渐没落，而DCOMConnection则反而因为
Microsoft的DCOM的慢慢改善而成为比较实际的应用对象。当然，这些又属于
Delphi 4的开发故事了。

虽然Delphi 97采取了比较冒险的做法，但是由于其品质良好，又支持COM/VCL组件的
开发，因此也很快征服了Delphi使用者的心而大获成功。当时许多Delphi的使用者仍
然是以开发Client/Server应用系统为主，不过由于Delphi 97好用的COM技术以及应
用Web的WebBroker技术，再加上Multi-Tier的功能，都让使用者大呼过瘾，把Delphi
作为学习这些先进技术的好工具，因此Delphi 97在当时到达了巅峰的地步。而
Delphi/VB和PowerBuilder/Gupta缠斗的情形也逐渐明朗。Delphi/VB的销售量和市场
占有率已经远超过PowerBuilder/Gupta 了，PowerBuilder/Gupta也注定将从通用开发
工具以及主从架构开发工具市场中让出绝大的市场份额。

其时PowerBuilder仍然不肯服输，并且坚称PowerBuilder在总收入方面仍然是第一。
这是因为PowerBuilder在当时仍然非常的昂贵，比Delphi/VB至少贵了两三倍以上。
但是在不断地快速流失市场的情况下PowerBuilder的售价很快就出现了大幅的下降，
至此Delphi和VB终于获得了全面的胜利；Client/Server开发工具的战争已止，但是
接下又上演了另一出精彩的Java开发工具大战。

危机的开始

在Delphi 3再次获得了胜利之后，Delphi 4决战的目标已经从Delphi、VB、PowerBuilder
和Gupta混战的形势转变为和VB对战的局势。原本Delphi有继续进击的机会，因为在
当时Delphi 3的功能的确强劲，而且许多功能都领先业界至少半年以上的时间，不过
可惜的是，在1996年Borland担任CEO的Delbert Yocam先生正好在这个时候开始了改
造Borland的计划，几乎造成了对Delphi不可挽回的错误，这要从Zack Urlocker被
Delbert Yocam拔擢成Borland Marketing的副总裁开始说起。

1996年11月，Borland邀请了Del Yocam入主Borland成为新的CEO，希望通过Delbert
Yocam在管理方面丰富的经验改善Borland长久以来在公司管理方面的积弱不振。
Delbert Yocam原本是Apple计算机公司的副总裁，应该是拥有丰富的管理经验，不过
不知道Delbert是不是在大型计算机公司呆惯了，因此花钱花得特别凶。Delbert在一
进入Borland之后立刻花了大钱更换总裁办公室里所有的家俱和装潢，其后到各地出差
时又要求头等舱以及总统套房，花钱像流水一样。当时我便对这位新的CEO没有什么好
印象。

Delbert在进入Borland之后一直想改造Borland。在Delphi 3大获成功之后，Delbert
便把重点集中在Delphi的身上。Delbert认为Delphi非常成功，是Borland的摇钱树，
因此一直想从这个产品线获得更多的收入。好大喜功的Delbert觉得Delphi的根基已
经很稳固，因此可以更快速地从Delphi身上取得资源。这让Delbert在1998年下了一
个严重的错误决策，几乎折损了Delphi的大好基业。

Borland和Microsoft的法律大战

在Microsoft不断地挖角，甚至把Anders也挖走之后，Borland已经到了"士可忍，孰
不可忍"的地步。Microsoft挖角的动作愈来愈像是恶意挖角，似乎是想把Borland搞
垮。Borland无法忍受的是Microsoft不但在操作系统和开发工具上进行不公平的竞争，
现在甚至进行人事上的不公平竞争。Microsoft不思在产品上和Borland一决雌雄，反
而进行挖墙角的破坏，Borland实在是忍无可忍了。

1997年5月，Delbert Yocam终于向美国法院提出了对于Microsoft的控告。当时Borland
提出的控诉理由是"Microsoft对于Borland进行Brain Drain"的行动。Microsoft在30
个月内从Borland挖角了34名Borland关键的开发者，而且每一名被挖角的人到了
Microsoft之后都担任和在Borland类似的角色，这摆明了就是要利用这些人在Borland
的知识快速地帮助Microsoft提升和Borland的差距，并且了解Borland内部的产品和技
术的开发状况。这种不公平的竞争应该是没有任何一家公司能够容忍的。

在Borland正式提出了诉讼之后，具备侵略性企业文化的Microsoft当然就立刻反击，
和Borland对簿公堂。Borland和Microsoft从开发工具战场一直斗争到法律战场，互
不相让的情形让许多看客大呼过瘾。Borland对于Microsoft来说似乎就是打不倒的勇
者，不管情势再艰辛，仍然能对抗到底，因为Borland知道，对于Microsoft一旦让步，
以后就永远没有机会了。当时，业界许多人都已经预测Borland迟早会采取行动，但
是没有想到这么快就勇敢地响应。Borland当时的行动引起了许多信息业界的尊敬和
支持。

这场官司的进行很快就有了初步的迹象，所有的证据都对Microsoft不利。Microsoft
一看情势不对，又不想让Borland真的消失，以避免吃上在开发工具市场垄断的官司，
所以立刻表达愿意和Borland在庭外和解。正是由于这个原因，才有后来1999年时
Microsoft对于Borland的投资，Microsoft这项投资正是这次庭外和解的条件之一。
不过Delbert的运气并不好，虽然Microsoft愿意和Borland进行庭外和解，但真正和
解的动作以及Microsoft对于Borland的赔偿事项却是发生在Delbert之后的Borland下
一任CEO，即Dale Fuller身上，Delbert种下的稻穗却是由Dale Fuller来收割。

接二连三的错误决策

1998年，Delbert Yocam再次展现了好大喜功的本性，在没有充分地讨论以及共识之
下，Delbert Yocam决定把公司名称从众所周知的Borland改为Inprise。Delbert决定
如此做有数个原因：

"   由于Paul Gross和Zack Uplocker的Golden Gate计划让Borland进入中间件市场，
因为Borland在企业市场以往没有很强的知名度，许多人认为Borland只是开发工具厂
商，因此Delbert为了解决这个问题决为Borland取一个新的名称

"   使用Inprise的意思是指Borland可以Integrating The Enterprise。为提供企业整
体解决方案的软件公司

"   基本上Delbert Yocam在进入Borland之后已经开始改变Borland，悄悄地进行第二
次Borland改造的行动。这就是以行销为主的Borland，有别于以往Philippe Kahn所
领导的以产品/技术为主的Borland。为了代表Delbert的决心并且重新出发，Delbert
认为公司该使用一个新的名称

1998年4月，在Delbert的主导之下，Borland花费了数百万美元之后终于改名成为
Inprise公司。不过Delbert原本是想在更改公司名称之后可以重新出发，但是没有想
到，在Borland改名为Inprise之后，各种负面的效果却接踵而来。

首先，传统的Borland使用者都强烈反对Inprise这个名称，这些Borland使用者都喜
欢原来的Borland。第二个问题，是许多新的使用者都听过Borland，但是在改名之后
这些新的使用者找不到Borland，以为Borland已经不见了，又从未听过Inprise这家
公司。第三，则是竞争对手刻意放出的讯息，故意散布Borland已经被一家叫做Inprise
的公司并购了，因此希望原先的Bor]and用户能够放弃使用Borland的产品。

Delbert万万没有想到，在花了大钱更改公司名称之后，Inprise(Borland)却开始得
疲于奔命地应付各种不利的后果。结果是赔了夫人又折兵，不但浪费了资源却无法在
企业市场闯出名号，又折损了Borland的金字招牌。

另外一个有问题的决策是把Zack Urlocker拔擢成Borland行销部门的副总裁。由于Zack
在Delphi 3出色的表现，以及和Paul Gross激活的Golden Gate Strategy让Delbert
心动，并且Delbert认为通过Golden Gate Strategy可以让Borland打入企业市场，因
此Delbert对Paul Gross和Zack Urlocker都印象深刻。不久之后，Delbert分别提拔
了Paul Gross为Borland开发工具部门的副总裁、Zack Urlocker为行销部门的副总裁。

本质上Zack是一个非常好的开发者，对于产品也有很敏锐的感触，应该是非常理想的
产品线管理人物，Borland应该让Zack好好地呆在R&D部门，为Borland的产品线运筹
帷幄，好好地开发Borland以后的产品。只可惜的是"水往低处流，人往高处走"，副
总裁的位置放在面前，Zack当然想升官发财(谁不是呢？)。不过Zack并没有想到自己
的优缺点。他固然是出色的开发人员和产品开发人员，但是对于行销却是门外汉。在
Zack做了行销副总裁之后，Borland的R&D小组不但失去了一员大将，更糟糕的是Zack
似乎也开始向Delbert学习，慢慢有了好大喜功的做事方式。

首先，Zack扩充Borland行销人员到达了100多人的数目。可是，当时全世界Borland
的员工才将近1000多人，行销的人员居然超过九分之一的比重，实在是太夸张了。不
过，这么多人的部门在当时仍然没有做出什么好的行销工作，仍然被Borland的使用
者抱怨。我还记得当时我曾向行销部门要求所有开发工具的市场竞争资料，结果行销
部门只说没有这种资料，当时我还很生气，这么庞大的部门居然连这么基本的竞争信
息都没有。事实上，当时Delbert Yocam同意让Zack的行销部门招聘这么多人，除了
是因为Zack很红之外，和Delbert想改善以往Borland做得很烂的Marketing工作也有
很大的关系。Delbert认为Zack在产品线方面表现得很出色，因此也希望通过Zack的
能力来进行Delbert对于Borland行销方面的改善工作。

可惜的是Zack上任之后表现得不如预期，大家对于Zack的表现也是贬多于褒。很快，
Zack就失去了以往在R&D小组时的自信满满，开始逐渐消沉，最后终于离开了Inprise
(Borland)。Zack从因为Borland C/C++3.0时的OWL framework快速窜起，在Delphi
3时达到生涯的高峰，一直到以行销副总裁之尊黯然离开Borland，真是令人感慨。如
果Zack能够清楚了解自己的优缺点，不要去接行销的工作，而继续在R&D部门发展，
也许他会有更好的成果。从Zack的奋斗过程，我认为程序员也许应该想想自己未来的
发展方向，好的技术人员一定是好的管理或是行销人才吗？

一开始我知道Zack Urlocker这号人物，是在数年前我还在Georgia Institute of
Technology念书时从那时著名的"Windows Tech Journal (WTJ)"得知的。当时Zack在
WTJ上一直有Object Pascal的专栏，写的内容都非常好，深深地吸引了我。因此当时
每个月初都开车大约半小时到最近的计算机商店购买当期的WTJ，目的就是为了阅读
Zack的文章，在那个时候我就认为这个家伙真是厉害。

据我所知，Zack在1999年离开了Borland之后，加入了Active Software以及数个其他
的软件公司，大都是担任行销方面的高阶主管。Zack在其后的数个职位上表现得不错，
不晓得是不是因为在Borland时缴了大量学费而学习到的知识。不过不管如何，我仍
然认为Zack Urlocker是一位值得尊敬的人物，因为他至少在一生中开发了2个重要而
且成功的产品"Borland C/C++和Delphi"，本身的技术水准也很高。相信Zack也将永
远记得Borland C/C++和Delphi，这两个产品是Zack一生的成就和骄傲。再见了Zack
Urlocker，相信许多的Borland C/C++和Delphi的使用者都会记得你的。

自巅峰而下--Delphi 4

中国人一直不喜欢"4"这个数字，认为它不吉利。难道说"4"对于Borland来说也是一
个挥之不去的噩梦吗？当初的Borland C/C++4．0对Borland来说是永难忘怀的噩梦，
到了Delphi 4，难道Borland又要重蹈覆辙吗？

时值1998年，是下一个Delphi版本应该要推出的年份，也是Delbert Yocam进入Borland
当CEO的第2年。对于美国企业的CEO来说，第2年是CEO向董事会显示经营绩效以及缴
出成绩单的时候了。Delbert为了能够缴出靓丽的成绩单，因此在1998年决定必须拉
高Borland的营收，以冲高Borland的股票价格。但是，当时的Borland才刚进入组件
和中间件的市场，尚未在企业市场占稳脚跟，因此Delbert决定在Borland的开发工具
产品线中动脑筋。Delbert做的决定就是强迫规定从1998年起，在每一个Quarter(也
就是每3个月)，每一个Borland产品开发部门都必须推出一个新产品，让Borland每一
个Quarter都有新产品可以销售，以便增加Borland的营收。

不过，DelbeN这个决定却相当的糟糕，这让Borland每一个产品部门的主管都面临了
强大的压力，因为即使是产品还没有准备好推出，但是时间一到，不管产品品质如何，
都一定要出货。Delbert这个错误的决定让1998年又成为Borland的噩梦年。

Delphi 1、2和3的时间间隔都是1年多一点，展现了Delphi强劲的生命力。依照原本
的计划，Delphi 4也应该是在1998年推出的。但是1998年Borland在内部开始研发数
项新的科技和产品，加上Microsoft不断的挖角行动，都让Delphi 4的研发工作受到
了延迟。依照当时Delphi 4的研发时程，Delphi 4最早应该在1998年的第4季才能够
推出。但是很不幸的是，为了达成Delbert Yocam的要求，Delphi 4在1998年的第三
季就必须出货。在接近1998年的第3季之时，虽然Delphi的R&D小组仍然无法完成
Delphi 4，并且极力抗拒出货，无奈在CEO强大的压力下，Delphi 4仍然必须在第3季
准时出货。

从我个人的角度来看，当时Delphi 4的产品品质应该只到Beta 2的阶段，离真正能出
货尚有一段不小的距离。Delbert强迫Delphi 4推出，不但打击了Delphi R&D小组的
土气，如此乱搞产品线，以外行领导内行的结果只是让Delphi砸坏了自己的招牌。不
过站在Delbert的角度则又不一样了，因为对Delbert来说，如果在1998还无法冲高
Borland的营收，那么Delbert肯定是要下台的，因此Delbert只有孤注一掷了。

1998年的第3季，Delphi 4果然被强迫推出了。虽然Delphi 4的新功能仍然亮眼，但
是品质不稳的恶名也很快地出现在使用者的抱怨之中。随后，使用者的不满愈来愈强
烈，Borland面对四面八方的反弹不得不快速地做出响应，立刻开始着手Delphi 4
Patch的开发，以期快速修正Delphi 4的臭虫。依我的看法，Delphi 4一直要到
Patch 2才应该是当初Delphi 4出货时的品质。由于Delphi 4的反应不佳，因此未能
再次把Delphi的销售量拉上新高，Delphi原本锐不可当的气势也为之一挫。对于
Borland来说，Delphi 4的销售并没有增加太多的收入，Delbert打的如意算盘当然也
落空了。Delphi 4的失败也严重地影响了C++Builder的品质和销售，Delbert恶搞产
品的开发之后不但又让Borland开始赔钱，终于也自尝恶果，在1999年被Borland的董
事会开除。不过。无论如何，Delbert的决策已经对产品造成了巨大的伤害。

虽然Delphi 4的诞生过程充满了困难，命运也很坎坷，不若它的兄弟般好命。但是
Delphi 4却意外地向全世界揭露了Delphi另外一个Architect的庐山真面目，那就是
Chuck Jazdzewski。在Delphi 4中，使用者只要开启About对话盒，并且按下
"Alt+chuck"，那么就可以看到下图的画面。这个简短的画面是Delphi R&D成员之一
偷偷使用V8录下来并且放入Delphi 4中的，这也是第一次Chuck露脸于全世界。Chuck
事先并不知情，而在以往的Delphi 1/2/3中放的人物图片则一直是Anders。这些隐藏
的有趣图片以及Delphi R&D开发小组的名单在Delphi中称为"Eastern Eggs"。

直到1999年，在费城举行Borland Conference时，我才真正有机会见到Chuck，并且
和Chuck当面讨论一些事情。Delphi 4的失利让Delphi从巅峰的态势往下沉沦，要等
到Danny Thorpe继Zack之后掌握Delphi的研发大权后才能再次向前挺进。

Delbert最后的挣扎

由于Delbert错误的决策先后让Delphi 4和C++Builder 4失利，Borland每季又开始亏
损了。显然，Delbert自己也心知肚明，如果再没有任何建树的话，他很快就要下台
了。为了做最后的挣扎，Delbert决定和其他公司合作。1998年正是Java快速兴起的
年份，SUN在JavaWorkshop失利之后，便一直想找一个好的Java开发工具。而当时
Borland发表了JBuilder 2，虽然JBuilder还不是Java市场上最受欢迎的Java开发工
具，但是JBuilder是最快速成长以及最受好评的Java开发工具。SUN看到了JBuilder
的潜力，因此对于JBuilder拥有强烈的兴趣。

SUN显示了对JBuilder的兴趣，无疑给了Delbert Yocam打了一针强心剂，几乎在绝望
中的Delbert似乎看到了一丝曙光。Delbert很快便和SUN接触，看看SUN能够提出什么
条件。Delbert的如意算盘是让SUN花大钱并购Borland，如此一来，JBuilder不就自
然成了SUN的产品了吗？由于在那个时候Borland的股价已经跌到了3到4美金之间，而
SUN的股价却高高在上，大概是在80多美金。因此，如果Delbert能够促成合并，那么
Delbert Yocam便可以大捞一票，甚至在并购之后，Delbert还有可能成为SUN的副总
裁，继续位居要津。

不过世事不能尽如入意。SUN只对JBuilder有胃口，对Borland其他的产品却没有多大
的兴趣，因为Delphi/C++Builder等都不属于Java系列的产品。而且Delbert Yocam又
狮子大开口，希望SUN以每股20几美元的代价收购Borland的股票，当场吓得SUN退避
三舍，这件事情后来也就不了了之了。当然，Delbert Yocam很不甘心，因为促不成
这宗合并案子，再加上Borland被Delbert搞得乌烟瘴气，下台的命运也就不可避免了。

也许是"天将降大任于斯人也，必先苦其心志，空乏其身"吧，Borland在Philippe Kahn
离开之后，历经了数任CEO，但是一直没有找到真正好的CEO，能够适当地带领Borland
走向光明。不过Delbert Yocam似乎是黎明前的黑暗，在Delbert不名誉地离开Borland
之后，Borland也即将看到未来之光。

Danny的接棒和决心

Delphi 4的仓促推出果然在市场上反应很差，销量上也一落千丈。原本寄望能够再次
获得好成绩让Delphi的总销售量再次冲上新高，并且为Borland带来更多的营收。但
这一切都很快地幻灭了，品质不好的产品仍然得面对市场严厉的考验。在Delphi 4遭
受了前所未有的失败、接着C++Builder 4也铩羽而归之后，Borland又开始走下坡路
了。Borland好不容易通过Delphi带来的希望却在错误的决策下被牺牲了。在1999年
4月Delbert终于被Borland的董事会扫地出门，结束了在Borland的日子。我认为，
Delbert在Borland将近3年的时间里，对Bodand造成了许多的伤害，其好大喜功的管
理方式对Borland的产品线更几乎造成了无法弥补的伤害，是我所认为的最糟糕的
Borland CEO。更离谱的是在Borland的董事会开除Delbert后，他居然还以合约未满
为由，要求Borland支付额外的谴散费，大捞了一票，真是人心不古，工作做得如此
差却还有脸提这种要求，在最后一刻仍然压榨Borland。

在Delphi 4的伤害造成之后，Delphi R&D小组要面对的是如何收拾残局，并且想办法
解决造成的问题。在这个时候Chuck由于把精力放在Borland另外秘密的产品和技术的
研发上，因此无法花太多的时间在Delphi 5的研发上。此时，在Delphi上一向表现良
好的Danny Thorpe便逐渐挑起了Delphi的重负大任。

Danny在Delphi 2之后便有大将之风，开始负责Delphi最低阶的编译器以及RTL(Run-
Time Library)的工作。Danny是美国San Diego大学毕业的，主修就是编译器技术。
在Delphi 4之后，Danny几乎成了RAD部门主要的Architect，负责了RAD大部分产品的
研发工作，甚至又成为Microsoft再次挖角的对象。

对于Danny来说，如何重塑Delphi 5让Delphi从失利中重新站起、找回昔日的光荣便
是一个非常重要的工作。在Delbert Yocam于1999年离开Borland之后不久，现任的
Borland CEO Dale Fuller先生便被Borland邀请加入成为Borland的代理CEO，希望能
够通过Dale Fuller的经验挽救沉沦中的Borland。在Dale入主Borland之后，首先展
开的工作除了整顿Delbert在位时形成的庞大无用的行销部门之外，在产品线方面则
是看好Linux的未来，要求Borland的RAD部门必须开发出Linux下的RAD工具。

在Danny接掌了Delphi主要的开发责任之后，又和Chuck一起再次形成中坚的RAD精英
份子。Chuck主要负责新技术和新构想的实验作品，而Danny则是负责困难的编译技术
以及RTL。由于Turbo/Borland Pascal以及Delphi的最佳化编译器都是Anders
Hejlsberg撰写的，因此当Anders离开Borland之后几乎没有人能够维护编译器程序代
码。Anders都是使用汇编语言(Assembly)撰写复杂的编译器程序代码，而且其品质是
如此之好，不但连Chuck Jazdzewski都赞不绝口，更麻烦的是当时Borland几乎没有
工程师敢随便更动这些程序代码。

因此在Anders Hejlsberg于Delphi 2离开了Borland之后，Borland立刻采取了数项行
动希望能够解决这个"烫手山芋"。Borland决定的第一件事情是从Delphi的编译器抽
离大部分最佳化的工作。因为要在Anders的程序代码再继续加入最佳化程序代码是
Borland当时没有把握的事情。另外，由于当时Borland已经决定开发C++Builder，
而C++Builder也需要一个最佳化的编译器，因此，Borland认为如果能够提供一个共
同的后端最佳化编译器，那么Delphi和C++Builder不仅都可以使用，还能够解决没有
人敢修改Delphi编译器的问题。这个决定就是后来Delphi 3以及C++Builder 2推出之
后Borland宣称的"Delphi和C++Builder可使用共同的后端最佳化编译器"，这个工作
当时是交由Borland的编译器小组Lee他们负责的。

不过共同的最佳化编译器只解决了一半的问题，对于Object Pascal语言本身的改善
仍然需要能够修改Anders撰写的编译器，那么到底谁能够进行这个工作呢？答案当然
就是另外一个软件天才--Danny Thorpe了。Danny在接手Delphi的开发大任之后，就
开始为已经停止开发一段时间的Object Pascal语言本身进行演进的工作。此外，
Danny也开始为Delphi底层的RTL进行改造，并且为Delphi的编译器加入更多最佳化的
功能。

Danny之所以同时在ObjectPascal程序语言、Delphi RTL以及Delphi编译器进行渐进
的改善工作，是有许多因素影响的。首先，当然是为了接下Anders留下的工作，另外
一个原因是在Delphi 3之后，必须再次对于COM的支持进行强化。最后，是为下在
Delphi 4之后，准备把Delphi移植到Linux上。事实上，Borland在Delphi的R&D小组中曾经
一度准备把Delphi和C++Builder移植到SUN的作业平台上，这是为了因应Delbert和SUN
合并时进行的准备工作。甚至Delphi的R&D小组认为，既然要开发跨平台的Delphi和
C++Builder，那么不如把Apple的Macintosh操作系统也纳入考虑。Delphi的R&D小组
在当时甚至已经列出了开发SUN和Macintosh平台的时间表，但是稍后随着和SUN合并
计划的破灭以及Delbert的下台，这个跨平台的Delphi计划也就暂停了。一直等到Dale
Fuller上台强力要求开发Linux平台的RAD工具之后，Delphi的R&D小组才再次激活跨
平台的计划。

为了支持更好的COM开发能力，Danny修改了Delphi的编译器，直接支持COM接口的参
考计数值(Reference Count)的维护工作，以免除开发者繁杂的程序代码，提供了类
似Visual Basic的能力。同时Danny也在Object Pascal程序语言本身中加入接口
(Interface)的机制，让Object Pascal和Java一样对接口程序设计都提供First Class
的支持。Danny并且更进一步，巧妙地结合COM的接口以及Object Pascal程序语言的接
口，让Delphi的程序员更方便地使用和处理COM接口。Danny的这些努力，就是Delphi
的使用者在Delphi 3之后逐渐在Object Pascal中看到的Interface机制。对于非常熟
悉Delphi的读者来说，应该可以发现Delphi 1/2中Object Pascal变化的部分很少，
但是从Delphi 3之后，每一新版的Delphi在Object Pascal程序语言本身都有进步，
这些都是Danny所做的努力。

在RTL方面，Danny更是投注了大量的心血，Danny的第一步是去芜存菁。Delphi经过
了三、四年的发展，许多RTL中的程序代码不是过时，就是需要进行最佳化的调整。
因此从Delphi 4开始，Danny便逐渐整理和改善Delphi的RTL，这方面的成果从
Delphi 5之后便逐渐显露出来，Delphi的RTL不但在效率方面有了进步，更提供了愈
来愈多以前版本的Delphi所没有的功能。当然，Danny在Delphi RTL方面最大的贡献
是改善RTL成为跨平台的基础。Danny维护后的Delphi RTL最后也成功地移植到了Linux
平台上，并且克服了许多Windows以及Linux平台差异处的困难。当然，Danny Thorpe
和Chuck Jazdzewski是Kylix得以推出的最重要的功臣之一。为了解决Kylix在Linux
平台上许多的技术问题，后来还引起了Linux开发者社群围攻Danny Thorpe的精彩大
戏，最后导致Danny Thorpe不再管Kylix的开发而全力投入.NET的阵营，这当然又是
另外一个极为精彩的故事了。

对于Danny来说，只有一个最重要的目标，那就是再次擦亮Delphi的光芒，让Delphi 4
的失败能够在下一个版本中一雪前耻，并且把Delphi开发成最棒的RAD开发工具。Danny
的决心也让Delphi R&D小组再次安定了军心，在历经了Delbert错误的决策、Microsoft
大幅的挖角、Delphi 4的失利之后，Danny带领了一些新的Borland工程师展开了艰苦
的工作。

Danny的杰出表现早已深获许多人的赞扬和肯定，也充分地展现了继Anders Hejlsberg
之后，Borland另外视为宝贝的天才的风采。现在，Danny不但早已独当一面，更成为
了Borland .NET的Architect，负责综合整理Borland未来在.NET上的开发工具。在2002
年Borland的Conference上，Danny正式由Borland的CEO Dale Fuller先生颁发
Borland President Awards大奖，这是继Chuck Jazdzewski、Blake Stone之后，
Borland第3个获得最高殊荣的R&D人员。在Danny接受大奖之时，现场所有的BorCon参
加人员都起立热烈鼓掌，看来，即使在Borland没有颁发这奖项之前，Danny早已被所
有了解他的贡献的人所肯定和钦佩，这只是一个迟来的奖项而已。

我曾在1999年费城的BorCon见到了Danny，并且在澳洲举行的BorCon和他有简短的对
话。Danny的身材不算高大，瘦瘦的，但是非常的温文尔雅。和Danny讲话是一件很舒
服的事情，因为你可以问他许多技术的问题，只要Danny有时间，他会很乐意和你讨
论的。

恭喜Danny!Borland又为PC软件界培养了一个天才和明星。我相信Danny Thorpe也将
成为许多开发者学习的对象，当然也包括我在内。

和对Anders Hejlsberg一样，最后再让我整理一下Danny Thorpe对于Borland和产品
线重要贡献和获得的殊荣，让读者也能对这位值得尊敬的软件开发人员致敬：

"   负责开发Delphi RTL/编译器困难的工作

"   改善Object Pascal程序语言，加入现代语言元素--Interface

"   开发出Kylix并且解决Linux平台的臭虫

"   1999年被Borland内部评选为全Borland最重要的50人之一，是Borland不可放弃的
人才

"   2001年荣升Borland .NET Architect

"   负责开发Borland .NET下一代整合开发工具--Galileo

"   和Chuck Jazdzewski共同开发代号为Charlotte的下一代Web Service程序语言

"   2002年于BorCon获Borland President's Awards大奖殊荣

对于我来说，Borland孕育了无数的伟大软件工程师，当然有一些人我无缘认识，因
此对于这些人，我只能说是"久仰大名"，例如Windows平台的系统和除错大师Matt
Pietrek。但是有一些人却是我认识、甚至有过对话的。这些人每一个都令我折服，
也让我向往这些伟大软件工程师到达的境界，他们是：

"   Borland C／C++、dBuilder的Framework大将Carl Quinn

"   不世出的软件天才Anders Hejlsberg

"   Borland首席科学家Chuck Jazdzewski

"   Borland RAD核心支柱Danny Thorpe

当然，还有本书稍后会叙及的Java天才，Mr. Blake Stone。

重回基本的精致之作--Delphi 5

1999年8月，距离Delphi 4推出将近一年之后，由Danny领军的Delphi 5终于准备推出
了，这次没有CEO不合理的要求，Borland又投入了适当的资源，再加上Danny和
Delphi R&D小组的全心开发，Delphi的开发步调又回到了以往的轨道。在Danny
Thorpe的细心和坚持之下，Delphi 5在推出时的完成度是非常高的。

注：Borland的每一个产品在推出之前都会进行完成度测试和评估，这和其他的软件
是一样的。每一个产品在完成度到达多少才推出是不一定的，一般来说在85%以上就
是不错的产品，低于80％就推出的产品则等于是推出Beta版的软件，品质一定不好。

当Delphi 5推出到市场之后，其品质果然又受到了Delphi使用者的喜爱，销售数字也
证明Delphi 5已经成功地扫除了Delphi 4时埋下的阴影。再加上当年的JBuilder 3又
迈入了一个全新里程，打造成了一个完全由Java撰写的Java开发工具，因而大获市场
肯定，进而正式为Borland在Java市场带来了空前的胜利和大量的收入。Borland又开
始产生盈余了，Delphi和JBuilder从1999年开始也正式成为了Borland的两大摇钱树。

不过Delphi 5虽然成功，但是从销售数字来看，Delphi的销售几乎已经到了顶峰，不
易再高度成长并且带来更多的收入，这从其他Windows传统开发工具的情形也可以看
得出来。所以对于Borland来说，应该要开始为Delphi准备下一代的功能和平台了，
重新设计Delphi的所有功能和GUI接口，再次地演进Delphi的风貌。即使Delphi也和
Visual Basic、PowerBuilder一样即将走入下一代的开发环境，但是Borland仍然有
责任在世代交替之间提供Delphi使用者顺利的移植方案。可以很明显地看到，
Delphi 6提供了Web Service功能让以前和未来的应用程序能够相互整合，Delphi 7
则将提供Microsoft .NET平台开发的功能。Delphi 6和Delphi 7即是为Delphi的开发
者走向未来提供的垫脚石。

Delphi 5应该是Delphi 3之后最好的一个Delphi版本，称为Windows平台下最好的RAD
开发工具是当之无愧的。虽然Borland RAD小组持续的开发最好的Windows开发工具，
但是在Windows平台上的开发模式却已经悄悄地进行了自DOS以来最大的改变，那就是
Microsoft为了因应Java的攻势而展开的 .NET计划。Windows平台上的开发概念、开
发工具和开发技术即将揭开新的序幕，Microsoft也准备逐步淘汰原生的Windows开发
工具。

PC平台上的开发工具从DOS、Windows到未来的.NET，一共历经了数个阶段。在每一个
阶段，开发工具的市场都有着群雄逐鹿、竞争惨烈的战况。开发工具市场几乎是所有
软件中竞争最激烈的。从DOS时代PC的开发工具市场有着数10家软件厂商竞争，到了
Windows平台只剩下10几家、最著名的也就不过五六家，再延续到未来.NET的平台，
举是轻重的开发工具开发商可能会只剩下Microsoft和Borland。

上面的表格是我整理从DOS、Windows第1个阶段、Windows第2个阶段以及未来.NET平
台下的开发工具竞争情势。从上表中，读者可以看到不同的阶段主宰流行的程序语言、
以及最后在开发工具市场胜出的厂商。开发工具情势的演变是Microsoft和Borland
仍然将主宰这个市场，其他的厂商只能占有极小的市场和影响力。Borland也证明了
只有她能够和Microsoft抗衡，也是在Windows平台下，除了Microsoft之外唯一的独
立开发厂商。我相信Microsoft和Borland仍然将在.NET平台的开发工具领域中缠斗下
去，虽然Microsoft已经率先推出了Microsoft Visual Studio，但是2003年第2季
Borland也将推出全新的集成开发环境--代号为Galileo的产品作为响应，一场精彩的
龙争虎斗又将在2003年展开序幕。

具有讽刺意味的是，数年前许多人质疑Borland是否能够活下去，许多人也因为担心
Borland的未来而不敢使用Delphi。但是现在证明，Borland不但成长得愈来愈好，
Delphi还继续推出了新版本Delphi 7，Delph 8也在Borland的计划之列。Delphi 7将
是Windows平台下最好的原生Windows开发工具，也是撑到最后一个的RAD开发工具，
连Microsoft都没有做到。Delphi 7不但延续了原生Windows应用系统开发的生命，
也为未来.NET平台的开发做了铺路和转移的准备。Delphi、VB、PowerBuidler和
Gupta经过了数年的大战之后，结果证明，Delphi才是撑到最后的英雄。

第四章  未完之传奇

"成功产品的背后有着更多不为人知的秘密!"

Chuck的秘密计划

Chuck像个藏镜人。虽然他始终是Delphi最重要的三个人物之一，但是却一直不愿意
站在最前线面对大众，而宁愿躲在幕后进行令人惊讶的软件革新工程。Chuck进行的
许多开发和研究并不广为人知……

当Anders离开了Borland之后，Chuck短暂地成为Delphi的总Architect。不过，Chuck
负责Delphi的开发工作后不久，就把Delphi Architect以及重要的工作交由Danny来
负责，因为Danny早已显示了大将之风，成为Chuck最为信任的软件专家。而Chuck呢？
虽然他仍然负责Delphi中许多重要的工作，但是后来大部分的时间是花在新技术和新
产品的秘密研究之中。对于一些Delphi例行性的工作，Chuck并不会花费太多时间。

在Delphi 3的研发阶段，Chuck的主要精力并不是在Delphi 3上，因为Danny和Zack负
责得很好。Chuck当时主要是进行两件重要的研发工作，即Delphi的Java编译器以及
Apollo计划。

原来，在开发Delphi 3时，Anders和Chuck都已经预知了Java将来必会成功，成为重
要的语言和软件技术。因此Anders和Chuck都知道必须在Java方面进行一些因应之道，
以未雨绸缪保持Delphi的竞争力。后来Anders离开了Borland，而Chuck则选择了投入
资源研究Delphi和Java的整合技术。当时Chuck的想法是为什么不能够开发一个类似
Java的JVM，直接把Delphi的程序代码转换为Java的ByteCode，让Delphi的应用程序
直接在JVM中执行呢?甚至，当时Chuck还想，为什么Borland自己不开发一个Delphi
JVM，让Delphi也可以执行在Windows、Linux、Solaris和Mac OS之中呢？

有了这个疯狂的想法之后，Chuck立刻要求Borland的高层批准这个研究计划，让他能
够有资源进行研究工作。由于当时正值Anders因为不满在Borland没有足够的研究资
源而离开了Borland，进入Microsoft一展心中的鸿图。因此，Borland高层当然不愿
得罪Chuck，以免他也离开Borland。由于当时Delphi 3的进度在掌握之中，而且
Delphi为Borland带来了大量的资源，因此Borland高层批准了Chuck的这个不可思议
的计划，让Chuck开始了研究之路。

Chuck有了资源之后，就立刻投入研究的领域，在Delphi 3的开发末期也没有花太多
的时间在Delphi上，反而加速地和Borland的编译器小组为Delphi For Java编译器进
行研发工作。在1997年中左右，Chuck有了初步的成果，已经能够把一些简单的
Object Pascal程序直接编译成Java的ByteCode、并且执行在JVM之中。这实在是一个
不小的突破，因此在当年的BorCon 1997中，Borland和Chuck正式对外公开了这个技
术，立刻引起了Delphi使用者强烈的兴趣，因为这代表一旦这个编译器研发出来，
那么Object Pascal便立刻成为一个像Java一样的跨平台程序语言，而且，如果
Borland能够继续把VCL和RTL移植进来，那么，Windows平台的Delphi程序员可以通
过这个技术同时开发多个平台的应用程序，这实在是太美妙了。

当BorCon公开了这个技术之后，Borland立刻面临了愈来愈多的Delphi使用者的询问
以及要求Borland尽早推出这个技术的压力。当然，Chuck以及Delphi研发小组也非常
兴奋，因为这代表Delphi又将有新的市场以及新的成长动力，所以Chuck立刻要求
Borland投入更多的资源，以加速研究这个Delphi For Java编译器以及相关的研究工
作。

不过，此时却发生了两件事情，最终让Chuck放弃了继续开发Delphi For Java编译器
的意图。首先，Chuck和Borland的编译器开发小组发现JVM似乎和Java语言系结得太
紧密，以致JVM的许多伪指令都和Java语言的架构系结在一起，无法轻易地由其他语
言来提供类似Java语言的架构，除非修改这些语言架构来仿真Java语言的架构。这个
原因造成了当Chuck想把Object Pascal一些复杂的数据类型和语言架构编译成Java
ByteCode时发生了极大的困难。

第二个决定性的原因是，由于当时JBuilder已经表现得愈来愈好，Borland希望投入
更多的资源到JBuilder小组，而且不希望有其他的产品或是技术影响JBuilder的成长，
因此，Borland高层对于Delphi For Java编译技术的开发也没有很大的兴趣，再也
没有批准更多的资源给Chuck。最后，Chuck的这个Delphi For Java编译计划便宣告
终结了。这实在是件可惜的事情，不过，当时Chuck研究的东西并没有白费，因为现
在Delphi小组也根据当时Chuck研究的成果来开发.NET上的编译器，希望通过以前投
入的资源和经验来开发更好的Delphi For .NET编译器。

另外一个Chuck在Delphi 3开发阶段秘密进行的研究计划则更为重要了。当时我更期
望这个技术能够出现在市场之上，不过可惜的是，最后也由于Borland高层要求Chuck
投入Kylix的研发工作而一直拖延到今日都还在软件实验室中，这就是属于Data
Component技术的Apollo计划。

Apollo项目的缘由要从Delphi 2开始说起。在Delphi 2开发时，Anders一直想在Delphi
中建立一个Garbage Collection的功能，而Chuck则希望继续扩充VCL的功能为VCL加
入Data Component的能力。由于VCL使用的组件架构在连接数据时是使用数据感知组
件(Data Aware)技术，但是许多真正使用面向对象技术的程序员反而对使用数据感知
组件相当地反感，而且在大型面向对象项目中，数据感知组件也被证明是不适当的。
因此Chuck为了赋予VCL开发大型面向对象项目的能力，决定加入Data Component技术
。

所谓Data Component技术，是指VCL架构可以代表实际世界中的domain对象，这些
domain对象可通过VCL的技术直接储存在数据库之中，或是从数据库中取出，类似EJB
中的OR Mapping(Object-Relational Mapping)技术。如此一来，Delphi的程序员可
以在Delphi中直接使用VCL组件来代表如员工和公司等实例(instance)，而且可以随
时把员工和公司实例储存到数据库中，再从数据库中取出员工和公司成为对象，而不
需要使用数据存取对象直接处理数据库中的数据。Chuck早在五六年前就想在Delphi
中实现目前Bold等公司提供的Object Instance技术。

没有想到，就在Chuck进行Apollo项目到了一半的时候，由于当时Borland的CEO Dale
Fuller先生看好Linux的发展，因此下令所有Delphi小组的成员都必须投入到Linux
开发工具的研发工作，全力为Kylix催生，于是连Chuck也被要求先暂缓所有的研究计
划，投入Kylix的开发工作。其实，当时我就非常反对像Chuck这样的顶尖人才进入
Kylix小组撰写程序代码，因为这实在是非常浪费的事情。Chuck应该进行更为重要的
研究计划，而不是只开发一般的工具而已。但是，当时Borland高层认为Linux将可带
领Borland一飞冲天，因此仍然坚持所有的人力都必须投入。不过，市场就是变化得
这么快，在Chuck和Danny都投入到Kylix的开发之后，虽然Delphi小组几乎以创记录
的时程在1年半左右就在一个新的平台开发了一个新的产品线，但是在Kylix推出之
后，Linux平台的疯狂热潮却开始快速消退。所有投入Linux的厂商再也无法仅以沾
上Linux的名称就可以让股票日创新高，市场终究是要回到基本点，只有真正获利的
公司才能够在市场成为赢家。

在Chuck被Kylix开发工作延误了近2年的时间后，Apollo再也不像当初那么吸引人了，
因为市场已经出现了类似的科技，例如EJB的OR Mapping技术和Bold等公司的产品。
如果Borland当初能够让Chuck全力发展Apollo计划、并且在其他公司之前推出Apollo
的成果，那么Delphi将可以在OR Mapping方面占有领导的地位，Borland研究的OR
Mapping技术说不定还可以被SUN授权使用，就像Oracle花了大钱从WebGain购买类似
的技术一样。Anders和Chuck这两位拥有一流技术和眼光的技术人物，或多或少地被
许多平凡的管理人物糟蹋了好几次。

Chuck本身是一位非常和蔼可亲的人物，我曾经多次和Chuck交谈，每次谈话时Chuck
总是笑嘻嘻的，似乎没有事情可以让他感到忧虑。如果不知道Chuck的人和Chuck交谈，
那么可能没有人会相信，这位看起来像是好好先生的人在软件方面有这么惊人的成
就和高深的造诣，而Chuck一头接近红色的头发也让我第一次见到他时被吓了一跳。

当Chuck和Danny被征召开发Kylix时，其实也不是非常顺遂的。在Kylix激活之后，照
例是由Danny负责Linux上编译器和RTL的研发工作，而Chuck则负责VCL和CLX方面的工
作。由于要在Linux上开发集成开发环境，必须先在Danny负责的底层RTL和编译器完
成之后才能够开始设计。但是，Danny在把Delphi的RTL和编译器移植到Linux的过程
中发现了一些Linux的臭虫，因此，当时Danny在Linux的论坛上公布了他发现的臭虫，
并且希望Linux的社群能够修改这些问题，如此一来Borland才能够继续研发Kylix。

不过，也许是Linux的社群拥有排外的情绪，一直认为Borland不是正统的Linux软件
厂商，因此对于Danny指出的Linux臭虫也嗤之以鼻，认为Danny什么都不懂就来说是
Linux的臭虫。由于Linux论坛上的人非常的不友善，而且坚决不承认Danny提出的是
臭虫，因此也惹得Danny非常不高兴，认为做软件的技术人员为何不能就事论事，明
明有问题却死不承认。于是Danny便在Linux论坛上和这些人发动了笔战，愈吵愈轰动，
最后演变成了两派人马互相批评。我在当时也想不通，为什么明明Danny已经指出了
Linux有问题的地方，而这些也是搞软件的人却有如此的反应？这些人是不是太小心
眼了呢？以Danny如此功力深厚的人反而被这些Linux的人说成是不懂软件开发真是笑
掉人的大牙，这些人应该看看Danny做出了什么东西，看看他们能不能做得出来再说。

由于Danny无法在Linux论坛上得到结果和支持，因此一怒之下干脆自己来修改Linux
的臭虫，好让Kylix能够继续开发下去，不再需要这些Linux社群的帮忙。这也是为什
么在安装Kylix时，Kylix不但会检查使用者Linux使用的版本，并且会安装Patch档案
以修改Linux操作系统的问题。Danny选择了安装额外的Patch档案的方式来解决Linux
的臭虫，而不是直接修改Linux的核心，再由Borland分发Linux Distribution。当时，
在Danny解决了Linux执行时期函数库的一些臭虫之后，Kylix才能够顺利地开发下去。
后来，在Kylix小组开发Kylix的集成开发环境时也发现了一些XWindow的臭虫，Danny
也是选择由Borland自己来修改加以解决，而不需要Linux社群的帮忙。

当然，由于Danny和Linux社群之间的大战也让Danny憋了一肚子气，在Kylix推出之后，
就把随后相关的开发工作交给Kylix小组来负责，Danny则专心到.NET研发小组为Borland
开发.NET上的下一代开发工具了。Danny离开Linux是Linux的损失，这些和Danny争吵
的Linux程序员不知道他们在Linux上损失了一个天才型的软件人员。有时我想，一些
庸才不就是不断地攻击天才吗？难怪古人说"不招人忌是庸才"了。看了Danny大战Linux
论坛这一幕，我也只能在旁摇头叹息，不过我个人倒是很高兴Danny和Chuck全力开发
NET产品，因为我一直想使用Borland的开发工具学习和开发.NET应用程序呢。

目前，Chuck在Borland进行的工作是在.NET上研究先进的技术，包含了在2002年
BorCon上Chuck公开展示的新语言--Charlotte。Charlotte主要是提供Web Service的
First-Class语言，是由Chuck定义Charlotte的语法、功能，并且实现Charlotte编译
器的。我实在佩服像Chuck以及Anders、Danny这些人物，因为这些人几乎都可以独自
开发和实现新的程序语言，其功力的确是一般软件人员难以想象的。

在BorCon上，Chuck已经展示了Charlotte的语法以及初步的编译器，目前，在Borland
.NET内部，Charlotte使用了另外一个比较正式的名称，到了2003年或许我们就可以
看到Chuck和Danny在2002年一整年努力的成果了。

回到未来

2002年，Borland推出了Delphi 7。虽然此时Microsoft已经信誓旦旦地表明，.NET才
是Windows的未来，不过现在Windows应用程序的开发仍然是主流。但是未来呢？
Delphi的未来是什么呢？

Borland已经对全世界宣布了2003年即将推出.NET上的开发工具，首先支持的语言将
会是C#和Object Pascal，而且在.NET上，Delphi已经成为Object Pascal的代名词，
这意味着未来在.NET上，Delphi已经是一个语言名称了，Delphi的使用者将使用Delphi
语言在.NET上开发新一代的.NET应用系统。那么在Windows平台呢？Delphi 7会是最
后一个版本吗？

当然不，虽然根据各种信息调查的结果显示，从2003年开始，.NET将进入起飞的阶段，
但是原生Windows程序的开发仍然拥有三四年的需求。既然如此，那么一定还有许多
的使用者仍然需要原生的Windows程序开发工具，Borland不会放弃这些使用者和这么
大的市场，因此Borland也一定会继续推出新的Delphi版本供使用者使用。

更何况，即使是对于想要开发.NET的使用者来说，可能有极大部分的人也同时需要开
发原生窗口应用程序。那么，为什么软件厂商不提供一个开发工具能够让使用者在同
一个集成开发环境下同时开发原生窗口应用程序以及.NET应用程序呢？这个需求就是
Delphi的优势和机会。看看现在Delphi 7提供的功能，我们会很惊讶地发现，其实
Borland已经偷偷地在进行一些革新的做法。

如果读者在Delphi 7的集成开发环境中安装了Delphi for .NET command-line
complier IDE integration，那么就可以如下图般在Delphi 7的集成开发环境中激活
Delphi For .NET编译器，以便在Delphi 7中开始撰写.NET应用程序。在2002年11月，
Borland又公开了Beta版本的VCL.NET供Delphi 7使用者下载，以便在.NET中使用VCL
组件。

不过，许多人会觉得光是拥有Delphi For .NET编译器以及VCL.NET并不够用。如果要
开发.NET的WinForm应用程序，那么Delphi 7目前并没有提供类似Delphi的Form
Designer，因此仍然非常不方便，Delphi的使用者仍然需要一个解决方案。

让我们想想，虽然目前Delphi For .NET没有像Delphi的Form Designer，但是如果我
们能够使用Delphi本身的Form Designer作为.NET WinForm的开发接口，然后，如果
能够再通过一个工具把Delphi的TForm和VCL转换为.NET的WinForm以及VCL.NET不就可
以了吗？如此一来，Delphi的使用者几乎可以在不花费时间成本之下立刻在Delphi中
开发.NET可视化WinForm应用程序，这不是一举数得吗？没错，其实Borland也早就想
到了，因此Borland也正想开发一个Delphi转换到.NET程序的转换器让Delphi的程序
员使用。这样Delphi的程序员就可以直接使用Delphi的Form Designer来设计.NET
WinForm的接口，最后再通过转换器自动地转换为.NET的WinForm应用程序。

如果读者使用过Delphi 7的Delphi For .NET编译器，那在其中的文件以及Delphi的
论坛中就可以看到"Morpheus''这个名称。其实，Morpheus正是Delphi For .NET编译
器的研发计划的代号[在电影The Matrix中，Morpheus是救世主(The One)基努李维尚
未出现之前的领导者，Morpheus的任务就是寻找救世主以拯救末世]。因此Delphi的
研发小组很有创意地把Delphi For .NET编译器命名为Morpheus，以代表Delphi For
NET编译器是未来Borland推出纯.NET开发工具之前的救世主，负责带领Delphi程序
员走向未来.NET的救赎之道。而Morpheus计划的任务就是为Galileo打下成功基础。

虽然我们对Delphi 8可能提供的功能现在还不清楚，但通过使用者的需求以及市场的
现况，可以推算出如下轮廓：

■  新的集成开发环境：这是为了让Delphi能够同时在集成开发环境中开发原生窗口
    应用程序、.NET应用程序以及Kylix应用程序

■  新的VCL和CLX：可以让VCL同时使用在原生窗口和.NET之中。此外Borland也将再
    次修改VCL/CLX以增加Framework在三个平台的兼容性

■  新的Delphi/Kylix和Delphi.NET编译器：可以在Object Pascal语言上提供更为兼
    容的效果。这是因为在Delphi For .NET中，Borland已经为Object Pascal加入了
    许多新的语言元素和功能，Borland可能也将为Windows和Linux平台上的编译器加
    入这些功能

■  更多的辅助工具：帮助程序员同时开发三个不同的应用系统

当然Delphi 8还将有其他许多未知的功能，不过上面所列的几项应该是Delphi 8肯定
具备的。如果Delphi 8真能提供上述功能，那我相信它将是使用率最高的窗口开发工
具，因为除了程序员完全是开发.NET应用程序之外，Delphi 8可以提供最齐全的开发
能力。

Delphi 8将是Delphi最后的一个版本吗？这我也不知道，唯一可以用来判断的标准是
NET多久能够完全占据窗口开发的应用。如果真有那一天，那也就是所有原生窗口退
出市场主流的时候，就像数年前的DOS开发工具一样。届时也请读者把Delphi的最后
一个版本保留起来，以作为我们一起经历过原生窗口开发的见证，同时，也作为这个
曾经是最棒的原生窗口开发工具的纪念。

Delphi风云榜

Delphi的开发过程创建了许多记录，并且也造就了许多有名的人物。Delphi创建的记
录是许多开发工具无法企及的，而围绕在Delphi外围的杰出开发者也各领风骚，为
Delphi的传奇添加了更多精彩的故事。这些Delphi记录和杰出的Delphi开发者故事值
得读者们一一品味，特别是Delphi使用者们熟悉或听闻过的人们。他们虽然不像Delphi
的灵魂人员Anders、Chuck或Danny那样，广为人知、受人尊敬，但对Delphi的发展，
他们也具有不可磨灭的贡献，这里我们也来看看他们的"庐山真面目"。

Delphi集成开发环境之父

相信每一个Delphi/C++Builder的使用者每日都花许多时间在Delphi/C++Builder的集
成开发环境中，既然如此，那除了Anders、Chuck和Danny之外，大家一定要认识一下
负责开发Delphi/C++Builder集成开发环境的主要领导人Allen Bauer。

Allen Bauer是Borland的资深工程师，已经在Borland工作了相当长的时间。Allen除
了从Delphi 1开始便负责集成开发环境的研发工作外，还不断地翻新集成开发环境、
改善Delphi/C++Builder集成开发环境的公开标准：Open Tools API的架构。我曾经
在费城旅馆的电梯中和Allen交谈过，Allen讲话非常轻声细语，给人一种翩翩君子的
感觉。

Allen的这张照片应该是最近的，因为相片中的Allen比1999年我在费城时看到的样子
老了许多，看来最近几年Allen为Delphi/C++Builder的集成开发环境投入了不少的心
力。目前Allen正在为Galileo全力开发新的集成开发环境，据说Allen将在新的集成
开发环境中加入许多更强劲的功能，2003年我们继续关注Allen的下一个力作吧。

Borland RAD工具的推广大使

我非常怀念Charlie Calvert，因为在所有Delphi R&D小组中，我和Charlie Calvert
有过最多共事的经验。Charlie Calvert属于Borland Developer Relationship小组
中的资深经理，主要工作是负责开发全世界Borland RAD工具并协调其与使用者之间
的关系。Calvert不但是著名的Delphi/C++Builder Unleashed书籍的作者，前段时间
还撰写了JBuilder 7的书籍。

Charlie Calvert本人是一位素食者，为人非常的热情和蔼。他在Borland工作的后期
也参与了小部分Delphi和C++Builder研发的工作。Charlie Calvert曾说当Borland不
再开发全世界最好的工具时就是他离开Borland之际。两年前Charlie Calvert终于离
开了，这让我非常难过，我认为他的离开是Borland的损失。我曾经问过Charlie
Calvert，为什么要离开Borland？他回答说是因为不习惯当时Borland的转变(Delbert
乱搞开发工具的时期)而打算自己创业。不过令人高兴的是，在Charlie Calvert离开
Borland之后，他仍然在从事Borland相关工具的训练工作，看来Charlie Calvert仍然
对Borland的工具有着一份强烈的爱意。

Delphi的强中手

除了Delphi R&D小组之外，我认为最强的Delphi高手应该是Ray Lischner了。Ray
Lischner博土从Delphi 1开始就积极参与Delphi的相关工作，稍后更撰写了名震Delphi
圈的数本书籍，包括《Secrets Of Delphi 2》、《Hidden Paths Of Delphi 3》以
及《Delphi In a Nutshell》等好书，其深厚的Delphi功力也是Delphi R&D小组所公
认的。由于Ray的书籍一向令我折服，因此在Delphi 3时还特别要求台湾出版商引入
Hidden Paths Of Delphi 3，并且为Hidden Paths Of Delphi 3进行中文书籍的翻
译工作。

除了撰写书籍外，每一个Delphi的新版本，Ray都参加Beta测试。Ray是一个非常直率
的人，一旦遇到臭虫或是Borland没有做好的地方，他都会毫不留情地要求Borland更
正或是批评Borland没有尽力。我曾经在Borland内部的Delphi论坛中看到Ray精彩绝
伦地痛批Borland没有把产品做好。尤其在Delphi 4时更是不惧高层权势痛骂Borland
乱搞Delphi，看得我大呼过瘾。虽然我身为Borland的人，不敢骂Borland高层的人，
但是心中所想是和Ray一样的，而由Ray这位具有身份地位的人口中骂出，实在令我觉
得爽快，当然Ray如此做也是"爱之深，责之切"的缘故。因此直到现在，在参加RAD工
具Beta测试时，我还是最喜欢看Ray的评论，因为Ray的评论不但有深度，更敢直言，
通常是最有帮助的论坛讨论内容。

Delphi双响炮

说起Steve Teixeira和Xavier Pacheco这两位仁兄，相信也是许多Delphi程序员耳熟
能详的大人物，因为他们两位正是《Delphi Developer's Guide》这本好书的作者。

Steve Teixeira和Xavier Pacheco都曾是Delphi R&D小组的成员，不过这两位仁兄目
前都离开了Borland，各自创业去了，毕竟自己当老板更有赚头。说起Steve Teixeira
和Xavier Pacheco，令人好笑的是他们两人的身材实在是很强烈的对比，Steve
Teixeira年轻高大，而Xavier Pacheco则极为瘦小，因此当Xavier Pacheco站在
Steve Teixeira旁边时，Xavier Pacheco就像一个小孩一样。

我和Steve Teixeira比较熟悉，因为曾经和他在费城一起开过会，也有过交谈。
Steve Teixeira在Delphi R&D小组中负责比较低阶核心的除错功能，Steve Teixeira
让我想起当初Matt Pietrek在Borland的成长过程。由于Steve Teixeira和Xavier
Pacheco都是Delphi R&D小组的成员，因此他们自然能够取得最新、最深入的信息来
写书。

Delphi COM高手

说到使用Delphi来学习COM方面的知识时，就不能不提Binn Ly这位大名鼎鼎的人物，
Binn Ly也算是华人在Delphi圈中之光荣。话说在Delphi 3推出之时就以多层架构为
重点功能，强调Delphi能够撰写多任务的中间件服务器。不过了解内部技术的Delphi
程序员都知道，其实Delphi 3中的中间件服务器只能开发Single Threaded型态的COM
服务器，还不能开发真正的STA和MTA型态的COM服务器，这也是为什么Delphi 3的
MIDAS服务器在客户端使用者人数较多时执行效率就不甚理想的原因。

当时Binn Ly先生就指出了Delphi 3的问题，并且决定自己开发一个真正的Delphi封
装COM技术的framework，并且提供真正的STA、Apartment和MTA的解决方案。这在当
时是一项非常惊人的工程，因为除了Microsoft的ATL之外连Delphi都还没有提供，而
Binn Ly先生却决定完全使用Object Pascal来开发一个如此复杂的framework。后来
Binn Ly先生不但成功地开发出来，还在自己的网站上公开了framework的原始程序代
码，而且还写了许多COM和Delphi方面深入的技术文章。虽然在Delphi 4之后Borland
也终于慢慢地提供了比较完整的COM封装技术，但是Binn Ly先生在Delphi和COM方面
权威的形象已经深入Delphi程序员的心中，他本人也成为日后Borland邀请在BorCon
主讲COM/COM+讲座的台柱之一。

VCL．NET Architect

Eddie Churchill是在Delphi 3之后才加入Delphi R&D研发小组的，不过Eddie在
Delphi R&D研发小组中却上升得很快。

Eddie在加入Delphi R&D小组之后，便开始了Delphi中Diagram Designer的研发工
作，原本Eddie的工作是准备在Delphi中开发出UML的功能，以便为Delphi/C++
Builder提供完整的OOA/OOD的功能。

不过由于后来Borland高层决定和Rational合作，而且Eddie小组需要极大的资源来开
发，因此Borland的RAD部门便在Diagram Designer实现之后决定暂停这方面的研发工
作。其实在Delphi 3时，当时的Delphi产品经理Ben Riga就想为Delphi加入UML的功
能，只是一直无法拥有足够的资源来投入这方面的研发工作，一直到Delphi 5之后才
逐渐在Delphi/C++Builder看到这方面的初步成果。

现在Eddie Churchill和Danny等人投入开发Borland.NET方面的产品，并且是VCL.NET
的Architect，负责把VCL移植到.NET中，在2002年的BorCon中，Eddie Churchill就
说明了把VCL移植到.NET之上的困难和挑战，目前在Delphi使用可下载的Delphi For
NET Preview中已经可以看到Eddie Churchill在VCL.NET方面的初步成果了。

WebSnap始祖

Jim Tierry是在Eddie Churchill之后不久加入Delphi R&D研发小组的，他的第一个
工作就是接手Delphi的WebBroker技术，以开始打造Delphi/C++Builder的下一代Web
技术，初步的成果就是Delphi 5的InternetExpress。

不过在InternetExpress推出之后，Jim自己并不满意，因此立刻开始进行
InternetExpress下一代的开发工作，那当然就是WebSnap了。由Jim带领的WebSnap
开发小组终于在Delphi 6中推出WebSnap技术。不过也是由于资源的限制，因此在
Delphi 7中，Borland决定使用更为完整的IntraWeb作为Delphi在Web方面的主力。
目前Jim Tierry应该是在开发.NET下Web方面的技术和产品，我也希望在2003年能够
有机会和Jim见上一面，让他谈谈目前工作的方向。

Delphi Plug-In第一把交椅

我在日常使用Delphi时，一个少不了的工具就是Eagle Software出品的CodeRush，虽
然有些人认为CodeRush有点不稳定，但我认为CodeRush是一个非常好用的工具，当然
这也是为什么CodeRush几乎在每一年Delphi Magazine的年度产品评比中都是第一的
Delphi Plug-In工具。

CodeRush是由著名的Delphi高手Mark Miller先生开发的，Mark不但是多个产品的作
者，更是BorCon中经常受邀的主讲者。我曾经在许多地方和Mark有着交往，在2000年
澳洲的BorCon时我还曾经告诉Mark当时的CodeRush在中文Windows 2000中有臭虫，因
为当我使用CodeRush的快捷键时，CodeRush会送出重复的字符。Mark当场便拿出
NoteBook查询CodeRush的程序代码，并且要求我也打开我的NoteBook展示CodeRush
的臭虫给Mark看。在Mark了解了问题之后便询问我的旅馆房号，这才发现我们是住
在同一个旅馆。没有想到的是，当晚Mark便打电话到我的房间请我过去再次追踪这
个问题。后来Mark确定CodeRush没有问题，应该是中文Windows 2000在某些地方处
理的方式和英文Windows稍有不同，这应该是IME方面的原因，不过Mark答应我将会
提供walk-around的方式来克服这个问题。我回国后不久，就收到Mark寄来的一个
Patch档案修正了这个问题，其工作效率真是令人惊讶。如果读者也在使用CodeRush
这个产品，那可以经常到CodeRush的论坛看看Mark的发言，许多时候Mark的信件都
是深夜二三点寄出的，Mark工作的狂热的确令人吃惊，不过在Mark有了Baby之后这
个现象就比较少发生了。

MIDAS/DataSnap的掌舵手

Borland在Delphi 3便推出了MIDAS，一直开发到现在的DataSnap。其实Borland一开
始时就对MIDAS有非常大的野心，准备把MIDAS开发成中间件的标准技术。不过随着中
间件从以RPC为主变化成CORBA、COM/COM+以及EJB，Borland也很快地放弃了这个想法，
因为Borland不可能单独推出中间件技术来对抗业界的标准。

因此在Delphi 4之后，Borland便开始转变MIDAS的角色，把MIDAS定位成一个通用的
数据存取处理层技术，让MIDAS能够使用在CORBA、COM/COM+之中提供方便有效率的封
装数据存取功能，以弥补这些组件技术在存取数据方面的不便--必须使用一笔一笔数
据的方式来处理数据。

MIDAS这样的转变是非常正确的，因为在CORBA、COM/COM+中要存取数据实在是非常的
不便，经常必须在对象接口中提供特定的方法让客户端存取特定的数据，并且在移动
数据时也非常的麻烦，而MIDAS却提供了完整的解决方案。正是由于MIDAS的方便好用，
因此Microsoft也仿照在ADO中开始模仿MIDAS的功能，在ADO.NET中更是全面使用MIDAS
的观念来处理数据的存取。Borland也曾经把MIDAS移植到Java中成为JMIDAS，可是由
于Java世界非常强调标准，所有的标准都必须由SUN来制定，而SUN又使用JDBC、
Entity Bean以及现在的JDO来处理数据，因此JMIDAS之后就停止了开发。

Delphi 3、Delphi 4中的MIDAS都由不同的工程师负责。在Delphi 4中是由Josh负责
的，在这期间Josh和Dan Miser合作提供MIDAS的技术和解决方案，当时的Dan Miser
并不是Borland的员工，而只是MIDAS的爱好者。后来由于Josh离开了Borland，Borland
就把MIDAS的维护和新版本开发工作contract给Dan Miser，因此在Delphi 6之后的
DataSnap是由Dan Miser开发的，而Dan也成为了DataSnap的头领。

由于Dan Miser非常喜欢DataSnap，愿意为Borland工作，因此现在Dan已经到Borland
应征，准备正式成为Bodand的员工，继续把DataSnap移植到.NET上，并同时开发新的
DataSnap功能。

Delphi Spirit

Marco Cantu这位意大利的仁兄，应该是许多Delphi初学者都知道的人物，因为Marco
Cantu的《Mastering Delphi》一直是Delphi书籍中的长青树，深受初学Delphi的人
所喜好。

Marco Cantu也经常是BorCon的讲座主讲人以及Delphi相关杂志的专栏作家，不过我
一直无缘聆听Marco Cantu先生的讲座，因为每次我都选择了同时进行的其他讲座，
真是令人遗憾。

元老重臣

最后一个我想介绍的人物可能许多人并不熟悉，但是这位仁兄却一直是Borland开发
工具中的要角之一，那就是Bruneau Babet先生。Bruneau Babet很少公开露面，除非
在BorCon中读者才有可能见到他。

Bruneau Babet从Borland C/C++产品开始就是Borland的研发人员，在Borland C/C++
结束之后也转入Delphi R&D小组开发Delphi，而Bruneau Babet工作的重点一直是以
COM方面的技术为主。

Bruneau Babet除了进行Delphi的研发之外，主要的时间是负责C++Builder的开发工
作，因此他也从事C++Builder中融合ATL方面的工作，在BorCon中，Bruneau Babet演
讲的主题主要是Borland开发工具在COM/COM+的技术支持。

在这里，我无法介绍完所有相关的重要人物，除了上述几位外，许多大家熟悉的人物，
包括Dr. Bob、John Kaster等，我都没有介绍到。这是因为Dr. Bob和John Kaster
是许多人非常熟悉的，他们的照片在网站上可以经常看到，因此就不再列为重点，这
里是以读者不太熟悉的人物为主，让喜欢Delphi/C++Builder的读者能够看看这些杰
出软件人员的长相、了解他们的个人资料，让许多"久闻其名"的人物真实地呈现在我
们面前，作为我们学习的借鉴。

第六章  失去的王冠--Borland数据库工具的战役

在Borland的产品线中，有两个产品是较少受到瞩目的，那就是Borland从Ashton-Tate
并购来的dBase系列以及昙花一现的IntraBuilder。对于Borland来说，dBase和
IntraBuilder是非常可惜的牺牲品。dBase发展的黄金时机被Philippe Kahn白白浪费，
IntraBuilder带来的无限潜力硬生生地被Delbert Yocam糟蹋掉。Borland最有机会的两
个关键时刻分别被两任CEO蹉跎，不知到底是时也？命也？运也？

dBase和IntraBuilder这两个产品，到底是如何在Borland中发展的呢？为什么最后dBase
和IntraBuilder都会进入死胡同？让我们一起来探索其中的秘密。

IntraBuilder的诞生

谁说"洞悉先机"一定是好事？当初哥白尼在几个世纪之前大胆地提出了天体运行论，
同势力庞大的基督教对抗，因而被基督教视为邪说，一直到3个世纪之后才被罗马教
皇承认。而哥白尼的一生都在承受着巨大的压力，Borland的IntraBuilder几乎也面
临了同样的命运。

1995年，当浏览器的应用逐渐成为主宰力量之后，各种Web的应用也开始快速地发展
起来。一开始Web应用是以面向文件为主，许多Web应用都使用纯文本编辑器来开发HTML
网页。但是人们很快发现，这种方式非常不经济，因为Web应用虽然有很大一部分属
于美工的需求，但是当Web进入人们的生活后，许多Web应用便开始需要结合数据处理
而转向商业的应用。因此，很快Web的解决方案便开始从静态网页的应用进入到使用
程序来解决的阶段。但是，当时正值浏览器大战的阶段，Netscape正和Microsoft的
Internet Explorer拼斗得你死我活，而Java也开始兴起。此时浏览器并没有标准，
连带着对HTML、JavaScript的支持也混乱无比。因此，虽然许多程序员都感觉需要一
个Web开发工具帮助他们开发逐渐炙手可热的Web应用程序，信息业界也开始有强烈的
需求，但是混乱的Web标准却让许多程序员不知所措。

不过，Borland的Visual dBase小组却从中看到了极大的契机，因为在为Visual dBase
未来的版本加入支持Web的功能时，Visual dBase小组突然发现，既然Web的功能是许
多程序员想要的，那么，为什么不直接提供一个可视化的Web开发工具，让需要开发
Web应用程序的程序员能够拥有最好的工具，而不需要痛苦地使用纯文本编辑器来开
发Web应用程序呢？

时值1995年，这的确是一个令人相当震撼的想法，因为它体现了未来需求的趋势。当
Visual dBase小组提出这个想法之后，立刻在部门内获得了极大的回响。几经商议，
Visual dBase小组决定先开发一个可视化的Web开发工具来测试市场，而且他们决定
就使用Visual dBase来开发这个新的产品。这实在是个大胆又令人惊讶的决定，因为
当时不但没有类似的产品，而且决定使用Visual dBase而非C/C++来开发新产品，更
是不可思议，开发工具真的可以使用Visual dBase来开发吗？

当Visual dBase小组决定开发这个新的开发工具时，却面临了一些技术上的抉择，那
就是使用什么语言作为这个新开发工具的核心？另外，该产品既然是一个Web开发工
具，当然需要一个Web Server作为后端的驱动引擎。但是，当时的市场上只有Netscape
和O'Reilly等少数厂商拥有Web Server引擎。因此，Borland必须决定使用什么Web
Server。不过，这些问题很快就有了答案。

由于Java快速地兴起，Applet也成为学习Java的入门知识，因此，JavaScript很快就
被众人视为开发Web应用程序的标准语言。于是Visual dBase小组决定使用JavaScript
作为这个开发工具的核心语言，并且强化当时的JavaScript语言，以支持这个新的开
发工具。另外，由于当时的Web Server大都不便宜，因此，Visual dBase小组决定自
行开发一个Web Server作为这个开发工具的内建Web Server。最后，Visual dBase小
组定义这个开发工具必须拥有下面的功能：

■  可视化开发环境，允许程序员使用组件和拖曳的功能来设计Web应用程序
■  使用JavaScript作为核心语言
■  提供内建的Web Server
■  结合BDE/IDAPI来连接各种数据库

这个开发工具便是IntraBuilder--后来震撼一时的数据库Web开发工具先驱。

在IntraBuilder开始开发之后，Visual dBase小组很快发现，虽然他们可以使用Visual
dBase完成大部分的工作，但是，终究有一些功能是Visual dBase力所不逮的地方，
因此，在IntraBuilder开发的后期，为了让它能够支持当时Microsoft刚推出的、同
Applet相抗衡的ActiveX以及动态执行Applet，Visual dBase小组还是使用了部分的
C程序代码来完成这些功能。

IntraBuilder的震撼

1996年9月，经过1年多的开发，IntraBuilder终于推出在世人的面前。IntraBuilder
推出之后，全世界的专业媒体几乎都对IntraBuilder好评有加，而且都不能相信Borland
能够如此快速且先知地推出数据库的Web开发工具。

全世界的好评如潮，因此，在IntraBuilder准备正式出货之前，Borland也是信心满
满。我记得，当时在拿到IntraBuilder的Beta版后，虽然我对于Web的开发仍然没有
太多的经验，但是很快就了解了这个产品的潜力，因为IntraBuilder和当时其他的Web
开发工具以及编辑器比较起来，简直是领先了数个世代之久，而且还能够用来作为学
习JavaScript的工具和开发连接数据库的Web应用程序。这些功能在市面上几乎没有
任何的竞争对手可以比拟。即便以今日的标准来看，IntraBuilder提供的Web可视化
设计能力仍属一流。因此，当时我就觉得这会是一个大卖的产品。

IntraBuilder面对的困难

即便Borland非常有信心，专业媒体也一片看好，但是没有想到的是，在IntraBuilder
推出之后，只带来了第一波销售热潮，随后的销售却很快冷却下来，造成了IntraBuilder
叫好不叫座的情形。这实在是一件很奇怪的事情，因为IntraBuilder产品本身没有太
大的问题，产品的方向也是正确的。但是为什么IntraBuilder在市场上就是无法拥有
亮丽的表现呢？这个问题是Borland急于寻找答案的。记得当时在台湾发表IntraBuilder
时，似乎也是回响热烈，但实际出席的人却不多。台湾Borland的产品经理还在会场
询问我，为什么出席的反应这么不热烈，产品本身不是不错吗？

在IntraBuilder首次遭遇挫折之后，Borland很快便找出了其中的重要问题所在。有
些属于产品本身的小瑕疵，有些则是当时整个环境的问题。总结当时IntraBuilder
1.0失败的原因有：

■  IntraBuilder太过于先进，许多程序员不知如何使用
■  IntraBuilder不支持中文
■  浏览器对于JavaScript语言的支持程度混乱
■  IntraBuilder在GUI方面的Render尚有瑕疵

由于当时Web的程序应用还属于萌芽期，Internet/Intranet程序应用仍然处于第一波
面向文件的阶段，大多数的Web应用是使用HTML和一般编辑器来制作的。这个时期距
离第二波程序员开始大量使用各种不同的Web语言来开发Web应用程序仍然有1、2年的
时间差。

可惜的是，IntraBuilder就是太早的察觉了这个趋势，因此当IntraBuilder推出之时，
仍然是领先第二波Web应用的发展。从下面的图形，我们也可以看到IntraBuilder
推出的时机的确是先于数年后其他Web开发工具的脚步。

正是由于IntraBuilder推出的时机太早，因此只能吸引站在前端的开发人员，大多数
的开发人员对于这样革命性的产品，浑然不知其重要性，造成IntraBuilder一开始只
能销售给Borland的少数客户以及其他领域顶尖者的结果。不过我认为这是一件好事，
因为IntraBuilder先期的销售数量虽然没有达到Borland的预望，不过IntraBuilder
一开始便攻入了最重要的客户群，占据了金字塔顶端客户的mind-share。只要
IntraBuilder能够再接再厉，等到1、2年后，当大多数的开发人员了解了Web开发工具
的重要性以及实用性之后，IntraBuilder将可快速收割成果。此外IntraBuilder的理
念与技术领先于其他竞争对手数年之久，即使其他Web开发工具推出，IntraBuilder也
能够以逸待劳，痛击竞争对手。

在Borland分析了IntraBuilder遭遇挫折的因素后，很快便展开了相应的行动，因为
Visual dBase小组对于IntraBuilder仍然非常有信心。在支持DBCS方面，由于
IntraBuilder 1.0不支持DBCS，因此造成了在许多亚洲国家和地区，包括中国台湾地
区、日本和韩国以及中东无法销售的问题。这个影响当然是很大的，因为光是一个日
本市场，几乎就可以销售数千万套。

另外一个扰人的问题，就是由IntraBuilder开发出来的Web应用程序在不同的浏览器
中会发生网页内容和位置与在IntraBuilder中设计时不一致的情形。这个问题形成的
原因很复杂，大都和当时不同的浏览器在render网页内容时的差异有关。当然，当时
尚未有一致的标准，使得不同的浏览器支持的HTML版本和JavaScript版本不同。不过，
虽然这些问题不全是Borland的错误，但是，就如同当时一个IntraBuilder使用者在
Forum中留下的一句话"It may not be Borland's error，but it definitely is a
Borland's problem(不是Borland的错误，却是Borland的问题)"。

为了解决IntraBuilder面对的问题，Visual dBase小组很快便开始进行了IntraBuilder
第二个版本的开发工作，目的就是为了解决IntraBuilder客户所抱怨的问题，并且强
化IntraBuilder在扩展性和执行效率方面的功能，以期让更多的客户愿意使用
IntraBuilder。1997年6月，Visual dBase小组手脚很快地推出了IntraBuilder 1.5，
进行第二次的出击。

IntraBuilder 1.5几乎是一个成熟的Web开发工具，因为IntraBuilder 1.5可以支持
DBCS，并且大幅提高了IntraBuilder应用程序的执行效率。此外，Visual dBase小组
也特别使用C改写了IntraBuilder在render网页的功能，让IntraBuilder能够更精确
地呈现Web网页的内容，并且大幅提升了在不同浏览器中的兼容性。

经过了这么多的改善之后，IntraBuilder在全世界的销售果然有了起色，慢慢地向
Borland为IntraBuilder设定的目标接近。Visual dBase小组当然也是很高兴，因为
这证明了他们的眼光是正确的。因此，Visual dBase小组在IntraBuilder站稳了脚步
之后，便开始进行IntraBuilder 2.0大改版的工作，希望通过2.0版本让IntraBuilder
成为最成功的Web开发工具。

再接再厉，IntraBuilder 2.0的开发

1997年，Borland已经准备好了新版的IntraBuilder，并且在当年的Borland Conference
中公开宣示了IntraBuilder 2.0，也为未来的IntraBuilder 3.0提供了发展蓝图。新
版本的IntraBuilder一切看起来是非常的顺利，而且Visual dBase/IntraBuilder小
组也信心满满，准备为IntraBuilder再下一城。

当时的Borland正和最具影响力的Netscape以及Microsoft共同制定JavaScript的标准，
并且准备捉交到ECMA。其时IntraBuilder Architect Randy Solton正忙于和Netscape
以及Microsoft的人员定义JavaScript的最终标准，希望两大浏览器Communicator和
Explorer能够在未来支持这个新的标准，以便让IntraBuilder的应用程序能够正确无
误地执行在这两个浏览器中。不过，由于Netscape和Microsoft正处于最激烈的战火
中，彼此各怀鬼胎、谁也不服谁，因此标准制定的流程进行得非常缓慢、不顺利，这
也间接造成了开发IntraBuilder的难度。

在Borland Conference 1997中，当时IntraBuilder的Director Michael Gardner展
示了IntraBuilder 2.0的新功能。

在IntraBuilder 2.0中，Borland提供了一个内建的HTML可视化编辑器，以提供更为
精确的网页编写功能(类似今日Macromedia提供的工具)。IntraBuilder 2.0的ActiveX
具有同时在客户端和伺服端执行的能力。这个功能非常Cool，因为在当时，ActiveX
大都只能执行在客户端，而IntraBuilder 2.0却能够让ActiveX同时执行在客户端和
伺服端，这可就稀奇了。另外，IntraBuilder 2.0对于JavaBean的支持也将和ActiveX
一样完全，这代表两种不同的组件技术在IntraBuilder中将会是相同的First-Class
组件。这可是Macromedia在数年之后才能在UltraDev中实现的技术。

另外一个IntraBuilder 2.0最重要的功能就是提供了跨平台的能力。Borland准备同
时开发Windows和UNIX平台的IntraBuilder，计划支持的UNIX平台包含了Solaris、HP
-UX、AIX和IRIX。这在当时可算是非常大的手笔，因为当时市场上不但没有类似的产
品，更遑论是提供跨平台的Web开发工具。因此，我认为当时如果Borland能坚持下去，
就将拥有绝佳的市场契机。

在1997年的Borland Conference中，除了Michael Gardner的讲座之外，IntraBuilder
的Architect Randy Solton也在Borland Conference主讲了两个讲座，深入地讨论了
IntraBuilder 2。0的新功能和实现技术。

此外，当时IntraBuilder的产品经理Klaus Krull(K.K.)也在现场同台演出，并且声
明IntraBuilder 2.0的Beta版将提供给有兴趣的开发者测试。从所有的迹象来看，
IntraBuilder 2.0已经是蓄势待发了。

另外，当时IntraBuilder的QA工作，是由华人出身的Ken Chan所领军。其实从Borland
C/C++ 3.0开始，华人在Borland的R&D以及QA部门中一直占有一定的比例，对于Borland
产品开发有着不小的贡献。

不过，事情的发展很快就出乎所有人的意料，在Borland Conference 1997年举行过
后不久，Borland突然放弃了IntraBuilder。这个消息传来，对于当时急切等待
IntraBuilder 2。0的我来说，实在是晴天霹雳。为什么Borland会突然放弃
IntraBuilder，这是当时我一直想要了解的问题。我曾经询问过台湾Borland的好友，
但是他们也不知道实际的原因。后来我曾经听到几种说法：其一是Delbert Yocam对于
IntraBuilder没有兴趣，因此不愿意再投入资源开发下去；另外的传言则是Borland
决定全力开发JBuilder，因此把IntraBuilder的资源移到JBuilder去；还有的说法
是IntraBuilder开发团队和Delbert处不来，因此集体离开Borland。不过事情的实际
答案仍然是一个谜，即使到了今日，我再次为Borland工作时，仍然无法获得确定的
答案，实在令人遗憾。

我认为IntraBuilder是最为可惜的产品之一，因为早在1996年，当其他软件公司尚未
察觉到Web需要一个良好的、能够和数据库整合在一起的开发工具时，Borland居然就
已掌握到软件时脉，而且推出了实际的产品，可说是一片大好，也是Borland少有能
够走在别人前面的好时机。如果当时Borland好好地持续开发IntraBuilder，我相信
IntraBuilder一定会成为比今日Macromedia的UltraDev还好的产品，而且也将是我认
为属于"消费型软件"的产品，Borland将可在数年之后的公元2000年大展鸿图。只可
惜Delbert Yocam似乎是脑筋坏了，不然就是没有眼光，居然在IntraBuilder 2.0几
乎已经完成之前决定放弃。不但让Borland失去了在Web开发工具方面占有一席之地的
机会，也失去了数年后让全世界疯狂的Internet/Intranet和DotCOM的黄金发展阶段，
真是令我扼腕。甚至在Delphi 3/4时，我强烈建议在Delphi中开发类似的IntraBuilder
功能的心愿也无法达成。我想，这应该是Borland在并购Ashton-Tate之后，另外的一
个重大失策。

令人遗憾的结局

在Delbert Yocam决定放弃IntraBuilder之后，这个举动也几乎成为压垮骆驼的最后
一根稻草，因为这对Visual dBase小组实在是一个非常大的打击。Visual dBase小组
已经看到Visual dBase的市场不断地下滑和萎缩，因此急需一个新的产品以增加收入
并开拓未来的产品线。不过，在Delbert决定了IntraBuilder的命运之后，也代表了
宣布Visual dBase小组终将结束的未来。正是由于Delbert的决定，引发了1、2年后
Visual dBase小组所有人都急于跳下Visual dBase这个曾经一时的旗舰，转而纷纷希
望加入Java这艘新的战舰，从而引发了稍后Borland内部的极大争议。

直到现在，我仍然非常喜欢和怀念IntraBuilder。因为我在CDC服务时，便曾和一位
同事共同把IntraBuilder引入CDC作为开发Web解决方案的开发工具。由于CDC使用Delphi
作为主力开发工具，而IntraBuilder的开发模式又和Delphi很类似，因此对于
IntraBuilder的接受程度很高。IntraBuilder 1.5解决了中文问题和执行效率问题，
当时我开发的Pilot系统可以执行得非常顺利，因此我决定在Web方面的工具使用
IntraBuilder。没有想到，后来Borland居然放弃IntraBuilder，顿时之间所有的心
血都化为流水。身为Borland产品使用者的我，不能够接受Borland这种处理产品的
方式，更何况Borland在当时也没有提供任何可取代IntraBuilder的产品。Borland
处理IntraBuilder的方式引起了当时许多IntraBuilder使用者的反弹，也让Borland
几乎无法再涉足Web开发工具的市场。

命运坎坷的dBase

回顾dBase产品的一生，实在令人不知说什么好。dBase曾经主导了PC数据库技术的发
展主流，在早期也几乎霸占了PC数据库市场。十几年前，当人们发现一台PC在执行了
dBase之后，居然能够处理许多日常数据，立刻便为dBase不可思议的能力而着迷，进
而创造了dBase不可一世的时代。

1980年8月，George Tare和Hal Lashlee两位先生创建了Software Plus软件公司。稍
后，他们和Microsoft一样，从一个小软件公司购买了Vulcan Data Base软件，并且
根据Vulcan Data Base开发出dBase产品的前身。很快，George Tare和Hal Lashlee
合作的软件便获得了许多使用者的好评，他们的软件逐渐在市场上受欢迎。不久之后，
George Tate和Hal Lashlee便成立了Ashton Tate公司，展开了dBase神话的时代。

在Ashton-Tate推出dBase II之后，正值PC开始快速成长的时期。由于当时的dBase
II在PC上提供了合理的数据处理能力，因此很快便有了大量的使用者，dBase II的影
响力也开始渗入商业使用者领域，而Ashton-Tate这个招牌也逐渐成为广为人知的公
司。

1984年是Ashton-Tate一生最为重要的一年，因为在这年的6月，Ashton-Tate推出了
dBase III。dBase III在数据处理能力、运算速度方面都比dBase II大幅提升，正好
符合当时PC愈来愈大量数据应用的需求。在Ashton-Tate推出dBase III之后，立刻在
全球大卖，随后推出的dBase III Plus更是奠定了Ashton Tare在PC数据库方面至尊
的地位。dBase III和dBase III Plus的空前成功，使得Ashton-Tate营收大增，并且
成为当时全球第3大的软件公司。和Microsoft、Lotus分别以DOS、Lotus 1-2-3和dBase
各在操作系统、Spreadsheet以及数据库市场鼎足而立。

当Ashton-Tate在数据库市场不可一世之时，Oracle还是一个名不见经传的小公司。
怎知10年风水轮流转，现在的Oracle已经成为数据库的霸主。为什么Ashton Tate这
个曾经执PC数据库牛耳的公司后来会一蹶不振呢？这都要从Ashton-Tate的dBase IV
说起。

急转直下的dBase IV

当Ashton-Tate的dBase III/Plus成功之后，Ashton-Tate的野心就更大了，急于和
Microsoft/Lotus逐鹿天下。Ashton-Tate决定投入大量的资源开发下一代的dBase软
件，把处理数据的能力再次提高，并且提供更为复杂的功能。虽然Ashton-Tate的想
法很好，要把PC数据库的竞争再次升高，提供更为高阶的应用，但却忽略了当时PC硬
件设备是否能够跟上Ashton-Tate设定的标准的问题。

在Ashton-Tate开发dBase IV到中期之后，却发现当时PC的设备无法顺利执行dBase
IV，此时Ashton-Tate才发现事态严重。其实，在Ashton-Tate开发dBase IV之前，并
没有评估硬件需求或是没有控制dBase IV的开发。无论如何，对于Ashton-Tate来说，
dBase几乎是唯一的软件，也是成功的支柱。结果，对于最重要的产品居然管理成这
个样子，从这个迹象便可知当时的Ashton-Tate可能被dBase III/Plus的胜利冲昏了
头，也开始夜郎自大起来。

Ashton-Tate发觉了dBase IV的问题之后，立刻和一些软/硬件厂商合作，为当时只能
使用640K内存的PC加入新的内存设备，以便执行需要海量存储器的dBase IV。虽然后
来的确弄出了一个解决方案，但却不为市场大众接受。dBase IV在Ashton-Tate无法
解决内存需求问题之下仍然执意推出，结果市场一片负面评价。不但一般的PC内存不
够无法顺利执行，再加上dBase IV的臭虫极多，立刻被市场所唾弃。原来的dBase使
用者仍然继续使用dBase III/Plus，不愿意升级到dBase IV，这让Ashton-Tate面临
血本无归的窘况。再加上dBase又得面对FoxBase和Borland Paradox愈来愈强劲的竞
争，Ashton-Tate无法推出让dBase使用者满意的下一代产品，只能眼看着市场不断流
失。

1990年初，Ashton-Tate内部起了内讧，导致dBase的主要Architect以及许多工程师
离开Ashton-Tate，而Ashton-Tate在数年之间仍然无法解决dBase IV的问题也让人不
可思议。此时，Ashton-Tate在Paradox和FoxBase的鲸吞蚕食之下，几乎快变成一个
空壳了。公司营收不断下滑，dBase市场占有率不断下降，人员更是快速流失。到了
1991年，Ashton-Tate几乎已经撑不下去了。

在Ashton-Tate快速走下坡之际，却是Borland即将到达巅峰之时。1990年，Philippe
Kahn从Borland本身的Paradox成长情形知道了dBase的状况，已经逐渐看出Ashton-
Tate的颓势。于是Philippe Kahn知道，Borland称霸PC数据库市场的时机即将到来，
而且Borland必须比Microsoft先出手才能够赢得这个不容错过的好机会。

1991年，在Ashton-Tate已经摇摇欲坠之际，Philippe Kahn终于决定出手。因为
Philippe Kahn知道，绝不能让Microsoft先叫牌。更绝的是，Philippe Kahn一出手
就是雷霆一击，条件好得让Ashton-Tate根本无法拒绝。1991年7月，当Philippe
Kahn以440 Million叫牌之后，Ashton-Tate很快就全面投降，决定从此嫁入Borland。

Ashton-Tate的被并购和走入历史

1991年，不可一世的Philippe Kahn以极大的霸气和本钱并购了当时已经快速走下坡
的Ashton-Tate。Philippe Kahn购买Ashton-Tate的真正目的是为了与Bill Gates一
争长短，以图成为PC软件界的霸主。另外一个目的则是为了彻底消灭dBase，因为
Philippe Kahn认为Borland自己的Paradox比当时问题多多的dBase IV好得太多了，
一旦dBase退出市场，那么Paradox即可席卷PC数据库市场，让Borland同时成为PC开
发工具以及PC数据库市场中的老大，进而同主掌PC操作系统的Microsoft和控制PC计
算软件的Lotus分庭抗礼。

在Borland以不可思议的高价购买了Ashton-Tate之后，立刻引来了华尔街的批评，因
为华尔街的分析师都认为Philippe Kahn出的价格太高，Ashton-Tate在当时并不值440
Million多美金。不过对于Philippe Kahn来说，用4亿多美金来与Microsoft/Lotus一
较长短的大企图相比，实在不算什么，因为Borland有的是钱。

在1991年Borland并购Ashton-Tate时，Borland的市值其实比Ashton-Tate小。当时的
Ashton-Tate是排名第5的软件公司，而Borland只排名到第9。但是Ashton-Tate已经
在走下坡，手头拮据。反观Borland则是蒸蒸日上，现金多多。Borland并购Ashton-
Tate一事，媒体都以"小鱼吃大鱼''为标题进行报道。当时Ashton-Tate的营业额大概
是250多个Million美金，而Borland的营业额则大约是230多个Million。因此，在Borland
加上Ashton-Tate之后，立刻成为一个年营业额将近500 Million的软件公司，排名跃
为当时全球第3大的软件公司，仅次于Microsoft和Lotus。读者可以想想，现在的Borland
年营业额才200多Million，但是10年前却已经拥有500 Million，可见当时Borland的
盛世和规模之大。在Borland完成了Ashton-Tate的并购之后，Philippe Kahn每日都
得意洋洋，因为在Philippe Kahn看来，成为全世界第一大、击败Microsoft的日子已
经不远了。

Ashton-Tate被Borland并购之后，其光辉灿烂将近10年的时光也随之消逝。Ashton-
Tate原本很有机会成为今日的Oracle，继续占据PC数据库市场龙头的地位，没有想到
Ashton-Tate却把好好的一盘棋下到了死局，硬生生地把自己的命脉产品玩完。虽然
Ashton-Tate是一个很好的负面教材，但人类似乎永远学不会历史，数年后的Informix
也走上了和Ashton-Tate极为类似的道路。

不甘之作，dBase For Windows 5.0

在Philippe Kahn得意不久之后，Microsoft也并购了FoxBase这家公司，并且快速地
推出了FoxPro这套可以在Windows下执行的、与dBase兼容的软件。由于Microsoft掌
握了原本DOS下dBase程序员急需一个Windows下的dBase开发工具的心态，因此当FoxPro
For Windows推出之后，立刻吸引了许多原先dBase III/dBase III Plus的使用者。
虽然Borland在Microsoft推出FoxPro For Windows之后开始流失使用者，但是，由于
其时Paradox For DOS的销售仍然良好，因此，Philippe Kahn并没有放在心上，仍然
认为最终Paradox For Windows可以击败FoxPro For Windows。在这里，Philippe Kahn
显然犯了轻敌的错误。

在Microsoft连续推出两个版本的FoxPro For Windows之后，Borland终于察觉原先dBase
的使用者正处于快速地流失之中。虽然Borland已经推出了Paradox For Windows，而
且销售也在预期之中，但是很显然，Paradox For Windows并不能阻止dBase客户的流
失。Philippe Kahn此时才开始着急。此外，Borland也面临还在使用dBase For DOS
使用者强大的压力，他们要求Borland推出dBase For Windows。

其实，dBase For Windows产品本身还是不错的，不过由于已经太晚加入Windows平台
数据库战场，而且是在匆促上阵的情形下，本身的臭虫当然不少，再加上得面对轻装
上阵的FoxPro For Windows，dBase For Windows几乎没有什么胜算。随后的结果果
然如同许多人预期的一样，dBase For Windows在推出之后不但无法憾动FoxPro For
Windows的江山，反而引来原本期待的dBase使用者的绝望。dBase的使用者在苦等Windows
版的dBase数年之后，Borland仍然无法提供一个高品质的产品。顿时之间，大量不满
的dBase使用者都转向了Microsoft的FoxPro For Windows，也造成了dBase For Windows
不可挽回的败势。

在dBase For Windows失利之后，许多人都开始把矛头对向Philippe Kahn，认为是
Philippe Kahn的自大和轻敌搞死了dBase For Windows这条原本有机会的产品线。如
果Philippe Kahn能够在并购Ashton-Tate之后好好地开发dBase For Windows，并且
在Microsoft的FoxPro For Windows之前推出，那么Borland将可让大部分dBase For
DOS使用者转入Windows的市场。唉，如果时光能够倒转，如果Borland能够早一步推出
dBase  For Windows，再进而开发出后来的关系数据库(Relational Database)产品，
那么，Borland现在可能仍然是前3大的软件公司。

最后的帝王--Visual dBase 7

很显然，Microsoft以极小的代价购买了FoxBase，并且用FoxPro For Windows抢走了
Philippe Kahn花大钱购买来的dBase使用者，的确是等于狠狠地打了Philippe Kahn
一巴掌，让Philippe Kahn知道，先出手并不代表会赢得最后的胜利。

这对于日日夜夜想打败Microsoft的Philippe Kahn来说，当然是无法忍受的耻辱，因
此，Philippe Kahn念念不忘的就是如何扳回一城。在dBase For  Windows 5.0失利
之后，Borland决定再次重新出发，准备推出新版本的dBase For Windows，来挑战
FoxPro For Windows。不过，市场情势的发展却出现了变化，PC数据库市场已经开始
走入关系数据库的时代，桌面型数据库的市场已经开始出现下滑的现象。

1997年12月，Borland推出最后一版的dBase For Windows 7.0来角逐市场。dBase For
Windows 7.0的品质和功能才是Borland早该在几年前推出的产品，如果Borland早几
年推出dBase For Windows 7.0，那么Windows下dBase的市场绝对会由Borland寡占，
FoxPro For Windows将不是对手。只可惜时不我待，在dBase For Windows 7.0推出
之际，Windows下dBase的市场已经大势已定。虽然dBase For Windows 7.0的确是一
个好产品，但是它再也无力改变市场了。此外，此时PC桌面型数据库的市场也逐渐萎
缩，Microsoft也准备走向关系数据库市场，Windows下dBase的市场对于Microsoft来
说，已经不那么重要了。

在dBase For Windows 7.0推出之后，Borland事实上也察觉到了PC数据库市场的变化，
准备以InterBase进入关系数据库的市场。至此，延续数年之久的PC桌面型数据库
的战火也终于近乎停止状态了。

当Borland的Visual dBase小组发现整个数据库市场的变化之后，内部产生了相当大
的矛盾，许多Visual dBase的工程师在不看好dBase产品的情形下纷纷决定转换跑道。
"弃船"也许是当时最适当的形容词，几乎所有的Visual dBase的工程师都希望进入
Borland Java开发小组，没有人愿意继续留在Visual dBase小组。因此，当时Visual
dBase小组在Borland内部引起了不小的骚动。每一个人都想到Java小组，许多Borland
C/C++小组的工程师也都希望进入Java开发小组，但是Java小组并不能容纳这么多人。
最后许多无法进入Java小组的工程师不是离开Borland，就是随着Borland卖出dBase
时跟随Visual dBase到了新的公司。

最后的晚餐

1998年的Borland Conference应该是Visual dBase在Borland最后一次的盛会了。当
时使用Visual dBase的使用者已经不多，因此在BorCon 1998年中Visual dBase的讲
座也不多。不过对于一些dBase的忠诚使用者来说，Visual dBase 7.0仍然是他们的
最爱。因此在BorCon 1998年，当时在Visual dBase界中最著名的支持者Alan Katz负
责了许多Visual dBase的讲座，也号召了许多dBase的使用者参加这次的Borland
Conference。

Alan Katz的努力显然是希望Borland不要放弃Visual dBase，能够继续开发dBase的
产品。不过，这些努力仍然无法挽回市场的形势以及Borland的决心，BorCon 1998也
终于成为Visual dBase最后一次的舞台。

生命的延续--dBase 2000

1998下半年，Borland终于决定把Visual dBase卖掉，因为Borland已经不想在Desktop
的数据库市场竞争了。在Borland决定卖掉Visual dBase的信息传出之后，立刻引起
了许多dBase使用者的强烈反应。他们认为Borland不负责任，因为如果Borland随便
把Visual dBase卖掉，那么Visual dBase便注定会从此消失。由于当时dBase使用者
的压力太大，因此Borland不得不小心翼翼地处理这个烫手山芋。当时的Borland已经
是放也不是，不放也不行了。

为了缓和dBase使用者的强烈不满，Borland宣布会谨慎地选择购买dBase的公司，而
不会随便把dBase卖出去。这个时候，Alan Katz也知道了Borland的决定。出于对
Visual dBase的热爱，Alan Katz决定找寻资金来源把dBase的版权从Borland的手中
买下来。很快，他找到了一些dBase的爱好者，每人拿出一定的资金来集资购买Visual
dBase的版权。在Alan Katz取得了资金之后，便立刻和Borland联络，准备和Borland
谈判。当然，在Alan Katz集资的过程中，Borland也试着寻找对Visual dBase有兴趣
的公司或是个人，不过这个过程并不顺利。

因此当Alan Katz和Borland接触之后，双方立刻有了交集，双方都有很高的意愿。不
过，在深入的谈判之后，Borland很快发现Alan Katz的资金和Borland想要求的版权
费有很大的距离。原本Borland不太想再谈下去，不过，在Alan Katz和Borland接触
的消息传出之后，却获得了许多dBase使用者的欢迎。Alan Katz在dBase界的高知名
度以及多年来对于dBase的贡献都让dBase的使用者觉得，如果由Alan Katz收购dBase，
那么dBase仍然将有美好的未来。于是dBase的使用者开始向Borland施压，希望Borland
能够成功地和Alan Katz谈好条件。

虽然Borland不太接受Alan Katz的条件，但是在遍寻不到适合的买主、再加上dBase
使用者的强烈要求和Borland急于解决Visual dBase的情况下，Borland终于在半买半
送的条件下把dBase所有的原始程序以及版权卖给了Alan Katz。在Borland决定出脱
dBase给Alan Katz之后，Alan Katz便立刻和朋友成立下KSoft软件公司，准备延续
Visual dBase的产品生命。

1999年3月12日，Borland终于廉价售出了1991年花费数亿美金并购来的dBase产品，
dBase在Borland不受重视的日子也终于结束。Alan Katz在购买了dBase的版权之后不
久，便把公司更名为dBase Inc.公司，1年之后，也就是2000年的12月，dBase Inc.
推出了自己的新dBase产品，取名为dBase 2000，至此dBase系列产品也终于正式延续
了产品生命。dBase在80年代诞生以来，持续生存了近20年的时间，可说是PC软件中
生命力最为强韧的软件了。dBase被Philippe Kahn的狂妄自大所牺牲，IntraBuilder
因Delbert Yocam目光如豆而夭折。虽然dBase因为再转卖给其他公司而得以延续生命，
但是对于Borland来说，dBase和IntraBuilder终究是在遗憾中结束了生命的产品。

Paradox

对于Borland来说，Paradox一直是棵摇钱树，为Borland赚进了大把的钞票，同时也
让Borland称霸PC数据库市场。不过Paradox并不是Borland自己研发的(嗯，写到这里，
我才突然想到，Borland数据库产品几乎都不是自己开发的，都是并购来的)，是从一
家叫做Ansa的小公司购买来的。在1985年，为了进入PC数据库市场，Borland看上了
Ansa公司的Paradox产品，于是在1985年的秋季正式购买了Paradox，成为Borland第
一个数据库开发工具。

其实，在Borland所有的数据库产品中，Paradox是最受Borland照顾的，这也许是因
为Paradox是Borland的第一个数据库产品，也或许是因为Philippe Kahn对于Paradox
情有独钟。但Paradox对于Borland也有着很大的影响，因为Paradox后来不但成为Borland
的主力产品之一，存取Paradox的数据存取引擎也成为数年后Delphi的主要数据库和
存取引擎，BDE/IDAPI也是从Paradox Engine演化而来的。

Borland取得了Paradox之后，很快就开发出了Borland Paradox For DOS，正式进军
PC的数据库市场。由于Paradox当时独特的Query By Example(QBE)以及每一个版本都
维持兼容的良好特性，很快就吸引了许多的使用者，Paradox也成为当时dBase系列之
外另外一个非常流行的数据库产品，在国外非常的盛行。而Paradox之所以没有在台
湾/大陆等地流行起来，原因便是Paradox一直和Double-Byte的兼容有问题，无法正
确地处理中文信息。

由于Paradox在DOS以及Windows初期的版本中表现得非常抢眼，因此Philippe Kahn一
度想以Paradox称霸PC桌面型数据库市场，投入许多的资源研发Paradox For Windows，
并且不惜压制Borland自己的dBase产品来壮大Paradox在Windows市场的占有率。不
过，很显然Borland的脑筋仍然没有转过来。在dBase、Paradox和FoxPro等PC数据库
开发工具被使用了多年之后，已经开始慢慢地进入一般计算机使用者的市场来解决日
常数据处理的工作，因此在PC桌面型数据库市场，已经开始需要一些比dBase、Paradox
和FoxPro等更简易、好用的产品了。在这方面Lotus便掌握得比Borland好，因为Lotus
开始开发适合一般计算机使用者的桌面型数据库工具，那就是后来的Lotus Approach。

Paradox的导向一直是以程序员为主，后来Paradox引以为傲的开发语言Paradox
Application Language(PAL)也以面向对象为宣传重点，强烈地吸引着想使用面向对
象技术开发数据库应用程序的程序员。正是因为Paradox从头到尾都是以程序员为导
向，所以在Paradox到达了巅峰之后，仍无法吸引一般的计算机使用者，也无法进入
这个新兴的市场--Paradox对于这类计算机使用者而言实在是太困难了。因此，当
Lotus的Approach步步为营(嗯，"Approach"这个名字还真符合当时的状况)，掌握
了新起的PC桌面型数据库工具市场之后，Borland等于同时失去了dBase市场给FoxPro，
又无法通过Paradox渗入新的数据库工具市场。

当Borland也察觉到Paradox的瓶颈以及新兴起的PC桌面型数据库市场之后，急于让
Paradox进入Lotus Approach掌握的市场。因为Borland相信，以Paradox这么优秀的
品质，绝对有机会同其他新的竞争对手一较长短。因此，Borland开始了Paradox
For Windows 5.0的研发工作，准备为Paradox加入许多简易的功能，以打开新市场
的契机。

虽然Borland很努力地想要转变Paradox的产品形象并且打入新的市场，无奈Paradox
的产品定位已经非常的固定，而且此时Microsoft也进入了PC桌面型数据库工具市场，
并且以Microsoft Access屠杀和血洗Lotus Approach，Paradox当然再也没有机会在
这个市场称雄了。不过也还好，Borland晚了一步进入这个市场，才没有让Paradox
和Approach一样被Microsoft的Access以极为不合理的手段所消灭。

1994年3月，当时的Novell还想在Office产品线中和Microsoft一争长短，因此大手笔
地并购了WordPerfect公司，并且从Borland买走了Quattro Pro以及Paradox的使用权。
Novell当时的想法是让这些Office产品和Novell的Network OS连接在一起，以便与
Microsoft抗衡，挽救Novell日益下滑的局面。不过，当时我根本不看好Novell的这
个举动。连开发商业应用程序为主的Lotus都不是Microsoft的对手，更何况从来不以
商业应用程序为擅长的Novell呢？而且除了NOS之外，Novell还开发出过什么知名的
产品呢？因此，Novell真正的目的恐怕并不是和Microsoft竞争，而是为了固守Novell
NOS的地盘，防止被Microsoft进一步地侵蚀。从这个现象，我们可以知道Novell早
在1994年便开始逐渐采取防守的策略，已经无力和Microsoft竞争了。

Paradox的告别作

Paradox和Borland的缘分似乎已经快到了尽头，虽然Borland试图在Paradox For
Windows 5.0时改变Paradox的策略，转向一般计算机使用者，不过Borland的努力显
然失败了，Paradox的核心就不是为这个市场设计的。因此，在Paradox For Windows
5.0表现得不如人意之后，Borland又决定把Paradox定位在专业的P C桌面型数据库工
具市场，准备推出下一个Paradox重要的版本--Paradox For Windows 7.0。

1995年12月，Borland推出了几乎是品质最好的Paradox，即Paradox For Windows 7.0。
严格地说，Paradox For Windows 7.0是当时所有PC桌面型数据库开发工具中功能最
强大、品质最稳定的工具，可以说是当时的王者。可惜时不我待，其时大部分的桌面
数据库应用都被Microsoft Access抢走，一般PC使用者的人数远超过数据库程序员的
数量，因此，Microsoft Access的销售量是其他所有PC桌面型数据库开发工具的数倍
之多，再加上关系数据库也快速地流行于PC的应用之中，PC桌面型数据库开发工具在
上/下夹攻之中，市场也逐渐地消失了。

对于PC桌面型数据库开发工具市场的不断萎缩、以及关系数据库市场的快速兴起，
Borland也了解到必须正视市场的变化。因此，Borland开始着手从Ashton-Tate取得的
InterBase，准备进军关系数据库市场，同时卖出Paradox以集中资源开发InterBase。
此时，刚好Corel夹着CorelDraw以及绘图软件取得的雄厚资金从Novell手中又买下了
PerfectOffice所有的软件。因此Borland也决定一次性把所有的Paradox版权卖给Cord。
1996年1月底，Borland正式和Corel签约，卖出最后Borland保留的Paradox权利给Corel。
从此，Borland不再拥有任何Paradox的权利，也不再继续开发Paradox。这也就是为什么
Delphi/C++Builder之中的Paradox数据库规范最高只到Paradox 7，因为Borland再也
没有权利开发新版本的Paradox以及Paradox引擎和数据库规范了。

Corel在取得了Paradox之后，也持续地开发Paradox For Windows一直到9.0的版本，
但对于市场已无任何举足轻重的影响，因为延续10几年的PC桌面型数据库市场已然退
出市场的主流，不管是dBase、FoxPro、Paradox还是其他的类似产品，也注定被Access
和关系数据库所逐渐取代。

后言

Borland在PC桌面型数据库以及关系数据库方面的战役一直是问题连连。除了Paradox
之外，Borland接连错失了以dBase主掌天下的大好时机，也没有及早通过InterBase
进入关系数据库市场。如果当时Borland能够在一开始从Ashton-Tate取得InterBase
之后，立刻研发和进入关系数据库市场，那么以当时Borland的力量绝对可能成为关
系数据库的霸主。因为在那个时候，Oracle等公司还是非常小的，而Microsoft也没
有关系数据库的产品，但是Borland手中却有InterBase。无奈，Philippe Kahn没有
看到未来数据库市场可怕的成长潜力，任手中的宝贝闲置了好几年。等到其他的关系
数据库厂商已经闯出了名号后，才发现原来自己家中早已有一个好东西，但是在落后
别人已多的情形下想要追赶，却已不容易了。

Borland在PC数据库市场上犯了过多的错误以及失去了许多宝贵的机会，否则很有可
能主宰PC数据库市场、持续地和Microsoft竞争，并且站稳软件大厂的地位。回顾Borland
在PC数据库市场的搅和，实在是令人不解而又令人叹息!既然有眼光并购潜力十足的
各个数据库厂商，为何又放任大好的契机流失呢？这个问题的答案恐怕只有Philippe
Kahn才知道了。

第七章  中途岛之战--Borland和组件技术

"没有中间件技术，我们就没有未来!"

Golden Gate Strategy

1996年，Borland察觉到软件技术将会开始朝中间件的方向发展。由于Borland一向只
开发工具软件，因此如何面对这个软件趋势便成了重要的问题。当时Borland陷入一
片混乱之中，新任CEO Delbert Yocam还尚未进入公司，软件和产品线的开发方向几
乎都是由担任Borland R&D Director一职的Paul Gross负责。1996年7月，Paul Gross
和Delphi的负责人Zack共同激活了一个崭新的计划，其目的是为了让Borland能够在
未来的软件业界中保持高度的竞争力。

当时，Borland已经开始想往企业市场发展。但是，Borland缺乏企业市场需要的大型
架构技术，那就是所谓的中间件(Middleware)。中间件通常都非常复杂，而且需要许
多时间才能够开发完成，更何况中间件服务器都需要运行在许多不同的硬件平台上，
例如SUN、HP和IBM等大型机器中，而那时Borland只是一个开发PC软件的公司，不但
对大型机器的开发完全没有经验，而且也没有相关的硬件设备来支持开发。尽管如此，
Borland和Paul都知道，在未来中间件技术绝对是软件产品的主战场之一。如果Borland
不趁早往这方面发展，那将永远没有机会成长为大型的软件公司。因此，Paul和Zack
知道，Borland必须想办法克服所有困难，以取得中间件技术。当然，最快的方法就
是并购拥有这方面技术和产品的公司。在寻寻觅觅了一段时间之后，Paul终于找到了
在Boston的一家软件顾问公司。虽然这家公司不大，但是却拥有使用RPC(Remote
Procedure Call)通讯协议技术的中间件市场的领导产品--Entera。

RPC是一个存在了非常久的软件技术，发展得非常成熟。Entera被许多如HP之类的大
型公司使用。于是Paul想通过并购这家软件顾问公司以取得Entera，再通过Entera把
Borland打入企业级市场。如果Borland能够整合Entera和Borland的开发工具，那么
大型企业可能也会开始使用Borland的工具。这对于Borland来说，算是很好的机会，
因为如此一来，Borland不但可以取得中间件技术，更可以让开发工具进入以往Borland
难以进入的市场。

就在Paul心动之际，又恰逢这家位于Boston的软件顾问公司经营发生了问题，也在寻
找新的资金来源，因此和Borland可以说是一拍即合。不久之后，Borland便宣布，Entera
正式成为Borland的产品之一。在Paul决定并购Entera之后，立刻激活了Golden Gate
Strategy(金门战略)，开始要求Borland的开发工具必须和Entera整合在一起。同时
Borland也第一次开始大量购买大型的硬件，准备研发Entera，至此Borland通过Entera
正式进入了大型的以及基于UNIX平台的软件市场。

在Borland取得了中间件技术和产品之后，便很高兴地把Golden Gate Strategy呈现
给世人，宣示Borland已经成为整合科技的领导厂商之一。当时Paul还特别拨了一笔
预算，拍摄了一个宣传Borland Golden Gate Strategy的动画影片，其中使用的宣传
语是"We don't want to own the world，we just want to make it work better(
我们不想拥有世界，只想让它运作得更好)"。相信许多读者可能会记得这个影片。

Borland在取得了Entera之后，算是进入了陌生的中间件市场。虽然Borland通过Entera
企图打入企业市场，但严格地说，Entera只是让Borland这个招牌被较多的企业知晓。
而Borland在销售Entera方面表现得并不好，因为Borland一开始并不熟悉RPC技术，
另外就是Borland当初的销售体制无法成功地销售企业级的软件，因为新的公司体
制尚未建立起来。由于Entera在之后的表现不如人意，后来几乎只有Entera的旧客户
才购买新版本，Entera已经无法吸引新的客户了。这当然也是因为市场上的中间件技
术主流已经慢慢转换为使用CORBA和DCOM技术。因此，不久之后，Borland便把Entera
的维护和开发新版本的工作交由Borland亚洲研发中心新加坡来处理了。

Borland一直到取得了CORBA技术之后，才开始真正掌握中间件技术，并且逐渐打入企
业市场。

并购Visigenic，取得CORBA技术

Borland在第一次的中间件尝试不甚成功之后，还是没有放弃想在中间件开发的决心。
当企业市场的中间件主流技术转为使用CORBA之后，Borland又看到了第2次机会。

当CORBA技术逐渐被企业和PC界视为明星技术之后，提供CORBA相关产品的IONA和
Visigenic便成为许多人眼中的潜力软件公司了。不过由于IONA已经早一步推出了CORBA
产品并且也已经拥有了许多客户，因此IONA成长得非常快速。相反Visigenic是刚成立
不久的小软件公司，而且还处于亏损状态。

Visigenic是由Roger Sippl先生创立的。Roger Sippl是信息业界非常有名的人，因
为他也是Informix的创始人。像Roger Sippl这样的人，在美国被称为"创投冒险家"。
这群人的特点就是拥有极为敏锐、先趋的眼光，不断找寻新的信息契机成立软件公司。
一旦新公司有了一点成果之后，便立刻果断地卖出公司以求获利，而甚少长久经营一
家公司。

Roger Sippl创立了Informix公司，在有了一点经营成果之后，立刻把Informix卖掉，
大赚一笔，此后又再试图建立其他的小公司寻找机会和买家。Visigenic就是后来Roger
Sippl看好CORBA技术之后成立的小公司。Borland看到CORBA的潜力，但没有足够的本
钱并购IONA，因此看上了规模还小的Visigenic。Borland找上Visigenic，表示愿意以
数百万美金和股票分配权购买Visigenic公司，当然Roger Sippl立刻答应了。因为如
此一来，Roger Sippl不但可以让Borland负责Visigenic的负债，还能够赚进大把的
现金和Borland的股票，何乐而不为呢！

因此在1997年11月，Borland正式购买了Visigenic，而Roger Sippl也成为Borland当
时的CIO。当时我就知道，Roger Sippl一定是暂时性的担任Borland的CIO，目的就是
帮助Borland顺利接收Visigenic的产品线。一旦Borland掌握了之后，Roger Sippl一
定会立刻离开Borland，再次找寻新的机会。果然当Visigenic的产品在Borland稳定
之后，Roger Sippl也就离开去创立其他的软件小公司了。不过，对于Borland来说，
这并没有损失，因为Borland要的本来就只是Visigenic的CORBA产品。1998年，我还
在Borland的总部Scott Valley聆听了已经快要谢顶的Roger Sippl的演讲，宣示Borland
未来在中间件市场的光明前景。那也是我最后一次看到Roger Sippl。Borland取得了
CORBA产品之后，果然没有再败坏家产，而是立刻投入资源开发Borland自己的CORBA
产品线，那就是VisiBroker。很快，Borland就有了成果。当时Netscape正和Microsoft
火拼到最高点，Netscape为了增加Navigator在企业级市场的优势，决定在Netscape
中内建CORBA客户端引擎。在Netscape评估了IONA和Borland的CORBA产品后，决定使
用Borland的CORBA引擎，因为当时Borland虽然没有像IONA一样拥有比较完整的CORBA
产品和CORBA服务，但是VisiBroker却拥有体积小、执行速度快的优点，正好适合在
客户端的浏览器中使用。

当Netscape找上Borland的时候，Borland简直是喜上心头。当时的Netscape是如日中
天的软件公司，全世界使用Navigator浏览器的人数超过数百万。如果Netscape决定
使用VisiBroker，那Borland不但得到了最大的客户，而且还可通过Netscape的名气
立刻让全世界的人、包括企业级的使用者都知道Borland这家公司，了解Borland是有
能力提供企业级的软件解决方案的。

在Netscape和Borland磋商之后，立刻就有了结果。Borland答应以极低的价格授权
Netscape在Navigator中使用VisiBroker。虽然在这次的商业谈判中，Borland几乎
没有什么赚头，但是，Borland却达成了极为重要的形势胜利。首先是通过Netscape
的授权使用，Borland的VisiBroker在CORBA市场的占有率立刻超越了IONA；第二是
VisiBroker通过Navigator打入了企业市场，让许多大型的企业开始对VisiBroker产
生了兴趣，以致后来VisiBroker在金融和电信领域突破IONA的阵地，成为更受欢迎
的CORBA引擎；第三点当然就是Borland可以通过Netscape这个成功的案例宣传Borland
的CORBA产品，让VisiBroker再也不会矮上IONA的产品半截了。

在这次成功地出击CORBA市场之后，Borland终于开始让IONA正视自己为最强劲的竞争
对手了。这也开始了Borland和IONA之间无止境的CORBA大战，双方在各个CORBA应用
领域厮杀惨烈，一定要分出高下。

当然，Borland在CORBA的成功也让Patti和Zack的Golden Gate计划显得比较圆满，而
且在Paul和当时Borland R&D Director Joe Bently的要求下，Delphi和C++Builder
也都开始支持CORBA的功能。至此Golden Gate计划逐渐走向成型阶段，Borland终于
在中间件技术杀出了一条血路。

Paul Gross的愤怒和Golden Gate的坠毁

但不幸的是，当Delbert Yocam在1999年4月被Borland董事会踢出门之后，担任Borland
R&D副总裁的Paul Gross便一直认为Borland新的CEO职位应该非他莫属了，于是开始
积极争取CEO一职。不过，Borland的董事会却认为如果公司真的想进入企业市场，就
必须拥有专业的销售团队，需要一个在销售领域非常有经验的人来担任CEO。Paul Gross
出身于R&D，对于销售没有太多的经验，无法为Borland建立起所需要的销售团队。因
此，Borland董事会决定从外面寻找新的CEO。

在得知了Borland董事会的决定之后，Paul Gross非常愤怒。因为他认为Golden Gate
Strategy是他策划的，Borland能够进入企业市场，取得中间件技术，都是因为他的
眼光和功劳。现在Borland董事会居然不考虑由他接任新的CEO，Paul Gross心中充满
了怨言，对于Borland产品线的开发工作也就顿时失去了兴趣。

在Borland开始向外寻找新的CEO之际，Microsoft也得知了这个信息，于是马上就和
Paul Gross接触，想了解Paul Gross的动向。此时正是Paul Gross最不满的时候，因
此和Microsoft相谈甚欢，很快便答应到Microsoft工作。由于Paul在Borland已经是
R&D部门的副总裁，因此Microsoft答应给Paul的职位也是Microsoft开发工具部门的
副总裁，负责Microsoft的Visual Studio以及Internet方面的产品研发工作。这又是
一个Microsoft直接挖角Borland人才到自己公司担任类似工作的例子。Paul Gross虽
然是以副总裁的角色被挖走，Microsoft给予Paul的待遇也很高，但和Anders Hejlsberg
比起来还是差多了。这也说明美国对于技术专才的重视，高层管理人员的待遇不见得
会比第一流的技术人员高。

注：从Paul Gross的事例中，似乎可以看到技术人员的宿命。技术人员最高的职位好
像就是技术副总裁了，想做CEO是不太可能了的(除非是技术人员自己开的公司)。这
是真的吗？

看来，Paul Gross在Gold Gate Strategy中写错了那句名言。Paul Gross是想拥有全
世界的，所以才加入Microsoft，不是吗，Paul？

随着Delbert Yocam、Zack Urlocker以及Paul Gross等人一一离开Borland，Golden
Gate Strategy就再也没有人提起了。虽然Borland已经拥有了当初Golden Gate Strategy
规划的所有软件技术，不过在Java快速兴起并且掌握了企业市场之后，软件的发展似
乎已经移转到了Java应用程序服务器市场。这个软件趋势也造就了BEA的快速成长。
等到Borland的下一任CEO Dale Fuller先生任职之后，他立刻投入大量的资源进入Java
应用程序服务器的竞争市场。至此，Golden Gate Strategy也就正式成为历史灰烬了。

到EJB的阵地吧！

虽然Borland在CORBA领域逐渐超越IONA，并且开始成为市场的领导者，不过，Java的
日渐兴盛也开始让CORBA面临考验。而在Windows平台，CORBA也必须面对Microsoft的
COM/COM+中间件技术的竞争。当SUN提出Java的RMI技术后，一些对CORBA并不了解的
人开始鼓吹CORBA已经是日薄西山了，他们认为CORBA这个已经存在许久且复杂的技术
可能会被Java方面的RMI取代。不过，后来事实很快就证明RMI根本无法取代CORBA。
先不说RMI的功能和CORBA比起来简直是九牛一毛，更何况RMI的执行效率根本不是CORBA
的对手，因此关于RMI是否能取代CORBA的争论很快就平息了下来。

不过，当SUN提出了J2EE架构准备力推EJB技术时，又有许多人不看好CORBA的命运，
认为CORBA的长路将尽，Java世界终将使用EJB而不是CORBA。一开始，SUN也认为EJB
是最好的中间件技术，认为企业应该采用EJB作为中间件的引擎来开发企业应用系统。
不过当SUN真正试着把EJB打入企业市场时，才发现CORBA早已在企业市场根深蒂固，
许多大型的应用系统都是使用CORBA技术开发的。如果SUN要把EJB推上企业中间件
的主流，那么EJB一定要能够同CORBA兼容和沟通。因此后来SUN修改了EJB的规格，让
它和CORBA兼容，以顺利解决大型企业需要整合CORBA以及新的EJB技术的需求。

Borland很早就发现CORBA和EJB根本不冲突，反而有很高的兼容性，CORBA的跨平台特
性又非常适合用来实现EJB的功能规格。因此在1999年，Borland开始进行用VisiBroker
作为实现EJB服务器引擎的研究工作。Borland在中间件市场付出了庞大的成本，*不
容易才在CORBA方面有了一点成果，如果又被EJB抢走中间件市场的主流，那么Borland
岂不是损失惨重？而且Borland好不容易通过Golden Gate计划进入中间件市场，从RPC、
CORBA一路走来，既然已经在中间件市场投下了重注，那就没有理由现在因为EJB而
退出市场。更重要的是Borland看到了未来EJB市场的潜力，如果SUN真的能够把J2EE
架构打人大型企业应用的核心，那么掌握EJB服务器的厂商将会拥有巨大的商机，因
此Borland无论如何都不能放弃这个市场。

为了在EJB市场成为领导厂商之一，Borland不惜巨资投入了许多的资源来研发EJB服
务器的产品，并且以开发工具和CORBA产品赚得的资源源源不断地资助EJB开发小组，
以期能够早日开花结果，让Borland在EJB的中间件技术市场再下一城，奠定Borland
在这个领域技术至尊的地位。不过事情发展得却并不像Borland预期的那样简单。

几乎也在同一时期，另外两位重量级的厂商BEA和IBM也分别投下了巨大的资源进入EJB
市场。BEA选择的方式是快速并购Tuxedo，并且以Tuxedo为引擎开发EJB服务器；而IBM
则是占有最丰富的资源优势，以最大的团队规模投入Java和EJB市场。虽然Borland也
投入了巨资，但是Borland的"巨资"和这两家比起来根本不够看。很快BEA和IBM就有
了成果。当然，由于UNIX服务器战场的关系，当BEA和IBM推出EJB的服务器之后，立
刻引起HP等大厂商加入EJB来火拼。SUN自然也不会置身事外。一场EJB的世界级大战
展开了。

这么激烈的EJB战场，是当初Borland可能没有想到的。加入中间件技术大战的厂商每
一个的规模都比Borland大上几十倍，甚至是数百倍。这种大规模的阵仗是Borland前
所未见的。因此，当Borland开发出了EJB服务器引擎之后，才发现在大型中间件市场
不是光比技术和产品。除了技术和产品之外，还要比公司招牌的知名度、专业服务、
专业顾问咨询和专业的销售团队。此外，更需要极大的公司资源准备打一场长期的消
耗战。

一直到进入了EJB市场，Borland才真正了解到这个市场的对手是如何对战的。为了在
这个割喉市场生存下去，Borland公司策划了第三次的转变，以便为Borland建立专业
的销售体系，准备以不同的手法开打EJB的战争。这在稍后Borland的演变一文中有详
细的说明。

 

够强壮再玩下去吗?

到了2002年，中间件市场已经到了成熟而且是最后关头的时刻。EJB厂商之间的竞争
已经快见分晓，Borland是否能够坐稳除了BEA/IBM之外的第三领导厂商地位，事关
Borland能否在EJB服务器市场存活下去。又或是Borland与BEA成为联军，一起攻占
其他EJB竞争对手的最后滩头堡呢？这个答案也许在2003年会揭晓。不过，不管如何，
现在的Borland似乎又在中间件市场找到了另外一线生机，那就是.NET平台下的中间
件战争。这个故事将在稍后"EJB对抗CORBA？有趣的假设"一章中讨论。

第八章 Borland的成长和改变

(文章来源：<<Borland传奇>> 电子工业出版社 2004年，作者：李维)

  许多人都用过Borland的产品，就像我和正在阅读本书的读者一样。有的人非常喜欢Borland，有的人则只把Borland当成一个普通的软件公司。不可讳言，软件人员对于自己使用的工具或语言，总有着一股喜爱和狂热。当然，在爱屋及乌的效应下，他们对于推出工具或语言的公司自然也有了类似的情结。
  对于许多软件人员来说，"Borland"这个名字是非常可敬的。因为Borland敢于对抗Microsoft，历经十几年仍然屹立不倒，而且还能不断地推出令人惊喜的产品。这令人印象深刻，使人打心底里佩服。当然，Borland的产品品质有高有低。面对优秀产品，总会让人高兴不已，让人有少康中兴、打败Microsoft、一吐心中闷气的愉悦；相反，对于并不令人满意的产品，又有一种恨铁不成钢、混杂着担心Borland未来的焦虑感。这种既期待又悸动、心情上下反复的感觉，是那些不喜欢Borland产品的人所不能体会的。
  在十几年的发展中，Borland展现了强劲的生命力。在每一个关键时刻，Borland以不同的产品、技术和策略度过了一次又一次的挑战和难关。虽然 Borland始终代表着除了Microsoft以外的最大独立软件开发厂商，可事实上，她从创立一直到现在，已经历经了三个重大的转变。这些转变不但影响了Borland产品的走向，也影响了Borland的组织架构以及未来的发展。不知喜爱或是关心Borland的读者是否注意到这些转变？在继续阅读本章的内容之前，不妨先回头想想您是否知道这些转变。

Philippe Kahn，产品和技术为主的Borland
  Borland的创始人Philippe Kahn代表的是Borland第一时期。在Philippe Kahn主掌期间，Borland从无到有、茁壮成长至全盛，成为全球瞩目的、世人最看好的软件公司之一，继而业绩快速下滑终至差点解体。 Philippe Kahn创造了Borland最辉煌的软件王国，也差点成为亡国之君。先不论Philippe Kahn的功过如何，总之，在他主控的时期，Borland最注重产品和技术，甚至日后Borland的命运也似乎和Philippe Kahn的个性有着密切的关系。
  恃才傲物的Philippe Kahn从来不给美国华尔街的分析师什么好脸色。1991~1993年，是Borland最会赚钱的时代，也是Borland内部生产力最高峰的时期。当时Borland的股票价格高高在上，最高时期曾经每股单价超过了100多美元。在那个时候，PhilippeKahn几乎是Borland的国王，拥有 Borland大量的股票。功成名就的Philippe Kahn认为Borland的成功都是他的功劳、都应归结于他的领导，况且Borland的实力和产品非常坚强，不需要为那些华尔街的分析师进行什么公关工作，Borland的股票仍然将是投资大众的最爱。因此，当华尔街的分析师希望Philippe Kahn能够向他们说明Borland未来的开发方向以及公司在管理和财务方面的信息时，Philippe Kahn并不理会这些分析师。所以，在Philippe Kahn时代，Borland和华尔街的关系并不好。
  有一次，华尔街的分析师邀请了许多公司的CEO演讲，其中也包括Philippe Kahn。没有想到，Philippe Kahn的现场演讲却完全不给这些分析师面子，还嘲笑他们是笨蛋，因为Borland完全不需要任何的分析，Borland就是最好的公司，投资 Borland准没有错。Philippe Kahn这个自大而且不给面子的行为终于惹火了许多华尔街的分析师。这不但使Borland和华尔街的关系更为紧张，而且，许多分析师也常常借机修理 Borland，宰杀Borland的股票。更糟糕的是，在Borland从1994年逐渐走下坡之后，许多分析师更是落井下石，看坏Borland的未来。因此，不时地有Borland将会关闭、被并购或是被拍卖的不实消息散出，让Borland的股票价格快速地往下落底。这都是 PhilippeKahn种下的恶果。
  Philippe Kahn对于产品和技术的坚持造就了Borland，但是太过坚持反而变成了刚愎自用，他完全听不进去其他的意见。通常来说，Philippe Kahn一定会参加Borland许多的产品开发计划会议。对于好的或是他喜欢的产品，Philippe Kahn坚定支持，即使产品可能没有市场，他也不去理会。或者是因为太过于坚持产品、一定要尽善尽美，即使严重地延误了产品应该上市的时期，造成产品已经没有推出的价值，PhilippeKahn也不管。因为Borland是他的，他有100％的决定权。此外Philippe Kahn在许多会议中太过于强势，喜欢主导产品的研发，造成产品开发主管不知如何是好，因此惹火了许多有天分的研发人员，致使他们纷纷求去， Borland C/C++的Eugene Wang就是一个很好的例子。
  Philippe Kahn少年得志，以至于最后目中无人、狂妄自大，终致鞠躬下台。不过，Philippe Kahn毕竟是所有Borland CEO中最重视产品开发的。自他之后，再也没有任何的CEO能像他一样，知道唯有产品和技术才是Borland的命脉。Philippe Kahn对于Borland未来发展的规划也是以产品和技术为主轴。当时的Borland最重视软件开发人才、工程师和产品经理。但从Philippe Kahn下台之后，整个形势慢慢地有了改变。不过，总体来说，这个时期的Borland，是我最喜欢的。

Delbert Yocam，强势Marketing为主的Borland
  Borland第二个重要的时期应该是Delbert Yocam上台之后。在Philippe Kahn被赶出公司之后，Borland历经了一段没有真正CEO的时期。在这个时期，担任CEO的人都只是暂时的，因为Borland董事会决定从业界寻找有实际大型企业管理的人物接手BorlandCEO一职，以带领Borland走出低潮。事实上，从这个时期开始，Borland已经逐渐走向一般大型软件公司的路线，而不再以充满软件开发者理想的公司自居，因为此时的Borland需要的是大量的收入和有效率的管理，以拯救Borland濒临破产的命运。Borland放弃了Philippe Kahn，建立起Borland理想而务实的生存之路。
  寻寻觅觅了一段时间之后，Borland终于找上了曾任Apple副总裁的Delbert Yocam。由于Delbert拥有丰富的大型企业经验，并且对软件公司很有兴趣，因此和Borland董事会一拍即合，答应担任CEO以重振 Borland。事实上，在Delbert之前，Borland的董事会也曾找了许多知名的美国大型企业经理人，希望他们担任CEO。但由于当时 Borland已经岌岌可危，许多专业经理人都不感兴趣，致使Borland一直无法找到理想中的CEO。所以，Delbert的应答立刻让 Borland董事会精神大振，认为Borland终将起死回生，回复以往光荣的历史。不过始料未及的是，数年后的事实证明，找Delbert担任CEO 是一个错误的决策。
  不知读者是否发现问题：Borland董事会中应该会有经验丰富的人选，为什么不直接从中寻找而要从外面找人呢？其实，原因也同样，那就是Borland 董事会中有资格担任CEO的人也认为这个工作艰巨，不敢轻易尝试。另外一个问题则是，既然数年后证明当时找Delbert Yocam管理Borland是一个错误，那为什么这些经验丰富的董事会成员却无法预知当初就不应该找他担任Borland的CEO呢？可见，要成功地管理一个公司是不容易的，即使是经验丰富的专业人土，也不见得能够找到适当的管理人才。Delbert Yocam成为Borland的CEO之后，立刻开始了两项工作。第一是把他在Apple的工作团队带入Borland。Delbert逐一安插他的工作团队到Borland的每一个重要职位，以便完全掌握Borland并且执行Delbert的意志。Delbert从Apple引进Borland的人物，大多属于管理阶层的经理人，只有Rick LeFaivre属于信息技术方面的人。当时，RickLeFaivre被任命为Borland的CTO(Chief Technology Officer)，负责掌管Borland的信息技术和产品开发。
  Delbert在成功地建立了自己的管理阶层之后，第二步便是开始掌握Borland的产品。为了实现改造Borland的计划，Delbert很快就提升Zack为Borland Marketing副总裁，开始试图改善Borland一向积弱不振的Marketing表现。
  刚开始接手时，Delbert是有心好好地管理Borland。因此，在Delbert管理的早期，Borland还有盈余。除了Delbert个人比较奢侈的享受外，并没有太大的错误。我也曾经在Borland的总部听过Delbert对员工讲话，那是因为当时的那一季Borland表现得很好， Delbert很高兴地鼓励大家继续努力。演讲之后，公司还举行了一个小Party，提供有大量的食物和饮料。嗯，当时我还大饱了一顿口福。
  不过，随着时间的过去，由于Delbert过度干涉产品的开发，Borland开始走向亏损，公司股价也始终没有出色的表现。更麻烦的是，Delbert 砸下巨资让Zack领导的Marketing部门不但没有太大的表现，反而招致更多的抱怨，让Delbert管理下的Borland烽火连天、麻烦处处。 Borland董事会开始质疑Delbert的管理能力。在后期并购工作失败、而且Delbert带入的管理团队看到大势不妙、纷纷跳船求去之后， Borland董事会也终于决定换掉Delbert，另觅新的CEO，自此Delbert的时代宣告终结。
  基本上，我认为Delbert想要改善Borland在Marketing方面的弱势是正确的步骤，因为Borland一直拥有好的产品和技术，但在 Marketing方面却一直混乱一团。当时，Borland的收入主力仍然是Box-Moving的产品。这就是说，Borland主要是以销售盒装的开发工具为主，尚未进入以组件和中间件为主的时期。因此，强化Borland在市场的知名度以及领导地位，再配合好的产品，Borland是大有可为的。但是，Delbert过于心急地干预产品开发时程和方向，这不但没有改善Borland Marketing的弱势，还把产品搞坏了，实在是赔了夫人又折兵，也让Borland元气大伤。

Dale Fuller，高效率Sale Force的Borland
  Delbert离开Borland之后，Borland的CEO真空了一段时间，因为董事会还在搜寻适当的人选，希望他能够带领Borland走出困境。不过在Borland找寻CEO的同时，软件业界进步和竞争的脚步并没有停顿下来。在开发工具和软件产业中，除了Box-Moving的产品之外，组件和中间件的力量愈来愈强。BEA便是在这段时间通过购买了Tuxedo之后快速地在EJB应用程序服务器的市场中成长。而Borland在并购 Visigenic、取得了CORBA的技术和产品，而且也推出EJB应用程序服务器之后，Borland传统的销售Box-Moving方式却不适合用来销售中间件。因为Box-Moving的产品可以靠Channel卖出，但是中间件产品却需要搭配教育培训、专业咨询服务来一起销售。另外，中间件产品需要较长的销售期间，更需要专门的销售人员来服务客户，这些都是当时Borland没有建立起的公司制度。因此，即使Borland拥有最好的组件和中间件技术，却因为不知道如何销售而任凭好时机消逝。此外，在Windows平台上的开发工具也已经逐渐达到了饱和。虽然Windows平台上的一些开发工具厂商慢慢地淡出，使Borland和Microsoft能够逐步蚕食其他厂商留下来的市场，但无疑这已经所剩无多。因此，Borland需要新的市场、新的刺激，才能够持续成长。
  Borland下一任CEO面对的挑战是很艰辛的，因为Borland需要再次改变，以适应销售组件和中间件的产品。另外，新的CEO必须开拓新的市场，让Borland的开发工具产品能够拥有成长的空间。最后，新的CEO必须能够带领Borland走出亏损，并且想办法拉高Borland的股价。 Borland的董事会在接连找了数个失败的CEO之后，此次对于新的CEO特别谨慎，希望新的CEO不要再把Borland搞砸了。
  Borland董事会找上Dale Fuller，是因为当时正值Internet/Intranet热潮兴起之时。Dale Fuller成功地创办了自己的公司、并且在经营了一段时间之后又漂亮地把公司以高价卖出。因此，Borland董事会对于Dale Fuller高明的手腕和眼光深感兴趣，开始接触Dale Fuller，看看Dale是否有意愿接手Borland。在卖掉了自己的公司之后，Dale此时也正需要另外一个一展身手的舞台，所以，当 Borland的董事会和他接触之后，Dale开始注意Borland这家软件公司，并在思考了一段时间之后决定接任BorlandCEO。当然，我不知道Borland董事会和Dale之间的约定，不过，在Dale开始接任BorlandCEO之时便有谣传，说Dale Fuller是希望以高明的手腕看看能否为Borland找到归属。因为，Dale Fuller选择了大量的Borland股票权而不要求高薪，希望用股票选择权大赚一票。

和Corel的合并案
  Dale上任之后不久，便逐渐接近公元2000年全球Internet/Intranet疯潮以及股市狂飙的时期。当时所有和电子商务以及Linux、 CORBA有关的软件公司的股票都狂飙不已，例如RedHat、BroadVision和IOAN等。但是奇怪的是，虽然Borland也拥有CORBA 的技术和产品，可是Borland的股票却从来没有狂飙过，真是令人不解。Dale Fuller眼看Linux概念股都开始狂飙，立刻决定投入Linux市场，责令Borland的RAD部门必须立刻开发出Linux上的开发工具(这就是Kylix的源起)，希望能够通过这个举动吸引全球看好Linux的热钱大买Borland的股票。
  此外，Dale Fuller和当时Corel的CEO Michael Cowpland经人介绍之后，两人一见如故。当时Corel决定开发Corel Linux，而Borland也决定开发Linux上的开发工具，更重要的是两人都看好Linux的热潮，而且当时Corel的股票已经开始上涨到30多美金。因此，Dale和Michael在试探了彼此合作的意愿之后，立刻一拍即合。公元2000年的2月7日，Corel和Borland宣布了两家公司准备合并的消息。
  在Dale Fuller和Michael Cowpland宣布合并的消息之后，原本以为靠着Linux概念和两家公司(一个开发Linux操作系统，一个负责Linux开发工具)的完美组合，肯定会带动两家公司股票价格的上涨。
  没有想到，消息公布之后，却不被业界看好。因为当时许多业界的专家都已经预测Corel撑不了多久，原因是Corel的产品的市场占有率快速地下降，花下大把银子推出的CorelOffice根本无法动摇Microsoft Office的地位。此外，Corel的现金也即将用完、情形不妙。
  果然，合并消息发布之后不久，Corel的股价很快地往下跌，而且居然跌到比Borland还低。至此，Borland和Corel的合并应该算是破局了，因为Borland不可能和比自己价值还惨的公司合并。于是在公元2000年5月17日，Dale Fuller终于叫停了这桩合并案。Dale提出的理由有三：
  ■  Corel 2000年第1季的收入锐减■  Corel宣布接下来的2个Quarter的情形也是一样■  Corel宣布在3个月之后现金将会用完
  当时Borland虽然亏损，但是仍然握有大量的现金，而Corel却是现金即将用完。如果不停止这个合并案，那么Corel也很快会把Borland的现金耗尽，到那个时候Borland便万劫不复了。因此Dale毅然坚决地停止这桩合并交易，并且付给Corel一笔金钱作为取消合并的赔偿。
  在此事件之后，Michael Cowpland也从Corel辞去了CEO一职。而Dale Fuller在遭遇了这个挫折并且无法找到适当的合并公司之后，决定开始改变自己的角色，准备再次转变Borland，让Borland成为适合当前竞争的软件公司。

开始打造成销售的Borland
  Dale Fuller在抛开了被合并或是并购其他公司的想法之后，第一件事情便是开始回头检视Borland的状况和产品线，看看为什么Borland会陷入亏损的地步、以及如何让Borland重振雄风。其实，当时Borland虽然处于亏损，但拥有的现金仍然相当充裕，有稳定而大量的使用者群组，并没有亏损的理由。因此，Dale首先决定，稳定Borland开发团队的军心，弥补Delbert Yocam对于Borland产品带来的伤害，并且大幅整理Borland的管理阶层，尝试为Borland建立一个更有效率的专业管理团队。此外， Dale大刀阔斧地进行了下列工作：
  ■  稳定开发工具产品线，回归产品开发的本质■  扩充新的产品线
  ■  建立专业销售团队他首先将Borland的产品线划分为三个主要部分，分别是负责Windows/Linux RAD开发工具的RAD部门；负责Java开发工具的Java部门；以及负责组件和中间件的Enterprise部门。每一个部门都建立了明确的管理组织架构，力求改善Delbert时混乱的产品管理。
  第二项工作便是扩充新的产品线。由于Microsoft在Windows平台上占尽了优势，虽然Borland仍可和Microsoft一搏，但Dale 认为，Borland如果要持续成长，必须拥有更多的收入。因此，Dale决定在Linux上增加新的产品，除了原先Linux上的开发工具之外，也要开发下一代产品。
  Dale发现Borland拥有CORBA和EJB的技术和产品，但是却没有这方面专业的销售团队，使用的仍然是传统的销售方法，造成了这些产品叫好不叫座的状况，迟迟无法打开市场。因此，Dale执行的第三个计划，便是为Borland建立专业的销售团队，使用适当的方式销售CORBA和EJB产品。于是，Dale开始在Borland的销售区域中建立专业的管理和销售团队，并且开始改变Borland的一些公司政策，以便配合新的销售策略。Dale的努力果然逐渐显现出成效来。Borland从2000年开始便逐渐转亏为盈，而且营业额不断增加，进而创造了Borland在2001/2002年连续获利和营收上升的表现，在全世界一片不景气的情形中呈现出亮丽的成果。Borland的年营收额从当时Delbert的180几Million美金成长到现在超过220几Million美金，开始愈来愈接近10几年前Borland全盛时期的营业额了。
  Dale改造Borland的行动也影响了Borland的日常工作方式。例如，在我以前为Borland工作时，除了负责产品和技术之外，也兼做一些 Presale的工作，因为那时Borland没有正式的Sales人员，所以技术人员有时也必须客串一下Sales。但是在Dale引入了专业的销售人员之后，有许多工作现在都是由专门的Sales人员负责，技术人员则配合Sales进行工作。现在的Borland编制中有了以前没有的Sales团队。
  Dale的改造除了增加了Borland的营收之外，也改变了Borland的组织结构。Sales人员和Sales部门现在是Borland强势的力量，和以往Philippe Kahn时以技术人员为主、以及Delbert Yocam时以Marketing为主完全不一样。现在Borland的技术人员和Marketing人员必须配合Sales来工作，所有员工的表现也以 Sales绩效为衡量的根据。虽然我非常怀念Borland以往的时光，但是我也知道这个转变是不可避免的，因为这是让Borland更有竞争力的必要步骤。只是我认为，太过强势的Sales在长期来说仍然不太好。Dale应该在Borland逐渐成为有效率的销售公司之后，再回头好好加强在技术和研发方面的力度，让Borland能够再开发出几个划时代的伟大产品。
  在Dale Fuller成功地打造富有成效的销售企业之后，Borland不但每季都赚钱，更重要的是，在2001/2002年全世界不景气中居然还不断地成长。同时，Borland开始在欧洲和亚洲快速地成长，不断带动Borland营收创造新高。这也让许多专家跌破了眼镜，创下软件公司在不景气的气候中还持续成长的范例。Borland的股票价格虽然没有狂飙，但是已经比许多当时有名的软件公司的股价还高。Dale成功地完成了Borland第三次的转变。 Borland除了技术和产品之外，同时也成为拥有高效率管理和销售的公司，的确是和以前不一样了。现在Borland手中不但拥有大量的现金可以并购对 Borland有帮助的小公司，更有许多知名的软件大公司现在都和Borland合作。例如，Sybase和Borland合作推出了JBuilder- Sybase Edition、JBuilder-WebLogic Edition。从2000年到2002年，Borland的确打了一场漂亮的胜战。

第四波的演变
  Borland在历经了三波的改变之后，已经逐渐成了一个比较典型的美国软件公司。虽然不再有Philippe Kahn时代以开发者为主、带有理想主义色彩的软件公司形象，但是在本质上比以前好多了。特别是经Dale Fuller大力整顿之后，Borland的营运效率比Delbert时代好上数倍。不过，Borland虽然比以前更有效率、更有竞争力，但是却得面对比以前更为险恶的生存环境和竞争。
  首先是软件平台和技术的改朝换代。虽然Borland努力在Java方面有了一定的成就，但是又面临了Microsoft .NET的推出。其实，Borland一开始也为了是否要跟随Microsoft进入.NET新平台而犹豫不决，因为Borland当时想要趁Linux 的热潮改走跨平台的方向，而不是在Windows平台辛苦地和Microsoft竞争，这也是为什么Borland在.NET方面进入得比较缓慢的原因。不过，随着Linux在2000/2001年从爆炸性成长逐渐回归成正常的发展之后，Borland很快发现，光靠Java和Linux市场将无法获得足够的利润。另外，在所有知名的信息研究机构的分析都指出.NET在未来将和Java一起占有相当大比重的市场之后，Borland才知道是不可以失去. NET市场的。于是，Borland这时匆匆地投入了.NET产品的研发。
  第二则是随着软件利润的趋于下降，Borland必须想办法维持公司的成长，开辟新的产品线。从2000年开始，Borland推出并且扩充了Kylix 产品，研发了新的.NET产品，并且有数个内部不公开的技术和产品在进行中。这些行动让Borland投注了许多的资源，是否能够成功，是对 Borland开发产品的功力以及公司是否能够在市场和策略方面合理搭配的考验。在现在这个时代推产品，已经不像数年前只要品质够好就可以，还需要其他许多方面的配合。
  第三则是随着软件技术愈来愈多，应用也愈来愈多元化。这使得产品的潜在客户群被分散。如何凝聚使用者成了开发工具厂商重要的工作。Borland除了需要巩固原有的使用者外，也急需开发新的潜在客户才能够达到经济客户规模。因此，Borland必须在使用者族群方面建立良好的支持社群，并且强化和使用者互动的关系。
  第四，Borland除了需要持续增加效率之外，回归基本面、好好地着重产品开发并且建立坚强的开发者社群是最重要的工作。

软件高科技公司的命运
  如果读者是在信息产业经历了一段时间，那么可以观察到目前著名软件公司在经营上风格的异同。每一家公司在成立之初，创办者都有特定的理想或是技术，软件公司也一样。不过随着公司的成长和发展，软件公司的风格却逐渐地出现差异。我说的风格当然不是指每一家的企业文化，这当然会有不同，我指的是软件公司的创始人目前是否仍然是这家公司的主要负责人。
  美国企业喜欢并购，许多公司的创始人也喜欢在公司有了一点成就之后立刻卖出公司，以股票换钞票，许多的美国公司董事会也喜欢动不动就换CEO。这造成许多公司的CEO只注重炒短线的工作，只想把公司股票价格炒高，然后卖了公司就闪人。如此做法会让软件公司的产品和营运快速地走下坡路。Borland就历经过这种CEO。但是请读者观察，只要是公司创办人仍然还在掌舵或是担任重要职位的软件公司，对于产品就会坚持，不会随意以炒股票来恶搞。例如以 Microsoft来说，虽然这是一家饱受争议的公司，但是她的创始人Bill Gates仍然掌握Microsoft，因此Microsoft仍然在源源不断地开发产品和提出新的构想。不管这些产品是好是坏，我们都不可否认， Bill Gates仍然在努力地实现他的理想，即使一般大众都认为这是狼子野心。这让Microsoft持续地保有活力和竞争力。
  再比如，Oracle的创始人Larry Ellison仍然执掌Oracle。虽然Larry Ellison也是属于好大喜功的人，但是我们不可否认，在Larry的领导下，Oracle仍然振奋向前。这些现象可以从其他的、正在力争上游的软件公司看出，例如Developer Express、Atozed software以及目前正和Microsoft在多媒体市场打得不亦乐乎的RealPlayer等，这些公司的特点便是对于产品的努力和坚持。
  反观一些走下坡或是关闭的公司，其中许多都是由于公司的创始人离开而导致。例如以前著名的数据库厂商Informix，就是由于创始人Roger Sippl卖掉Informix的股票另起炉灶。后继者对于公司没有热忱，最后因为经营不善而终于成为历史。Informix如此，Netscape又何尝不是呢？Netscape被American Online并购之后，快速地走下坡路。前一阵子我看到的新闻消息指出，目前Netscape在全世界的占有率只剩下3％。这个曾经占有超过90％市场并给予Microsoft强烈威胁的浏览器巨人，也在创始人离开之后消声匿迹，逐渐被人淡忘，真是令人不胜唏嘘。
  Philippe Kahn的Borland是只会做产品的公司，Delbert Yocam时的Borland只会短线操作，以致让Borland快速走下坡路。现在，Borland在Dale Fuller的主掌之下好不容易地回稳，并且在2001/2002年全世界不景气之中仍然呈现稳健的成长，算是相当难能可贵的。Dale Fuller虽然不是Borland的创始人，但是似乎对于经营Borland真的发生了兴趣，愿意管理Borland，也愿意投入心力规划 Borland的产品线，是相当认真的CEO。Borland在经过了多年之后终于找到了一位不错的CEO，希望Dale Fuller能够以公司创始人般的热忱，带领Borland再创另外一个高峰。
  当然，公司创始人是否仍然是软件公司的重要人物不是判断一间软件公司唯一的指针。如果软件公司能够适当地吸引专业的管理人才来改善公司的体制是很好的事情，因为这样的公司有可能结合创新的理想，对产品的坚持以及有效率的专业管理，这是对公司以及使用者最好的保障。没有了创始人的存在，软件公司总是少了一股对于理想的坚持，不是吗？

Borland Conference
  Borland Conference对于Borland的使用者来说是非常重要的事件。就像回教徒一生一定要去麦加朝圣一样，Borland Conference也是许多Borland开发者想要参加的重要技术研讨会。Borland Conference已经有了相当久的历史，在美国也算是评价很高的技术研讨会，每年几乎都会被专业媒体评选为最值得参加的Conference之一。我一直都非常喜欢参加Borland Conference，因为这绝对是超值的盛会。BorlandConference最近几年都维持一个惯例，那就是一年在美国东海岸举行，下一年在美国西海岸揭幕。我曾很幸运地参加过3次Borland Conference，分别是1995、1998和1999，每一次参加都收获满满。参加Borland Conference除了可以聆听许多精彩的Seminar之外，也可以遇见许多信息界重要的人物，例如我就在Borland Conference中见过BruceEckcle、Martin Fowler和Peter Codd。当然，也可以和Delphi、C++Builder和JBuilder的开发团队见面而且和他们交谈、互动。通过和这些R&amp;D 研发小组见面，我也认识了许多Borland R&amp;D中重要的人物，Chuck、Danny和Blake等。也只有在Borland Conference中才有机会、有比较多的时间和他们交谈，否则就必须飞到Borland总部Scott Valley才能见到他们了。
  早期的BorCon是比较偏向开发工具的Seminar，每一个开发工具各自提供多场的Seminar让参加者选择。因此，在BorCon上很容易就可以从参加者的人数和反映来了解Borland每一个开发工具产品在市场上的表现。C/C++的参加者在较早的BorCon中占据了大部分的Seminar，每一场C/C++ Seminar都是挤得水泄不通。但是在1995年Borland推出了Delphi之后，每一年参加BorCon的人中Delphi的使用者占据了愈来愈多的比例，而C/C++的参加人数反而快速地下降。一直到了最近几年，Delphi的人数还是BorCon中占有最大比例的群组。但是，在BorCon 的参加者中，Java的开发者也占有愈来愈高的比例，由此可见开发工具和语言使用的趋势。
  在Borland陆续取得了组件和中间件技术、推出CORBA、EJB产品之后，最近数年的BorCon更是呈现了多元化的发展。BorCon中的 Seminar愈来愈多，同时也有许多的Seminar是围绕着COM+、CORBA、EJB以及软件设计、开发和管理的主题。在早期参加BorCon 时，我大都选择参加开发工具和技术的Seminar。但是到了后期，却非常喜欢参加软件设计和架构的Seminar，因为在这些Seminar中可以听到非常多的、宝贵的知识和经验，这是很难在其他地方能听到的。
  我喜欢收集BorCon的T-Shirt，不但免费、好穿，更有纪念价值。现在我仍然拥有一件1995年的、紫色的BorCon T-Shirt，夏天时穿在身上好不神气。每一届BorCon都有专门设计的Logo和代表本次BorCon的T-Shirt。下面是我收集的一些 BorCon Logo和参加BorCon的小花絮，与读者一起分享。
  1998年，我参加了在丹佛举办的BorCon。不过在丹佛实在有些无聊，除了白天的Seminar之外，晚上不知道做些什么。丹佛的BorCon结束之后，Borland又另外举行了内部工程师训练，因此我总共在丹佛呆了一个多星期，都快发霉了。好在是和朋友一起参加的，彼此间还有个伴。另外也巧遇了几个从台湾去的人，居然其中还有相识的，感觉特别温暖。
  费城的BorCon是非常令人难忘的。我和李匡正(Tom Lee)在赴会途中被整惨了。先是从台湾坐飞机到Newark机场，因为空中交通拥塞，飞费城的飞机在延滞了4个多钟头之后才取消，我只好和Tom Lee从Newark坐巴士，这样又花了4个钟头才到费城。当时香港和新加坡的同事还在苦等我和Tom Lee，很久未到，以为我们出事了，吓出了一身冷汗。
  但在费城参加BorCon时却很愉快。因为一行中有高官相随，所以吃了费城最好的牛排，也抽了点时间游览费城市区。但是从费城回台湾又是噩梦一场。因为从费城到LA的班机延误，所以当我和Tom Lee到了LA机场之后，回台湾的班机已经出发了，而且随后的一班飞机也没有空位。害得我和Tom在LA机场空等了12个多钟头，才搭上回台湾的飞机。更惨的是行李却已经直接Check-in，而我的长袖衣物都在check-in的行李中，害得我在LA机场差点被冻僵。
  我很想参加2002的这次BorCon，因为很想看看Anaheim市的模样。当然，这也是因为Anaheim有一个Anaheim天使队，Tom Lee很喜欢这支球队。不过，由于当时我正忙于工作，无法分身参加，实在遗憾。2003年将是BorCon 20周年的庆典。听说这次Borland将要隆重举办，提供最丰富的BorCon。我也想参加不可错过的BorCon 2003，拿几件T-Shirt作为永远的纪念。想想，一个技术Conference能够举办20年，可真是不容易，不知道参加的时候，是否能够有机会在异乡巧遇我的读者呢？

并购、自保和集团战
  商场真是诡谲多变，没有人知道会发生什么事情。但是，2002年底，数个令人震惊的软件公司并购案可能会大大地影响2003年软件公司的竞争，也有可能影响到我们每一个人的饭碗。
  200l/2002是Borland绝处逢生、营运蒸蒸日上的时段。Borland靠着在Java开发工具市场所向披靡的机会连续11季产生盈余，并且在大多数软件公司赔钱的情形中快速地累积了大量的现金。虽然就公司营运的角度来看，拥有大量未使用的现金不见得是好事情。但是，在这段不景气的时间中， "Cash is King"，拥有现金就是拥有力量。在蓄积了强大的能量，并且思索了如何在Java和.NET平台的竞争下找出一个康庄大道后，Borland终于在 2002年底出手了。
  首先，Borland确定了在.NET上的开发之路，誓言成为除Microsoft之外最好的.NET开发工具和企业解决方案提供厂商。此外， Borland也决定在Java战线上往上再提升一个层次，拉大和对手的竞争距离，以确保Borland在Java平台的优势。
  由于未来软件的竞争势必是Java和.NET两大平台主宰，因此，如何在两大平台保持竞争力，是每一个软件厂商都必须严肃面对的。坦白地说，别说是 Borland，现在已经没有任何公司能够再建立一个新的平台同SUN的Java和Microsoft的.NET竞争了。所有的软件厂商都必须在这两个平台下提供最好的工具、技术和解决方案，软件厂商如何同手握平台主宰力量的SUN/Microsoft竞争，这便是每一个软件厂商能否生存下去的重要话题。
  对于Borland来说，既然无法取得系统平台的优势，而单靠工具以"点"为单位作战的时代也已经过去，如何进行"面"的全面备战便是Borland必须思考的战略问题。还好，Borland还是有一些聪明的人，想到了既然如果无法争取到系统平台的优势，那么为什么不在系统平台上提供一个"中立的应用平台 "呢？这真是一个好想法，并且也值得一试。
  所谓"应用平台"，是指Borland要在Java和.NET上提供全方位的软件解决方案。这也就是说，Borland除了以往的开发工具、中间件和 J2EE之外，将提供完整的软件供应链。在2002年的产品线中，要想实现软件供应链，Borland仍然有很大的缺陷。例如Borland几乎只有开发工具和后端的中间件，缺少了效率调整、整合测试、Modeling工具、自动测试等软件和工具，更不用说许多在中间件方面的服务，例如Messaging 服务、Transaction服务等。这些工具都是小规模的软件，因此Borland面临了是需要自己开发还是通过其他途径来取得所缺少的软件的抉择。
  其实，Borland面临的选择已经不多而且很明显了。如果Borland决定自己开发从未进入过的软件市场，那不仅需要花费长期的开发时间，而且在开发出来之后，又必须面对市场已经存在的竞争对手，胜算不大且缓不济急，等到Borland开发了新的软件之后可能已经来不及。因此，Borland决定通过现金并购的方式来取得这方面软件，所以展开了稍后的一系列Borland大并购行动，继而也震惊了软件界，引发了另一波软件公司并购的热潮。

并购行动的展开
  Borland出击的第1步，便是根据Blake Stone的建议，并购VMGEAR公司的OptimizeIt产品线。由于JBuilder已经是Java开发工具市场的老大，许多程序员经常会询问为什么Borland没有提供Java效率调整方面的工具，也都非常希望Borland能够为Java程序员提供这样的工具。当时，市场上Java效率调整工具主要是由Sitraka的JProbe和VMGEAR的OptimizeIt在进行激烈的竞争。在Blake看好OptimizeIt的情形下， Borland很快就决定并购VMGEAR，因为OptimizeIt不但可以让JBuilder的战斗力更为坚强，还能够帮助Borland填补欲形成的软件供应链的缺陷。
  2002年1月22日，Borland以现金快速收购了VMGEAR，很快成为Java效率调整工具的领导者，OptimizeIt也很快整合到 JBuilder中并且扩充功能，增加了OptimizeIt Suite这个新的产品。Borland并购VMGEAR并且在很短的时间内便推出新的OptimizeIt产品，可见这次是玩真的，而不像以前往往在并购了新的公司和软件之后便放在那里不闻不问。
  在购得了VMGEAR之后不久，同年的10月9日，Borland以更大的动作收购了闻名的团队开发以及软件管理公司Starbase。这个收购行动当时出乎许多人和软件公司的意料。因为在2000年，Starbase公司的市值还超过Borland，其股票的价格也远远高出Borland的股票价格。没有想到两年之后，Borland居然有能力并购Starbase。由此可见两年来Borland和许多软件公司势力的消长。Borland购得 Starbase公司之后，意欲提供软件应用平台的计划也隐约可见了。
  在Borland当时的计划中，软件应用平台应该包含需求分析工具、分析和设计工具、开发工具、测试工具以及执行应用软件的服务器工具。Borland购得了Starbase之后，就拥有了Starbase的团队开发工具以及软件需求分析和管理工具，再加上从VMGEAR取得的效率调整工具、 Borland自己的开发工具以及CORBA/J2EE服务器，距离Borland想要形成的软件应用平台仍然缺少重量级的Modeling工具。
  其实，从Borland开发工具的演进过程中，已经可以发现若干Borland欲往Modeling方向发展的蛛丝马迹。先从JBuilder开始说起，在JBuilder 6中，Borland已经开始想为JBuilder加入Modeling的功能，随后出现在JBuilder中的Refactoring和 ClassDiagram的功能就是一个证明。
  虽然急着往Modeling的方向开发，但是Borland也知道自己开发这方面的软件将是旷日费时的。因此，Borland决定使用并购的方式快速取得这方面的技术和产品。放眼望去，Modeling工具市场几乎只剩下两强相争的局面，那就是Rational和
  TogetherSoft。由于Rational的市值远比Borland大了许多，虽然Borland已经和Rational有商业的合作，但是Borland仍然没有可能并购Rational。既然如此，那剩下的答案就非常清楚了。
  在Borland完成了VMGEAR和Starbase的并购之后，Borland的软件应用平台几乎已经完备，剩下的缺角就是设计和分析工具了。
  虽然TogetherSoft并不像Rational一样是Modeling工具市场的第一，也不像Rational拥有比较完整的产品线，但是 TogetherSoft的Modeling工具在Java/C/C++市场享有盛名，其软件功能和图形使用界面远远超过了Rational的软件。就软件品质来说，TogetherSoft已经超越Rational甚多。只是TogetherSoft没有Rational的三位知名大师而已。
  在Borland决定和TogetherSoft合作之后，TogetherSoft也非常欣然地接受了Borland的提议，因为 TogetherSoft正想往开发工具市场发展，以补足TogetherSoft没有适当开发工具来结合其Modeling工具的遗憾，这也是为什么 TogetherSoft在早一步从WebGain购买Visual Café权利的原因。现在，Borland拥有最佳的开发工具，再结合TogetherSoft的Modeling工具，两家公司有机会共创双赢、打败 Rational而成为盟主。于是TogetherSoft很快就答应了Borland的建议，同意和Borland合并。世事真是难料，没有想到当初 Visual Café和JBuilder恶斗数年之后，竟然由Borland取得了VisualCafé，也让Visual Café最后在Borland的手中成为历史。
  正是因为Borland并购TogetherSoft，成了压垮骆驼的最后一根稻草，所以在消息宣布之后，立刻引起了许多软件公司的震惊和不安，这也激活了软件界的并购风暴。我当时的预测就是Rational将首当其冲。

并购的涟漪效果
  Borland宣布并购TogetherSoft，立刻引起了软件界的轩然大波。由于Borland和TogetherSoft的合作，对于 Rational产生了巨大的影响，而Borland又和Rational有软件合作，因此为了缓和对Rational的冲击，Borland便下令公司内的人必须对这件事情封口。当时我就认为Rational也不是傻瓜，他们一定会了解事情的严重性，即使Borland不提，Rational也一定会有动作。果然在不久之后，Rational便通知Borland，结束和Borland在Java Enterprise Studio以及Windows Enterprise Studio的合作，反将了Borland一军。当然这也正式代表Borland终将进入Modeling市场的大战。Rational和Borland 的战事尚未真正开火，就被"螳螂捕蝉，黄雀在后"的IBM盯上了，IBM开始正式向Rational下手。为什么IBM会找上Rational呢？这要从 IBM和BEA之间愈演愈烈的EJB服务器战争说起。
  由于IBM的WebSphere和BEA的WebLogic已经进入最终的市场第一位争夺战，两方人马都是无所不用其极地想要干掉对方。不过，由于EJB 服务器的市场已经进入成熟的阶段，现在光靠EJB服务器核心已经无法作为胜出的筹码了。这也是为什么WebSphere和WebLogic都开始加入其他的辅助功能，例如Portal服务、管理服务等，以求能够压过对手。不过，当大部分的软件服务都被加入之后，剩下来的当然就是从整合开发工具以及分析/设计软件上动脑筋了。
  这也是为什么当初BEA会和WebGain合作而IBM也不愿意放弃VisualAge For Java的原因。即使Visual Café和VisualAge For Java已经无法在Java开发工具市场成为第一位的工具，但由于使用EJB技术的企业愈来愈多，也有愈来愈多的企业要求结合Java开发工具和 Modeling工具以便开发大型的Java以及J2EE应用系统。IBM很显然也注意到了这个市场和需求，于是在Borland并购了 TogetherSoft、Rational感觉到巨大压力的时候，立刻找上Rational。由于IBM出手阔绰，再加上Rational自知要独自面对Borland和TogetherSoft的联军没有多大胜算，因此也很快答应了IBM的条件，正式由IBM接收了Rational。
  在IBM确定并购Rational之后，这股软件公司之间重量级的并购潮不但没有结束，反而更为暗潮汹涌，因为IBM并购了Rational之后，开始对 BEA和Microsoft产生更大的影响。IBM在取得了Modeling工具之后就在EJB服务器中取得了整合的优势，对于BEA将有更强大的攻击力。而BEA在原本已经逐渐落居下风的EJB战役中如果还面临IBM整合Modeling的攻势，那么情势必将更为恶劣。因此，当时我认为BEA将是 IBM这桩并购案最大的受害者。果然之后不久，许多专业媒体都评论了BEA不利的局势，预言BEA最强的支持者将会是Borland，甚至许多人也传出 BEA将并购Borland的消息。对于这个传言，BEA的响应似乎是正面的，因为现在BEA已经和Borland有所合作，而BEA和Borland的产品线也非常互补，没有什么严重的冲突。不过，我个人还是希望Borland能够维护独立的软件公司。
  另外一个受影响的软件厂商则是Microsoft。Microsoft在以前早就和Rational有合作，不过Microsoft还是那个调调，在自己没有Modeling工具之前希望和Rational合作，但是一旦有了类似的工具之后(即Visio)，就停止了和Rational的合作，这种做法类似当初Microsoft和Sybase的合作关系。不过，在IBM取得了Rational之后情势又不同了，因为现在IBM拥有了非常完整的产品线， IBM可使用这条产品线，以强大又完整的J2EE架构正面攻击Microsoft的.NET。因此，后来也传出了Microsoft有意并购 Borland以取得Modeling工具的风声。如此一来，Microsoft不但可以在．NET上提供全世界最好的开发工具、Modeling工具，又能够取得.NET需要的组件模型，即CORBA.NET，以对抗EJB，可以说是一举数得。不过在开发工具方面，Microsoft和Borland有严重的重复，又可能会引起独占市场的疑虑，因此我个人认为，这是不太可能的结合，真的要说，那么双B(Borland和BEA)的组合反而比较可能。
  不管未来的发展如何，应该发生在2003年的大战终于在2002年末正式提前开打，Borland也即将进入另外一个新的转变。
 
  第九章  软件技术和平台的大竞赛

(文章来源：<<Borland传奇>> 电子工业出版社 2004年，作者：李维)
 
  2002年的2月，Microsoft终于推出了.NET，也击败了许多爱看Vaporware好戏的人。.NET的出现，代表了窗口平台的软件开发将进入一个新的领域，对于窗口平台上开发工具厂商也有深远的影响，因为.NET是有史以来变动最大的窗口平台。第一次，Microsoft把窗口变成一个虚拟执行环境，通过SOAP/Web Service技术，把窗口和各种行动以及电子装置整合在一起，提供了下一代的整合虚拟数字世界。这个影响是深远的，它不但冲击了操作系统，影响了下一代窗口操作系统的发展方向，也改变了开发工具在这个虚拟执行环境中的角色。开发工具厂商必须重新定义、定位开发工具在.NET中扮演的角色以及未来的发展趋势。
  Windows3.0和3.1曾为窗口平台带来了最辉煌的时代，造就了C/C++四大天王(Borland、Symantec、Watcom和 Microsoft)、C/S双雄(PowerBuilder和Gupta)、COBOL两大家(RMCOBOL和Acu COBOL)以及无数充满活力的开发工具厂商。图形用户界面的盛行也让各种Framework充斥于市。随着C/C++语言的流行，其他语言很快便退居2 线。MFC的出现让Symantec和Watcom退出市场，VB和Delphi的快速成长则让C/S双雄饮恨不及。开发工具市场在Windows 98之后有了快速而巨大的变化。最后，除了Microsoft和Borland等少数厂商之外，大部分的开发工具厂商都逐渐退出了这个竞争最激烈、门槛最高的市场。随着.NET的推出，Microsoft又把竞争门槛再度拉高。这次Microsoft瞄准的是企业信息市场以及Java平台，程序语言和开发工具的竞争不再是Microsoft关心的重点，Microsoft的重点是如何在窗口平台提供类似Java已经发展将近10年的计算环境。不过，这个目标却苦了开发工具厂商，因为他们必须面对新的虚拟执行平台、新的编译技术和新的Framework。更糟糕的是，开发工具厂商必须在.NET中找到一条新的生存之道，由于.NET包含了：
  ■  一个虚拟执行环境--Common Language Runtime(CLR)■  一个庞大且完善的Framework--.NET Framework因此开发工具厂商必须在这两者以及两者交错产生的软件元素中找到新的技术、新的应用和新的利基，才能够持续在.NET中生存。更麻烦的是，Microsoft已经提供了一个开发工具范例--Visual Studio.NET，它比当初SUN的失败作品Java Workshop好得太多。这不但证明了Microsoft是一个比SUN更精于开发工具的厂商，而且，其他的开发工具厂商要想凸显其产品更在 Visual Studio.NET之上，也将是一件更艰苦的工作。也许.NET的出现会加速淘汰更多的开发工具厂商，让.NET平台上的开发工具厂商更纯化，最后只剩下最具实力的少数厂商。目前各家开发工具厂商如何适应.NET的冲击？它们会提出什么新的软件技术同Microsoft以及其他厂商竞争？谁会是最后的胜利者？这都将是非常有趣的事情，仔细观察并分析这些问题，或许从中也能学到许多的宝贵经验。
  .NET和Java的发展过程提供了许多耐人寻味的东西。有趣的是，.NET和Java虽然在现在以及未来的发展有许多类似的表现，但是这两个平台的骨子里却有一些重要的差异。其中最明显的，就是JVM和CLR分别如何执行最终的应用程序以及单一语言对语言中立的考验。除此之外，Java和.NET对于中间件组件技术的对抗也是最激烈的一环，因为中间件技术将是未来主宰系统架构的主要因素，SUN和Microsoft都希望自己力推的平台成为新的应用标准。
  Java和.NET的竞争，虽然从虚拟执行环境、程序语言、Framework一直延续到最新的软件技术--SOAP/Web Service和数据存取技术，但是组件模型仍然是其中最重要的，因为它代表的目标市场--企业信息领域，才是这两家必争之地。Java和.NET的组件模型是程序语言设计之奇、Design Pattern之美、数据存取架构之广以及设计构想之深的结晶。组件模型不但是SUN和Microsoft市场的关键，也代表了两家领导厂商的软件技术实力以及系统架构的思想逻辑。因此在讨论Java和.NET竞争时，充分了解J2EE以及.NET在组件模型方面的发展是很重要的。通过了解这两个阵营在组件技术的竞争，我们也可以很容易掌握未来Java和.NET的发展趋势。因此随后的文章将从Microsoft和SUN发展组件模型的历史和趋势开始讨论，让读者了解Java和.NET中位居关键地位的技术演进，以及组件模型如何影响Java和.NET的未来走向。在本文后半部分，我们将讨论.NET对于窗口平台中开发工具厂商的影响，以及未来开发工具的适应和发展趋势。

Microsoft的COM组件模型
  Microsoft的COM组件模型一直在很稳定的发展中。舍弃繁杂的OLE细节之后，COM才真正地奠定了Windows组件模型的核心，开始可以提供制作企业逻辑对象的能力。DCOM开始提供远程访问和分布式计算以及对象回收的机制，让COM组件模型能够提供企业级计算的能力。不过在DCOM的时代，客户端仍然是通过Proxy/Stub直接和COM对象互动，还未到达像EJB组件模型那样由虚拟服务器控管以提供系统服务等功能。但是， Microsoft很快在MTS 1.0中正式加入了这个功能，至此，COM组件模型能够顺利地加入企业核心服务，例如Object Pooling、Role-Based安全权限和交易管理等功能。严格地说，在MTS出来之后，COM组件模型才有资格成为关键性系统的核心组件模型。也因为MTS，才有后来的Microsoft DNA架构。在Windows 2000中，MTS正式成熟演进到COM+1.0，除了把MTS调整得和操作系统更契合之外，最重要的进步是大幅提升了执行效率，因此， Microsoft的TCPP数据大都是以COM+加VC++撰写的。
  在不久前推出的Windows XP中，COM+又进步到1.5版。在COM+1.5版中，Microsoft对COM+进行了许多改善，其中最重要的便是再次提升了COM+的执行效率，让它比COM+1.0更快。此外，延展性也是COM+1.5的调校重点。Microsoft为COM+1.5加入了Partitioning功能，企图让COM+的Application能够在不同的Container服务器(DllHost.exe)中执行，提供对象并联的架构，以增加COM+应用系统的延展性。不过，从COM+1.5目前实现的程度来看，这应该是初步的规划，未来应该还有很大的进步空间。
  此外，COM+1.5也加入了Application Pooling的机制，让程序员可以控制COM+ Container服务器执行的数目。当Container服务器的执行数达到右图中集区大小的数目之后，Windows操作系统便会重复使用已经存在的 Container服务器，而不会允许客户端继续建立新的Container服务器，如此一来，就不会让客户端启动太多的Container服务器以拖垮 Windows操作系统。
  而应用程序回收(Application Recycling)功能则是Microsoft为了克服COM+内存泄漏(Memory Leak)问题加入的。在COM+1.5中，程序员可以指定COM+的Application在一定时间、或是在COM+的Application的内存使用到达一定的数量、或是被调用了一定的次数、或是被启动了一定的次数之后就重新启动COM+的Application。这样，可以让Container 服务器结束运行，而操作系统则可以回收因为COM+对象泄漏的内存。在COM+尚未像EJB或是.NET一样以虚拟执行环境进行Garbage Collection之前，这倒不失为一个好方法，因为Windows 2000和XP在进程安全控制方面有了大幅的精进。此外，COM+1.5的组件服务程序也允许程序员直接管理和设定旧的COM/DCOM组件，不需要再使用DCOMCNFG.exe程序。1.5的组件服务程序整合了所有型态的COM组件，是相当不错的功能。
  从COM+1.5的发展来看，其他的许多功能都属于小进步，未来COM+的发展将会很小，进而COM+会真正地转变成Windows的核心服务之一。未来 Windows的组件模型应该是由.NET的组件架构来接棒，因为Microsoft仍然需要一个提供虚拟执行环境的组件架构，以提供良好的 Garbage Collection和Partitioning的功能，进一步和EJB竞争企业系统的延展性，而这个征兆可以从稍后讨论的.NET发展看得出来。

SUN的EJB组件模型
  经过了将近2年的时间后，SUN终于在最近推出了新一版的EJB 2.0功能规格，很快也被BEA和Borland的BES实现出来。SUN在EJB 2.0中提出了许多先进而复杂的功能，目的是为了大幅强化EJB作为企业核心组件架构的本钱，以便在企业系统中和Microsoft下一代的.NET组件竞争。
  从SUN定义EJB的规范开始，就展现了其和COM不一样的观念。EJB一开始就非常重视Design Pattern和组件种类，例如Session Bean和Entity Bean各自负责不同的角色，再借助于Java的Garbage Collection，提供了成为企业信息系统组件必要的基础。但是，在EJB 1.x中，所有的Bean Instance之间的调用都是使用Remote Interface方式，因此在许多的应用方面付出了较大的开销，导致一些情况下执行效率不佳。在EJB 1.x中发展出了许多的Design Pattern来改善这种现象，例如鼓励使用Coarse-Grained对象，以减少网络Round-Trip和Bean之间的调用次数。
  在EJB 2.0中，SUN终于为改善这个问题而提出了Local Interface。所谓LocalInterface，是指当Bean Instance在同一个EJB Container中时，EJB Container可以使用Local Interface调用来代替Remote Interface调用，这样可以增加3倍以上的对象启动效率。另外，SUN加入Local Interface功能的重要原因是为了支持EJB 2.0中大幅强化的CMP(Container Managed Persistence)功能。
  简单地说，EJB 2.0中的CMP允许程序员使用EJB Query Language来定义Bean之间的关系。只要程序员使用EJB QL定义了一个Bean和另外一个Bean的关系(Relationship)，那客户端便可以在存取了主要Bean之后，再通过Bean定义的 Finder或是Selector方法取得所有的从属Bean。如果读者不太了解这个意思，可以参考下面的示意图。在客户端建立主CMP之后，可以通过主 CMP的Finder或是Selector方法取得所有的从属Bean，此时，主CMP便可以通过EJB QL向数据源查询所有相关的数据，再由EJB Container根据查询的数据自动建立从属Bean、并且和主CMP建立关联。如此一来，2.0的CMP可以免除程序员自行撰写存取数据和建立CMP 的程序代码的麻烦，并且允许EJB Container使用最佳化的方式从数据源存取数据和建立CMP。为了增加这个过程的执行效率，EJB2.0的功能规范要求这种Bean必须支持 Local Interface，当然，这也代表着这些会建立关系的Bean必须执行在一个相同的EJB Container中。EJB 2.0的CMP增加了功能和效率，但是也增加了Bean之间相互依靠的关系，这会影响EJB程序员在设计系统时的布局。此外，EJB 2.0的CMP虽然提供了这么强大的功能，但这也是不同厂商实现的EJB服务器执行效率有差距的地方。不同EJB服务器使用的实现方法的不同，会大大影响执行效率。这就是为什么SUN定义了ECperf标准来检验和评比EJB服务器的真正执行效率的原因，这稍后会谈到。
  因此，在EJB 2.0功能规格中，SUN定义了数个机制来增加EJB服务器的执行效率，这在EJB的架构已经很完整的情形下是很自然的下一步。当然，除了上述的功能外， EJB2.0功能规格也增加了MDB(Message Driven-Bean)，MDB可以让程序员使用异步的方式传送信息，事实上把原本JMS的功能加入到EJB的功能规格中，是为了对抗 Microsoft把MSMQ整合进COM+。请看EJB进化的示意图，我认为EJB 2.0最重要的进步便是执行效率、OR Mapping以及EJB的查询语言。EJB的查询语言开启了未来和JDO(Java DataObject)的整合，目的是和Microsoft在.NET中定义的OPath和数据对象相互竞争，这在稍后也会再说明。至于OR Mapping，则是一个非常复杂的机制。它规范了BeanInstance和数据源之间的关系，这个标准可能会让许多小的EJB服务器厂商退出EJB市场，或是无法完整地支持EJB 2.0的功能规格。
  再看看Local Interface的意义。在EJB 1.x中，客户端调用Bean Instance时，在Container中Bean和Bean之间都是使用Remote Interface的方式进行调用，如下图所示：事实上，图中显示的启动模式是非常浪费资源的，因为图中的Bean都属于同一个
  Container之中，为什么要使用缓慢的Remote调用模式呢？因此在EJB 2.0中定义了Local Interface。如下图，现在只有在跨越网络或是跨越不同的Container时才需要使用Remote调用模式，这大大地改善了使用的资源和调用效率。
  更好的是在EJB 2.0中，一个Bean可以同时定义Remote Interface和Local Interface。如此一来，Bean的使用者和组合者(Assembler)可以更有弹性地分发和部署EJB Bean。在EJB 2.0中，Bean只要从EJBLocalObject继承下来，就可以拥有Local Interface的功能。例如程序员可以用下面的程序代码来提供Local Interface的功能。本质上，实现和定义Local Interface的方式和原本的Remote Interface非常类似，因此EJB的程序员可以很自然地学会这个新的EJB功能。
  public interface YourobjectClass extends EJBLocalObjectpublic interface YourobjectClass extends EJBLocalHome了解了EJB 2.0增加的功能之后，现在就可以回到前面朋友询问我的问题了，为什么在EJB中没有看到任何像COM一样的线程模型之类呢？事实上这很简单，因为EJB 是一个标准功能规格，并不包含如何实现的细节，在一般的EJB书籍中当然看不到类似的东西。而且，COM之所以有这么复杂的各种线程模型，是因为COM发展的包袱以及历史的因素所造成的。不过，这并不代表在EJB中没有线程模型的问题，因为EJB厂商如何实现EJB功能规格会深深地影响EJB服务器的效率。因此，线程模型反而是EJB程序员应该知道的东西，只是依据不同的厂商而有不同的结果，不像COM功能规格是由Microsoft定义的，也是由 Microsoft实现的，因此会有一致的执行行为。EJB的线程模型应该是使用Object Per Client的模型。这个意思是说，EJB Container会为每一个请求的客户端建立一个独立的Bean服务。因此，如果EJB厂商没有特别进行最佳化的工作，那EJB使用的模型应该是类似 COM中的STA，也就是说，一次只有一个Worker线程在Bean Instance中执行。下图就显示了这个架构，对每一个客户端就启动一对Worker Thread/Bean Instance。
  上图叙述的是正常的情形，那如果让两个客户端同时存取一个Bean Instance时，会发生什么情况呢？下图就显示了这个架构。在这个情形中，如果有两个客户端要同时存取Bean Instance，那EJB Container如何控制呢？在一般的EJB书籍中，似乎也没有看到和同步处理有关的范例，难道说，可以不进行任何的处理就让两个客户端同时存取吗？这当然不会，因为此时EJB Container就会进行管理，以STA的模式控制同步存取，因此客户端的存取必须依序(排队)来调用Bean Instance。
  这个情形也可以直接从Bean的实现程序代码中看出，例如下面的程序代码是EJB的标准范例Entity Bean的实现程序代码。请注意，在这个Bean类别中定义了数个private变量，并且在Bean的方法中直接存取和处理这些private变量，完全不需要考虑任何的同步处理机制，这就是因为EJB Container一般就是使用Object Per Client的模型以及类似COM的STA的线程控制模型。
  这只是一般的EJB Container可能会使用的模型，但有一些EJB服务器提供了最佳化的机制，可能会提供更为有效率的方式。下面的表格列出了COM/COM+和EJB在线程模型方面的比较：
  因为不同的应用程序服务器厂商实现而不同读者必须注意的是，上表并不代表COM+是比较好的，只能说COM+提供了较多的选择，可以让有经验的程序员调整执行效率。但是，相对地也让情形复杂了许多，而且COM+的MTA线程模型也不容易实现。
  正由于EJB功能规格会因为不同的EJB厂商实现而有不同，因此，除了前面提到的EJB2.0中CMP和OR Mapping会影响EJB服务器的执行效率之外，如果再结合线程模型和对象建立的技术，那下面列出的问题是影响执行效率的重要因素：
  ●如何实现和控制Worker Thread。事实上这就是EJB Server中Thread Pooling的机制●如何实现和控制EJB Bean Instance。这就是EJB Server中Object Pooling的机制为了让EJB服务器有公平的效率比较基础，SUN定义了ECperf标准让使用者能够用来评量各家EJB服务器的执行效率，以避免各说各话的情形。从这一点也可以看出，SUN现在开始注重EJB服务器的执行效率因素了。
  为什么我说线程模型会因为不同的EJB服务器而有不同呢？现在让我们以实例来看看EJB服务器的行为。下图是我使用4个Delphi建立的客户端应用程序，并且使用SIDL技术来调用Borland Application Server-BAS中的一个Stateless Session Bean的结果。从图中可以明显地看到，即使是在有4个客户端的情形中，BAS仍然使用了MTA模式，只建立一个Stateless Session Bean，并且让4个Worker线程同时存取，因此执行效率非常高，使用的内存资源也非常少。
  而下图则使用4个Delphi客户端应用程序调用Stateless COM+对象(使用Both线程模型)，从图中可以看到，COM+使用Object Per Client的模式，建立了4个COM+对象服务4个客户端，虽然执行效率也非常高，但是使用的资源稍比BAS多。
  接下来，再让我们讨论一下未来Microsoft的组件模型以及SUN的组件模型的演进趋势。

Data Access Technology
  在未来，Microsoft和SUN的组件模型大概都会强调数据存取的技术，因为从前面讨论的EJB 2.0 CMP的内容中我们可以知道，现在SUN已经在为对象和数据之间建立连接的技术了，而未来的JDO技术将进一步紧密结合数据对象的观念，让程序员面对的所有东西都是对象，不再有数据和对象不一样的观念和使用方式。
  不过别以为Microsoft只会呆在原地，在PDC 2002中Microsoft已经宣示了未来ADO.NET的发展方向。ADO.NET未来将会结合数据和组件的观念，让.NET的程序员以对象的观念来代表数据，就像EJB中的CMP/BMP一样。如此一来，.NET的程序员可以像EJB一样声明代表数据源中数据的数据类型，并且使用以XML格式封装的数据对映叙述器(DataDescriptor)来连接数据对象和数据源之中的数据。如此一来，.NET的组件模型也提升到和EJB 2.0加上未来JDO一样的层次。
  例如程序员可以定义如下的数据类型：    public abstract class Customer {      public abstract string Name{get; set;}      [Link(Account)] public abstract IList Accounts {get;}    }
      public abstract class Account {      public abstract float Amount {get; set;}      public void CalculateTotal() {
          // business logic
        }
      }并且定义上述Customer和Account之间的连接关系，这和EJB2.0中新的CMP功能一样，然后再定义如下的对象/数据对映器，把对象和数据源连接起来，请特别注意下面relationship的部分：
  最后，程序员可以使用如下的形式通过数据对象存取数据，并且在数据对象之间自动形成关联的关系。这非常有威力，和EJB/JDO不相上下。事实上， ADO.NET和EJB/JDO实现的观念和想法非常类似，这是巧合还是模仿呢？基本上可以说，这两大阵营都有互相参考对方技术的地方。
  下图就是未来ADO.NET的数据对象架构，程序员只需要修改Schema Mapper就可以连接到不同的数据源，例如MS SQL Server或是Oracle等。
  除了ADO.NET的数据对象外，Microsoft也开始定义类似于EJB QL的对象查询语言，目前暂时称为OPath。当然，我们可以进一步地讨论更为深入的组件技术问题，不过由于篇幅的限制，就让我们以后在专门讨论技术的书籍中继续说明好了。
  下图很清楚地说明了Microsoft和SUN组件模型的发展趋势。从图中，我们几乎可以知道这两者非常类似，发展的方向也趋于一致。未来比较的因素可能是执行效率、延展性、能够执行的平台以及开发工具的支持程度和使用的方便性吧。
  综合上述内容，从最近Microsoft的COM+/.NET的推出、SUN的EJB 2.0功能规范的完成、以及中间件厂商实现的EJB应用程序服务器来看，Microsoft似乎也已经开始采用类似Java的虚拟执行环境以及EJB的模型来重新塑造.NET的组件模型了。COM+将逐渐退居幕后提供系统核心服务，甚至会慢慢地消失于未来.NET的执行平台之中。不过由于.NET的进入门槛不低，而且目前仍然有大量的原生Windows开发人员以及Windows应用程序，因此，这个从COM组件模型完整转换到.NET的过程可能仍然需要数年之久，而COM在现在开始的数年内仍然是Windows平台上最重要的中间件技术。
  据Gartner Group的调查和估计，在2003到2004年使用EJB技术开发的Java应用系统将占整个Java平台的40％左右，这表示EJB技术已经获得了大型企业和专业软件厂商的认可，是企业级的组件模型。EJB 2.0必须开始增加执行效率，故此加入了LocalInterface。此外延展性也成为EJB应用程序服务器的发展重点，因为EJB应用程序服务器势必将承载更多的存取，以担负起企业的关键应用。因此，EJB厂商开始在EJB服务器中切割虚拟伺服环境，并且在每一个虚拟伺服环境中执行不同的软件。例如一个虚拟伺服环境负责执行JSP/Servlet Container，而另外的虚拟伺服环境则执行EJBContainer等，如下图所示。这样做的好处是不但每一个Container更安全，而且应用程序服务器的延展性将更为优秀，因为在多CPU的机器中可以分配专门的CPU给不同的Container，并且在一个EJB服务器中可以同时执行多个 EJB Container。
  这里有一个很有趣的区别，那就是由于Microsoft掌握了操作系统，Microsoft可以尽量地把.NET的虚拟执行环境移往操作系统的核心，提供更为良好的执行效率；但是由于提供EJB的厂商没有这项优势，因此必须以更好的实现方式来开发EJB应用程序服务器，这也是为什么SUN以ECperf这个标准来评定各家EJB应用程序服务器的执行效率的原因。但是从目前EJB服务器的实现观念和技术看，仍然是领先于Microsoft的.NET。不过不要小看Microsoft，虽然.NET在2002年的第一季才推出，但是Microsoft已经在开发.NET的第2个版本了，.NET的发展步伐是很快速的。
  中间件技术将会继续不断地发展下去，各种新的组件观念和实现技术也将持续地出现。组件模型技术和中间件已逐渐取代早期的程序语言和数据库服务器，成为现在信息架构的主导力量，Microsoft和SUN都希望成为这个领域的领导者。不过谢谢信息市场的竞争力量，让这两家大厂都无法消灭对方，反而由于竞争的力量造成了组件模型不断地创新，使信息人员能够持续地使用新的、更好的、更成熟的中间件技术，来实现日趋复杂的信息系统，虽然这个学习的过程很辛苦，但这也是信息行业让人感觉到有趣味的地方，因为你不会总觉得工作是一成不变的。
  只是现在Web Service的兴起让组件模型的界限开始显得模糊了，而Web Service也是Microsoft.NET和下一版Java JDK强调的重点功能。看起来，Web Service技术将会开始把组件模型逐渐地转换为面向组件服务，让组件模型的决胜点从面向功能逐渐转向面向服务。以后哪一个组件模型能够提供企业级的服务模型，将会是决定系统使用的架构的关键点，而这个现象已经可以从一些中间件厂商最近的动作中隐约的看出。

.NET对于开发工具厂商的影响
  .NET的推出，对于所有开发工具厂商而言都是一大挑战，这除了牵涉到技术层面之外，还包含了复杂的产品定位的问题。相对于当初Windows 3.0/3.1推出时各个开发工具厂商百家争鸣的盛况比起来，如今的.NET平台就显得逊色了许多。当然这主要的原因在于.NET中语言不再是重点，再加上语言可以内嵌在Microsoft的Visual Studio.NET中，这顿时让许多的开发工具厂商失去了定位以及竞争优势。如果开发工具厂商只是做一个语言的Plug-In到Visual Studio.NET中，那将很难生存下去。
  对于像Borland的Delphi、C++Builder以及Sybase的PowerBuilder而言，如何在新的.NET环境中保持竞争优势是很重要的问题。因为在.NET中，应用程序执行环境、CommonLanguage Runtime(CLR)以及.NET Framework都是由Microsoft所掌握，其他工具厂商如何在Microsoft一手控制的环境中营造出竞争优势呢？另外在.NET中，开发工具厂商必须把应用程序编译成Common Intermediate Language(CIL)的格式，再由JIT编译器编译成原生机械码执行，如下图所示。
  因此，如果开发工具厂商要在.NET环境中继续提供竞争产品，那至少必须在下面的三个领域中找到答案，并且做出实际的解决方案：
  ■  编译器的竞争--如何把程序语言最正确且有效率地编译成CIL■  .NET Framework的竞争--如何在.NET Framework上进行加值的工作，并且定位产    品竞争力
  ■  开发工具本身功能集(Feature Set)的竞争从编译器角度来说，由于.NET的CLR内建的Virtual Execution System(VES)支持一般的程序语言功能，同时又提供了丰富的对象模型支持能力，以提供面向对象语言对映到CLR的能力，因此.NET可以说是 OOP-Friendly的执行环境，这非常有助于面向对象程序语言在.NET中实现，例如对C/C++、Object Pascal等真正的OOP来说是个好消息，而Microsoft的新语言C#就是一个好的OOP实现范例。但是对于使用脚本语言作为骨架的开发工具(例如PowerBuilder)来说，可能就需要花上许多的功夫重新规范，以便能够适当地使用CLR的特性。当然除了程序语言之外，如何开发出一个有效率的 CLR编译器更是开发工具厂商需要费心的地方。
  在Framework方面，Microsoft的.NET Framework摆明了要和SUN的J2EE/J2SE/JEME等竞争，而且花了许多的资源打造.NET Framework，力求能够提供给程序员最好的开发功能。但是，对于开发工具厂商来说则是有喜有忧。一方面，Microsoft虽然提供了良好的. NET Framework，可以减少开发工具厂商需要花费的成本；但另一方面，开发Framework的权力掌握在Microsoft手中，特别是 Microsoft也有Visual Studio.NET作为竞争产品，因此如何定位便成了重要的问题。就我的看法，如果开发工具厂商无法在.NET Framework上进行增值的工作，那最后仍然难逃被淘汰的命运。
  即使开发工具厂商能够克服前面讨论的两个问题，最后仍然要回到产品本身的竞争力上来。没有集成开发环境、组件架构、调试环境和高生产力，仍然无法和 Visual Studio.NET竞争。开发工具厂商不但要像以往一样提供一个集成开发环境，甚至还必须做得比Visual Studio.NET更好、更具创意。这也不是一件容易的事情，因为这必须有突破性的想法。例如，其中的一种可能就是再把.NET的通用性延伸，除了像. NET不把语言的差异作为重点之外，也不把CIL产生的结果作为差异。由于CIL是一组标准的中介信息，开发工具厂商可以继续把CIL转化为.NET、原生窗口应用程序、Linux应用程序，甚至是移动设备上的程序代码，如下图所示。
  如此一来，这种开发工具将更为广泛和实用，也是开发工具极好的竞争优势，特别是现在仍然有许多的软件厂商需要继续开发小而快的原生窗口应用程序。
  Microsoft .NET的出现不单对于Microsoft本身有重大的意义，对于窗口平台上所有开发工具厂商和SUN都有巨大的影响。开发工具厂商正面对着从 Windows推出以来最严格的考验，这是一场生与死的竞争。对于SUN来说，.NET代表的是Microsoft正式全面地向Java平台挑战，时间将决定JVM和CLR的胜负，而Java单一语言的通用性也将面临.NET语言中立的考验。至于传统的窗口程序设计人员而言，也许正如"魔戒传奇"中的哈比人一样，明知前途坎坷，仍然必须选择走向严寒的雪山或是诡谲的地道，因为目的只有一个：在新一波的软件技术和平台中找到一条生存之路。
 
  第十章 令人焦虑的时代

(文章来源：<<Borland传奇>> 电子工业出版社 2004年，作者：李维)

  "通向未来之路在哪里？"时间进入2000年之后，许多事情变得似乎都不确定了，世界经济的走向和信息技术的趋势变得更令人困惑。在经过了 Internet/Intranet、Linux和Open Source的洗礼之后，目前信息技术的发展似乎已经趋向多元化的状态。虽然许多的信息系统仍然在使用我们早已熟悉的技术(例如Web和主从架构)，但各种新的信息技术也在层出不穷地出现(例如SOAP和Web Service)，再加上.NET和Java两大平台之间逐渐升温的战火，让许多软件开发人员眼花缭乱，继而心生疑惑--"自己未来的前途到底在哪里？" 其实，信息人员产生这样的疑惑是很正常的。因为信息技术的发展到达了前所未有的阶段，不但各种程序语言之间掀起了混战，操作系统平台、虚拟执行平台、开发工具、组件模型等都兴起了热战。而虚拟执行平台让跨平台模糊了以往壁垒分明的开发领域，程序语言的多样化稀释了原本由数种语言瓜分天下的态势，而Web和多层架构又逐渐瓦解了传统的信息架构。这些信息技术的多元化发展，不但让传统的开发人员面临难以抉择的命运，虚拟平台、程序语言和信息架构等众多的组合变量，也让开发人员顿然之间感觉负担沉重，担心自己已经跟不上信息发展的快速脚步，那软件开发人员的未来到底在哪里呢？

信息技术多元化的发展
  和许多人的工作一样，也许你还在使用Delphi/C++Builder开发主从架构或是Web或者一般的应用系统，又或许是使用JBuilder开发 Java应用系统。总之，你可能已经熟知目前所使用的技术，并且大量地应用在日常的应用系统中。但是，身为软件开发人员，必须了解软件趋势的发展，必须随时注意新的软件技术，因为唯有不断地增加自己的附加价值，才能够在这个竞争激烈、演进快速的产业中生存下去。
  其实从整个软件技术发展的趋势中，细心的软件人员已经能够看出未来的方向。在软件开发的过程中，每一个时代都有主导的软件技术在影响着当时的产品以及软件公司的兴衰。当然，能够掌握软件趋势的人或是公司也都获得了成功。从下图中我们可以看到，在不同年代中不同的信息技术掌握了当时的主宰力量。60/70年代是由数据处理和程序语言独领风骚，到了80年代便由数据库当家作主，90年代各种组件和中间件又主导了系统架构。
  但是从60/70/80/90年代的软件技术来看，每一个时代都是由一个点的信息技术来主导。不过在Internet/Intranet时代，面向对象和 Modeling等技术对于信息系统的影响愈来愈大，信息技术的演进逐渐从点形成了面，上图就显示了在2001年之后主要的软件力量来自平台的整合和竞争、以及全方位的软件技术。其实，作为软件人员，我们也可以从自己的信息生涯中咀嚼出这个趋势，问题只是在于有没有花时间进行自我思考。
  数年前的软件人员可能只需要了解程序语言即可，例如只需要会C/C++就可以找到工作。那时数据库也几乎属于专门的技术领域，当时的DBA只要会管理数据库就行，因为还有许多专门写SQL的程序员。但随着时间的推移，软件人员开始需要同时会程序语言、SQL以及管理数据库。接着又需要了解组件技术、Web 技术、终至面向对象和Modeling等技术。为什么对软件人员的要求会愈来愈高？这是因为整个软件的发展趋势正在走向信息技术整合的道路。
  未来的软件趋势是走向软件和系统整合，这代表着软件人员必须知道得更多，掌握更多的技术才能够顺利迎接未来的挑战。唯有掌握每一个独立的软件技术，软件人员才可能有能力拥有系统整合的能力。从许多的观察、分析和统计中，我们可以抽离出下面这些最重要的软件技术或是软件特质。这些技术需求和软件特质是未来成功的软件人员都必须具备的，唯此才能够持续地在竞争愈来愈激烈的软件业中保持高度的竞争力。
  ■  了解多种程序语言■  熟悉更多的系统架构■  面向对象和UML模型技巧成为软件人员的基本要求■  快速学习和开发的能力
  ■  精致化的开发能力对于上述的技术和特质，许多读者会认为这本来就是正常的事项，为什么还需要在这里再次提出？这是因为其中许多的事项由于时空因素的关系，不是有了新的意义，就是有了更大的压力。在本章和第13章中我会分别做详细的说明。
  软件人员在发展本身技能并且了解信息技术发展的趋势之时，当然也需要了解目前各种软件平台和软件领域发展的状况，以便规划本身的发展方向。目前，如果我们以平台作为分类的标准，便可以概略分成UNIX/Mainframe、Windows、Java以及.NET四大平台。由于未来趋势的演进，在这些不同平台中的软件人员也会有不同的境遇和发展。不过总体来说，UNIX/Mainframe和Windows平台的前景都属于逐渐下滑的趋势，其原因就在于这些平台已经处于成熟、饱和或是即将由新的平台所取代。
  如果仔细观察Java平台，可以发现它已经开始进入爆炸成长期。事实确实如此。Java在历经了数年的奋斗之后，的确开始在全世界开花结果。Java除了在美国和欧洲快速占据市场之外，在亚洲也开始快速崛起。例如Java在台湾的表现一年比一年好，不但使用Java的人数增长了许多，Java的开发工具 (例如JBuilder)也一年比一年卖得好。JBuilder已经隐然有和Delphi/C++Builder分庭抗礼的趋势。也由于Java的势力日盛，因此Java软件人员的身价也水涨船高。
  更有趣的是.NET的发展。虽然.NET在2002年才正式推出，但是许多的分析和预测都显示了.NET的发展将不会像Java一样需要花上6/7年才达到一定的高度，.NET的脚步将快上许多。从上图中我们也可以看到.NET平台的趋势已经处于温和上升的状态。根据Microsoft最新公布的信息，到目前为止，全世界已经有4千万台的PC安装了.NET的虚拟执行环境。估计在2003年，Microsoft推出下一代的操作系统Microsoft .NET Server之后，将有为数更多的PC安装.NET虚拟执行环境。当然这也代表了.NET的时代可能会比我们想像中更早到来，这同样预示着.NET软件人员的需求会开始浮现。
  根据Gartner Group的调查显示，以后的信息势力会由Java/.NET平分市场，最有可能的结果是Java将会称霸中/后端以及 UNIX/Linux/Mainframe市场，而.NET则可能控制客户端、Microsoft的行动消费端，并且逐渐朝向中间件攻城略地。未来更有可能通过Intel/AMD高阶CPU的计算能力以及Microsoft的.NET Server而在原本由UNIX控制的低/中/高阶工作站市场取得一定的优势。
  下面的分析图更是显示了四大平台之间势力消长的情形。.NET将很快取代Microsoft原本的DNA架构而成为Windows平台下的企业系统核心技术和架构。我认为这个现象是合理的，但是更有趣的问题是.NET何时将穿透Mainframe和Java平台呢？
  看完了平台之间的竞争后，再让我们看看2002年应用程序开发种类的趋势。

应用系统分布趋势
  每一位读者实际开发的应用系统种类可能都有不同。有的读者可能是开发MIS应用系统的，有的可能在开发Web解决方案，也有读者是在开发分布式应用系统或是低阶的系统软件、嵌入(Embedded)式软件，或者驱动程序系统。不管读者主攻哪一种信息系统，了解整个信息产业的开发分布状况都会是很有帮助的，因为这些信息有助于信息人员准备和规划自己的职业生涯，了解整个信息产业的走势。
  下图显示了2002年信息人员开发的应用系统种类统计结果。从图中可以看出，主从架构仍然是第1名，如果结合数据库的开发，一共拥有24.8％的占有率。同时我们也可以看到，Web的开发几乎已经超过主从架构，估计到了2003年，Web开发将超越主从架构，成为最流行的应用系统开发种类。
  在Java和.NET企业平台愈来愈有影响力之际，未来最重要的系统种类是什么？其实答案已经相当明显了，那绝对不会是低阶的系统种类，而是多层架构、Web/Web Service系统、组件系统等应用。各位读者可看到了未来所需求的人才？

组件架构使用趋势
  Java的EJB和Microsoft的COM+都想在企业市场竞逐，成为企业对象应用系统的核心组件架构。但是EJB和COM+却选择了两个不同的发展方向。对于EJB，SUN只是定义出其标准功能规格，再由各个EJB厂商根据标准EJB规范来开发EJB服务器。而COM+却是由Microsoft定义标准规范并且自己实现。正由于EJB和COM+采取不同的策略，因此EJB获得了较多厂商的支持，推出了许多不同的EJB服务器，但是COM+却凭借着内建于Microsoft的操作系统而拥有较多的使用者。
  目前EJB的功能规格已经发展到2.x版本，Microsoft也准备推出COM+1.5版。SUN和Microsoft推广了许多年的EJB和COM+，到底这两个组件架构在业界被使用的状况如何？两者是不是雷声大雨点小呢？
  根据去年调查的结果显示，EJB的确已经开始在企业生根，已经有19.3％的企业在使用EJB技术；另外有15.3％的企业准备开始使用EJB。这个趋势和Gartner Group对于EJB的预测非常符合，估计到了2004年，有40％左右的企业会使用EJB。从这个现象来看，EJB实在可以说是已经成功了，其实用性也获得了证明。台湾EJB的实用性正日渐普及，许多的大型企业、ISV都已经开始使用EJB作为关键企业应用系统的核心技术，EJB的人才需要也日渐升高。
  由于COM+是内建在Microsoft的Windows的操作系统中，理所当然地其使用率应该是不低。只是COM+的前身COM/MTS等由于其延展性受人质疑，因此使用COM/MTS作为企业核心技术的并不多，大多数是使用COM作为客户端的可重复使用软件组件。但是COM+推出之后，由于其执行效率和延展性都大幅精进，再加上Microsoft在TPCC上显示的惊人效率也都是使用COM+组件，因此COM+逐渐打入企业市场，成为Windows平台核心的组件架构，被许多企业的应用系统所采用。
  根据2002年调查结果显示，COM+使用率已经超过了34.5％，同时还有13.9％的企业有兴趣采用。Microsoft在努力推广COM技术数年之后终于有了一定的成果。不过Microsoft现在面临的挑战是.NET对于COM+的影响，由于Microsoft的平台正从原生窗口转换到.NET的阶段，许多人也开始困惑起来，.NET中的组件架构仍然是COM+？还是有其他的组件架构来代替？如果.NET仍然要使用COM+作为组件架构，那么纯. NET的开发工具又无法开发原生的COM+组件，如此一来在.NET中COM+不就又不是First Class的组件架构了吗？如果纯粹使用.NET的组件，那么纯.NET组件的延展性尚未经过实际的验证，也不提供Two-Phase Commit和分布式Commit的能力，又如何能用来作为企业应用系统的核心组件呢？看来Microsoft在这方面还有很长的一段路要走。
  CORBA呢？在EJB/COM+的强攻之下，CORBA似乎失去了原有的光彩，但是不可否认的是，CORBA仍然是架构/服务最完整、经过最长时间验证的组件模型。根据2002年的调查结果显示，CORBA仍然有相当数量的使用率，而且未来也仍然保有稳定的使用率，可见CORBA仍然受到相当的欢迎。
  随着Microsoft .NET的出现和成长，CORBA似乎反而可以在.NET平台有更大的潜力，相关的讨论请参考下一章"EJB对抗CORBA？有趣的假设"。
  信息技术到了现在的阶段可以说是"平台逐渐整合，但是程序语言则呈现百家争鸣的情形"。再加上UML等Modeling的技术和软件愈来愈贴近软件人员，数据库和SQL技术更已经成为软件人员最基本的技能，因此软件人员本身也自然朝向身通18般武艺的阶段。只是好的软件人员耍起来虎虎生风，而一般的软件人员在愈学愈多的情形下则一无精通，到最后反而是害了自己。
  回到前面的问题，目前的信息技术的确是朝着多元化的方向发展。太多的技术、产品、架构、程序语言、数据库、客户端种类等技术，造成了许多软件人员的困惑和焦虑，这是很自然的现象。但是另一方面，平台在收敛，系统开发正走向整合阶段，对软件人员的要求也走向整合。因此，除了焦虑之外，软件人员在了解了软件趋势之后，更应该提出疑问：
                              你准备好了吗？

快速的开发周期
  上大学时，要学习系统分析和设计(System Analysis and Design)课程，正好看到一个统计，说程序员一天只写一行有效的程序代码，当时我简直乐坏了。心想一定要进入信息行业，又有高薪又有地位，更重要的是工作如此轻松，一天写一行代码，闭着眼睛都可以做到。没有想到，在真正进入了信息行业之后，情形却大为不同。不但工作繁重，每日更需撰写成百上千行的程序代码，这哪里是一天写一行的日子？不禁心生感叹，自己似乎入错了行。
  所有的读者都可以感觉到，现在系统开发的时程要求得愈来愈快。我记得5/6年前，系统和项目开发的速度还是1年到1年半左右，到了3/4年前已经缩短成 10个月左右，在Internet/Intranet快速兴起之后，许多系统和项目甚至缩短到了3个月就要推出的迫人时限。信息机构的调查显示，系统和项目的开发时程将持续地缩短，到了2012年居然只有一天的时程，这种超高标准的要求可能会吓坏许多的软件人员。不管这份调查的数据是否100％正确，但是从这份信息调查趋势以及我本身的经验来看，愈来愈短的开发时程却是不争的事实。
  面对愈来愈短的开发时程，软件人员应该如何适应？这是许多人面临的困扰。其实许多的程序语言、开发工具、软件工程都强调帮助软件人员提高生产力，以适应快速开发的要求，只是随着时程的要求愈来愈高，许多传统的程序语言和开发工具都已经呈现力不从心的现象。既然如此，那解决问题的方案是什么呢？
  数年前，业界对于软件开发的速度要求愈来愈快，这造成了软件品质的下降。许多软件在完善率尚未达到一定的水准下便仓促推出，造成了更多的问题，因此软件业曾经被许多人讥笑为"不可靠行业"。为了改善这个现象，许多软件工程技术相继出现，以求提高软件品质。其中最为突出的是以面向对象的各种软件工程，强调软件IC、可重复使用的软件组件为特质，以加快软件开发的速度并且提高软件品质。面向对象的大旗造就了3位面向对象大师，也让UML等模型工程独领风骚，进而让Rational公司成为近年来最重要的软件公司之一。不过几年下来，UML对于软件开发的贡献一直受到争议，许多软件人员对于UML过于复杂的流程和过多的UML图形产生怀疑，因此前一阵子又兴起了Extreme Programming的热潮，强调轻便、动态、快速开发的特性。其实这个现象正反映了软件业界对于开发"速度"的要求已经超越了过份强调软件工程流程的重要性。现在的信息业界需要的是"灵活的"开发速度。
  右边的图片明确显示了从2002年下半年起，许多企业和软件公司对于软件开发特性的要求，其中列为最重要的特质就是"灵活性"，接着仍然是强调速度的Extreme
  Programming的特质。其实，这些对于软件开发的要求也正回应了上一张图形显示的对于开发速度的要求。
  我认为UML/RUP和Extreme Programming/Agile Development之间并没有冲突，反而是相辅相成的。对于大型、复杂的系统开发，UML/RUP仍然是目前为止最好的方法之一，只是需要适当的修正，不要过份强调所有的形式流程。而Extreme Programming/AgileDevelopment则特别适合中/小型系统，需要快速反应时间的开发要求。
  既然快速开发已经成为现在最重要的软件开发要素之一，那传统软件人员应该如何适应呢？其实这个原理也不难了解，答案就隐含在上图中Developer- Centric包含的意义。想想看，现在的许多企业是如何增加效率的呢？答案之一就是组织扁平化，尽量减少不必要的重复浪费。软件开发也是一样，软件工具应该尽量以开发人员为中心，让开发人员使用较少的循环能够完成更多的开发阶段，并且提供更可靠的软件。例如，新一代的开发工具允许开发人员在一个开发环境中，同分析/设计人员以UML的模型来沟通，并且能够在一个开发环境中撰写程序代码，以可视化方式检视程序代码的关系和可靠度，能够在相同的开发环境中进行单元测试、压力测试、负载测试，并且和测试人员合作。另外，在这个开发环境中也能够和开发团队共同进行项目管理和版本管理的工作。如此一来，开发人员可以在较短的时程内提供更高的生产力，缩减开发循环。当然，这意味着以后软件人员必须知道得更多、要求也更高，但是，这的确可以让开发人员更有效率，并且增加整个团队开发的生产力。
  面对要求愈来愈高的动态开发时程，身为专业软件人员的你：                            可准备好了吗？

程序语言的战争
  从程序语言的发展史来看，数年前似乎就有统一的趋势。在商业应用上COBOL几乎是事实标准，在科学计算上Fortran有不可取代的地位，而C/C++ 则几乎垄断了大部分其他的应用。但是随着Internet/Intranet以及RAD工具的兴起，这个由数个主流语言掌握的局面很快被打破了。特别是在各种脚本语言(Scripting Language)和Java在Internet应用上逐渐取得了优势之后，各种新的程序语言纷至沓来，让人眼花缭乱，不知如何选择。程序语言战场在寂静了数年之后却突然陷入了前所未有的热战之中。
  其实，各种程序语言的不断出现，反映的就是以往的程序语言已经不足使用或是不适合使用在特定的应用中，因此才需要新的程序语言来解决问题。新的程序语言代表了信息应用的多样化，而以往由COBOL、Fortran、C/C++主掌的情势也被快速地打破。如今的软件开发人员可能必须同时熟悉数种程序语言，并且在不同的应用中选择使用最适当的程序语言。
  以Web应用系统的开发为例，看看目前这个最流行、最重要的应用系统是由什么程序语言开发的。在台湾地区，不可否认的是ASP绝对是最多人使用的解决方案，这是由于台湾大部分的Web应用都属于中、小型系统，而且Web应用系统分布的区域并不算广大，因此ASP就足够满足大多数的需求，软件人员选择的标准是好用、开发迅速的程序语言。
  但是，对于美国或是大陆这种幅员广大、并且拥有许多大型系统的应用而言，很可能和台湾地区的情况大不相同。那么，到底世界上的软件人员是使用什么程序语言来开发Web应用系统呢？对于这个问题的答案，我很有兴趣，因为可以拓宽自己的视野。下图显示的是信息机构对美国软件人员调查的结果，从图中可以发现使用最高的居然是XML，而不是ASP或JSP。不过XML、ASP和JSP这3者加起来占据了3分之一强，可见这3种程序语言是Web应用开发的主流。另外值得注意的是，虽然PHP最近声势不断地增长、并且拥有Open Source的优势，但是居然只占有4％的使用率。PHP的成长率很惊人，这在稍后也会说明，不过PHP要想在Web开发领域占有显著的地位，仍然需要多多努力。
  除了Web的开发之外，如果不注重开发工具的区别而纯以程序语言的角度来看，下图显示的就是目前针对程序语言所做的调查统计结果，Java、Visual Basic、C/C++和C#是目前4大主流程序语言。不过下图中的C#数字是指C#在2003年的表现，而不是在2002年的情形。
  图中的调查结果，显然和我国台湾地区以及大陆的情形有些出入。在台湾，Java正快速爬升，C/C++的影响力则持续下滑，而最大使用的程序语言应该就是 Visual Basic和Object Pascal了。台湾地区的情形和大陆稍有不同，目前在大陆Java也是快速地兴起，不过尚未形成最有影响力的语言之地位，反而是C/C++仍然为大陆目前最有影响力的程序语言，Object Pascal、Java和Visual Basic则紧迫在后。根据CSDN网站统计的结果，目前各程序语言讨论的文章数分别如表所示。
  从右边图形和数字，我们可以了解在大陆使用C/C++语言的人数实在是众多，而Java已经超过了Visual Basic。不过未来的发展情形则更令人好奇，因为在全世界的C/C++都开始逐渐走下坡之际，C/C++在大陆的市场会不会也发生类似的现象呢？ Visual Basic和PowerBuilder会不会持续下滑？Java何时会成为霸主？C#又何时会迎头赶上？这些问题都非常值得观察，因为这不但影响了各程序语言之间势力的消长，也代表着软件工作市场的需求和变化。
  有趣的是，在Windows和.NET平台上，程序语言正以前所未有的生气蓬勃发展，而且不同的程序语言间互相激荡、相互影响，再产生新的程序语言或是在原有的程序语言中加入新的机制以符合新的需求。但是在Java平台，却几乎只有Java语言，没有其他的选择。那么读者是喜欢单一程序语言的单纯，还是喜欢多种语言产生的灿烂火花呢？我个人是比较喜欢多种语言的，因为我认为，我们可以通过欣赏不同程序语言的设计精神和思想来吸收更多的知识和技术，通过不同程序语言彼此竞争的结果，可以嗅出未来程序语言的发展方向，这大概也是因为我从大学时就特别喜欢程序语言和编译器课程的结果吧。

知己知彼，百战百胜
  就让我们以EJB服务器市场这个实际的竞争范例来看看信息产业是如何竞争和演化的吧。三四年前，当EJB市场开始成长时，许多软件厂商相继投入这个潜力十足的市场。当时，所有EJB厂商竞争的基准大概都是符合EJB规范、使用最新JDK标准以及执行效率最良好的EJB服务器。当时竞争的EJB服务器可以用满山满谷来形容，为什么呢？因为在这个阶段纯粹是以技术为决胜点，这个门槛并不高，拥有技术的软件人才多得是。因此，这个阶段中有眼光和智慧的厂商便了解到，光凭EJB服务器引擎是无法作为胜出的要件的，必须想办法增加竞争门槛以阻绝竞争对手持续逼近，或是增加"软件服务"以提供竞争对手没有的功能。
  到了EJB服务器竞争的第2阶段，逐渐胜出的EJB厂商便开始为EJB服务器加入各种服务，其中一类是以增加商业应用服务为主，例如Portal Service、ERP Service等。而另外一类则是以技术服务为主，例如分布式交易服务、安全服务等。由于这些软件服务的加入，在EJB服务器竞争的第2阶段便逐渐产生了 EJB服务器的领先群，许多其他的EJB服务器厂商在眼看竞争无望之下自然地退出了市场，HP就是一个例子。
  现在EJB服务器市场又进入了最后厮杀的阶段，因为在领先群中的厂商大都提供了类似的服务。那么接下来要如何竞争呢？IBM很快就看到了关键点，那就是为 WebSphere加入整合开发平台的能力。通过并购Rational取得Modeling工具和技术，IBM可结合原有的Java开发工具为 WebSphere形成一个关键开发平台，同时吸引企业使用者以及开发人员为WebSphere形成的企业平台开发更多的客制化服务，以便为 WebSphere形成势力强大的专属力量。这是WebSphere最大竞争对手WebLogic目前没有的优势。从EJB服务器竞争的过程来看，致胜的关键便是软件人员是否能够看到别人看不到的优势、并提供额外的服务。对于软件人员的发展，道理也是同样。大部分的软件人员都只注重在特定的开发工具或是程序语言中精进，但似乎都是随着别人的脚步而前进，少数软件精英除了在信息技术领域有高人一等的修为外，真正胜出的却是能够为自己增加附加价值、提供创造力的能力。就像JBuilder的Chief Scientist--Blake Stone，为什么他能够在年纪轻轻的情形下成为领导者？许多资历、年纪都比Blake Stone多的研发人员反而只能当工程师呢？很简单，因为Blake Stone更早地看到了JBuilder的发展趋势和竞争策略，掌握了Java开发工具发展的动脉，能够为JBuilder开发团队提供更多的价值，再加上坚强的技术实力，终于成为家喻户晓的Java天才。
  我一直认为任何软件技术终将被大众所熟知和掌握，就像数年前的主从架构一样，因此光凭借技术并不能让人领先多久。反而是通过平日不断培养的眼光和趋势、再加上专业的技术才能够让软件人员保持在领先群中，并且掌握软件趋势的动脉。拥有这种特质的软件人员能够不时的提供服务，不时地为团队提供持续的创新力，自然也就能够百战百胜了。

结论
  人类对于新事物的害怕，通常都是由于对新事物的无知所引起。同样，软件人员对于未来的困惑和焦虑则来自不知如何是好，这也是对于未来趋势发展的无知所引起。本节中，我们通过分析、观察和统计了解了以往、现在和未来软件趋势的发展，当事实的走向豁然开朗之后，困惑和焦虑不再重要，软件人员反而应该反躬自省地自问：面对未来，我们准备好了没有？
  不管Java和.NET两大平台之间的战争如何，不管哪一个软件组件或是程序语言会获得最后的胜利，世界对于软件系统快速开发的要求不会因为那一方胜出而改变，软件人员必须准备好面对这个趋势。想想，JBuilder以每半年一个新版本出现，Java JDK和.NET也几乎以1年半之间推出两个版本的速度在彼此争战之中，连传统的开发工具现在也几乎以一年一个版本的速度出现。更夸张的是， Internet/Intranet的技术现在几乎每3个月就有一番新的面貌，开发人员应该如何自处呢？
  机会可能会降临在每一个人的身上，但是只有时时准备好的人才能够把握住机会，不让它从手缝中溜走。

第十一章 EJB对抗CORBA？有趣的假设

(文章来源：<<Borland传奇>> 电子工业出版社 2004年，作者：李维)

  "组件模型的两大巨头终将对决？"
  什么是.NET？我们可以从各种技术角度探讨.NET，NET的技术书籍也可以撰写成几十本、甚至是上百本。但是Microsoft提倡.NET，最重要的目的是提供一个足以和Java平台对抗的"企业平台"(Enterprise Platform)。Microsoft希望企业能够使用.NET作为企业应用系统的核心平台，根据这个企业核心平台再开发各种应用系统，连接新式的移动设备(Mobile Device)，形成企业应用系统需要的完整信息供应链，提供类似目前Java拥有的企业业务。Microsoft希望通过.NET打入企业市场的企图是不言而喻的。
  为什么Microsoft急于打入企业市场呢？主要因为企业市场是获利最为丰富的市场，也是Microsoft长久以来最想进入的市场。另外， Microsoft不希望Java独占企业市场、进而产生对Microsoft的威胁，这是第二个关键因素。其次更重要的原因是，Microsoft在客户端几乎已达饱和，继续成长的空间有限，需要另外能够持续成长的市场，而企业市场、消费端市场、通讯市场以及游戏市场就是Microsoft注重的目标了。
  Microsoft要想打入企业市场，需要面对的是表现愈来愈好的J2EE架构。目前J2EE已经被愈来愈多的大型企业用作企业核心的信息技术。根据 Gartner Group的调查，EJB的架构将逐年增加，到了2003年将会拥有超过40％的使用率。这代表EJB将成为企业应用系统的核心组件架构，更多的企业系统将使用J2EE来建制。
  这些现象在大型的信息业界反映得非常真实和明显，例如台湾的台积电(TSMC)、联电(UMC)和友达光电等都已经在使用Java和J2EE作为新一代信息系统开发的核心技术。再看看目前EJB服务器的两大领导厂商产品--BEA的WebLogic以及IBM的WebSphere。WebLogic和 WebSphere除了已经成为许多企业的核心J2EE服务器、提供企业开发应用系统的基石之外，还慢慢形成了企业应用系统的解决方案中心，并从其中衍生出许多新的软件需求和应用。例如许多的Portal系统、ERP、CRM或Web Service应用都围绕在这两个J2EE服务器的外部进行增值的应用。这种现象已经开始形成非常巨大的力量，让EJB服务器的竞争从EJB核心服务器演变到EJB解决方案的地步，宛如一个黑洞在不断地吸引新的应用和力量进入、使用这个架构。这种软件群聚的效应正是企业级信息技术应该形成的现象，因为唯有如此，才能够让影响力不断扩大。当初Microsoft的Windows就是这样，吸引了全世界程序员为Windows开发应用软件，以 Microsoft Windows为应用的核心，这才造就了Windows成为全世界客户端操作系统的霸主。
  由此可见，一个核心软件技术对于信息应用的重要性。当初Microsoft在Windows上力推COM/COM+组件模型，希望它们成为Windows 上的核心组件技术，提供企业在Windows平台上开发企业应用系统的解决方案。其实以效率来说，COM+的确是不错的。根据许多的测试以及TPCC上公布的结果来看，COM+的执行效率几乎是最好的。而前段时间TheServerSide上公布的EJB对COM+的评比更是闹得满城风雨。Java业界仍然不肯承认COM+比EJB来得有效率，但是以目前的数据来看，在Windows上EJB的确远远比不上COM+。在Microsoft多年的推展之后， COM/COM+的确也有了不错的使用结果。根据2002年北美关于COM+的信息调查显示，使用COM+技术的人占了34.3％，而且还有9％的人回答将会采用COM+。虽然COM+在执行效率方面表现很好，但不可否认的是COM+只能在Windows平台使用，而且在Internet应用中使用不便，延展性也不若EJB，这都是COM+致命的缺点。

.NET核心组件技术
  既然Microsoft希望.NET成为企业应用的平台，那.NET需要提供什么呢？除了开发工具之外，.NET最重要的便是提供一个类似J2EE架构的软件解决方案，以吸引软件人员为.NET开发企业级的应用系统，帮助.NET打入企业市场和Java平台竞争。
  那现在的.NET中有什么类似J2EE架构的技术呢？从下图我们可以清楚地看到，Microsoft在.NET中正逐渐建立起同SUN Java平台竞争的技术核心。Microsoft和SUN的虚拟竞争平台现在几乎非常类似，不过，目前的Java在组件技术的领域远远超过了 Microsoft提供的解决方案。
  Microsoft在.NET中的组件技术是以.NET组件配合COM+为主。COM+在.NET中转为操作系统的核心服务，提供事务管理 (Transaction Management)的功能，而.NET组件则可以同时扮演.NET中的可视化组件(Visual Component)、数据感知组件(Data-AwareComponent)以及中间件(Middleware Component)。然而使用.NET组件作为.NET平台中间件有许多问题。首先是.NET组件必须依靠COM+组件提供分布式事务管理能力；另外，.NET组件目前也没有像EJB一样的Fail-Over和Load-Balancing能力，这在企业级的应用中是明显不足的。
  此外，.NET组件必须和COM+一起搭配使用，这意味着程序员必须开发COM+组件，而.NET的原生工具无法开发COM+组件，程序员还是必须使用原生的Windows开发工具。此外，一旦使用了COM+，代表此.NET应用系统无法移植到其他的平台。如果Microsoft把.NET移植到 Linux或是FreeBSD上，那使用COM+组件的.NET应用系统将无法移植到这些平台之中。
  那么，Microsoft是不是需要一个新的、能在.NET平台使用的组件架构呢？就我的眼光来看，如果Microsoft希望把.NET平台定位在企业系统同J2EE竞争，那的确是需要这种技术，但这对于Microsoft是有一点困难的。首先，Microsoft正忙于在一二年内达到Java平台花了七八年的成果，正忙于开发.NET本身、.NET开发工具、.NET下的数据库，并且把所有的Microsoft Server应用程序移植到.NET之下，可能一时无法投入太多的资源来开发一个全新的企业级的组件架构。
  另外，再看看Microsoft建立组件架构的历史就可以了解到，在这方面Microsoft的确不太在行。期望Microsoft在短时间内在.NET平台定义类似EJB的企业组件架构的规格并且将其实现出来，似乎是不太容易的事情。
      组件技术    结果
      16位VBX     失败    32位VBX     失败    OLE         失败    COM         尚可    ActiveX     失败    MTS         失败    COM+        不错    .NET组件    不适合使用在企业级应用中既然新创.NET下的企业组件架构不是短时间内可以完成的，那是不是代表着.NET在这方面已经无法和J2EE竞争而提早出局呢？其实并不一定，因为如果无法快速开发一个新的组件架构，那为什么不使用已经存在且已经验证是适合企业应用的组件架构呢？让我们想想.NET的特性和需求是什么，就可以推知什么组件架构最适合在.NET平台下成为企业级的组件架构了。
  什么组件架构已经使用过很长的一段时间，且经过了市场的验证呢？    →  CORBA、EJB和COM+
  什么组件架构可以跨平台？    →  CORBA和EJB
  什么组件架构允许多种语言开发和使用？    →  CORBA
  从上面的问题中，我们已经看到答案是呼之欲出了。更关键的是上面的第3个问题。由于.NET是一个语言中立的平台，程序员可以使用任何语言来开发.NET 应用程序，因此在.NET平台的组件架构必须能够让各种不同的程序语言来开发和使用，而不像EJB一样只能使用Java语言。对比一下，CORBA正好符合语言中立的要求。此外CORBA是一个跨平台的组件架构，可以随着.NET移植到各种平台。因此从各方面来看，CORBA实在非常适合使用在.NET之中并成为.NET的核心组件架构。

CORBA和EJB
  CORBA已经在企业应用系统使用了很长时间，是一个架构成熟、经过了市场严格考验的组件技术。在CORBA之后的许多组件架构其实也都学习了 CORBA。例如J2EE中的EJB规格可以使用CORBA来实现，在EJB 2.0之后也要求EJB服务器必须和CORBA兼容，由此可见CORBA组件架构的重要性和成熟性。目前，CORBA仍然是一个在持续发展中的组件规格， OMG也持续为CORBA定义更为完整的核心和服务规格。
  CORBA使用的Stub/Proxy以及组件服务架构深深地影响了COM+和EJB的实现架构，以致COM+和EJB组件架构和CORBA都有许多神似的地方。
  由于CORBA几乎是其他组件架构的始祖，因此CORBA绝对有能力、有份量和EJB分庭抗礼。如果.NET能够在其平台上以CORBA作为核心组件架构，那么.NET就可以提供同J2EE一样好的企业应用架构。虽然许多人会质疑在PC上执行企业应用系统会不会力量不够？但是，随着64位的CPU (Intel和AMD)即将推出，Microsoft也准备推出64位的操作系统。在.NET虚拟执行环境的保护下，如果再加上安全强固的CORBA，那么.NET的确可以提供相当有竞争力的企业执行平台，与J2EE在中/低阶的企业应用中竞争。如此一来，Java/J2EE就不再拥有企业应用中的绝对优势了。
  既然CORBA对于Microsoft .NET平台的企业运算有这么大的助力，那么CORBA组件架构在.NET平台上将以什么样的架构来提供服务呢？

CORBA For .NET
  CORBA要如何在.NET平台上提供企业级的服务呢？由于CORBA使用IIOP通讯协议作为调用CORBA服务的接口，因此传统的CORBA引擎(例如Borland的VisiBroker)，应该会为CORBA伺服端和客户端产生可连接的DLL或是函数库，这些DLL和函数库就负责让客户端通过 IIOP调用伺服端的CORBA服务器。因此CORBA即使是执行在.NET平台中，也是使用IIOP作为调用的通讯协议，如右图所示。
  不过，在.NET下Microsoft是使用.NET Remoting机制作为远程和分布式沟通的通讯协议。那么，.NET的CORBA开发工具要如何结合.NET的Remoting机制、并且允许.NET下各种不同的语言通过IIOP调用远程的CORBA服务呢？
  其实，这同在Windows下提供原生窗口开发工具开发CORBA应用系统几乎是一样的，只是在.NET下CORBA引擎必须进行一些额外的工作以让.NET的开发工具和应用程序能够使用CORBA技术。
  首先，.NET下的CORBA开发工具必须能够提供.NET下主流程序语言的支持，这代表CORBAFor .NET必须为每一种程序语言产生客户端的CORBA.NET Stub和伺服端的CORBA.NETProxy。其次，为了和.NET Remoting机制结合在一起并提供IIOP的能力，CORBA For.NET必须产生一个Adapter和.NET RemotJng作为沟通的机制，.NET Remoting通过这个Adapter再调用最底层的CORBA For .NET引擎，CORBA For .NET引擎再把.NET Remoting的调用惯例转换为IIOP通讯协议。经由Adapter和CORBA For .NET引擎的转换之后，就可以调用远程的CORBA服务和CORBA服务器，甚至通过RMI Over IIOP调用到远程的EJB服务器，如下所示：
  上面说明的架构还是比较详细的。由于在.NET下各种程序语言都会被.NET的编译器转换为.NET的IL，因此CORBA For .NET工具可以产生一个IL型态的客户端CORBA.NET Stub。如此一来，不管程序员使用的程序语言是什么，都可以保证能够通过这个CORBA.NETStub来调用远程的CORBA服务。这个架构其实比以前Windows下的CORBA开发工具更容易，因为在Windows下，CORBA厂商还必须为不同的程序语言产生不同程序语言的客户端CORBA Stubs。现在.NET下CORBA厂商反而因为.NET几的特性而更轻松和一致了。一旦CORBA厂商能够在.NET下实现CORBA For .NET，那么不但可以让.NET的程序员开发真正企业级的.NET应用系统，更由于CORBA和EJB是兼容的，因此.NET下的CORBA服务器也能够通过RMI Over IIOP调用和整合EJB服务器，提供.NET和J2EE无缝整合的能力，并且允许使用者的应用系统能够从.NET平台顺利地移转到J2EE平台，如下所示。更何况，现在许多的EJB服务器还能够像管理EJB对象一样地管理CORBA对象，这意味着执行在Mainframe或是UNIX/Linux的 EJB服务器能够管理和整合执行在.NET中的CORBA对象或是CORBA服务。.NET有了CORBA这个解决方案之后，终于有了进入可提供企业级应用程序架构的能力了。

巨人终将对决？
  CORBA的复杂度使其一直未能被广大的程序员所接受，现在的CORBA本身已经非常安全强固，而且经过了十几年企业市场的考验(即使是EJB也不过在企业市场才经历了2个版本的洗礼)，CORBA的开发厂商应该已经清楚，CORBA不被大多数开发人员接受的原因并不是CORBA不够好，而是CORBA太复杂。因此这些开发厂商应该舍弃CORBA中鲜为人用的服务，先提供一个完整的CORBA引擎以及企业应用最重要的两个服务--事务管理服务 (Transaction Service)和安全服务(Security Service)。更进一步的是，如果CORBA厂商能够在客户端提供.NET的组件来封装比较复杂的CORBA调用和存取机制，并且结合数据存取的能力，那么，.NET下的程序员将能够以非常快的速度学习和使用CORBA组件架构。如此一来，CORBA将有机会在.NET平台中大展身手，有机会成为. NET平台中最有潜力的组件架构，也将有机会让CORBA一吐闷气，让世人了解CORBA的价值。"EJB和CORBA两大巨人终将对决"？不，更正确的说法应该是J2EE/EJB终于找到了可敬的对手--.NET/CORBA，而CORBA和EJB也将进入"既竞争又合作"的时代，当然前提是有厂商推出 CORBA For .NET的软件产品。

 第十二章 回到C/C++的王国

(文章来源：<<Borland传奇>> 电子工业出版社 2004年，作者：李维)

  "让我们重返荣耀之都吧！"当年Windows平台C/C++开发工具四大天王一战，在Microsoft取得了市场的主导力量之后，C/C++开发工具的市场和竞争反而缓慢了下来，Windows上C/C++开发工具的进步也开始牛步化。VC++一连两三个版本的进度幅度并不大，除了稍后推出的ATL还有新意和技术革新，VC++编译器除了在C/C++语言上更趋近于标准之外，MFC本身几乎已经没有什么大的进步了。在Watcom和Symantec退出市场之后，VC++也顺利地接受了Watcom和Symantec的市场。而Borland C/C++虽然也损失了大量的市场，并且失去了C/C++的王座，但是在数年后，Borland推出C/C++Builder，以C/C++ RAD工具、以及更符合ANSI C/C++标准和VC++进行市场的区隔，也慢慢地收复了一些失地。虽然Borland C/C++工具系列已经无法像以前一样是市场第一的C/C++开发工具，但是Borland在Windows的C/C++开发工具市场仍然占有30％强的市场份额。
  C/C++开发工具在C/C++ Framework一战之后，开发的重点却似乎模糊了起来。由于VC++没有强劲的竞争，因此整个的发展速度缓慢下来。不过C/C++技术在C/C++语言、函数库(Library)和通用Framework方面却快速地如雨后春笋般兴起。特别是在C/C++语言的标准化更为完善、以及Template的功能被C++ Standards Committee接受而且被广泛地由C/C++编译器支持之后，各种支持和使用Template的Framework、C/C++函数库也快速地占据了 C/C++开发者的心灵，成为有力的程序技巧之一。在Java日益兴盛、开始威胁C/C++的市场时，反而激发了C/C++语言前所未有的高度发展。不过，目前C/C++开发工具以及C/C++编译器是否跟上了C/C++这么快速的发展脚步呢？在本章继续讨论之前，也许应该让我们先看看目前C/C++市场的现况。

日不落帝国
  曾几何时，C/C++是征服全世界的语言之一。在数年前C/C++语言全盛的时期，我记得几乎所有的应用系统都选择使用C/C++来编写，如从系统程序、公用程序、软件包到项目开发，因此也造就了C/C++开发工具横扫软件销售市场的现象。但是随着RAD工具和Java的逐渐受欢迎，让C/C++开始从许多的市场撤退。特别是当Java兴起之后便快速取代了以往C/C++在跨平台语言的主导角色，让C/C++语言在这个市场受到Java最大的威胁。不过， C/C++仍然在许多方面的应用不可否认地具有绝对的优势，特别是在需要高度执行效率的应用系统中，例如驱动程序和低阶的系统程序等。那么C/C++目前的市场到底有多少？有没有像两、三年前许多信息机构预测的那样，Java将会大幅抢走C/C++的市场、并且吸引大量的C/C++程序员呢？让我们以实际的数据来看看目前的状态。
  右图是全世界专业信息机构对于C/C++开发工具市场规模和使用状况的调查结果。从这个结果图形中我们可以得知几个非常重要的C/C++信息：
  首先请读者注意的是，就整体来说C/C++开发工具的市场的确是处于小幅的下降趋势之中，根据Gartner Group的调查，C/C++市场是以5％的幅度下降，而根据Evans DataSurvey的调查，C/C++市场则是以3％的幅度下降。不过稍后我们会说明，C/C++开发工具是在哪些平台和应用中产生变化。
  另外一个值得注意的地方，是C/C++语言主要是用于三个应用领域之中，分别是客户端、伺服端和维护现有的应用程序。从图中我们也可以发现C/C++语言被使用的转变状态，在工业应用方面，C/C++开发工具仍然有很大的成长，这当然是因为C/C++语言被广泛用于驱动程序的开发，例如显示卡驱动程序、网卡驱动程序等。此外C/C++语言也被用于移动设备的开发，例如Nokia为了和Microsoft的Smart Phone对抗而推出的Symbian手机系统。当然，在操作系统、系统程序和低阶核心应用方面C/C++语言仍然有着不可取代的地位。
  但是，C/C++在其他方面的应用的确是在下降之中，特别是在企业的应用系统方面。例如目前在大型项目、软件包、MIS和企业内部的应用系统中，使用 C/C++语言的比例的确在下降。其中主要的原因是C/C++语言本身的难度较高，因此生产力也不如其他语言和开发工具。加上较易使用的RAD工具和 Java出现之后，C/C++语言在这些领域的影响力是大不如前的。这个现象也非常契合台湾地区目前的状况，在前几年C/C++兴盛的阶段，几乎大部分的软件包厂商和SI以及系统厂商的确都是以C/C++开发工具为第一选择。不过由于C/C++需要的人力素质较高，而且生产力无法大幅提高，因此在目前软件包和项目的开发大多都由Delphi、VB、PowerBuilder以及Java所瓜分。至于C/C++开发工具使用的操作系统分配状况，则可以由右面的调查结果来说明。从图中我们可以发现，UNIX/Linux操作系统平台仍然是占了最大的使用平台，这当然是由于UNIX/Lmux本身就是使用C/C ++语言开发的。而且在UNIX/Linux平台我们可以发现，C/C++开发工具的规模仍然在成长，可达成10％左右的年成长幅度。由此可知，虽然 Java现在已经入侵UNIX/Linux平台，但是对于C/C++的影响仍然不太显著。C/C++开发工具第二个最大的平台就是Windows平台了，虽然现在Windows平台是开发工具百花齐放的状态，但是不可否认的是，C/C++仍然是Windows最重要的数个语言之一，因为122 Million到137 Million的市场规模是相当大的。而Windows平台的C/C++开发工具的成长虽然在为数众多的开发工具瓜分之下，仍可达到12％的成长率。这代表C/C++语言即使是在Java强力竞争之下仍然拥有一定的成长量。由于Windows平台下的C/C++和Java开发工具是处于同时成长的情形，因此，这可能表示在Windows平台下许多的程序员应该是同时使用了C/C++和Java开发工具。
  至于其他平台的C/C++开发工具则呈现下降的趋势，而且是处于快速下降的情形，这也可以解释为什么Java在Mainframe和OS/400等大型专属平台成长快速的情形。由此可见，在这些专属市场中C/C++语言的确是受到Java很大的影响。
  除了C/C++语言本身之外，再让我们观察一下目前主流语言应用的现况，通过观察不同语言之间势力消长的情况，我们也可以了解其他语言对于C/C++语言的影响。右图即显示了信息机构对于目前几个主流语言之间成长和下降的预估。
  从图中我们可以看到，几乎所有的传统语言例如VB、C/C++和COBOL等都呈现下滑的趋势，相同的现象当然也在第2级的主流语言例如Object Pascal和PowerBuilder等中看到，但是新一代的虚拟语言却呈现了对比的情形而大幅上升和成长，表示使用这些新语言的程序员人口正在快速的兴起之中，例如SUN的Java和Microsoft的C#，而Java快速兴起也可以解释为什么Borland的JBuilder现在已经是 Borland最大收入来源的开发工具。
  看完了C/C++整体市场的趋势之后，C/C++语言目前在程序员人口中使用的情形到底是如何呢？下图是2002年针对美国程序员调查的结果，从这个结果中我们已经可以看到，在所有调查的人数中使用C/C++的程序员占了45.6％的比率，但是只使用C/C++单一语言的比率只有3％，可见，现在大部分的 C/C++程序员应该已经开始同时使用两种以上的语言。
  而第二幅图则是针对美国程序员对于未来计划使用C/C++语言的调查结果，从图中可以证明前面图形和分析的结果，C/C++语言的确是以3％到5％的速度在衰退之中，也有愈来愈多的C/C++程序员开始使用多种语言来进行开发的工作，当然C/C++程序员选择的最多语言就是Java和C#了。
  在"令人焦虑的时代"一章中我们已经讨论了Java语言目前使用的状况以及未来的发展。从其中我们了解了Java虽然快速地兴盛，但是也看到了Java似乎已经在美国进入成熟期，开始出现稳定的状态并且有小幅的衰退。既然C/C++和Java这两个拥有共同基因的语言都处于稳定或是小幅衰退的情况，那么流失的程序员到底到哪里去了呢？当然答案很明显，这些流失的程序员是转到拥有相同基因的C#语言阵营了。
  虽然Microsoft的Visual Studio.NET是在2002年的2月才正式推出，但是C#的编译器和相关的工具早已在Beta阶段便为许多程序员所使用，因此在2002年便已经吸引了一些程序员使用，而这些第1波使用C#的程序师大都是从C/C++和Java语言转换跑道而来的。右图是C#语言在2002年使用的状况调查，C#在不到1年的时间便吸引了美国14.6％的程序员人口使用是相当惊人的表现。
  那么未来呢？C#还能够稳健地成长吗？因为唯有稳健成长的语言才能够有机会成为主流的语言。右图便是对于2003年C#语言使用状况的评估，从这些数据我们可以看到，C#语言果然将以稳健的脚步成长，每年以将近10％的速度发展，而C#如果持续地照这样的速度发展下去，那么C#将在4年之内达成Java花了七八年才达成的现状。当然，C#这种成长趋势也暗示了Microsoft的.NET将在不久的时间内对于Java平台产生重大的影响。
  对于C/C++、Java和C#这三个拥有类似基因的语言，如果我们把它们的发展放在一起比较的话，会发现目前C/C++和Java语言正处于激烈竞争的状态。但是C/C++和Java千万不可忽视C#这个后起之秀，C#正以旺盛的企图快速地向两位老大哥挑战之中，以竞逐在程序员心中主流的地位。
  从上面所有的分析中，我们可以知道使用C/C++语言的人数虽然的确是在下降之中，但是幅度并不大，这代表C/C++语言有着非常稳定的支持力量，这当然也是因为在许多的应用中C/C十十语言拥有不可取代的优势，更何况C/C++开发工具的市场仍然拥有将近600 Million美金的规模。这实在是一个非常大的数字，以Borland来比较的话，Borland全年所有的软件营收不过是240 Million左右，可见C/C++市场的潜在力量，对于Borland来说这是绝对不可放弃的开发工具市场。
  相对于欧洲的发展模型和美国非常接近，另外一个全世界最大的程序员市场--中国大陆，并没有在这次的调查中显示出开发工具的使用状态，也许未来应该有全球软件语言的调查评估。不过从各种迹象显示，大陆的市场目前是以C/C++和Ddphi分占程序员使用的大宗，而Java则在快速的成长之中。这和台湾地区有一点不同，那就是在台湾地区是以VB、Delphi和C/C++为主要的语言力量，而Java则是几乎进入成熟的阶段，开始和VB、Ddphi以及 C/C++分庭抗礼。因此对于Borland来说，不管是在中国大陆和台湾地区，C/C++开发工具都是很重要的，所以Bodand的RAD部门宣称中国大陆的市场是Borland RAD部门最后的圣地，因为在中国大陆Borland的C++Builder、Delphi、Kylix和未来的C/C++开发工具以及.NET的开发工具都拥有全世界最大成长潜力的机会。

蓬勃发展的新兴C/C++力量
  其实不管是什么程序语言，在面对竞争日益激烈的情势中，程序语言的开发厂商和爱好者莫不卯足全力地捍卫和鼓吹其支持的程序语言，对于C/C++的发展厂商和爱好者来说也是一样的情形。更有趣的是，虽然使用C/C++语言最大的平台是UNIX/Linux，但是Windows上的C/C++开发工具反而是竞争得最为激烈、进步幅度也是最大的平台。对于Borland来说，在Windows平台上是市场排名第2的C/C++开发工具厂商，而且C++ Builder这条产品线对于Borland来说，占据了开发工具第3位的收入来源，对于Borland有着重要的贡献，Borland不但不可能放弃，反而更要想办法增加市场规模。在C++Builder推出并且从Microsoft抢回了部分的市场份额之后，Borland计划推出更新、更强劲的 C/C++开发工具。Borland也在BorCon 2002中透露了一些有关未来C/C++开发工具的计划。不过在我们讨论C/C++开发工具的未来之前，先让我们看看目前在C/C++技术方面重要的发展。
  首先在C/C++编译器方面Windows平台上厂商的表现实在是差强人意，不管是Borland或是Microsoft都没有完全实现出符合ANSI C/C++标准的C/C++编译器，这和数年前四大C/C++编译器厂商彼此竞争激烈、快速进步的情况来说实在是令人不满意，这也可见失去竞争的市场其进步缓慢的现状。不过Borland已经宣称在发展下一代最佳化的C/C++编译器，不但能够产生更好的最佳化C/C++编译机器码，而且也将符合ANSI C/C++标准。相对于Borland在C/C++方面的大动作，Microsoft反而显得比较沉寂，除了把VC++移植到.NET上的VC.NET之外似乎没有什么大的改善。当然，Borland是不是能够真地推出宣称的C/C++编译技术还要看在2003年的表现。另外，在C/C++连接器 (Linker)方面Borland也宣称将要搭配新一代的C/C++编译器推出新一代的C/C++连接器，提供更聪明、更紧密的最终机器码。
  除了编译器、连接器和C/C++开发工具之外，另外一股发展快速的C/C++势力便是各种C/C++的开放函数库和Framework了。许多的C/C+ +函数库和Framework由于品质良好而且采用开放源码的设计，因此也快速被许多的C/C++程序员使用而盛行于C/C++程序员的领域中，除了早为大多数C/C++程序员广泛使用而享大名的STL之外，其中最著名的当属ACE、Boost和Loki这三个C/C++函数库和Framework了。

C/C++的王牌Framework--ACE
  ACE是一个使用面向对象方式设计的C/C++Framework，主要是提供开发通讯应用软件使用的核心同步处理(concurrency)和分布式设计模式(design patterns)的功能。ACE提供了C++的封装类别(wrapper)和组件，让程序员在许多UNIX操作系统、Win32平台和实时操作系统 (Realtime Operation System)平台开发高效率的系统服务和应用程序。ACE Framework提供了将近150000行的程序代码以及450个左右的类。
  ACE为了分隔Framework的复杂度，采用了层次的架构来设计，下图就是ACE Framework的设计架构图。在ACE Framework的低阶层次中封装了OS的Adapter以及C++的封装类别，以增加ACE Framework在不同平台之间的移植性。而在ACE Framework的高阶层次中，则提供了延伸低阶C++封装类别的能力，以提供可重复使用的分布式组件以及分布式计算中间件。由此可知， ACEFramework的目的是提供一个跨平台的中间件Framework，以便让C/C++的程序员在各种平台中开发高效率的分布式计算应用系统。由于ACE Framework的流行以及广泛被使用，因此已经被许多C/C++程序员视为主流的C/C++Framework。目前也有许多的应用程序使用ACE Framework成功的开发出高品质的分布式软件。例如下图的ACE ORB便是使用ACE Framework实现重要的CORBA规格的实时ORB引擎：TAO。TAO由于使用了ACE Framework，因此也属于一个免费的ORB引擎，从遵照OMG规格的CORBA都能够使用ACE Framework来实现这一点，就可以了解ACEFramework的实用性。读者可以在www.cs.wustl.edu/~schmidt/TAO.html找到TAO的数据。
  另外一个使用ACE Framework实现的著名软件就是JAWS了。JAWS是一个高效率的Adaptive Web Server，下图是JAWS提供的复杂，强大的功能。读者也可以在www.cs.wustl.edu/~jxh/research/找到JAWS的数据。
  由于目前ACE Framework被使用得愈来愈广泛，所以许多C/C++编译器也开始支持ACE Framework。因此新一代的C/C++开发工具必须能够支持ACE Framework，最好还能够提供整合ACE Framework的功能，直接在C/C++开发工具内部支持ACE Framework。

Template和Design Pattern的极美结合：Loki
  Loki是一个愈来愈流行的C/C++类函数库，它是由Andrei Alexandrescu先生开发的，而Andrei也是"Modern C++ Design"一书的作者。事实上，Loki就是因为"Modern C++Design"一书的介绍才逐渐被许多C/C++程序员使用。
  Loki是结合了Design Pattern、Generic Programming和C++语言集成的C++函数库，充分展示了C++语言的优美和威力，并且提供了C++语言使用新的应用。由于Loki的优美和盛行，因此现在许多C/C++编译器和开发工具都以支持Loki为重要的功能之一。

最新的C/C++标准函数库Boost
  Boost是除了ACE和Loki外另一个快速崛起的C/C++标准函数库。目前Boost已经被C/C++Standard's Committee提议成为C/C++标准的核心函数库，由此可见Boost的重要性。目前Boost同样被许多C/C++编译器支持。未来的C/C++ 开发工具应该在核心部分就会支持Boost。未来的C/C++开发工具最应该采用的开放架构应该是在核心部分支持Boost和Loki，并且以开放的 Adapter来整合ACE Framework。

著名的C/C++函数库和Framework的开发厂商Rogue Wave
  数年前使用C/C++开发工具的程序员可能都知道Rogue Wave这家软件厂商，因为RogueWave就是以提供各种专业的C/C++函数库和Framework著名的。在数年前Borland和许多的C/C ++开发工具厂商也都向Rogue Wave授权使用Rogue Wave的C/C++函数库。我记得，数年前在使用C/C++语言时最喜欢使用的函数库也是Rogue Wave出品的产品。当年在C/C++User's Journal、C/C++Report等著名的杂志中，Rogue Wave的产品也是经常可见的。不过随着C/C++的盛况不再，Rogue Wave的声势似乎也不如前了，许多当时Rogue Wave著名的C/C++函数库也随着消失，在前一阵子甚至传出Borland可能并购Rogue Wave的传言。
  但是随着C/C++语言最近的重振声威，Rogue Wave似乎也开始有了比较积极的动作，也推出了许多新的C/C++函数库和Framework，有兴趣的读者可到Rogue Wave的网站上看看。
  不过，Rogue Wave的发展史也见证了C/C+4-语言使用的演变。以前Rogue Wave是以提供高品质的C/C++函数库著名，例如Rogue Wave曾推出过封装各种数据类型运算方法的C/C++函数库，但是在STL等开放C/C++函数库流行之后，Rogue Wave的产品自然走入了历史。另外，Rogue Wave也曾推出过封装ODBC的C/C++类函数库，以提供C/C++程序员在各种平台使用ODBC存取关系数据库的能力，但是随着0DBC成为历史， Rogue Wave这样的产品自然也开始消失了。
  因此，如何为一个已经流行超过10年的语言不断注入新的创意、技术和应用，是每一个C/C++开发厂商都必须面对的事情。

C/C++开发工具的未来
  那么C/C++开发工具的未来是什么？难道在四大C/C++编译器厂商大战之后C/C++开发工具的市场便没有创新了吗？除了Microsoft的VC.NET和Borland的C++Builder之外，Windows C/C++开发工具市场就此沉寂了吗？
  当然不，在前面我们看到了C/C++函数库和Framework的蓬勃发展，相较于目前C/C++开发工具厂商来说是有活力得多了。因此，未来的C/C+ +开发工具必须能够跟上最新的C/C++标准以及各种颇具威力的C/C++ Framework。未来的C/C++开发工具除了本身提供的编译器、集成开发环境和Framework之外，必须采用新的架构设计以提供C/C++程序员整合Third-Party或是Open Source的C/C++ Framework，而无需C/C++程序员辛苦地自己修改这些C/C++ Framework才能够使用。另外，未来的C/C++开发工具必须提供类似Java的高移植性，让C/C++程序员能够在各种平台开发各种C/C++应用系统。除了一般的应用程序之外，在移动设备、低阶系统程序等都必须能够胜任，而不像现在的Windows C/C++开发工具一样，各在不同的应用中占有优势。
  目前，Microsoft的VC++在窗口平台上的C/C++开发工具发展方向已经非常明显，那就是维持原生窗口C/C++开发工具的现状并且往 VC.NET发展。Borland呢？除了BorlandC++Builder 6.0之外，未来Borland的C/C++开发工具将提供什么新的发展呢？在前一阵子Borland已经宣布了未来仍将投入大量的资源研发新一代的 C/C++开发工具，将采用下图的架构提供给程序员最具整合威力的C/C++开发工具。
  从上图中的架构，我们已经可以预知未来的Borland C/C++开发工具将允许程序员高度整合最流行的C/C++ Framework，例如前面讨论的ACE、Boost和Loki等。这是非常重要的，因为未来的Borland C/C++开发工具将提供跨平台/移动设备的能力，而这些C/C++ Framework也大都提供跨平台的功能。如果Borland能够提供完整的整合能力，那么这代表未来的Borland C/C++开发工具不管在什么平台，都能够提供最完整和强劲的功能。
  如果Borland真能推出这种新一代的C/C++开发工具，那么这将是Borland从当初BorlandC/C++3.0以来最具创意的产品，也是最值得程序员期待的C/C++工具。Borland是不是能够遵照承诺推出呢？也许答案在2003年便会揭晓了。

 第十三章 软件科技的发展和Borland的未来

(文章来源：<<Borland传奇>> 电子工业出版社 2004年，作者：李维)

  "Into The Future？"
  在前面的章节中，本书讨论了许多现象和问题。除了Borland本身的发展故事之外，也讨论了一些科技的现状和未来的发展。在Java和.NET平台的竞争以及许多科学技术的发展下，Borland的未来到底会如何呢？Borland又要如何适应才能够持续在信息界竞争、生存下去，进而茁壮成为更大的信息公司呢？在本章中我将提出一些个人的看法。
  除了软件公司的发展之外，我也观察到了一些信息技术的走向。这些信息的发展在未来也都将牵动着开发人员的走向。除了在第10章中讨论的事项之外，我也认为更精致化的程序开发能力、面向对象和Modeling的平民化、Web Service的发展以及.NET平台的普及化都将在2003年开始对于开发人员产生愈来愈深的影响。其中，Web Service和.NET是开发人员无法控制的信息发展潮流。开发人员唯有在了解了它们的趋势之后，及早准备以适应未来的趋势。
  而精致化的程序开发能力、面向对象和Modeling技术的平民化，则是属于比较贴近开发人员的发展，也是开发人员能够掌握和进一步控制的因素，是软件人员必须了解未来继续从事软件开发工作时必须克服和掌控的技术趋势。
  到底这些因素的影响事项是什么呢？为什么它们对于软件人员在未来有很大的影响呢？这些也是本章讨论的重点。

不都是整理和抽丝剥茧吗？
  我在从事信息工作的生涯中使用过数种不同的程序语言、数据库、组件模型以及Framework。面对许多新的技术不断地出现，开发人员似乎陷入了永远学不完新东西的梦魇。不过，如果开发人员仔细回味许多技术的本质，却会发现这些技术其实只是把我们已经了解的东西再以更细致化的方式加以运用，关键在于开发人员是否注意到了这些本质和趋势而已。
  例如，目前在C++中流行得火热的Template、Policy-Based template，在Java、ObjectPascal和C#中当红的接口程序设计，以及各种组件模型和Web Service中的服务接口等，如果我们仔细地咀嚼，会发现许多的东西正是发挥程序员原本就拥有的整理和抽丝剥茧精神，再加以发挥的东西。这怎么说呢？让我们以数个例子来说明读者就容易了解了。
  首先让我们想想为什么会出现数据库这类的产品？很简单，因为由于数据愈来愈多，数据种类也愈来愈繁杂，因此造成了我们需要一种软件产品能够整理这些数据让它们更容易的被我们处理和使用，因此才有了数据库的想法和产品。
  在每一个程序员学习撰写程序代码时，也会发现随着撰写的程序代码愈来愈多，许多的程序代码不断重复出现和被使用，因此很自然的程序员开始使用例程 (routine)/子程序(subroutine)或是过程(procedure)、函数(function)等机制帮助我们进行程序代码整理和抽丝剥茧的工作。
  这些数据和程序代码整理的工作几乎是每一个程序员的求生本能，只是有的程序员只做基本的整理工作，而更聪明的开发人员则对于整理的工作有不同的看法，进而促使了许多延伸软件技术的出现，也开始对软件开发产生了重大的影响。例如，对于原本杂乱的程序代码以数据和程序代码分离的看法而逐渐产生了面向对象的技术，以分离例程/子程序和数据类型为看法的应用则产生了类似C/C++中的template技术，而以函数面对服务的看法，认为开发人员应该面向服务的开发模式则造成了接口程序设计(Interface Programming)的应用热潮。虽然现在这些从程序代码延伸出的技术都独领风骚，在软件开发界中产生了重大的影响和开发模式的改变，但是，如果我们追根究底来观察，这些技术不都是从对程序代码和数据的分析、整理和抽丝剥茧之后，以更精致的方式来处理和开发软件吗？
  因此，本着相同的想法和精神，聪明的开发人员开始脱离单一程序语言的架构而进入了开发出可重复使用的软件组件模型，让不同的程序语言都能够在统一的组件模型中达成团队开发的功效。这个更聪明的整理和抽丝剥茧的想法造就了CORBA、COM/COM+和EJB等组件模型的驱动力。
  除了脱离程序语言之外思考的开发人员外，另外有一些开发人员则再次回头检视本身和他人的程序代码，并且努力搜寻优良和成功程序代码的基因，因此发现了这些优良和成功的程序代码似乎都有着类似的模式和架构，再经过进一步的分析之后终于产生了Design Pattern，这成为目前最重要的软件开发模式和技巧之一。在这之后，这些聪明的开发人员了解到如果能够成功运用Design Pattern，并且把程序设计转变成以服务为目标的方式，将更能够简化、标准化和结合Design Pattern的运用，并且隐藏复杂的实现技巧，这就进而产生了Service Interface Programming的观念和技巧。由此可见，只要开发人员能够发挥细心整理和抽丝剥茧的能力，那么即使无法创造出伟大的新软件工程或是软件技术，但是仍然能够帮助我们增加生产力和软件品质。因此，对于开发人员来说重要的不是无止境地学习层出不穷的各种新技术，而是到底有没有了解这些技术之后代表的观念、思想，以及学习最重要的对于软件开发整理和抽丝剥茧的能力。在我的工作生涯中，一直认为技术终究是会被大多数的人学会的，但是在辛辛苦苦地努力这么多年后，到底我们的思想、眼光和抽丝剥茧的能力是否有所精进呢？如果没有，那么我们永远就像被蒙着眼睛，只能尾随着他人告诉的技术前进，永远找不到自己的方向。
  现在，再让我们以一个C++的例子来证明只要开发人员能够看透程序语言和技术背后代表的真实意义，那么即使是在已经被众人熟知的技术中，仍然能够创造出新的技术和含义。在Andrei Alexandrescu先生所著的"Modem C++Design"一书中，我们再次看到了聪明的开发人员对于程序语言的了解和对于程序代码撰写整理以及抽丝剥茧的惊人能力。Andrei的想法不算复杂，但是却巧妙地运用了对于C++ template深刻的了解而创造出了自己的精彩之作。其实，全书呈现的思维之妙，让读者可以从一开始的小范例就看出如何运用已经广为人知的技巧之后呈现出的不同风貌。
  例如，Andrei想法是以Policy-Based想法为主，以各种不同的准则来提供服务函数，那么通过C++ template的能力，让开发人员能够根据自己的需求来选择需要的Policy和数据类型，结合于C++的template，可以捉供开发人员前所未有的自由度，并且开启了以往函数库开发人员无法想象的挥洒空间。例如，下面的程序代码中提供了三个不同的类别，这三个类别都可以建立指定类别T的对象实例 (Object Instance)，但是，这三个类别各自使用了不同的方式来建立T的对象实例。在这里提供了建立T类别的对象实例的准则Create()方法，但是却允许开发人员自由地根据自己的需求选择要使用那一种方式来建立对象实例。
  由于上面的三个类别提供了相同的Policy(其实，从Service Programming的角度来看，可以说它们都提供了相同的服务)，因此，开发人员可以再自行定义一个consumer类别，并且结合C++的 template功能，让这三个服务类别成为客制化数据类型，再通过template的能力，自由地被开发人员选择使用。例如在下面的程序代码中， WidgetManager
  类别通过template功能可以在编译时期动态决定使用那一个Policy类别作为父代类别，而自动拥有建立T类别的对象实例的能力。
  最后，我们可以再次使用template能力在编译时期由开发人员代入欲建立的T类别的实体类别定义，通过template功能结合Policy服务和各种不同的数据类型。例如，下面的程序代码即指定了使用OpNewCreator这个Policy服务类别，以传统的new操作数来建立Widget类别的对象实例，并且定义成新的客制化类型MywidgetMgr：
  typedef WidgetManager&lt;OpNewCreator&lt;Widget&gt;&gt;MywidgetMgr; 在这个范例中，我们看到了Andrei真正了解了程序语言的机制，并且经过他的思考和抽丝剥茧之后，开创出了以Policy为主的template class library。Andrei的这番思考的确为C++语言开创了新的应用和视野，这正是发挥开发人员聪颖的整理和抽丝剥茧能力的另外一个好典范。
  不过，C++的template功能却只局限于C++程序语言本身，这是因为template是C++语言本身的特性，只有C++编译器提供了强劲支持。所以，C++的template无法在程序语言之外和其他的程序语言合作提供类似组件模型的能力，因为其他的程序语言并不了解template，也不支持 template，这也是为什么Microsoft会以COM来提供不同程序语言之间的整合，EJB则更单纯地只限定使用Java的原因。
  其实在上面讨论的C++ template中，仍然可以通过混合编译时期和执行时期的功能来提供C++在组件模型和其他程序语言或是技术结合的能力，同时又能够使用C++本身强劲的语言机制。例如，我们可以在外部使用XML作为组态文件，以指定我们想要使用的Creator以及想要建立的对象。例如下面的XML内容即指明了和前面相同的Creator：OpNewCreator，以及要建立的对象：Widget：
  而C++可输出一个纯粹的服务接口，类似COM的接口以便和其他组件模型或是程序语言整合：
  最后，在CPPCreator的实体衍生类别中可以通过分析XML组态文件的内容来决定建立何种的Manager：
  上述的机制可以让C/C++语言提升至组件模型和其他的技术整合的层面，又能够仍然使用本身强大的template、Policy-Based template或是template函数库。当然，这里我并不是以讨论C/C++程序语言的技巧为主，不过，上面的程序代码仍然可以进一步使用 dynamic dispatch来改善，成为品质更好的程序代码。
  其实，这些想法和实现机制仍然是在使用整理和抽丝剥茧程序代码的方式来解决问题，只是以更细致的想法重新给予程序语言或是工具新的意义并且运用在日常的开发生活之中，有时候只要脑筋稍为转个弯就能够看到新的应用。
  现在，除了在程序语言层面运用各种整理和抽丝剥茧的技术来增进我们开发的速度和品质之外，许多人已经开始运用相同的想法在建立企业应用系统了。例如，现在许多人已经了解Design Pattern除了在程序语言方面有实质的帮助之外，在企业应用系统的设计方面更有极大的应用价值。而且许多人已经开始整合这方面的Design Pattern，例如Martin Fowler最新著的"Patterns Of Enterprise Application Architecture"一书中便分析和整理了他观察和使用Design Pattern在设计和发展企业应用系统的心得。在这本书中，Martin Fowler也清楚地说明了他只是发挥了整理和抽丝剥茧的原则提供给开发企业应用系统的开发人员参考，许多的Design Pattern并不是他发明的。可见，现在许多的开发人员只是更精炼地观察和整理多年的开发经验，以萃取出更佳的Coding和开发的技巧以及开发惯例。
  而Design Pattern运用在企业应用系统中的功用是能够帮助开发人员更了解整个系统的架构，并且更容易掌握如何分门别类企业应用系统不同层次之间如何的切割和分发，能够营造出体质更为健全的复杂企业应用系统。
  目前，这股重新整理和抽丝剥茧的风气也已经蔓延到各种信息开发领域，从程序语言、组件模型一直到大型应用系统的设计和开发。我认为，下一步将继续进入整个开发流程的领域之中。当软件厂商提供了完整的开发流程工具之后，就开始会有人研究如何在开发流程中再度应用Design Pattern等技术。
  因此在未来，开发人员必须了解Patterns，并且在开发的过程中时时注意软件开发的趋势和使用惯例，不断吸收更多的技巧，以更精致的思想和方式来开发软件，如此一来才能够脱颖而出，在软件开发的生涯中出人头地。

Web Service Works
  SOAP和Web Service从去年开始快速兴起，并开始占据信息整合应用的市场。虽然许多人提出对于SOAP和Web Service执行效率和安全性的质疑，但是，SOAP和Web Service的穿透力、整合力却无庸置疑是极具吸引力的。因此，目前Web Service的各种规格除了蓬勃发展之外，Web Service的应用也的确开始出现在我们的四周。不过，WebService到底应用在哪些方面呢？SOAP和Web Service目前在信息业界使用的情形如何？相信这些都是许多人关心的问题，也是许多人想要知道的答案。
  最近，我被邀请到一家信息机构交流信息技术的心得。主持人告诉我他们现在拥有一个分布区域极为广大的信息系统。每一个区域使用的硬件、操作系统、数据库和开发工具都不同。而且，目前这些系统之间并没有专线连接在一起。现在他们想要整合这些系统，而且希望能够在机构中心向不同的区域查询货物数据并且在机构中心整合查询到的信息。
  这位主持人询问我有没有什么方法可以完成这个信息架构。在详细地讨论之后，我了解到机构中心从各个区域查询的信息都是属于小量数据的查询。由于在每一个不同的区域都有自己的数据库，因此可以通过每一个区域的数据库服务器从大量的数据中撷取查询数据，再把查询到的结果传回机构中心进行简单的整合工作。
  对于这个信息架构，我想最简单的方法就是在每一个区域的服务器上实现一个CORBA服务器，再由CORBA服务器对外提供查询接口。由于CORBA拥有跨平台、数据库和开发语言中立的特点，因此非常适合使用来作为原有专属系统提供对外的标准服务接口。有了CORBA服务器作为服务接口之后，我们可以继续把 CORBA服务转换为标准的WebService，再由机构中心使用SOAP，即可轻易地使用标准机制穿透并且整合原本的异质系统。
  使用Web Service的原因是由于在这个应用中只会有少量的资料查询，因此Web Service绝对可以胜任，而Web Service提供的穿透力和整合力是其他技术难以相比的。对于安全的需求，可以使用HTTPS加上CORBA的安全服务即可提供一定的安全可靠性。原本看起来困难的事情一下子就被Web Service和CORBA联手解决了。这正是一个非常好的Web Service应用范例。
  那么在2002年，Web Service在信息业界应用的情形到底是如何呢？到底有没有信息系统在使用SOAP和Web Service技术呢？其实，我们从各种开发工具都支持Web Service的应用来看，一定是有人已经在使用Web Service了，否则没有必要几乎所有的开发工具都争先恐后地加入对于SOAP和Web Service的支持。
  下图是2002年信息界对于使用Web Service的最后调查结果，从数字中我们可以看到，没有使用Web Service的比率是43.2％，但是超过50％的调查显示Web Service已经或多或少的被应用在信息系统之中了。而这些统计数据也代表了Web Service被实际应用的证明。
  另外一份对于Web Service应用的调查结果如下页所显示。我们可以看到在2003年中Web Service将有更大的使用比率，可见Web Service的应用将会快速地提升。如果我们把两份统计结果以趋势图同时呈现的话，会发现Web Service应用的成长比率几乎不会输给一般的开发工具或是程序语言的成长比率。
  在2003年Web Service除了将愈来愈普及之外，新的Web Service规格也将慢慢完善并且开始被软件厂商实现。除此之外，也开始有信息厂商对Web Service的缺点加以改善推出变形的解决方案。不过千变万变，不变的是在现在信息多元化的时代正显示了我们的确需要Web Service代表的穿透力和整合力。
  许多人当初说Web Service是不实际的技术，从目前的各种迹象和统计数字来看这些人似乎是错了。Web Service的简单化不代表无用，其缓慢也不代表不可用。我们只需要在适当的地方使用适当的技术，Web Service就是一个很好的例子。毕竟当初DonBox在定义SOAP时最原始的想法本就是"简单(Simple)"，不是吗？

面向对象技术的平民化
  "你们是用什么方法来开发系统的？"，"你们使用UML吗？你们在使用面向对象方式开发应用系统时使用所有的UML图形吗？"，"你们遵循RUP来发展软件吗？"，这些问题是我在和一些信息界的朋友聊天时经常询问的问题，因为我也非常想了解UML/RUP和Modeling在业界使用的情形。
  UML和Modeling的需求在三位OO大师多年的提倡并且成立Rational公司开始大卖Rose后，照理说UML和Modeling在信息业界应该是被广泛地使用，不是吗？但是情形似乎并不是如此。
  在我知道的许多案例中，许多公司或是信息机构在购买了Rose之后，要么被供奉起来成为一种先进/时髦的象征，不然就是被使用来作为画图的工具。即使是真地使用UML和Modeling的公司也大都只是使用Rose画画Use Case、Class Diagram和ObjectDiagram，再继续深入得几乎没有。为什么会如此呢？UML已经被证明是非常好的理论、开发方式和沟通语言，Rose也推出了这么多年，为什么UML的普及率仍然非常低呢？为什么许多购买了Rose的公司和机构也没有完全使用Rose的功能呢？这其中一定有一些问题存在。但是，这是什么问题呢？
  就我个人的经验来说，在许多的项目开发之中大概都只有使用到Use Case、ClassDiagram和Object Diagram，最多画画Sequence Diagram，接着就是结合组件模型、开发工具和数据库开始进入开发的阶段，比较注重CBD的开发模型，鲜少使用到其他的UML图形，因此可以说是偏向结合UML和Extreme Programming，以项目时程为最重要的依归，并不强调完全遵照UML和RUP。因此，我也非常想要和其他的朋友交流，了解其他人使用 UML/RUP的情形，或者其他人是如何使用OO技术开发项目的。
  我个人也是从事信息工作的一员。虽然没有什么显著的贡献，但是我对于UML和Rose始终有一份怀疑。当然，这份怀疑并不是指UML和Rose没有用，相反，UML的确对于软件工程有着卓越的贡献。不过我认为UML和Rose之中的许多东西过于繁琐，要实际应用在项目发展之上，除非项目没有时程和资源的限制，就像Rumbaugh自己在GE时从事的实验计划，拥有许多的资源和宽阔的时程，否则，怎么可能有时间和资源把所有的UML图形都画出来呢？至少就我个人的项目生涯来说是从来都不可能的，因为在我个人的信念中项目开发最重要的准则是"On-Time Delivery Of A Working And DecentSystem"，不是UML，不是RUP，更不是任何其他时髦软件技术。
  另外，我一直认为Rose实在算不上好的软件，每一次我使用Rose就有种回到Windows3.1时代的感觉。此外，Rose在绘制UML图形上始终有一些小问题，从版本1开始到现在都没有改善。因此我也曾经开玩笑地说，"Rose是全世界一流的OO分析师配合三流的程序员开发出采的产品"。因此我个人对于UML/RUP一直有着一份怀疑，只是人微言轻，不敢轻易表示对于UML/RUP的质疑。
  不过，在Extreme Programming对于UML/RUP开发模式提出类似的质疑和逐渐分庭抗礼之后，我也在Internet/Intranet上看到愈来愈多对于 UML/RUP的批评以及许多人公开讨论使用UML/RUP失败的原因和检讨。此后，我总算如释重负，因为这些都证明了不单是我个人有疑问，许多人都有相同或是类似的问题。我认为这些批评和质疑对于UML/RUP是一件好事，因为这可以让软件界再次审视UML/RUP不足之处，找出问题的所在并且加以改善，才能够让UML/RUP持续地对软件界和软件工程做出贡献。正由于Extreme Programming对于UML/RUP的挑战，反而可以让我们更清楚地了解什么方法才是最适合的。我个人认为，对于小/中的系统或是项目而言，简易的 UML和ExtremeProgramming是比较适当的，而对于大型的企业应用系统(Enterprise ApplicationSystem)而言，UML和RUP被证明是有效的。
  一直到2003年初听了TogetherSoft的首席科学家(Chief Scientist)Todd Olsen的演讲后，才正式确定了我的想法没有错。连Todd Olsen都认为UML/RUP太过于学术化，对于学术的研究没有问题，但是在实际的应用中则稍显繁杂。开发人员应该在开发工具的辅助下进行适当的修整以找出最"适当"的方式来进行项目或是系统、工具的开发。连Todd Olsen这种经验丰富、软件开发实力又惊人的大师级人物都这么说，我也就放下心来了。看来属于实战型的开发人员，依照武侠书的讲法，应该掌握的是"最具杀人威力的剑法，而不是华丽的招式"。当时我在聆听了Todd Olsen大胆的说法之后不禁大呼过瘾，隐藏在心中多年的质疑终于一挥而去。
  虽然过于拘泥于UML/RUP的开发模型不算是好的方式(或许这对于学术研究是正确的)，但是也没有人完全否认UML/RUP对于软件开发的贡献。事实上 UML是很重要的，因为它可以让开发人员使用同一种语言沟通，也可以很有效地使用Use Case让企业人员和开发人员沟通。但是为什么在Rational推广Rose这么多年来普及的成效仍然有限呢？我个人认为有如下的原因：
  ■  价格昂贵，难以普及■  只锁定金字塔顶端的开发人员■  过于强调完整的UML/RUP开发模式■  没有和开发工具整合在一起，以打入一般的开发人员群体由于Rose采取高价的策略，因此虽然为Rational赚进了大把的钞票，但是也让UML/RUP 和Rose的普及率难以大幅地扩展。想想10年前的Client/Server技术也是在
  PowerBuilder、Gupta等采取高价措施而难以快速普及，一直要到VB和Delphi等大众化开发工具提供了Client/Server功能之后，才让Client/Server快速为大多数的软件人员视Client/Server技术为理所当然的基本技巧。在 PowerBuilder/Gupta错失了占据Client/Server的庞大市场之后，再也无法成为Client/Server的领导厂商。
  同样地，如果Rational一直为Rose采取高价，只锁定高阶开发人员市场的策略，那么Rose很可能会在其他的竞争对手推出更好的UML产品之后快速流失市场，事实上这正是Rational在2002年面临的困境，因为Rose不但遭受许多UML小厂商的竞争，更被其最大的竞争对手 TogetherSoft打得难以招架，要不是Rational还有3位OO大师的名号在力撑，Rose早就被TogetherJ或是 TogetherSoft的Control Center打得落花流水了。从最近4年TogetherSoft可怕的成长速度可以看出来，Rational早已被TogetherSoft逼得寝食难安了。
  在Borland并购了TogetherSoft之后，Rational将面对更为艰难的状况。一旦Borland成功地在其的开发工具中整合 TogetherSoft的产品，那么将可能会像当初的Client/Server技术一样，可通过提供更平易近人的UML工具而快速让UML为大多数的开发人员接受而使用。再加上如果Borland以合理的价格提供UML和开发工具，那么将可以让UML打入金字塔中/低阶的开发市场，快速鲸吞Rose的市场。到时Rose在UML/Modeling产品本身不如TogetherSoft之下，再加上Borland开发工具的强力支援，Rational的大势不妙。因此这是为什么当Borland宣布并购TogetherSoft之后受伤最深的公司就是Rational，而Rational也立刻声明中断和Borland的合作的原因。最后在Rational眼看后势欠佳，再加上IBM提出动人的并购条件之后便立刻接受了IBM的提议。
  根据2002年的信息调查显示，大多数的开发人员已经视Modeling工具为相当重要的工具。
  而且目前使用Modeling工具的开发人员也相对地满意于Modeling工具提供的功能。因此，如果Modeling工具能够再和开发工具紧密地结合，那么Modeling未来的发展将更为快速。
  目前在所有和开发相关的工具中，Modeling和设计工具已经占据了相当重要的地位。根据2002年调查的结果显示，设计和Modeling工具已经分别占据了所有开发相关工具的第2和第8名，而且还呈现持续上升的状态。
  由此可见，开发人员已经愈来愈重视设计和Modeling工具。在Borland并购TogetherSoft之后，我认为Borland会以较为合理的价格提供整合Modeling和开发工具的软件包，快速把UML技术打入一般开发人员的市场，并且将会正式触发使用UML和Modeling功能成为开发人员的核心基本技巧，就像数年前Client/Server技术对于开发人员一样。因此，我们可以发现下面图形呈现的还是去年以前开发人员拥有的技术状况。开发人员的核心技术只需要拥有程序语言、数据结构和Algorithm即可。
  但是从2003年开始，一旦Borland或是IBM推出整合Modeling工具和开发工具的新一代软件之后，面向对象、Modeling和 Design Pattern等技术将被压缩到开发人员的核心基本技术之中。这代表未来的开发人员必须熟知面向对象、Modeling和Design Pattern等技术，再也无法逃避学习这些重要的软件技巧。
  因此，我们可以说信息公司的合并不但影响这些软件公司之间的竞争，也会对开发人员产生影响。在面向对象、Modeling和Design Pattern等技术成为开发人员的核心技能之后，当然可以增加软件开发的速度和可靠度，这对于整个软件产业而言是正面的结果。对于像Borland或是 IBM等公司，由于让UML和Modeling技巧和产品成为一般开发人员必须拥有的技巧和使用的产品之后，也可以通过更大量的市场来弥补产品价格下滑的损失。一旦UML/Modeling技术大众化和产品平价化之后，软件公司反而可以拥有更多的收入。
  面向对象和Modeling平价化之后便会开始进入开发人员的生活之中，也会开始影响我们开发软件的方式和流程。这两者会像从前的其他技术，例如 Client/Server、数据存取和Web等，慢慢成为几乎每一个开发人员必备的技术。然而不同的是，面向对象和Modeling对于我们的思考模式却有更大的影响和改变，因此造成的影响也将远比从前的技术更为深远。因为除了面向对象和Modeling的思想和开发流程之外，伴随着它们而来的将是更多的软件工程和软件技术。
  不过对于开发人员来说这实在是一条辛苦的不归路，学习的道路不但没有尽头，沿途还充满了艰辛。软件开发工作真是个辛苦的行业，不是吗？不过反过来想，软件开发生涯也将是充实、满载而归的路途，不是吗？

准备迎接.NET时代的来临
  2002年是.NET初临的时代。虽然.NET的初鸣并没有给人太亮眼的表现，但是同七八年前Java初次展现于舞台上时相比较，.NET的表现并不逊色，甚至比当年的Java表现得更好。
  在2003年，Microsoft更准备推出新版的.NET、.NET Server以及新的.NET开发工具，而且大部份的调查也都指出.NET将开始在2003年起飞。面对Microsoft一连串强势的动作，我们其实可以预见.NET也即将更为活跃和更有影响力。其实我也很想了解.NET在2002年到底表现得如何？除了市场上许多的.NET书籍、文章之外，我也在业界和许多朋友讨论以及询问2002年.NET在信息界使用的状况。我得到的结果都是在评估.NET之中，实际使用.NET开发的产品还不多，但是 ASP.NET被使用的情形则是令人惊讶的快速。我已经发现许多的网站开始使用ASP.NET来开发，可见.NET和当初的Java一样，是从 Internet/Intranet开始入侵日常的信息应用。
  最近一份.NET的调查报告终于把.NET在2002年使用的粗略状况呈现出来，显示出.NET的确已经有了初步的成果，虽然也许没有达到 Microsoft的期望，但是也有不错的成绩。下图是ASP.NET在这份调查中的结果，读者可以看到，已经使用和准备使用ASP.NET的比率已经超过50％，而且已经有18.9％的软件人员在使用ASP.NET开发Web应用系统，这对于推出才1年的技术来说是非常惊人的，也可以说ASP.NET是非常成功的。而下一份图形则显示出开发人员对于Microsoft .NET Server的使用情形。从数字结果可以看到.NET Server的接受度也非常高，也有超过50％的接受度。可见在Microsoft推出下一代的.NET操作系统之后市场反应也会非常的正面。
  从上面的两个统计结果来看，.NET已经比我们想象的更快地进入实际的应用领域中。在2003年看来准备在Microsoft Windows平台讨生活的开发人员的确是开始需要学习.NET了，因为很可能从2004年开始我们便将看到Windows平台又将进入世代交替的现象。

Borland的未来
  Borland正站在十字路口上，面对未来的方向。数年前Borland错失了开发消费型软件的契机，以致无法持续成长为更为强大的软件公司。看着 Borland从2000年开始一连串的发展以及在2002年完成的并购动作，我们可以看到Borland已经选择了另外一条道路，那就是全力往企业市场前进。
  企业市场一向是获利丰富的市场区块，这也是为什么Microsoft在称霸了客户端市场之后急于切入的市场。不过企业市场也是更为危险的市场，因为在这个市场中的竞争对手不但更大、更强壮，而且竞争的规模也远超过一般的软件市场。这也是为什么在这个市场区块中的竞争公司几乎都是数一数二的公司，例如 IBM、SUN、HP和Microsoft等。Borland如何同这些资源丰富的厂商竞争，对于Borland的管理阶层将是非常严酷的考验。
  不过，这似乎是不得不走的路，因为Borland传统的开发工具市场虽然在持续成长，但是传统开发工具的价格却不断下滑。例如当年Borland C/C++3.1的价格是一套799美金，现在的C++Builder Professional的功能比当年的Borland C/C++3.1多了数倍的功能，但是价格现在却只有399美金。这是许多信息产品相同的命运。Borland必须想办法扩充其他的市场，否则，只能像许多的开发工具厂商一样等着成为历史。既然数年前Borland错失了像Symantec成功地打入消费型市场的机会，因此，进入企业市场似乎是 Borland无可避免的道路。
  问题是Borland如何在企业市场以小搏大、对抗世界一级的信息大厂呢？原本这样的情势实在不怎么看好，没有想到在2000到2002年，世界历经了全球的不景气，许多信息厂、甚至包括许多一级的信息大厂例如HP、Rational、IONA等都面临了前所未有的严酷考验，不是元气大伤，就是被并购消失于历史之中。反而Borland通过公司有史以来最聪明的并购，不但成功地取得了关键技术和产品，更重要的是，Borland在顿时之间取得了一个绝佳的地位和制高点，拥有其他厂商所没有的完整产品线。这让Borland进可攻，有机会成为一流的软件大厂，重回世界一级的软件信息公司。也可让 Borland退可守，成为小而美的独立软件公司，继续下一个10年的经营，甚至能够以最好的价值和其他的软件公司合并成为更大的软件信息公司。这也是为什么最近一直有传言称Microsoft、BEA、IBM和Oracle都在重新审视Borland的价值，并且重新评估Borland这位突然之间实力大增的竞争对手。
  当然世事有得便有失。Borland在极短的时间之内取得许多的公司、技术、产品和企业文化，如何整合这些对于Borland来说也是一个挑战。在下一章中，我也会提出一些Borland面临的问题的个人看法。不过从Borland的走向来看，不管如何，势必需要面对和克服这些挑战和问题才能够持续在软件产业中竞争下去。我个人认为，Borland必须赶快在下面的事项中取得领先的地位才能够拥有高度的竞争力，并且顺利地面对其他的竞争对手。

提供全方位的开发工具
  既然单靠开发工具已经无法在现在的软件竞争中取得一定的优势，那么Borland必须发挥技术优势，并且整合所有的产品以便在Java和.NET平台提供全方位的开发工具。目前，Borland已经形成了完整的软件应用供应链。我预见Borland除了会在不久的将来提供整合性的开发工具产品之外，应该会持续在测试工具领域取得关键技术和产品，以便形成更强劲的产品线。Borland最近推出的OptimizeIt ServerTrace便是向这个方向努力的一个很好的例子。
  为什么？因为在日后开发工具日趋整合之后，整体的测试工具便显得重要了，因为在整合的开发工具中牵涉到的技术或是组件模型将会非常复杂，而传统的测试工具已经无法处理这些复杂的应用。这是为什么目前在测试工具市场能够同时存在多种用途的测试产品，而且由于测试工具市场快速地成长，因此，目前这个市场的利润相对的比开发工具好得多，例如出品LoadRunner的Mercury公司便非常成功而且成长得非常迅速。因此当大型软件公司开始注意到这类产品的重要性以及相对的价值之后，势必想要进入这个市场。而Borland在拥有了分析/设计、Modeling、开发工具、基础测试工具和组件模型以及分发平台之后，补强在测试领域的工具便很自然地成为下一步了。一旦在测试市场拥有强劲的技术和产品，Borland的实力将更为强大，同时可通过全面、整合性的技术和产品而保持合理的利润，以提供持续成长的推动力。

提升开发工具的价值
  当开发工具的价格不断下滑之后，Borland面对核心产品市场的趋势应该如何处理呢？这并不难解决。既然开发工具已经逐渐成为大众化的产品，高价的入门开发工具时代已经不可能再回来，那么Borland可利用产品区隔来增加这类产品线的收入，而这正是Borland在最近几年采用的策略。所谓开发工具产品区隔，是指在原有的产品线中提供更为高阶的产品，以吸引金字塔顶端的软件人员。例如Delphi原本提供三个不同的产品线：Personal、 Professional和Enterprise。到了Delphi 6之后开始加入Architect和Studio的版本，以便增加产品的附加价值，吸引资深的Delphi开发人员使用这些高阶产品，JBuilder终究也一样会采用这种策略。否则，世界上将仅仅Microsoft能够以不惜血本地大量抛售开发工具以便维护其Windows平台的利润，而任何软件公司都需要一定的利润来持续经营的。

进入Run-Time市场
  请读者现在想想，在软件产业中除了像Microsoft是靠大量的消费型软件大赚其钱之外，其他最赚钱的软件公司是靠什么种类的软件在赚钱呢？答案便是靠所谓的Run-Time软件赚钱。什么是Run-Time软件呢？让我指出几个例子读者马上就了解了。例如Oracle最赚钱的产品Oracle数据库就是属于Run-Time软件，IBM和BEA的EJB服务器也是属于Run-Time软件。Run-Time软件拥有大量使用、分发授权的特性，因此拥有相当良好的获利水准，甚至能够和消费型软件并驾齐驱，一种以大量取胜，一种以价值取胜。Run-Time软件一直是Borland想要拥有和进入的市场。从当初并购Visigenic和Entera开始，Borland就有这种想法。只是当初Borland的产品尚不够齐全，管理阶层也没有经验，因此一直不知如何进入这种市场。现在Borland产品线已经相当齐全，管理阶层也有相当大的雄心，因此，这是为什么Borland一直坚持持续开发CORBA和 EJB服务器的原因。如果Borland能够在Run-Time软件市场成功，又能够通过InterBase数据库进入嵌入式数据库市场，再通过整合开发工具大军横扫市场，那么，我可预见Borland将可快速重返全世界前10大的软件公司，恢复昔日的光彩和雄风。

结论
  2003年对于Borland是重要的一年，因为Borland在整合了许多的公司之后如何在2003年推出新一代的产品，对于Borland的管理阶层以及R&amp;D都是一项考验。此外，随着.NET的脚步不断逼近，Borland也必须尽快推出.NET之下的产品。许多人对于 Borland如何在.NET下继续在开发工具市场竞争充满了期望、疑问和困惑。不过，随着Borland取得了Modeling、分析、测试和分发技术 /产品之后，Borland的确可以在.NET下推出Microsoft无法提供的开发工具和解决方案。我个人也非常期待Borland能够尽早推出. NET下完整的产品线。如此一来，Borland不单是以开发工具和Visual Studio.NET或是其他.NET开发工具厂商竞争，还将提供更为全面的低、中、高产品线来竞争。这正可突显Borland的不同。而且 Borland将可再把竞争门槛往上提升，象征新一代Borland的竞争力。Borland从80年代率先推出In-Memory开发工具，90年代推出可视化集成开发环境开发工具，到了2000年之后，如果又能在.NET下率先推出新世代的整合性开发工具，那么即代表Borland又将再次改写开发工具的意义，持续下一个10年的竞争领先地位。Borland是否能像凤凰一样浴火重生、并且再次展翅飞翔呢？
  其实，我认为2003年对于BEA和IBM来说也将是分出胜负的一年。如果BEA无法在2003年增加WebLogic的竞争力，那么IBM的 WebSphere将在开发工具和Modeling工具的助阵下逐渐向WebLogic攻城略地，蚕食WebLogic的市场占有率。随着HP淡出EJB 服务器市场，SUN的iPlanet无法在市场上取得优势，看来IBM在Java阵营的影响力将会愈来愈大。这对于SUN是一项警讯，因为现在SUN除了还控制Java语言、JDK和EJB的规范之外，在Java开发工具、EJB服务器市场节节败退。现在，甚至在Web Service规范、Web开发规范等方面也都沦陷于IBM/Microsoft和Apache，SUN在Java各方面的势力真是日渐式微。
  而目前看来处于真空的.NET市场也即将出现变化。一旦.NET势力兴起，必将冲击Java的市场。那么对于许多Java厂商和EJB厂商会发生什么影响呢？.NET对于企业信息应用会产生多大的影响力？.NET何时将对Java产生穿透力？这些影响和变化也都将从2003年开始发酵。
  我认为2003到2004年对于信息界来说将会发生数件重大的事件，信息势力也将会被重新划分而产生新的主控力量和领导厂商。我们就等待着精彩好戏的上演吧，2003/2004这两年绝对不会是寂寞的年份。

 
  第十四章 传奇的篇章仍将继续！

(文章来源：<<Borland传奇>> 电子工业出版社 2004年，作者：李维)

  对于Borland来说，2001/2002年实在是很奇怪的时期。因为在这段时间里，Borland无畏于全世界经济的不景气，仍然持续地获利和稳定地成长。和许多1T公司的不断亏损和裁员相比，Borland的表现实在是非常的亮丽。究其原因，这主要与Borland慢慢建立起来的、有史以来最有效率的销售团队有非常大的关系。假如Borland没有这支专业的销售团队，那肯定也会和其它IT公司一样的局面：亏损和裁员。
  也许是天佑Borland吧，在Borland引入专业的销售团队之后，原本积弱不振的Marketing也开始逐渐上轨道了。不过我认为Borland仍然有隐忧，那就是本身产品线拉得太长、投入.NET的时间太晚、而业界的Java市场即将进入成熟期。

过长的产品线？
  如果花点时间研究Borland的产品，那读者可能会发现Borland实在拥有太多的产品线。从以前的4个开发工具Delphi、C++ Builder、JBuilder、Kylix，到数据库，再到CORBA、EJB服务器等，Borland拥有的产品超过了10个以上。面对这么多的产品线，仅研发费用一项就已很高，如何能够照顾好这么多的产品？这是好的现象吗？
  看看许多大型的软件公司，其赚钱的产品可能只有三、四个。例如Norton在退出开发工具市场之后，凭借着专心开发企业应用软件而一再成长，目前的规模早已超过Borland许多。Norton靠Norton Anti-Virus产品打入消费市场，让Norton Anti-Virus成为广受欢迎的"消费型软件"之后便一飞冲天。再通过Norton Anti-Virus衍生出其他相关的软件，进而扩大公司营业额，成为大型的软件公司。又例如Oracle仅靠数据库就成为第2大的软件公司，再衍生出 Oracle Finance、Oracle ERP等，这些企业软件也都是以Oracle数据库为核心发展出来的。成功的软件公司大都拥有一两个"消费型软件"来支撑公司的发展，但是Borland 呢？
  Borland目前提供了十几个产品，并且不同产品线的收入都差不多，没有一两个核心赚钱的产品，自然也就没有其他衍生的产品出现，因此Borland必须通过不断地推出新版本的工具和产品来维持收入，这实在是很辛苦的事情。因为这代表Borland需要不断地投入巨额的研发才能够推出产品，而且只能赚到少许的利润，这样当然成长得很辛苦了。
  其实这就是我在前面章节所说的，Borland在SideKick之后就一直没有办法开发出"消费型软件"的问题。当然软件公司可以采取不同的发展策略，例如软件公司也可以走向企业市场，因为企业市场的利润一向比PC市场来得大。这正是Borland目前想做的，因此Borland才会并购相关的软件公司以壮大其进入企业市场的本钱。不过我仍然认为Borland在开发工具市场拥有大量的使用者，除了进入企业市场的选择之外，Borland还是应该在PC 市场推出"消费型软件"。如此一来上下夹攻，不但可以精简产品线，更可以获取更多的利润以支撑更精良的产品研发。
  现在的Borland应该做的是重新规划产品线，去芜存菁，好好地发展产品，让每一个产品都有独特的定位以及合理的投资回报。这样不但可以集中研发资源，也可以提供给使用者品质更好的产品。好在目前Borland似乎已经注意到这个现象，开始收敛过多的产品线，清楚地为每一个产品定位市场。虽然 Borland到了现在才了解了产品线的问题，但是"亡羊补牢，犹为未晚"，希望Borland在2003年以及未来的日子中能够恰当地分配研发资源，奸好地推出精炼的产品，而不要一味地求多。

进入.NET的时机
  1999年底，在和一位供职于Microsoft的好友吃饭时，他很好奇地问我为什么Borland到了当时还不加入Microsoft .NET的支持开发厂商之中，以便开始发展.NET的产品。听了之后，我也觉得奇怪，为什么Borland在支持.NET方面进入得这么晚呢？
  这是有原因的，当时Borland内部对是否要支持.NET争论不休。许多人认为，在Windows平台中Borland已经和Microsoft竞争了这么久，非常清楚在Microsoft主控的平台中要和Microsoft竞争不但非常辛苦而且不易获利，因此这些人便反对继续支持Microsoft的平台，他们认为Borland应该在其他平台找寻出路。
  而另一派的人则认为，Microsoft虽然利用垄断进行不公平的竞争，可Microsoft的平台仍然是最大的平台。虽然和Microsoft竞争相当吃力，但是Borland已经这样生存了十几年，已经了解如何和Microsoft竞争。如果放弃Microsoft的平台，那不但一点都吃不到，而且其他平台的占有率太小，即使Borland有办法在其他平台占有大量的市场，但是相加相乘之后，说不定还是比在Microsoft平台上的占有率小。
  就在这两派争论不休之际，刚好2000年Linux开始吸引众人的目光，因此当时的新CEODale便下令全面转进Linux，准备放弃.NET平台。就是这个决定，让Borland在.NET方面晚了将近2年才投入。
  Borland在.NET平台进入的时机是晚了一点，但这是好是坏目前并不清楚。有人认为，晚投入.NET是件好事，因为Borland正好先让 Microsoft推广.NET，到了2003年.NET逐渐起飞之后，Borland刚好推出.NET下的开发工具和产品。但是也有人认为， Borland太晚投入.NET已经造成了影响，因为在2002年已经有许多程序员希望学习.NET，需要NET开发工具来使用，而Borland却错过了这一波的需求。
  Borland在.NET是不是投入太晚呢？以我的看法，确实是晚了一点，因为2002年我也在为苦无Borland的.NET开发工具使用而伤脑筋，我想这个感觉应该是许多Borland程序员都感同身受的。但是Borland晚一点投入.NET有没有什么严重的影响呢？我想时机应该还不是最重要的问题，让我们回想以往Borland在Windows上推出开发工具的时间，同样也是晚了Microsoft一到两年，但这是没有办法的事情，因为系统的主控权是在Microsoft手中。不过在以往的记录中，Borland仍然能够力挽狂澜，凭借好的工具来争取人心。因此我认为，既然已经晚了一些时机，那么Borland就应该更好地发展.NET下的开发工具和产品，以品质和功能来吸引程序员，这才是最重要的。

Java市场即将进入成熟期
  不光是Borland，对于许多软件公司而言，目前都是非常辛苦的时期。2002年10月份左右，SUN的iPlanet副总裁发表了"如果EJB服务器厂商再不停止流血竞争，那么EJB服务器市场将进入微利时代"的言论。当然，这位副总裁的目的是希望EJB厂商不要再降价竞争或是提供一大堆的Open Source EJB服务器，以避免扼杀SUN好不容易经营起来的企业市场。不过，iPlanet副总裁显然忘记了SUN在EJB服务器市场上并没有太大的占有率，而 EJB服务器的价格之所以会不断地下滑，是因为IBM和BEA的EJB服务器占有率已经达到经济规模，因此，他们可以使用降价的方式来追杀其他的EJB服务器厂商以持续增加市场占有率。而EJB服务器的竞争从强调EJB核心功能、附加服务，到现在的以价格来竞争，代表的就是EJB服务器市场已经进入成熟的市场，无法获取高额的利润，因此只能以量来弥补价差。
  除了EJB服务器市场之外，Java开发工具的竞争大概也已经分出了高下。无法继续参与竞争的Java开发工具将走向Open Source的不归路，Java开发工具的胜利者也必须面对价格下滑的局势。因此，市场领导者必须再次在市场寻求更大的占有率，这也将引发Java开发工具第2次的争夺战。看看目前的胜利者，我们就可以大概知道下一波的竞争态势。Borland在取得了TogetherSoft之后，势必会在 JBuilder中整合TogetherJ的功能，把JBuilder再往上提升，形成一个同时提供UML和Extreme Programming的全能Java开发工具。而IBM取得了Rational之后，也一定会把Rational整合到WSAD之中。不过这还不是最可怕的，如果IBM决定采用把WSAD和Rational半买半送的策略来攻击Java开发工具市场、以掩护WebSphere击倒最后的敌手 WebLogic，那么不但Java开发工具将有一番浴血战，EJB服务器市场也将进入烽火连天的场面。对于Oracle的JDeveloper来说，势将面对更为强劲的对手--JBuilder和WSAD。虽然Oracle也开始在JDeveloper中加入UML分析和设计的功能，但是不管 Oracle怎么做，大概都无法和TogetherJ及Rational竞争。Oracle的JDeveloper最后只能像以前的Oracle Developer2000一样送给Oracle的用户，或是Oracle决定展开价格战，以极低的价格来响应JBuilder和WSAD。如果 Oracle采取这个策略，那么受伤的应该是JBuilder，因为Oracle绝对不会打击到资源更为雄厚的IBM。
  因此，在Java市场即将进入成熟期之际，Borland必须再次提升JBuilder的价值才能够持续拥有成长的空间、并且推出新的Java工具以刺激市场需求。否则，在JBuilder之后，Borland又有什么工具或产品能够像当初JBuilder接下Delphi的棒子时那样持续地往前冲刺呢？
  软件产业即将进入各拥山头的竞争模式？在即将完成本书时，我知晓了一个令人遗憾的消息，那就是在Delphi Third-Party业中享有盛名的TurboPower公司宣布退出零售市场，并且把许多的产品开放成OpenSource。这实在令人惊讶，因为 TurboPower公司出品的软件组件和软件产品都非常精良，是许多Delphi/C++Builder程序员都在使用的，现在居然连 TurboPower公司都无法继续经营下去，那这代表着什么呢？
  其实，就在TurboPower宣布退出市场之后，另外一家著名的软件公司DeveloperExpress也很快地发表了 DeveloperExpress目前经营良好、未来将持续开发VCL/CLX和.NET下的软件组件的消息。DeveloperExpress的这个动作是希望使用者不要受到TurboPower负面消息的影响，并且想进一步吸引TurboPower的使用者能够转而使用 DeveloperExpress公司的产品。为什么一个极富盛名的软件公司都无法继续生存下去呢？让我们看看其他Third-Party软件公司，也许就可以一叶知秋了。
  目前，所有的开发工具都围绕着许多的Third-Party软件厂商提供各种不同功能的软件组件，这就是所谓的软件组件市场。软件组件市场的泛滥应该起源于数年前的Microsoft VBX，由于当时Visual Basic能够开发的功能有限，因此Microsoft定义了VBX规格，让其他软件厂商能够据此开发VBX组件以弥补VB功能的不足，这造就了VBX市场，许多小软件公司便凭借着创意和实力开发出各种VBX让VB用户使用。由于大多数的VBX都是使用C/C++开发的，因此稍后VBX也成为C/C++开发工具使用的软件组件。Delphi成功地成为第2大RAD工具，这为Third-Party市场带来了巨大的商机。特别是Delphi的VCL Framework采用开放源码的方式，让Third-Party厂商得以快速而且安全地为Delphi开发软件组件，因此各种Third-Party开发的VCL组件很快地出现在市场上。Delphi Third-Party软件组件的市场几乎是VB的好几倍，而VCL组件也在Delphi 3到Delphi 5之间成为全球最为兴盛的软件组件市场。
  Java在定义了JavaBean规格之后也带动了Third-Party的JavaBean组件市场。但是由于Java在客户端应用市场已经输给了 Microsoft，因此Java开始退居中介端、伺服端和Web方面的应用，这造成了以客户端功能和GUI为主的Third-Party JavaBean组件无法拥有经济规模的市场量，也因此一直无法像VCL组件市场一样的蓬勃发展。
  Microsoft的.NET推出之后，虽然.NET组件架构吸引了Third-Party软件厂商为.NET开发软件组件，但由于.NET目前在萌芽阶段，.NET的软件组件需求暂时没有太大的市场，这让一些已经提供.NET软件组件的厂商苦无成长的机会。更何况如果.NET也像Java一样以中介端、伺服端和Web方面的应用为主，那.NET组件市场可能也会像Java的JavaBean市场一样，无法大幅地成长。
  Third-Party组件市场的萎缩代表着软件竞争的日趋激烈，唯有提供多样化产品或是拥有优势的软件公司才能够生存。目前许多VCL组件厂商已经停止再开发新版本的VCL组件，这可以想像这个市场已经逐渐走入后成熟期。Third Party组件市场唯有在新一代的开发工具的开放架构下才可能有回春的一日。
  2002年12月底，InfoWeek报道了IBM并购Rational的消息，并且分析说以后将是软件大厂相互竞争的时代，以往为数众多的中型软件厂商将会日趋减少。同时，InfoWeek也指出，以后开发工具的软件市场将形成3大软件公司竞争的局面，这三家软件公司分别是IBM、Microsoft和 Borland。从这个报道我们可以知道，在2002年一连串的并购之后，关键的开发工具市场已经发生了质变，Borland通过一连串的策略并购后已经被软件界提升到能够和IBM、Microsoft相提并论的地位。这个现象就如我的好友李匡正先生说的，软件行业虽然只发展了数千年，但是软件行业的发展，终会像发展了上百年的汽车工业一样，只剩下少数的大厂，而且这些软件大厂将从开发工具、应用程序、服务器一直到分析、整合软件一应俱全。

软件行业真得会逐渐进入各拥山头的竞争模式吗？
  能够再次和IBM、Microsoft并驾齐驱，这是Borland一直梦想的事情，也是Borland在低迷了十几年之后另外一次重返软件大厂之列的大好良机。问题是在此之前，又会有哪一家目前台面上的软件公司会倒下、成为另外一个牺牲品呢？Borland能够把握这次契机，重造数年前营收规模 500Million美金、或是营业额更大的软件公司吗？

但是传奇的故事仍将继续
  在我撰写本书时，时间已进入到2003年。对于许多软件公司来说，2003年都将是严峻而且即将见分晓的时代，因为.NET在2003将开始起飞，开始对 Java产生更多的影响，Java和.NET这两个软件平台之争将牵动更多软件公司未来的发展。对于Borland来说，努力形成的软件供应链是否能够在两大平台下杀出一条血路？Borland RAD部门几乎倾全力打造的.NET产品Galileo是否仍然能够掳获开发者的人心？如何在Microsoft主导的.NET平台和Visual Studio.NET竞争？Borland在庆祝成立20年之际是否仍然能够在未来拥有一席之地？这都将牵动着Borland未来的命运。
  我并不能预测未来。不管Borland在2003年推出的产品是否能够成功地带领Borland走向下一个繁荣的10年，Borland以小搏大，分别在 Java和.NET平台和世界一级软件大厂竞争的勇气已经值得佩服了。在许多比Borland更大的软件厂商纷纷在这场激烈的竞争中败下阵来之际， Borland却靠着坚强的技术能力和创意十足的产品屹立不倒。在过去十几年中，Borland和Microsoft之间高潮不断的竞争好戏又将在 2003年再次上演。只是过去竞争者众，如今却只剩下Borland和Microsoft。2003年巅峰之战的结果将在以后的岁月中揭晓，不管是谁胜出，Borland已经在撰写.NET的传奇故事。也许数年之后，还会有人把Borland发展.NET产品的内部秘密以及在.NET平台奋斗的故事再次揭露于世吧。

附录：Borland大事记

(文章来源：<<Borland传奇>> 电子工业出版社 2004年，作者：李维)

  1983.5.2    Philippe Kahn和Anders Hejlsberg在美国Scott Valley共同成立Borland International公司。同年11月，发布Turbo Pascal，Borland一举成名。

  1984        发布内存常驻工具软件SideKick，成功打入消费软件市场。

  1985        发布Borland第一个，也是最后一个Basic开发工具产品：Turbo Basic。从Ansa公司购得Paradox。

  1986        发布Turbo Prolog。

  1987        发布Turbo C 1.0，提供C语言开发集成环境工具。Turbo Pascal 4.0也在这一年推出。

  1989        在购入Ansa公司(1987年)后，推出Paradox 3.0。

  1990        在Turbo C基础上推出C++开发工具Turbo C/C++。该产品也被称为Borland C/C++。

  1991        购入Ashton-Tate公司，获得dBase。发布电子表格软件Quattro Pro。该软件生不逢时，在与MS Excel、Lotusl-2-3残酷竞争之后，最后败给Excel，被Novell收购。

  1992        发布Borland C/C++3.0。这是第一个基于Windows的C++集成编程环境软件。在Borland C/C++3.1中加入了OWL作为核心。兼并Ashton-Tate公司，推出dBase 1.0。同时也取得真正的RDBMS——InterBase。

  1993        匆匆推出旨在与Visual C++对抗的Borland C++4.0。该版本尽管有不少创新，但最终被证明是失败的。发布DOS版本的dBase-IV 2.0，并被证明是可靠的数据库产品。

  1994        发布dBase for Windows 5.0。虽然承袭dbase名号，但其核心却是WordTech公司的Aragon for Windows。Borland在Comdex上了解到Aragon for Windows后，通过并购获取了这项技术。而真正的dBase只留下调试器于dBase 5.0中。在面临C/C++战场三面夹击的情况下，推出以OCF技术支持OLE的Borland C++4.5。此役之后，Microsoft占据C/C++市场半壁江山，而Borland的市场占有率却滑落到30％，开始走下坡路。

  1995        Philippe Kahn因经营不善辞去CEO一职，但继续留任董事会成员。CEO由Gary Wetsel接任。而Philippe Kahn则由于产品理念分歧的缘故，自己开办Starfish Software公司，致力发展SideKick等应用软件。后Starfish在无线通讯等领域颇有建树，并最终被Motorola以数千万美金的高价收购。同年情人节发布Delphi 1.0。该产品一炮而红，成为扭转Borland命运的转折点，也成为众多Delphi开发者的"初恋情人"。

  1995        发布品质最好的Paradox For Windows 7.0。一年后，Paradox被卖给Corel公司。同年11月，由于无法忍受Philippe Kahn对Borland的一再挖角，董事会决定将其逐出公司。购入中间件Entera技术，准备进军大型的基于UNIX平台的软件市场。

  1997        发布Delphi 3.0。该版本较好地平衡了COM/DCOM支持和分布式多层架构，并成为全球热卖的产品。发布C++Builder 1.0。尽管Borland并没有作太多的市场推销活动，但该工具推出之后仍广受好评，被誉为"C++开发者天堂"。C++开发者终于可以和Delphi 开发者一样，通过RAD的方式进行编程。Borland委托Dr. Niklaus Worth研究小组开发出效率优良的Java JIT编译器，随后发布Borland第一个Java工具：Open JBuilder 1.0，但市场反应不如预期。并购Visigenic Software公司，取得CORBA技术，并很快据此开发出VisiBroker。通过与Netscape的合作，成功地向大众展示该技术。发布 dBase 7.0。产品虽好，奈何时势不再。

  1998        宣布公司更名为Inprise，希望籍此表达Integrating the Enterprise的公司发展目标理念。改名行动以及"打造行销导向Borland"的计划最终都一败涂地。发布匆匆研发的Delphi 4.0，在市场遭到惨败。Delbert Yocam的好大喜功再次让Borland付出沉重代价。JBuilder 2.0发布，Borland的Java开发工具渐入佳境。

  1999        在和Borland就"Brain Drain"事宜展开诉讼并发现局势不利之后，Microsoft提议庭外和解并投资Borland。Delbert Yocam被解雇，Dale Fuller任Borland CEO。发布Delphi 5，一扫Delphi 4带来的耻辱。JBuilder 3.0发布。一年后的JBuilder 3.5纯以Java打造而成，毕其功于一役，充分体现了Borland的实力。出售dBase予Ksoft(后更名为dBase Inc.)。

  2000        发布JBuilder 4.0，是继JBuilder 3.5的乘胜追击之作。推出之后很快就成为市场的霸主。和Corel的并购案失败

  2001        发布JBuilder 5.0，大幅改变人们对JBuilder"不适用于团队开发"的印象。同年底发布的JBuilder 6.0，整合UML和Extreme Programming，更是支持EJB的最好开发工具。

  2002        发布JBuilder 7.0，最终奠定在Java开发工具市场唯我独尊的地位。并购VMGEAF,公司，获取OptimizeIt，并将其整合到JBuilder产品线。             同年10月，并购Starbase公司，准备提供软件应用平台。随即，对TogetherSoft的并购案，给业界带来极大震动。发布Delphi 7，被认为是Windows平台原生开发工具向.NET平台开发工具过渡的一代产品。随着Delphi 6、7的发布，Kylix(Delphi for Linux)也不断更新，品质也在持续的精进中。
 
 
 

posted on 2006-11-10 10:12 Vikings 阅读(1708) 评论(1)  编辑  收藏 所属分类: 程序哲学