📄 c++圣战.htm
字号:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<!-- saved from url=(0034)http://abc.diy5.com/ustone/ccz.htm -->
<HTML><HEAD><TITLE>C++圣战</TITLE>
<META content="text/html; charset=gb2312" http-equiv=Content-Type>
<META content="MSHTML 5.00.3315.2870" name=GENERATOR>
<META content=FrontPage.Editor.Document name=ProgId></HEAD>
<BODY bgColor=#000000 text=#ffffff>
<H2 align=center>C++圣战</H2><BR>Borland C/C++的反擊 <BR><BR>當Microsoft Visual
C++ 1.0 在C/C++開發工具市場獲得了空前成果的之後，Borland 才從Borland C/C++ 3.1的勝利夢中驚醒，思考如何面對Visual
C++的猛烈功勢。事實上當時的Borland如果腦袋清醒一點，好好看清當時C/C++開發工具的市場，那麼Borland應該會發現雖然 Visual C++
經過2年多的整軍經武，實力已經大不前。不過Borland C/C++ 3.1仍然在許多方面可以和Visual C++一爭長短的。例如其時Visual
C++的最佳化編譯器仍然落後Borland C/C++ 3.1一些，第2點是MFC仍然沒有完整的封裝Window
API，而且MFC是以較低階的方式封裝Window API，並不是很物件導向，也不是很容易使用。事實上以我的觀點來看，我認為就是因為 MFC 不好用，因此
Visual C++ 才需要在整合發展環境中提供以視覺化方式產生 MFC 程式碼的功能，第3是Visual
C++當時並沒有很好的封裝資料結構的Container Class，而Borland C/C++卻有非常好用的BIDS類別庫。第4，也是最重要的，Borland
C/C++ 3.1仍然擁有絕大的市場，而且幾乎所有的週邊公用程式，Shareware等都是使用Borland C/C++
3.1開發的。因此如果Borland不要急，好好的開發下一代的C/C++開發工具，即使Microsoft Visual
C++能夠掠奪一些市場佔有率，但是如果下一代的Borland C/C++能夠像Borland C/C++ 3.0一樣立刻拉開和Visual
C/C++的距離，那麼Borland在C/C++市場仍將擁有王者的地位。<BR><BR>可惜的是，也許Philippe
Kahn在和Microsoft的FoxPro For Window一役中被嚇到了，因此急於在Visual C/C++ 1.0之後立刻推出新的Borland
C/C++以扳回顏面。但是Philippe Kahn忘了，在這段時間之內Borland失去了許多的人材，Eugene
Wang也離開了，更重要的是在過去近3年的時間之內，Borland幾乎沒有持續的開發下一代的Borland
C/C++，在短時間之內如何能夠倉促的推出產品呢?<BR><BR>但是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。<BR>上面所說的每一項都是大工程，Borland早應該在Borland
C/C++ 3.1之後便開始做這些工作，現在要在短短的一年多的時間內重新開發一個這麼複雜的C/C++開發工具，幾乎是不可能的工作。但是在Philippe
Kahn的要求之下，這些Borland的工程師還是硬著頭皮做了出來。<BR><BR>不過我必須很沈痛的說，當時我在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的人。<BR><BR>但是很顯然的Borland並沒有聽到我的，或是其他Beta測試人的心聲，在Visual C++ 1.0推出後的1年多，Borland
C/C++ 3.1後的4年，Borland終於推出了新一代的Borland C/++ 4.0，這個肩負和Visual C++
1.0對抗的C/C++開發工具。<BR>在Borland C/C++
4.0剛推出之際，Borland確實為4.0做了極大的造勢，我記得在當時所有重要的電腦雜誌中，例如Byte，PC Magazine，Dr.
Bob等，都有4.0整頁的廣告。這個廣告的內容是以一個巨大的貓頭鷹為主，再搭配藍色底色系的Borland C/C++
4.0為主，選用巨大的貓頭鷹當然是因為OWL的原因，只可惜我現在找不到那幅廣告了。<BR><BR><BR>當時Borland使用了如下的廣告用詞
:<BR><BR>『Visual Is Only A Facial Facade』<BR><BR>來諷刺Visual
C/C++只提供了產生MFC程式碼的基本精靈，而Borland除了也提供相對應的AppExpert精靈能夠提供類似的功能以產生使用者選擇的OWL程式碼之外，Borland
C/C++
4.0的整合發展環境還提供了視覺化的3面版視窗，能夠讓程式師完整的掌握整個專案的情形。<BR>例如在下圖中便是當初令人眼睛為之一亮的AppExpert：<BR><BR>還記得Borland提供的AppExpert嗎?<BR><BR><BR>下圖則是當時Borland
C/C++的註冊商標，3面版視窗開發環境。看到下圖又令我想起當初使用C/C++寫程式的日子，下方程式碼面版清楚的顯示了我在1995年於鼎新工作時寫的智慧型Window排程系統，時間過得是真快啊。<BR><BR><BR><BR>令人懷念的Borland
C/C++ 4.0整合發展環境，三面版視窗<BR><BR><BR>當時Borland C/C++
4.0的3面版整合發展環境真是開創了一個新的局面，因為這個整合發展環境允許程式師知道每一個應用程式定義的視窗訊息，並且能夠立刻的顯示在下方的程式碼視窗中，的確是非常的方便，也比當時Visual
C/C++的整合發展環境來得先進。再加入Borland較為先進的編譯器技術和架構更好的C/C++ Framework-OWL，照理說Borland C/C++
4.0應該會獲得極大的勝利，那麼為什麼最後會以失敗收場呢？<BR><BR>沒錯，在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滑鐵盧的主要原因：<BR><BR>*整合發展環境方面-臭蟲太多，容易當掉而且反應速度緩慢<BR>*編譯器方面-最佳化玩得過火，產生錯誤的編譯程式碼<BR>*OWL方面-採用全新的多重繼承架構，雖然是正確的做法，卻和Borland
C/C++
3.1中的OWL不相容，造成許多程式師無法昇級C/C++專案<BR>*VBX方面-大膽的採用在16/32位元都能使用VBX的技術，造成一些VBX無法順利的在Borland
C/C++ 4.0中使用<BR><BR><BR>我想其中最可惜的就是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小組的努力。<BR><BR>我記得當時我的專案有使用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推出了根本不堪用的產品。<BR><BR>在我於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的直接介入，造成人事不和也有很大的原因。<BR><BR><BR><BR>David I.說『We Screwed it up!』 ，『It’s a
mess』<BR><BR><BR>在Borland C/C++ 4.0快速失利之後，Borland也體認到問題的嚴重性，因此立刻的著手開發Borland
C/++ 4.0的Patch，當時是稱為Service
Pack。但是在稍後的4.01版中並沒有完全的解決問題，一直要到4.02才稍為解決一些嚴重的問題，無奈時不我予，拖的時間太長，市場已經起了巨大的變化。<BR><BR>在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++來撰寫應用程式。<BR>Borland在3個主要的應用市場接連敗退，C/C++的江山注定將易主，其勢已不可挽。<BR><BR><BR>Borland
C/C++，Visual C/C++，Watcom C/C++和Symantec C/C++的纏鬥<BR><BR><BR>自Borland C/C++
4.0一役大敗之後，Borland在C/C++市場上建築的巨大堡壘似乎再也不是牢不可破了。Visual C/C++固然在不斷的接收Borland
C/C++失去的市場，此時在C/C++市場上也加入了另外兩個堅強的對手，那就是Symantec C/C++和Watcom
C/C++。<BR><BR><BR>Symantec C/C++的發展史<BR><BR>說起這兩個對手也都是個個來頭不小，先說Symantec
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -