c++圣战.htm

csdn10年中间经典帖子

C/C++吧。它的Think 
C/C++在Macintosh上便是非常有名的編譯器，因此早在C/C++領域便有深厚的基礎。在Symantec併購了PC上第一個C/C++編譯器Zortech 
C/C++之後，Symantec進入PC的開發工具市場也是箭在弦上了，只可惜的是其時Symantec還未找到一個在PC上有豐富經驗的開發工具領導者。<BR>也許是上天注定要引起稍後的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++編譯器最佳化方面的表現也不會輸給其他的編譯器。<BR><BR>當時我在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++了。<BR>對我的感覺而言，Symantec C/C++就像是一個技藝精良，又裝備華麗的C/C++軍團。<BR><BR><BR>Watcom 
C/C++的發展史<BR><BR><BR>真是非常有趣的是，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++開發工具。<BR><BR>不知道還有多人記得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軟體最成功的軟體公司。<BR><BR>談到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培養出來的。<BR><BR>在Watcom 
C/C++於DOS市場佔穩了腳步之後，由於Window已經逐漸成為市場的主流，DOS勢必將被逐漸淘汰出局，因此Watcom 
C/C++要繼續的生存下去，也一定要推出Window平台的C/C++開發工具。大約也是在1993，1994年左右Watcom終於推出第一個Window的開發工具。<BR>不過當時Watcom 
C/C++在Window推出的C/C++開發工具實在是平凡不已，其整合發展環境和另外三個對手比較起來簡直像是遠古的產品，一點特色都沒有，不過Watcom 
C/C++仍然是以它的最佳化編譯器做為號召。因此在當時發生了一個非常有趣的現象，那就是許多軟體公司會同時買Borland C/C++，或是Visual 
C/C++，Symantec C/C++之一，再搭配一套Watcom C/C++。在開發應用系統時使用其他三套開發工具之一，最後要出貨時再使用Watcom 
C/C++來編譯以產生最佳的程式碼。<BR><BR>在Watcom C/C++推出了Window平台的開發工具之後，仍然吸引了一群使用者，雖然Watcom 
C/C++的市場比起其他的三家來說是最小的，但是也在一方撐起了一片天，成為四大C/C++開發工具之一。稍後Watcom 
C/C++被Sybase併購，並且成為後來Sybase的Optima++的前身。<BR><BR>對我的感覺而言，Watcom 
C/C++就像是一個穿著樸素，但是卻擁有最佳訓練的白色C/C++軍團。<BR><BR><BR>關鍵的時刻-MFC Or 
Not<BR><BR><BR>在Symantec C/C++和Watcom 
C/C++逐漸的站穩了腳步之後，四大編譯器決戰的時刻也逐漸逼近了。在1994年未的決戰之前，Symantec和Watcom同時面對了一個非常嚴厲的考驗，那就是C/C++ 
Framework的選擇。<BR><BR>雖然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。<BR><BR>在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。<BR><BR>對於這一點我認為Borland還是做了一個正確的決定，因為如果當時Borland也License 
MFC，那麼不但在氣勢上便輸了一截，而且當MFC的發展是完全掌握在Microsoft的手裡，那麼就等於脖子是掐在別人的手裡，動彈不得了。可惜的是Symantec和Watcom並沒有看清這一點，以為有了和Microsoft一樣的Framework，就可以在其他地方和Microsoft以及Borland一決雌雄，Symantec和Watcom卻沒有想就是這一點決定讓後來的決戰一敗塗地，終究完全推出PC的C/C++開發工具市場。<BR><BR>時序到了1994年未，C/C++開發工具的四大天王決戰的日子終於愈來愈近了。<BR><BR><BR>OLE的攪局<BR><BR><BR>不知道是時運不濟或是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失敗的重要因素。<BR><BR>我還記得當時OLE似乎成為了一個令人趨之若鶩的時髦功能，因為Word的文件能夠內嵌在Excel之中，並且可以點選此Word文件，應用程式又立刻成為Word來編輯它，實在是令人覺得非常的神奇。不過在其時所有的軟體廠商中只有Microsoft的應用程式有如此的功能，其他的廠商例如Lotus，WordPerfect等都無法實作出這種功能。這造成了不公平的競爭，因為OLE技術是由作業系統廠商Microsoft推出的，但是卻讓它的應用程式部門同步擁有這種技術，而其他的軟體廠商都無法獲得第一手的OLE技術來實作，這是為什麼當時其他的軟體廠商如此火大的原因。<BR><BR>雖然後來其他的軟體公司在取得了OLE的技術資訊之後也推出了具備OLE功能的應用程式，但是畢竟是慢了Microsoft許久，市場也流失了許多。不過我也很奇怪的是在當時內建OLE功能的應用程式之中，幾乎所有的軟體廠商推出的應用程式在啟動數個應用程式而且使用OLE之後，就非常容易的當掉，只有Microsoft的應用程式不太會發生這種情形，因此許多人便認為Microsoft有隱瞞一些技術沒有讓其他的廠商知道。<BR><BR>由於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++使用，就是這關鍵的一點讓其他三家廠商吃了虧。<BR>對於OLE這個關鍵技術的影響，Borland是深知在心的，因此在計劃在Borland C/C++ 
4.5的OWL 2.5中支援OLE。當時Borland推出的解決方案便是OCF(Object Component 
Framework)。<BR><BR>Borland當初在設計OCF時有幾個重大的目標。這些目標包括了: 一、如何能夠使得OLE瑣碎 、複雜的介面能夠單純化; 
第二、如何能夠使得OLE在視窗環境下寫程式的思考方式 一致化--即使用「事件驅動」的方法。第三、如何能夠在微軟佔盡天時、地利(未必人和) 
的情況下使得Borland的產品具備OLE的功能。第四、如何能夠讓大多數C++的程式師都能夠享受OLE的功能而不侷限於OWL的程式師。由於上述的設計目標, 
而造就了典雅而具有彈 性的OCF。由於OCF本身是一完整而獨立的Framework, 
因此它可適用於各種應用程式發展Framework。<BR><BR>不曉得各位使用過Borland 
C/C++的朋友們是否還依稀記得下圖OCF的架構圖之一，以及下面的OCF範例程式碼，這些可是我把1994年寫的文章挖出來之後找到的，真是令我感慨，也回想起了當時的情景，也讓各位回憶一下OWL和OCF。對於不熟悉OWL和OCF的朋友，也可以從下圖和程式碼中觀察一下當時的技術以及設計的概念。基本上我現在看這些圖形架構，會發現它們並沒有落後現在太多，可見當時設計者的功力(Carl 
Quinn Again)。<BR><BR><BR><BR><BR>//<BR>// Insert an OLE object into the 
view<BR>//<BR>void TOleWindow::CmEditInsertObject()<BR>{<BR>001 
PRECONDITION(OcView);<BR>002 TOcInitInfo initInfo(OcView);<BR><BR>003 if 
(OcApp-&gt;Browse(initInfo)) {<BR>004 TRect rect;<BR>005 
GetInsertPosition(rect);<BR>006 SetSelection(new TOcPart(*GetOcDoc(), initInfo, 
rect));<BR><BR>007 OcView-&gt;Rename();<BR>008