標 題: c/c 的聖戰 發信站: 北大未名站 (2001年11月02日07:33:27 星期五), 站內信件 作者：李維 我的回憶和有趣的故事-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 經過2年多的整軍經武，實力已經大不前。不過 Borland C/C 3.1仍然在許多方面可以和Visual C 一爭長短的。例如其時 Visual C 的最佳化編譯器仍然落後Borland C/C 3.1一些，第2點是MFC仍然沒 有完整的封裝Window API，而且MFC是以較低階的方式封裝Window API，並不是很 對象導向，也不是很容易使用。事實上以我的觀點來看，我認為就是因為MFC不好 用，因此Visual C 才需要在整合發展環境中提供以可視化方式產生MFC程序代碼 的功能，第3是Visual C 當時並沒有很好的封裝數據結構的Container Class，而 Borland C/C 卻有非常好用的BIDS類別庫。第4，也是最重要的，Borland C/C 3.1仍然擁有絕大的市場，而且幾乎所有的外圍公用程序，Shareware等都是 使用Borland C/C 3.1開發的。因此如果Borland不要急，好好的開發下一代的 C/C 開發工具，即使Microsoft Visual C 能夠掠奪一些市場佔有率，但是如果 下一代的Borland C/C 能夠像Borland C/C 3.0一樣立刻拉開和Visual C/C 的 距離，那麼Borland在C/C 市場仍將擁有王者的地位。 可惜的是，也許Philippe Kahn在和Microsoft的FoxPro For Window一役中被嚇到 了，因此急於在Visual C/C 1.0之後立刻推出新的Borland C/C 以扳回顏面。 但是Philippe Kahn忘了，在這段時間之內Borland失去了許多的人材，Eugene Wang也離開了，更重要的是在過去近3年的時間之內，Borland幾乎沒有持續的開發 下一代的Borland C/C ，在短時間之內如何能夠倉促的推出產品呢? 但是Philippe Kahn可管不了這麼多了，急忙找來了Carl Quinn等人便要求立刻開 發出下一代的Borland C/C ，於是Borland C/C 4.0就在這麼鴨子趕上架下匆忙 的開發了。Borland在開發Borland C/C 4.0時犯了許多的大忌。首先在這麼短的 時間內Borland決定全新發展整合發展環境，第2是把OWL完全重寫，第3是大幅修改 最佳化編譯器，第4是整合當時棘手的VBX，Borland居然讓16位和32位的程序能夠 同時使用16位，醜陋的VBX。 上面所說的每一項都是大工程，Borland早應該在Borland C/C 3.1之後便開始做 這些工作，現在要在短短的一年多的時間內重新開發一個這麼復雜的C/C 開發工 具，幾乎是不可能的工作。但是在Philippe Kahn的要求之下，這些Borland的工程 師還是硬?頭皮做了出來。 不過我必須很沉痛的說，當時我在Beta測試Borland C/C 4.0時便和台灣 Borland的人說，如果Borland倉促推出Borland C/C 4.0的話，那麼不但不會對 Visual C 產生任何的影響，反而是自殺的行為，因為臭蟲實在太多了，整個整合 發展環境的反應也很緩慢，它的最佳化編譯器更是笑話，錯誤百出，真是像當時惡 名昭彰的Microsoft C 4.0一樣。我還開玩笑的說，是不是因為Microsoft從 Borland挖了大量的Borland C/C 人才，因此好勝的Philippe Kahn也還以顏色， 從Microsoft反挖Microsoft C的人，卻不幸的挖到了Microsoft C 4.0的人。 但是很顯然的Borland並沒有聽到我的，或是其它Beta測試人的心聲，在Visual C 1.0推出後的1年多，Borland C/C 3.1後的4年，Borland終於推出了新一代 的Borland C/ 4.0，這個肩負和Visual C 1.0對抗的C/C 開發工具。 在Borland C/C 4.0 當時所有重要的計算機雜志?，例如Byte，PC Magazine，Dr. Bo b等等，都有4.0? 頁的廣告。這個廣告的內容是以一個巨大的貓頭鷹為主，再搭配藍色底色系的 Borland C/C 4.0為主，選用巨大的貓頭鷹當然是因為OWL的原因，隻可惜我現在 找不到那幅廣告了。 痛失江山的Borland C/C 4.0 當時Borland使用了如下的廣告用詞 : 『Visual Is Only A Facial Facade』 來諷刺Visual C/C 隻提供了產生MFC程序代碼的基本精靈，而Borland除了也提供 相對應的AppExpert精靈能夠提供類似的功能以產生使用者選擇的OWL程序代碼之外 ，Borland C/C 4.0的整合發展環境還提供了可視化的3面版窗口，能夠讓程序員 完整的掌握整個項目的情形。 例如在下圖中便是當初令人眼睛為之一亮的AppExpert： 還記得Borland提供的AppExpert嗎? 下圖則是當時Borland C/C 的注冊商標，3面版窗口開發環境。看到下圖又令我想 起當初使用C/C 寫程序的日子，下方程式碼面版清楚的顯示了我在1995年於鼎新 工作時寫的智能型Window排程系統，時間過得是真快啊。 令人懷念的Borland C/C 4.0整合發展環境，三面版窗口 當時Borland C/C 4.0的3面版整合發展環境真是開創了一個新的局面，因為這個 整合發展環境允許程序員知道每一個應用程序定義的窗口訊息，並且能夠立刻的顯 示在下方的程序代碼窗口中，的確是非常的方便，也比當時Visual C/C 的整合發 展環境來得先進。再加入Borland較為先進的編譯器技術和架構更好的C/C Framework-OWL，照理說Borland C/C 4.0應該會獲得極大的勝利，那麼為什麼最 後會以失敗收場呢？ 沒錯，在Borland C/C 4.0剛推出之後訂單的確如雪片般飛來，銷售情形非常好 ，因為這畢竟是Borland在睽違了數年之後的大作，許多Borland的用戶都迫不及待 的升級，就像當初我也是拚命的要求台灣Borland要第一個給我Borland C/C 4. 0。但是在Borland C/C 4.0推出一段時間之後，市場的反應就急速的冷卻下來， 因為各種負面的批評不斷湧現，這主要的原因當然是因為Borland C/C 4.0的品 質實在不好，就像前面我在Beta測試時說的，由於Borland太急於推出4.0，因此並 沒有在最後階段修正許多的錯誤，又沒有經過最後系統微調的工作，又太大膽的加 入太多先進的技術，造成了整個產品的不穩定，而造成了大錯。下面幾點應該是造 成當初Borland C/C 4.0滑鐵盧的主要原因： *整合發展環境方面-臭蟲太多，容易當掉而且反應速度緩慢 *編譯器方面-最佳化玩得過火，產生錯誤的編譯程序代碼 *OWL方面-採用全新的多重繼承架構，雖然是正確的做法，卻和Borland C/C 3. 1中的OWL不兼容，造成許多程序員無法升級C/C 項目 *VBX方面-大膽的採用在16/32位都能使用VBX的技術，造成一些VBX無法順利的在 Borland C/C 4.0中使用 我想其中最可惜的就是OWL了，因為OWL 2.0在各方面都有一流的表現，實在是MFC 強勁的競爭對手，OWL 2.0也獲得了各方一致的肯定和稱讚。無奈的是由於OWL 2. 0做了從基本架構的改變，這是為了解決當初OWL 1.x使用了不標準的C/C 編譯器 技術的問題，但是這造成了原本Borland C/C 程序員極大的困擾，因為升級不易 。對於新的C/C 使用者來說又因為Borland C/C 4.0本身不穩定的因素而卻步， 因此造成了OWL 2.0叫好不叫座的下場，真是可惜了 OWL小組的努力。 我記得當時我的項目有使用FarPoint的SpreadSheet VBX組件，由於一直無法順利 的在Borland C/C 4.0中使用，並且會造成應用程序的當掉，最後追蹤執行程序 代碼卻發現應該是Borland C/C 4.0的問題，因此最後隻好在咒罵中放棄使用4. 0，而回到Borland C/C 3.1。我當時想，對於我這個長期使用Borland產品的人 都無法忍受4.0的品質，其它的程序員又怎能使用這個產品。我想這就是為什麼後 來4.0全面潰敗的原因，因為Borland推出了根本不堪用的產品。 在我於Borland工作的時間，有一次在新加坡和現在Borland開發者關系部門的副總 裁David Intersimone談起這一段往事，David也很感慨這一段往事，David直呼『 We screwed it up!』，『It's a mess』。David並且說當時整個Borland C/C 開 發小組都很混亂，和以往Borland C/C 3.0/3.1的開發小組比起來實在是差太多 了，除了因為一些重要的人物相繼離開Borland，而且Microsoft也挖走一大票人之 外，Philippe Kahn的直接介入，造成人事不和也有很大的原因。 David I.說『We Screwed it up!』 ，『It's a mess』 在Borland C/C 4.0快速失利之後，Borland也體認到問題的嚴重性，因此立刻的 ?手開發Borland C/ 4.0的Patch，當時是稱為Service Pack。但是在稍後的4. 01版中並沒有完全的解決問題，一直要到4.02才稍為解決一些嚴重的問題，無奈時 不我予，拖的時間太長，市場已經起了巨大的變化。 在Borland C/C 4.0失利之後，立刻造成了嚴重的後果，首先是Borland C/C 的 市場大量且快速的流失，讓Visual C/C 快速的成長。第二點是當初Borland C/C 3.1在公用程序市場打U的江山也拱手讓人，原本許多硬件廠商也使用 Borland C/C 3.0/3.1撰寫驅動程序也開始轉換到Visual C/C ，而嚴重的是在 應用程序市場方面由於4.0的品質以及稍後OLE的關系，也開始大量的開始轉為使用 Visual C/C 來撰寫應用程序。 Borland在3個主要的應用市場接連敗退，C/C 的江山注定將易主，其勢已不可挽 。 Borland C/C ，Visual C/C ，Watcom C/C 和Symantec C/C 的纏鬥 自Borland C/C 4.0一役大敗之後，Borland在C/C 市場上建築的巨大堡壘似乎 再也不是牢不可破了。Visual C/C 固然在不斷的接收Borland C/C 失去的市場 ，此時在C/C 市場上也加入了另外兩個堅強的對手，那就是Symantec C/C 和 Watcom C/C 。 Symantec C/C 的發展史 說起這兩個對手也都是個個來頭不小，先說Symantec C/C 吧。它的Think C/C 在Macintosh上便是非常有名的編譯器，因此早在C/C 領域便有深厚的基礎。在 Symantec並購了PC上第一個C/C 編譯器Zortech C/C 之後，Symantec進入PC的開 發工具市場也是箭在弦上了，隻可惜的是其時Symantec還未找到一個在PC上有豐富 經驗的開發工具領導者。 也許是上天注定要引起稍後的C/C 編譯器大戰吧，此時Borland C/C 3.1的幕後 支柱Eugene Wang剛好和Philippe Kahn鬧翻，離開了Borland。Symantec見此時不 可失，立刻重金延攬Eugene Wang到Symantec，為Symantec推出第一個C/C 開發工 具。在1993年左右吧，Symantec C/C 在Eugene Wang的掌舵之下推出了第一個 Symantec C/C 版本，立刻便獲得了市場的好評。自此之後Symantec C/C 軍心大 振，不斷的繼續改善，也逐漸的獲得了不小的C/C 市場，隱然成為可以對抗 Borland C/C ，Visual C/C 的另一山頭。當時Symantec C/C 是以最華麗，先 進的整合發展環境獲得市場的高度認同，在C/C 編譯器最佳化方面的表現也不會 輸給其它的編譯器。 當時我在RUN!PC上寫C/C 的文章，因此Symantec C/C 也有和我連絡，並且送給 我一套最高檔的Symantec C/C ，希望我除了為Borland寫C/C 的文章之外，也能 夠為Symantec C/C 寫一些東西，我想這就是做為寫技術文章的一個好處之一，那 就是可以拿到許多最Hot的開發工具。我還記得在當時安裝Symantec C/C 之後， 的確被它的整合發展環境吸引的說不出話來，因為實在是太棒了，Borland C/C 和Visual C/C 的整合發展環境和Symantec C/C 的整合發展環境比較起來，立刻 的就變成索然無味，平凡無奇了，到現在我仍然必須豎起大拇指對Symantec C/C 的整合發展環境說聲『讚』。我想Eugene Wang在這麼短的時間內把Symantec C/C 打造的好此之好，除了証明他的不凡功力之外，也有向Philippe Kahn示警 的意思。証明Philippe Kahn讓他離開Borland是錯誤的決定。我之所以如此說是因 為其時Symantec C/C 最喜歡點名挑戰的對象便是Borland C/C 了。 對我的感覺而言，Symantec C/C 就像是一個技藝精良，又裝備華麗的C/C 軍團 。 Watcom C/C 的發展史 真是非常有趣的是，Watcom C/C 走的路子和Symantec C/C 幾乎是完全相反的。 當時出品Watcom C/C 編譯器的是一家加拿大的小公司，不過這家公司卻對最佳化 編譯器有深入的研究。當時Watcom C/C 是以在DOS下能夠產生最好的最佳化程序 代碼聞名於世的，在其時有許多寫遊戲和DOS Extender的廠商都是指名要使用 Watcom C/C ，因為不論是Borland C/C 或是Visual C/C 產生的最佳化程序代 碼都比Watcom C/C 的最佳化程序代碼差上一截。再加入當時最有名的DOS Extender廠商PharLap公司也是使用Watcom C/C ，因此Watcom C/C 在專業的 C/C 程序員以及系統程序員心中是第一品牌的C/C 開發工具。 不知道還有多人記得PharLap這家公司，或是有沒有人記得Andrew Schulman這位偉 大的軟件技術人員。當時Andrew Schulman的Undocumented Windows一書紅遍了半 邊天，也惹得Microsoft要告Andrew Schulman。而Andrew Schulman便是PharLap公 司的首席工程師，也是當時最著名的『The ANDREW SCHULMAN Programming Series』的總監，例如當時由Matt Pietrek撰寫的Windows Internals也是轟動一 時的巨著。而PharLap公司是當時出版DOS Extender軟件最成功的軟件公司。 談到Matt Pietrek，熟悉Window Programming的人應該很少有不知這位大師級人物 的。Matt長期在Microsoft System Journal撰寫Under The Hood專欄，專門寫一些 深入系統的程序設計技術，在數年前便和Andrew Schulman，David Maxey成為 Widow System Programming的三大巨頭之一。Matt也是著名的Window除錯工具 SoftIce，BoundsChecker的主要研發工程師。Matt本身也是從Borland出道的，當 Matt初至Borland工作時便是在Turbo Debugger小組中研發除錯工具。當時 Borland的Turbo Debugger是DOS下最強的除錯工具，即使是Microsoft也無法推出 能夠和Turbo Debugger抗衡的除錯工具。Matt在這個小組中吸收了大量的知識，並 且快速的成為這個領域的專家。後來Turbo Debugger小組的部份成員被Microsoft 挖走，讓Microsoft掌握了Borland的核心除錯技術，以致後來也能夠推出不錯的除 錯工具。而Matt也出走到NuMega公司成為開發SoftIce，Bounds Checker的關鍵人 物。寫到這裡還是不禁要佩服Borland，因為當今許多名滿天下的重量級軟件工程 師都是由Borland培養出來的。 在Watcom C/C 於DOS市場佔穩了腳步之後，由於Window已經逐漸成為市場的主流 ，DOS勢必將被逐漸淘汰出局，因此Watcom C/C 要繼續的生存下去，也一定要推 出Window平台的C/C 開發工具。大約也是在1993，1994年左右Watcom終於推出第 一個Window的開發工具。 不過當時Watcom C/C 在Window推出的C/C 開發工具實在是平凡不已，其整合發 展環境和另外三個對手比較起來簡直像是遠古的產品，一點特色都沒有，不過 Watcom C/C 仍然是以它的最佳化編譯器做為號召。因此在當時發生了一個非常有 趣的現象，那就是許多軟件公司會同時買Borland C/C ，或是Visual C/C ， Symantec C/C 之一，再搭配一套Watcom C/C 。在開發應用系統時使用其它三套 開發工具之一，最後要出貨時再使用Watcom C/C 來編譯以產生最佳的程序代碼。 在Watcom C/C 推出了Window平台的開發工具之後，仍然吸引了一群使用者，雖然 Watcom C/C 的市場比起其它的三家來說是最小的，但是也在一方撐起了一片天， 成為四大C/C 開發工具之一。稍後Watcom C/C 被Sybase並購，並且成為後來 Sybase的Optima 的前身。 對我的感覺而言，Watcom C/C 就像是一個穿著樸素，但是卻擁有最佳訓練的白色 C/C 軍團。 關鍵的時刻-MFC Or Not 在Symantec C/C 和Watcom C/C 逐漸的站穩了腳步之後，四大編譯器決戰的時刻 也逐漸逼近了。在1994年未的決戰之前，Symantec和Watcom同時面對了一個非常嚴 厲的考驗，那就是C/C Framework的選擇。 雖然Symantec和Watcom都以各自的特色佔得了市場，不過在當時對於一個C/C 開 發工具來說，最重要的因素之一就是C/C Framework。因此Symantec和Watcom也 都必須提供使用者一套C/C Framework。不過這對於Symantec和Watcom都是一個 難以解決的問題，因為當時的C/C Framework已由Borland的OWL和Microsoft的 MFC所佔領，如果要自己發展新的C/C Framework，那麼Symantec和Watcom並沒有 如此雄厚的資源，也無法在短時間之內完成。因此Symantec和Watcom必須下一個決 定到底是要使用MFC或是OWL做為它們的開發工具C/C Framework。 在1993年初Symantec和Watcom分別和Microsoft簽約License MFC做為它們的開發工 具的C/C Framework。至此大勢以定，在C/C Framework的市場已經形成三家夾 擊一家的形式。當時許多人便預估Borland將成為輸家，因為市場已經成為一面倒 ，MFC看起來已經是勝券在握了。在當時於Borland的內部也展開了激烈的辯論，討 論是否也要License MFC做為C/C 的Framework，停止繼續開發OWL。不過後來 Borland還是決定繼續開發OWL，而不使用MFC，因為Borland的C/C 技術小組認為 MFC不論是在架構上或是設計上都比不上OWL。而且由於Visual C/C 在當時對於 C/C 的標準支持不如Borland C/C ，因此在MFC內部使用了大量的Macro以及不標 準的語法，因此如果Borland C/C 要使用MFC，那麼還需要修改編譯器來編譯MFC 。 對於這一點我認為Borland還是做了一個正確的決定，因為如果當時Borland也 License MFC，那麼不但在氣勢上便輸了一截，而且當MFC的發展是完全掌握在 Microsoft的手裡，那麼就等於脖子是掐在別人的手裡，動彈不得了。可惜的是 Symantec和Watcom並沒有看清這一點，以為有了和Microsoft一樣的Framework，就 可以在其它地方和Microsoft以及Borland一決雌雄，Symantec和Watcom卻沒有想就 是這一點決定讓後來的決戰一敗塗地，終究完全推出PC的C/C 開發工具市場。 時序到了1994年未，C/C 開發工具的四大天王決戰的日子終於癒來癒近了。 OLE的攪局 不知道是時運不濟或是Microsoft的刻意如此，在1994年Borland C/C 和Visual C/C 決戰的前夕，Microsoft推出了OLE(Object Linking And Embedding)技術。 OLE是Microsoft為了對抗Apple的文件技術以及IBM OS2的Workplace和文件技術應 運而生的。OLE可以讓Window平台的文件能夠內嵌在不同的應用程序中並且能夠讓 文件在應用程序中被即地編輯(In-Place Editing)。說實在的，Microsoft的OLE和 Apple以及IBM的技術比較起來實在是差多了，OLE在稍後也被証明是失敗的技術， 不過不管是Microsoft的OLE或是Apple/IBM的文件技術也都是失敗的技術，都沒有 造成巨大的成功。雖然這些文件技術都沒有成功，但是OLE卻足以成為Borland， Symantec和Watcom失敗的重要因素。 我還記得當時OLE似乎成為了一個令人趨之若鶩的時髦功能，因為Word的文件能夠 內嵌在Excel之中，並且可以點選此Word文件，應用程序又立刻成為Word來編輯它 ，實在是令人覺得非常的神奇。不過在其時所有的軟件廠商中隻有Microsoft的應 用程序有如此的功能，其它的廠商例如Lotus，WordPerfect等都無法實作出這種功 能。這造成了不公平的競爭，因為OLE技術是由操作系統廠商Microsoft推出的，但 是卻讓它的應用程序部門同步擁有這種技術，而其它的軟件廠商都無法獲得第一手 的OLE技術來實作，這是為什麼當時其它的軟件廠商如此火大的原因。 雖然後來其它的軟件公司在取得了OLE的技術信息之後也推出了具備OLE功能的應用 程序，但是畢竟是慢了Microsoft許久，市場也流失了許多。不過我也很奇怪的是 在當時內建OLE功能的應用程序之中，幾乎所有的軟件廠商推出的應用程序在激活 數個應用程序而且使用OLE之後，就非常容易的當掉，隻有Microsoft的應用程序不 太會發生這種情形，因此許多人便認為Microsoft有隱瞞一些技術沒有讓其它的廠 商知道。 由於OLE是如此的復雜，因此Borland無法立刻在OWL之中實作出這種功能，於是就 造成了市場上負面的影響。至於Symantec和Watcom雖然是License MFC，但是在其 時它們License的是MFC 1.x的版本，Microsoft並沒有把OLE實作在MFC 1.x中，而 是在實作在MFC 2.0之中。在MFC 2.0推出時最重要的功能就是Microsoft加入了 20000多行支持OLE的程序代碼，但是MFC 2.0卻僅限於Visual C/C 使用，就是這 關鍵的一點讓其它三家廠商吃了虧。 對於OLE這個關鍵技術的影響，Borland是深知在心的，因此在計劃在Borland C/C 4.5的OWL 2.5中支持OLE。當時Borland推出的解決方案便是OCF(Object Component Framework)。 Borland當初在設計OCF時有幾個重大的目標。這些目標包括了: 一、如何能夠使得 OLE瑣碎 、復雜的接口能夠單純化; 第二、如何能夠使得OLE在窗口環境下寫程序 的思考方式 一致化--即使用「事件驅動」的方法。第三、如何能夠在微軟佔盡天 時、地利(未必人和) 的情況下使得Borland的產品具備OLE的功能。第四、如何能 夠讓大多數C 的程序員都能夠享受OLE的功能而不局限於OWL的程序員。由於上述 的設計目標, 而造就了典雅而具有彈 性的OCF。由於OCF本身是一完整而獨立的 Framework, 因此它可適用於各種應用程序發展Framework。 不曉得各位使用過Borland C/C 的朋友們是否還依稀記得下圖OCF的架構圖之一， 以及下面的OCF范例程序代碼，這些可是我把1994年寫的文章挖出來之後找到的， 真是令我感慨，也回想起了當時的情景，也讓各位回憶一下OWL和OCF。對於不熟悉 OWL和OCF的朋友，也可以從下圖和程序代碼中觀察一下當時的技術以及設計的概念 。基本上我現在看這些圖形架構，會發現它們並沒有落後現在太多，可見當時設計 者的功力(Carl Quinn Again)。 // // Insert an OLE object into the view // void TOleWindow::CmEditInsertObject() { 001 PRECONDITION(OcView); 002 TOcInitInfo initInfo(OcView); 003 if (OcApp->Browse(initInfo)) { 004 TRect rect; 005 GetInsertPosition(rect); 006 SetSelection(new TOcPart(*GetOcDoc(), initInfo, rect)); 007 OcView->Rename(); 008 InvalidatePart(invView); } } 程序1 OWL的TOleWindow支持OLE插入對象之成員函數 // // Handle left double-click message // void TOleWindow::EvLButtonDblClk(uint modKeys, TPoint& point) { PRECONDITION(GetOcDoc() && GetOcView()); TOleClientDC dc(*this); dc.DPtoLP(&point); TOcPart* p = GetOcDoc()->GetParts().Locate(point); if (modKeys & MK_CONTROL) { if (p) p->Open(true); // Ctrl key forces open editing } else { SetSelection(p); if (p && p == GetOcView()->GetActivePart()) { // resync the active flag p->Activate(false); } GetOcView()->ActivatePart(p); // In-place activation } } 程序2 OWL的TOleWindow支持左鍵雙擊之成員函數 雖然Borland及時的在OWL 2.5中加入了OLE的支持，無奈Microsoft隨後又在OLE中 加入了許多其它的功能，因此讓OCF並無法完整的支持OLE所有的功能，B無法不斷的延後 Borrland C/C 的推出，因此在1994年未，Borland終於推出了決戰 的4.5版本。 C/C 開發工具的最後聖戰 『雖然已經過去了許久的時間，但是我仍然忘不了那場最慘烈的戰役!』 1994年未, 1995初Borland在痛定思痛之後，終於清除了Borland C/C 4.0中所有 的問題，也開發出了自Borland C/C 3.1以來最穩定，最快速的Borland C/C 4.5的版本，準備和Microsoft決一死戰。我還記得當時在書籍市場中許多有關 Borland C/C 和Microsoft C/C 的書籍都是使用十字軍的封面，而Borland C/C 的系列叢書都是以藍色為色系，而Microsoft的則是以紅色為色系，仿佛兩大 軍團終將決戰似的。 C/C 四大天王決戰一役的Borland主將-Borland C/ 4.5 不過這次的戰役不光是Borland的藍軍和Microsoft的紅軍相對抗，在Symantec的華 麗軍團經過了經軍經武，Watcom的白色勁旅枕戈待旦，而且都從Microsoft License了MFC之後，藍，紅，花，白四大軍團決戰的日子終於到了。首先當 Symantec和Watcom分別取得了MFC之後，Symantec便推出了C/C 7.x的版本，和 Watcom C/C 混戰了起來。兩個使用系出同門的C/C Framework產品戰得不亦樂 乎，隨後Borland C/C 4.5和Visual C/C 的新版本也加入了這場最重要的決戰 。但是讓Symantec和Watcom C/C 大吃一驚的是Microsoft使用的MFC居然比它們的 版本高出了一個版本(1.x對2.x)，而且新版本的MFC包含了完整的OLE支持能力。而 Borland雖然也有OCF，但是仍然不敵新版MFC中的OLE能力。由於當時幾乎所有的應 用程序都需要支持OLE，但是卻隻有使用Visual C/C 最新的版本才能夠開發完整 OLE能力的應用程序，因此不管OLE到底有沒有用，反正先加入再說。因此市場上的 情勢很快的就發生了巨大的變化，幾乎大部份的應用程序開發因為OLE的原因都選 擇使用Visual C/C ，Symantec和Watcom軍團很快的就敗陣下來。 至於Borland C/C 4.5雖然是一流的產品，如果沒有OLE的因素，Visual C/C 新 版本真的並沒有比4.5好。雖然4.5也有OCF，但是在市場上隻有Borland和Novell， WordPerfect選擇使用OCF，在和Microsoft的Visual C/C 經過將近一年的纏鬥之 後，其它大部份的廠商都選擇了Microsoft的MFC 2.x版，真是形勢比人強。基本上 OCF的架構真的是個好東西，隻是OCF無法完整的支持OLE，因為OLE的發展是掌握在 Microsoft手中，因此雖然OCF的架構良好，終究在功能上不及對手。Microsoft結 合操作系統，開發工具和應用程序的手段真是無往不利。擊敗Lotus，Borland是如 此，殲滅Netscape也是如此。 對於Symantec和Watcom來說，這場戰役就如同『長平之戰』，秦軍坑殺40多萬趙軍 一樣。殺得Symantec和Watcom全軍覆沒，大敗而歸，至此Symantec棄受PC的C/C 開發工具市場，轉而開始研發Java開發工具，進而在稍後推出了著名的Visual Cafe, 至於Eugene Wang則離開了Symantec，自此也離開了PC開發工具的領域。 而Watcom則是更為凄慘，整個公司在DOS的市場逐漸式微，而Window平台的開發工 具又大敗而歸，兩頭落空。不久之後Watcom便被新興而起的Sybase並購，從此消失 於競爭激烈的市場。 歸納Symantec和Watcom失敗的原因是C/C 的Framework MFC掌握在Microsoft手中 ，在決戰時刻Microsoft居然手握比Symantec和Watcom更新的MFC利器，而且在 Visual C/C 精進最佳化的技術並且改善整合發展環境之後，Symantec和Watcom訴 求的重點功能完全被Microsoft封死。因此在產品，技術，市場和氣勢上完全不如 對手的情形下，自然隻能任人宰割了。 對於Borland而言，雖然沒有像Symantec和Watcom那麼潰不成軍，但也是再次敗下 陣來。雖然平心而論Borland C/C 4.5的確是一個非常好的產品，無論在OWL，最 佳化編譯器，整合發展環境方面都有一流的表現，和Borland C/C 4.0比較起來 簡直有如脫胎換骨一般，到現在Borland C/C 4.5仍然是我最喜歡的版本之一。 但是無奈當初Borland C/C 4.0給人揮之不去的負面印象，以及無法完整支持當 時如火如荼的OLE技術，因此還是在決戰之中敗了下來。好在藍色的Borland大軍畢 竟是訓練有素的，雖然自此讓Microsoft佔據了超過50%的市場，成為C/C 開發工 具的老大，但是Borland仍然掌握了超過30%的市場，稍做喘息，並且支撐Borland 在各重要戰役失敗之後維持公司的運作，等待Delphi的浴火重生，再重新出發。 經過這一役之後，Microsoft終於清除了大部份的對手，對於Microsoft而言程序語 言開發工具的戰爭已經結束，這個市場注定將被Microsoft佔據大部份的市場。在 Microsoft手握操作系統，Office軟件和開發工具三大獲利市場之後，Microsoft也 開始將矛頭對準下兩個競爭目標，關連數據庫以及主從架構開發工具。在 Microsoft正式進軍這兩個市場之後，當然也展開了連番的好戲，尤其是在主從架 構開發工具方面又開啟了VB，PowerBuilder，Gupta/Centura和Delphi的驚天動地 大會戰。另外一個意外開啟的戰爭則是Microsoft在1995年和Netscape的挑起的瀏 覽器大戰。 對於Borland而言，在C/C 最後一役之後，基本上我認為開發工具的聖戰已然結束 ，Borland也正式開始走下坡。更嚴重的是我認為自此之後Borland不但喪失了 C/C 的江山，也失去了對於C/C 開發工具的創意，這是我感覺最遺憾的地方，到 現在為止我仍然認為Borland尚未重拾當初在Borland C/C 3.0/3.1時代獨領 C/C 創意風騷的精神。也許，也許，要看看C/C For Kylix或是C Builder 6 是否能夠重新找回這個失去已久的精神，不要再讓我失望了。 雄霸數年的C/C 的世界冠軍-Borland C/C 3.1-永遠的懷念 永不成氣候的C/C 開發工具-IBM Visual C/C IBM在C/C 開發工具扮演的角色一直令人啼笑皆非，因為在C/C 編譯器戰爭最激 烈的時刻，IBM這個全球信息大廠卻一直是缺席的。一直到了1995之後，C/C 編譯 器市場大勢已定之後才慢慢的加入戰局，推出VisualAge C 3.0，企圖進攻此市 場。但是此時市場早已由Microsoft的Visual C/C 稱雄。IBM的VisualAge雖然以 創新的可視化設計家能夠定義對象之間的關系，但是在其它方面卻乏善可陳，整個 整合發展環境也緩慢如蝸牛，需要非常高文件的硬件配備才能夠順利的執行，和 Visual C/C 以及Borland C/C 等工具比較起來就像是恐龍一般，因此幾乎沒有 在市場上引起任何的反應。 在IBM推出VisualAge 3.0並沒有在PC的C/C 開發工具市場獲得任何的明顯成果之 後，IBM又再次的集中了許多的資源，開發下一代3.5的版本，希望能夠在此市場佔 有一定的比率。我知道IBM在VisualAge投注了大量的資源，因為從Beta版開始台灣 的IBM便有人和我接觸，希望我也在RUN!PC上為VisualAge 3.5寫一些文章。因此在 1996年的6月我寫了一篇C/C 編譯器的比較文章，下面的資料便是數年前當時還在 Beta版的VisualAge 3.5和其它編譯器的比較： 從上面的數據中可以看到其實VisualAge 3.5的表現還不錯，隻是對於當時還在使 用AMD DX4-100/32M RAM機器的我來說，實在是跑不太動VisualAge 3.5。後來台灣 IBM負責VisualAge的產品經理請我吃飯，在此飯局中這位李經理同時請了賀元(後 來為資迅人的總裁)，薛曉嵐(後來為資迅人的副總裁)以及其它兩位作者，希望大 家在計算機雜志中繼續的為VisualAge 3.5寫寫東西，一起Promote此產品。在這個 飯局中我是第一次和賀元，薛曉嵐見面，當時賀元在中文PC Magazine有一技術專 欄。記得當時我向這位李經理提起我的機器幾乎無法跑VisualAge 3.5，他還立刻 一口答應願意借我一台當時IBM最高檔的PC，同時每寫一篇VisualAge的文章，除了 RUN!PC原本的稿費之外，IBM會再付一字2.5元的稿費。乖乖，IBM真是大手筆，我 算算當時我的產能，寫一篇文章就能夠賺2到3萬，又有免費的最高檔機器可用，真 是太好康了。不過後來我還是覺得IBM在此市場可能不會深耕，在不願意違背自己 寫作習慣和得罪Borland的顧慮下，最後還是沒有答應。現在想想當時真是太笨了 ，放?好賺的稿費不賺，嘻。 IBM的C/C 開發工具之所以在市場無法成功是一是因為並不了解在此競爭激烈的市 場中使用者到底要什麼。另外一個原因則因為IBM並不以PC上的開發工具軟件為重 要的事業，即使無法競爭對於IBM來說也沒有什麼影響，不像Borland這可是生命之 爭。因此IBM隻是興起玩玩，隨即放下。所以我覺得在PC平台使用IBM的工具是很危 險的，因為IBM可能隨時會放棄此市場。例如不知道現在VisualAge C/C 到底如何 ，是不是還在3.5或是4.0版，已經數年沒有任何的維護和改善了。 稍後IBM為了想在OS2和Window平台上推出能夠和Microsoft相抗衡的Basic工具，因 此秘密的研發了一個Object Basic。我也曾看過這個工具，但是Object Basic跑起 來慢得跟烏龜一樣．後來不知道是不是一直無法改善這個問題，因此IBM從沒有推 出此產品，現在IBM似乎隻對Java有興趣，VisualAge For Java還算發展的不錯， 希望不會有一天IBM對VisualAge For Java的態度會和VisuaAge For C/C 以及 Object Basic一樣才好． 快速殞落的潛力之星－Sybase的C/C RAD工具Optima 在1996年吧，Sybase並購了Watcom之後，終於推出了石破天驚的C/C 開發工具， Optima 。Optima 是當結合了Watcom的最佳化編譯器以及類似Delphi的組件拖曳 開發環境的第一個RAD C/C 開發工具，更棒的是Optima 的組件架構(類似 Delphi的VCL)完全是以純正的C/C 程序代碼撰寫的。這可不得了，因為這代表 Optima 是一個融合了Visual C/C 和Delphi兩大王者開發工具為一身的超級賽亞 人工具。 在我知道這個工具，並且取得實際的使用之後，令我極為震驚。因為這個工具對於 我這個使用了C/C 5,6年的人來說，是比Delphi還具有吸引力。因此在當年我立 刻的在RUN!PC上介紹了此不可置信的工具。果然，Optima 很快在開始風卷市場， 雖然沒有立刻的佔據很大的市場量，但是已經造成了一股氣勢，開始為Visual C/C 和Delphi帶來了壓力。 我記得當時台灣Sybase辦的產品發表會也吸引了數百人與會，不可一世。在我的 RUN!PC文章出版之後，台灣的Sybase立刻和我連絡。由當時的余協理和我見面，也 是希望我繼續為Optima 寫文章，台灣Sybase也提供額外一字加2元稿費的待遇。 但是我告訴余協理，Optima 1.0雖然很棒，但是仍然有一些臭蟲，而且和中文環 境相沖突，無法處理中文，需要立刻的解決問題才能夠在台灣的市場成功。她答應 我立刻的向總公司反應。我也老實的告訴她在問題沒有解決之前我無法寫一些不確 實的東西。後來台灣Borland的總經理方先生也找我去詢問有關Optima 的事情， 我告訴他Optima 是好東西，但是中文有問題。如果中文問題能夠解決，那麼將對 Borland的產品有很大的影響，當時我還不知道Borland由於Optima 的影響，已經 開始準備發展C Builder。 在1996年底左右吧，Optima 1.5終於進入Beta的階段，但是在我拿到Beta版時仍 然非常的失望，因為中文的問題仍然沒有解決。後來台灣Sybase又找我去，這次和 我見面的是台灣Sybase總經理郭俊男先生，以及Sybase的新加坡技術總裁，不過我 忘記這位先生的名字了。我們見了面之後，我立刻的把Optima 1.5中文的問題以 及許多的臭蟲告訴他們，希望他們能夠解決，如此Optima 1.5才能夠在中文市場 成功。可是出乎意我意料的是，他們似乎並不急?這些問題，反而詢問我是否有意 願為Sybase工作，做PowerBuilder的產品經理。 也許是因為我為Delphi寫了太多的東西，讓PowerBuilder受了很大的影響，因此他 們希望我到Sybase工作，以打擊Delphi並且Promote PowerBuilder。當時他們提出 的待遇條件實在是非常，非常的誘人，比我當時的薪水高出一倍左右（我當時在資 策會工作）。不過由於我對PowerBuilder實在沒有什麼興趣，因此我告訴他們如果 是做Optima 的產品經理，那麼我將會考慮並且接受。 沒有想到Sybase的新加坡技術總裁告訴我Optima 在1.5推出之後就可能會停止， 因為Sybase要把資源移去為當時癒來癒紅的Java研發一個新的Java RAD開發工具， 那就是後來的PowerJ。於是他問我如果不願意做PowerBuilder的產品經理，那麼是 不是願意做PowerJ的產品經理？由於當時我已經知道Borland開始了Open JBuilder的研發，而我對Open JBuilder的興趣遠大於PowerJ，因此並沒有答應 Sybase。果然，在Optima 1.5推出之後，不但中文的問題沒有解決，Sybase也沒 有繼續的對Optima 研發下去。 一個如此有潛力的產品就這樣消失了，真是令人遺憾，Optima 應該有很好的機會 可以成功的，我相信如果當時Sybase知道C Builder後來的成果，可能就不會放 棄Optima 了。而C/C 的RAD工具一直要到後來的C Builder來完成這個夢，又 是Borland成功的進入這個工具市場。 C/C 的開發工具之爭到此算是告一段落了，雖然後來Borland繼續推出了 Borland C/C 5.0但是品質仍然不夠好，市場反應也不佳，後來Borland終於在 Borland C/C 5.02之後宣佈停止此條產品線的開發，Borland C/C 的光榮歷史也就從此打止，真是令人不勝感嘆，而Visual C/C 從此在C/C 開發工具市場中再也沒有對手。不過沒有競爭的市場的確會讓人鬆懈的，後來的Visual C/C 進步的幅度癒來癒小，MFC也數年沒有什麼大進步，不像當時和Borland C/C 競爭時每一個版本都有大幅的改善。看來寡佔的市場的確是不好的。 As Promised-李維 智慧是命運的征服者

------
智慧是命運的征服者

真的是非常的精彩…， 有在看武俠小說的感覺！ 這好像是發表在 >

此為轉貼資料 C Builder和VC的比較 其實很久以前我就想寫這篇文章，其原因一方面是因?筆者深深感覺到C Builder的確是一個先進與強大的程式開發工具，但更最重要的一點是，我深信C Builder能給公司帶來巨大了商業利益與生?力的大幅提升，我可以假裝沒看到這幾點，但是基於良心與責任我不能不花點時間來跟大家分享一下我的看法與心得。 C Builder的前身是Borland C ，Borland C 所使用的 Application Framework是OWL，而OWL以物件導向的角度來看，也的確比MFC先進很多（這在學界早有定論），但是在市場上卻叫好不叫座，直到Imprise（以前的Borland）推出以VCL?Application Framework的Delphi之後，這才一炮而紅。 雖然Delphi的VCL非常強大與好用，但是Delphi所使用的是OOPascal語法，和C 不同，直到後來，Imprise才推出以C ?程式語言的C Builder，而其所使用的Application Framework正是赫赫有名的VCL。 VCL的全名是“Visual Component Library“，它是一種新一代的Application Framework，以元件化、視覺化?設計的方向。VCL的興起，起源於OWL和MFC都日見龐大與癡肥，不利於日益複雜的程式開發趨勢，於是Imprise的設計小組決定開發一套更物件導向化的Application Framework，使程式設計師能以視覺化的觀念、元件重用的觀念來快速設計出各式各樣的應用程式，將物件導向的威力與精髓發揮的淋漓盡致，相形之下，OWL和MFC都只算過時與半子的Application Framework。 果然～C Builder一推出後，在微軟的大軍壓境下以及人們西瓜靠大邊的心態下，仍然引起了一陣旋風，在News上許多程式師表示它們對C Builder的肯定與激賞，更有人指出，根據經驗，在微軟的市場優勢之下，Delphi和C Builder仍能欣欣向榮，這表示Delphi和C Builder的?品水準不是只贏微軟?品幾個百分點，而是數十至數百個百分點，否則Imprise的?品早就消失不見了。 到底C Builder的特性與優點在哪里呢？這對於我們公司又有什?利弊呢？我的觀點與分析如下。大家想一想，當我們使用Visual C 來開發程式的時候，最痛苦的事情是什?？答對了～那就是GUI的設計。根據經驗，通常我們利用Visual C 開發一套軟體時，設計GUI所花的時間幾乎占掉程式開發周期的三分之一～甚至到二分之一以上，而設計和介面無關的核心程式通常只占了不到二分之一左右至三分之二的時間，但是使用C Builder則可以大幅簡化這個問題。C Builder的VCL提供大量的各式各樣GUI軟體元件，讓我們可以將大部分的心力放在核心程式碼的設計上，而不必跟Windows系統的訊息、介面去搏鬥。 C Builder的Compiler在功能上跟Visual C 都一樣，Win32 API等都可以呼叫與使用（VCL就是架構在Win32 API之上，沒有不相容的問題，只是包裝的更高明，也非常有彈性），你不用擔心目前有什?事情是Visual C 可以做而C Builder做不到的，進而拒絕使用C Builder，抱持這樣的觀點就好像?了健康而不坐汽車，卻堅持騎腳踏車從淡水來上班一樣因噎廢食，在網路許多非常有經驗的程式設計師會告訴你這是多慮了。曾有人比喻的很傳神，如果Visual C 是手排車，那C Builder就是手自排兩用車（看過三菱的Sportsmode手自排兩用車嗎？）。 C Builder的程式設計細節是清楚而透明的，除了Application Framework的運作保有神秘感之外（MFC也是），所有的程式碼與檔案相關的檔案都是可以掌握與觀看的，不像某些開發工具，程式設計師許多事情是無法掌握的，而C Builder 所?生的碼大小與?生的時間都和Visual C 都是同級的（我指的是勝負差距都不大，到要一提的是，C Builder 3.0採用一種技術，可以使得第二次以後的Compiling速度提升五倍以上，筆者可以證實這一點）。 我的觀點是，我們公司非常適合大量採用C Builder作?程式開發工具，當然啦，?了相容性的考量和母公司有特殊要求的專案除外。由Visual C 轉換到C Builder不是很嚴重與痛苦的事情，反而會覺得很快樂，這就好像開手排車人改學自排車一樣，甚至可以更掌握C Builder的威力。 利用C Builder來開發程式，我們可以快速的?生程式的GUI layout和prototype，在後續調整程式介面的調整周期中也非常的方便，我個人認?至少可以比 Visual C 節省三至五倍以上的時間。 除了某些特殊需求的專案之外（例如版本升級，而原來的版本是VC開發的，或者參考改寫的程式碼是用VC寫的，事實上C Builder也可以支援MFC），我看不出來公司有什?專案的規模或內容非要靠Visual C 不可，自己找罪受不說，也違反了“Build a high performance company“的目標，而將大量的資源投注在落後的工具上，程式生?力也無法巨幅提升。因此我建議公司應該大量而全面性的鼓勵員工使用並熟悉C Builder成?第一線的程式開發工具，根據我的淺見，這樣的投資不但回收快速，而且效果宏大。 簡而言之，C Builder同時兼具C 程式語言的威力和Visual Basic這種 Rapid Development Tool的視覺化程式開發環境的便利，土法煉鋼或必先利其器，決定就在你了。 ********************************************************************** 作者：李維 我的回憶和有趣的故事-C/C 聖戰篇[長篇] http://epro2000.myetang.com/programmer/LiweiAndBorland.htm http://www.cstudent.com/freebbs/vt-acss-it/messages/107.shtml ********************************************************************** 發表人 - jackkcg 於 2002/10/06 13:14:13

------
**********************************************************
哈哈&兵燹
最會的2大絕招 這個不會與那個也不會 哈哈哈 粉好

Delphi K.Top的K.Top分兩個字解釋Top代表尖端的意思,希望本討論區能提供Delphi的尖端新知
K.表Knowlege 知識,就是本站的標語:Open our mind