c++圣战.htm

csdn10年中间经典帖子

InvalidatePart(invView);<BR>}<BR>}<BR><BR>程式1 
OWL的TOleWindow支援OLE插入物件之成員函數<BR><BR>//<BR>// Handle left double-click 
message<BR>//<BR>void TOleWindow::EvLButtonDblClk(uint modKeys, TPoint&amp; 
point)<BR>{<BR>PRECONDITION(GetOcDoc() &amp;&amp; GetOcView());<BR>TOleClientDC 
dc(*this);<BR>dc.DPtoLP(&amp;point);<BR><BR>TOcPart* p = 
GetOcDoc()-&gt;GetParts().Locate(point);<BR><BR>if (modKeys &amp; MK_CONTROL) 
{<BR>if (p)<BR>p-&gt;Open(true); // Ctrl key forces open editing<BR>}<BR>else 
{<BR>SetSelection(p);<BR><BR>if (p &amp;&amp; p == 
GetOcView()-&gt;GetActivePart()) { // resync the active 
flag<BR>p-&gt;Activate(false);<BR>}<BR><BR>GetOcView()-&gt;ActivatePart(p); // 
In-place activation<BR>}<BR>}<BR><BR><BR><BR>程式2 
OWL的TOleWindow支援左鍵雙擊之成員函數<BR><BR><BR>雖然Borland及時的在OWL 
2.5中加入了OLE的支援，無奈Microsoft隨後又在OLE中加入了許多其他的功能，因此讓OCF並無法完整的支援OLE所有的功能，Borland又無法不斷的延後Borland 
C/C++的推出，因此在1994年未，Borland終於推出了決戰的4.5版本。<BR><BR><BR>C/C++開發工具的最後聖戰<BR><BR><BR>『雖然已經過去了許久的時間，但是我仍然忘不了那場最慘烈的戰役!』<BR><BR><BR>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的則是以紅色為色系，仿佛兩大軍團終將決戰似的。<BR><BR><BR><BR>C/C++四大天王決戰一役的Borland主將-Borland 
C/++ 
4.5<BR><BR><BR>不過這次的戰役不光是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軍團很快的就敗陣下來。<BR><BR>至於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也是如此。<BR><BR>對於Symantec和Watcom來說，這場戰役就如同『長平之戰』，秦軍坑殺40多萬趙軍一樣。殺得Symantec和Watcom全軍覆沒，大敗而歸，至此Symantec棄受PC的C/C++開發工具市場，轉而開始研發Java開發工具，進而在稍後推出了著名的Visual 
Cafe, 至於Eugene 
Wang則離開了Symantec，自此也離開了PC開發工具的領域。<BR><BR>而Watcom則是更為悽慘，整個公司在DOS的市場逐漸式微，而Window平台的開發工具又大敗而歸，兩頭落空。不久之後Watcom便被新興而起的Sybase併購，從此消失於競爭激烈的市場。<BR><BR>歸納Symantec和Watcom失敗的原因是C/C++的Framework 
MFC掌握在Microsoft手中，在決戰時刻Microsoft居然手握比Symantec和Watcom更新的MFC利器，而且在Visual 
C/C++精進最佳化的技術並且改善整合發展環境之後，Symantec和Watcom訴求的重點功能完全被Microsoft封死。因此在產品，技術，市場和氣勢上完全不如對手的情形下，自然只能任人宰割了。<BR><BR>對於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的浴火重生，再重新出發。<BR><BR>經過這一役之後，Microsoft終於清除了大部份的對手，對於Microsoft而言程式語言開發工具的戰爭已經結束，這個市場注定將被Microsoft佔據大部份的市場。在Microsoft手握作業系統，Office軟體和開發工具三大獲利市場之後，Microsoft也開始將矛頭對準下兩個競爭目標，關連資料庫以及主從架構開發工具。在Microsoft正式進軍這兩個市場之後，當然也展開了連番的好戲，尤其是在主從架構開發工具方面又開啟了VB，PowerBuilder，Gupta/Centura和Delphi的驚天動地大會戰。另外一個意外開啟的戰爭則是Microsoft在1995年和Netscape的挑起的瀏覽器大戰。<BR><BR>對於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是否能夠重新找回這個失去已久的精神，不要再讓我失望了。<BR><BR><BR><BR><BR>永不成氣候的C/C++開發工具-IBM VisualAge 
C/C++<BR><BR><BR>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++等工具比較起來就像是恐龍一般，因此幾乎沒有在市場上引起任何的反應。<BR><BR>在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和其他編譯器的比較：<BR><BR>從上面的數據中可以看到其實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的顧慮下，最後還是沒有答應。現在想想當時真是太笨了，放著好賺的稿費不賺，嘻。<BR><BR>IBM的C/C++開發工具之所以在市場無法成功是一是因為並不瞭解在此競爭激烈的市場中使用者到底要什麼。另外一個原因則因為IBM並不以PC上的開發工具軟體為重要的事業，即使無法競爭對於IBM來說也沒有什麼影響，不像Borland這可是生命之爭。因此IBM只是興起玩玩，隨即放下。所以我覺得在PC平台使用IBM的工具是很危險的，因為IBM可能隨時會放棄此市場。例如不知道現在VisualAge 
C/C++到底如何，是不是還在3.5或是4.0版，已經數年沒有任何的維護和改善了。<BR><BR>稍後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一樣才好．<BR><BR><BR>快速殞落的潛力之星－Sybase的C/C++ 
RAD工具Optima++<BR><BR><BR>在1996年吧，Sybase併購了Watcom之後，終於推出了石破天驚的C/C++開發工具，Optima++。Optima++是當結合了Watcom的最佳化編譯器以及類似Delphi的元件拖曳開發環境的第一個RAD 
C/C++開發工具，更棒的是Optima++的元件架構(類似Delphi的VCL)完全是以純正的C/C++程式碼撰寫的。這可不得了，因為這代表Optima++是一個融合了Visual 
C/C++和Delphi兩大王者開發工具為一身的超級賽亞人工具。<BR><BR>在我知道這個工具，並且取得實際的使用之後，令我極為震驚。因為這個工具對於我這個使用了C/C++ 
5,6年的人來說，是比Delphi還具有吸引力。因此在當年我立刻的在RUN!PC上介紹了此不可置信的工具。果然，Optima++很快在開始風捲市場，雖然沒有立刻的佔據很大的市場量，但是已經造成了一股氣勢，開始為Visual 
C/C++和Delphi帶來了壓力。<BR>我記得當時台灣Sybase辦的產品發表會也吸引了數百人與會，不可一世。在我的RUN!PC文章出版之後，台灣的Sybase立刻和我連絡。由當時的余協理和我見面，也是希望我繼續為Optima++寫文章，台灣Sybase也提供額外一字加2元稿費的待遇。但是我告訴余協理，Optima++ 
1.0雖然很棒，但是仍然有一些臭蟲，而且和中文環境相衝突，無法處理中文，需要立刻的解決問題才能夠在台灣的市場成功。她答應我立刻的向總公司反應。我也老實的告訴她在問題沒有解決之前我無法寫一些不確實的東西。後來台灣Borland的總經理方先生也找我去詢問有關Optima++的事情，我告訴他Optima++是好東西，但是中文有問題。如果中文問題能夠解決，那麼將對Borland的產品有很大的影響，當時我還不知道Borland由於Optima++的影響，已經開始準備發展C++ 
Builder。<BR>在1996年底左右吧，Optima++ 
1.5終於進入Beta的階段，但是在我拿到Beta版時仍然非常的失望，因為中文的問題仍然沒有解決。後來台灣Sybase又找我去，這次和我見面的是台灣Sybase總經理郭俊男先生，以及Sybase的新加坡技術總裁，不過我忘記這位先生的名字了。我們見了面之後，我立刻的把Optima++ 
1.5中文的問題以及許多的臭蟲告訴他們，希望他們能夠解決，如此Optima++ 
1.5才能夠在中文市場成功。可是出乎意我意料的是，他們似乎並不急著這些問題，反而詢問我是否有意願為Sybase工作，做PowerBuilder的產品經理。<BR><BR>也許是因為我為Delphi寫了太多的東西，讓PowerBuilder受了很大的影響，因此他們希望我到Sybase工作，以打擊Delphi並且Promote 
PowerBuilder。當時他們提出的待遇條件實在是非常，非常的誘人，比我當時的薪水高出一倍左右（我當時在資策會工作）。不過由於我對PowerBuilder實在沒有什麼興趣，因此我告訴他們如果是做Optima++的產品經理，那麼我將會考慮並且接受。<BR><BR>沒有想到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成功的進入這個工具市場。<BR><BR>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++競爭時每一個版本都有大幅的改善。看來寡佔的市場的確是不好的。<BR><BR>As Promised-李維<BR>Edited by - Gordon 
Li on 11/01/2001 18:53:06<BR><BR></BODY></HTML>