不要用原來那個標題了
北丐洪七公
我也沒什麼時間吵。論文還有要修改的地方。
奇怪的是，
我開始說我不要再活在萎卵控制的世界裡，要換到unix和x去過我自主的生活，
馬上就有兩位網友咬上來了。
不曉得是萎卵主義者被人罵怕了，看到什麼不爽萎卵的都要趕快反撲回去還是怎麼的？
說實在的，我還真的因為這一系列的post感到很灰心。
我以前也在自己很窮的時候還硬著頭皮去買office。
也曾拿著手冊一點一滴地教別人用。
那些名為電腦白痴的人，他們的要求可不一定白痴！
有時候為了迎合他們高水準的要求，真的是翻遍手冊，絞盡腦汁。
也因此累積了不少的經驗和旁門招術。
可是有人就是可以一口咬定是別人使用的水準不夠，來支持自己的高姿態。
抱歉，我不會吃這一套的。
我不相信msyu先生能夠解決office的問題會比我多多少。
很多user根本還不需要ole/automation這種東西，就已經被office搞瘋了。
現在的我還是一樣隨時回答身邊任何人對於萎卵軟體中雜七雜八的問題的。
我的出發點始終都是：能夠多教會一個人不怕電腦，就是一件好事。
以後他會、他熟、他喜歡什麼公司的軟體、喜歡什麼公司，
都不是我所關切的。
我很賭爛萎卵，我想它不變我也就不會變的。
可是不是一開始就如此。
我更沒有認為它一路把dde、ole等等帶到今天更廣泛、更物件導向的
activex、com、dcom等等不是一件好事。
但是萎卵的手段，讓我無法不覺得它背後的用心是醜惡的，
是充滿著操控的意圖、是把商業利益排在技術之前，卻用技術來掩藏它的。
我覺得萎卵現在在這些方面的領先，並不是因為他真的最關切、或是最強。
我真的覺得他是靠著開始時的運氣加上現在的手段形成現在的假象的。
就以office和wordpro的競爭來看好了。從純粹最基層的使用者所看到的來說。
當wordpro announce它的許多功能之後，office也宣稱馬上會有同級產品了。
挾著以往大批的user的優勢，有多少end user會在office宣稱上市的一季前
花錢換另外一套軟體？
要曉得end user換用軟體需要多少時間？一個公司更不能不把這考慮進去啊！
所以，即使領先推出，也無法撼動市場。因為萎卵的基礎和lotus不一樣。
它只需要用嘴皮子和人打，就可以先擋住一陣子。
可是接下來看到的，是office一再的延後出貨。beta來beta去，
出貨了還要patch。它的正式版delay了兩季還是三季？有人記得嗎？
我是沒記那麼多，反正麻木了。
最後的成品，請問大家，比wordpro好的地方有多少？
wordpro又有多少地方是office還做不到的？
不要比現在，比wordpro 1.0和word7.0吧！
其它的東西，誰能說不是這樣？別人提出的solution，萎卵也宣稱他有，
user只能在不明究裡的情況下觀望。
「利不十不變法，功不百不易器」，這是很多人的通病。
等觀望到別的公司撐不住了，當然只看到萎卵做出來的solution啊！
那時候，不管你是擁護萎卵的或賭爛萎卵的，你當然都不能否認
萎卵的東西最好，萎卵的東西最先進。因為沒得比啦！
也許，現在不懂com、com+、dcom的精神的，最了不起只能說是活在五年前。
但是誰敢說如果不是萎卵這樣惡性競爭，我們不會在五年前就已經有了
同樣概念、甚至品質更高的solution了呢？
這就好像有人在問，如果沒有牛頓，我們是不是到現在還不曉得萬有引力？
如果沒有高斯，我們是不是到現在還不懂什麼是常態分布？
有時候歷史不能夠這樣去看、去評斷的。
當牛頓壓下萊布尼茲投的稿子，並宣布他早就做過微積分的研究，
到現在還不是有人認為牛頓做弊，還寫文章罵他？
怎麼，萎卵是不能罵的嗎？
我看到的是，這樣子商業掛帥、無所不用其極的萎卵，
在概念上是非常醜惡的，是反智的、是很可能阻礙知識的進步的。
我也看到有非常多人和我一樣。
在news group flame 比爾該死 和萎卵的group可熱鬧著呢！
我覺得，憑我們這些人任何一個的力量，都不足以和萎卵目前的力量相抗衡。
誰要說我：「沒看到你有拼過萎卵的能力」，我也承認。
只是這樣比有意義嗎？
不過，不曉得大家有沒有看過一本小書叫「猴子啟示錄」。
我相信認清萎卵之作為真正的害處的人會越來越多，
我相信會有一天大家都會賭爛萎卵，讓它垮臺的。那會是個有趣的相變。
美國人也花了很長的時間才發展出反托拉斯的概念。
他們已經了解過托拉斯的背後可能象徵著對進步的阻礙。
而知識、智慧的進步是人類最珍貴的寶藏。不能因為利益阻礙了它，
更不能掌握在獨夫手裡。
這是我所相信的，是我現在仇視萎卵的原因。
技術的問題，你們當然可以壓我。我本來就沒受過半點科班訓練。
可是我相信真理不在你們那裡。
--
[m※ Origin: 臺大電機 Maxwell 站 ◆ From: 140.109.112.145
ms...@oboe.cs.nchu.edu.tw
北丐洪七公 (o...@bbs.ee.ntu.edu.tw) 提到:
: 也許，現在不懂com、com+、dcom的精神的，最了不起只能說是活在五年前。
: 但是誰敢說如果不是萎卵這樣惡性競爭，我們不會在五年前就已經有了
: 同樣概念、甚至品質更高的solution了呢？
我跟你舉過當年Macintosh還擁有相當市場佔有率時的case.
事實上OLE這東西基本上做的就是subscribe & publish, 只是從資料換成物件。
這是幾年前的事情了呢? 不只五年了, 七八年有吧。
當年Macintosh上的辦公室套餐軟體混戰只會比後來Windows 3.x/95市場上
更激烈(因為大小公司林立), Microsoft也不握有作業系統的優勢, 握有作業
系統環境優勢的是Apple/Claris的組合。你有用過Claris Works for Mac嗎?
Apple提出了subscribe & publish, AppleScript, Apple也是把GUI OS第在
個人電腦平台上做得商用化而且平易近人的第一個廠商, 今天我們看到的很
多Windows上的工作方式跟思考方式, 如果Apple不是第一個提出來的, 就是
第一個實作出來賣的。
結果呢? 今天你可以找個有Mac的人問問, 看看現在Windows上有的技術跟
環境是不是可以在Mac上找得到一樣或更好的對應。你看看Mac OS上有人
proprose一個標準的object model嗎? 雖然程式開發工具都標榜著OO,
每個程式的object卻跨不出應用程式跟應用程式間的鴻溝。所謂的物件,
到這裡為止, 做的都還只是將過去那一大疊的GUI/OS routine包裝起來
的工作。
Apple沒有認知到一個向下延伸到作業系統層次的標準物件系統架構的
重要性, IBM有, 他們提出了SOM. 那有比COM早嗎? 我不知道, 也許IBM
在跟M$合作設計OS/2之前, 就已經在mainframe上使用這個架構了。
OK, 那問題很簡單了, 這種延伸到作業系統層次的標準物件系統, 如果
不是由OS vendor來作, 那有誰做得出來呢? 使用IPC/RPC當然可以做,
不過那至少也要是個大公司或者具公信力的組織。
你說會更早有人提出這樣或更好的方案, 我不能同意你的說法。
在歷史上, open system的觀念開始被提出來, 是在Sun跟Microsoft差不多
分別取得工作站級電腦盟主地位與個人電腦作業系統盟主地位之後, 差不多
就是1993～1994, 在之後, 其他廠商才開始跟隨所謂開放式系統的口號,
而打的仍然是獨家系統的牌; 這到最近兩三年才有顯著改觀。
Sun OS上很早就有RPC了, 可是沒有標準的object model; 其他各家
UNIX vendor也或多或少都早就有自己的RPC方式, 可是一直到OSF DCE RPC
出來, 大家才同意這樣一套統一的RPC用法。至於IPC, 除了pipe/socket,
一直到今天, 各家UNIX vendor都還沒有統一的shared memory用法。
IBM也許很早就有SOM了, 可是有誰用呢? IBM只在乎自己的solution可以在
客戶面前work, 並不在乎別的廠商用不用它的solution來開發東西, 因為
在mainframe的環境上, 大概也只有他自己一家公司, 剩下的都是租購
mainframe的公司裡的MIS/programmer......誰會把這種環境下寫給自己
用的程式拿出來賣人?
工作站應用軟體的環境也是類似, 除了OS vendor的套裝軟體跟一些廠商
為各平台分別開發的工程與科學應用軟體, 剩下的就是一大堆有免費原始碼
可以取得的東西, 而這些免費的東西就有如散沙, 除了FSF在作有系統的
發展, 還有誰在這種各個廠商各行其事的環境下做系統性的發展呢?
(所以應用軟體傾向憑一己之力完成所有事情也沒什麼好奇怪的)
當工作站市場盟主非Sun莫屬時, 工作站價位也差不多開始與高階個人電腦
重疊了, 當時的個人電腦資料庫套裝軟體盟主安信達(it's too long ago..
I forgot how to spell it in english)除了推出dBase for Mac, dBase
for Windows, 還在各工作站平台上(主要是Sun OS上)推出dBase. 結果是
dBase IV慘敗, 安信達被Borland買了下來。
在這種大環境下, 你覺得有人會認為讓一個程式能夠和其他程式以物件導向
的方式跟其他程式合作是一個很重要的特性嗎? 當年的JOOP上要看到一個
object model的字眼都還不容易哩, 大部分的討論都還是在述說C++要有哪
些特性(To collect garbage or not? To handle exceptions or not?),
STL? 那時候有這種東西?
Borland一向標榜自己是PC上OO的盟主, 無論哪一個版本的BC++ compiler
在推出時都擁有當時獨一無二最先進的C++特性, 甚至連AT&T本家的C++
to C translator可能都沒有的特性, BC++都有了。Turbo Pascal for
Windows跟BC++最早有OWL 這樣的OO application framework.
可是到這裡為止, Borland跟其他廠商一樣, 都只思考到怎樣讓OO在單一
軟體計劃裡頭加強programmer的效率－而不是勾繪出一個應用程式間的
OO溝通方式與環境。Who did this? Microsoft. 也許IBM最先想到要有
個object model來讓應用程式間能夠以OO的方式溝通跟合作, 也許還有
其他廠商或組織要更早想到, 可是Microsoft最早把這個COM大眾化商用。
這裡的意義是, 不只是propose一個object model, 而且公開它, 歡迎
大家來使用這樣的架構－an open system. Apple出過很多guideline
book, 告訴大家如何在Mac OS的環境下遵循Apple的規範來寫程式, 可是
就我印象所及(until 1993), Apple並沒有提出過一個object model讓
程式寫作者對這方面有個遵循方向。
當年市場上最了解OO的重要性的, 一個是Borland, 一個是Microsoft,
兩個都是主要的個人電腦程式開發工具生產商, 兩個也都賣商用套裝
軟體－只差在Borland的商用套裝軟體都是向別人買來的, Microsoft
是自己做的－到頭來, Borland還是把向別人買來的Paradox跟Word
Perfect又賣給了別人。
其他廠商? 你能指望當年誇稱 123的macro可以做任何事的Lotus嗎?
(就算能做任何事, 又如何呢? 那又不是我的程式, 能在123裡頭作
而不能在我的程式裡頭作, 對我一點用也沒有; 何況它並不真的能
作到任何事)
還有其他廠商, 又花了多少年, 才了解為什麼OO很重要, 才想到要
推出一個CORBA來對抗Microsoft? CORBA又花了多少年才制定出來?
現在RFC裡頭有DCOM, 可是沒有CORBA.
很多人到現在都還不了解為什麼OO很重要, 不是嗎?
四眼的王蟲
ms...@oboe.cs.nchu.edu.tw () wrote:
>還有其他廠商, 又花了多少年, 才了解為什麼OO很重要, 才想到要
>推出一個CORBA來對抗Microsoft? CORBA又花了多少年才制定出來?
這種說法有問題吧, COM 是在 1993 年 Microsoft 隨著 OLE2 一起
發表出來的, 而 CORBA 1.0 卻是在 1991 年就已經制定出來了, 這樣
能說是 CORBA 是為了對抗 COM 才制定出來的嗎? 我看是相反才對。
Microsoft 又是為甚麼不願意支持 CORBA 這個標準而自己搞一套
COM/DCOM 出來? 是否真的 COM/DCOM 的技術優於 CORBA 呢?
我是不這麼認為。 Microsoft 即使支持一項標準也是常常多加一些
有的沒有的東西就像 Java 的情形那樣, 目的是要將大家綁死在
Windows 上。
>現在RFC裡頭有DCOM, 可是沒有CORBA.
DCOM 不還是 Internat Draft 的階段而已嗎?
四眼的王蟲
--
生命是在黑暗中閃爍的光
Jiang-Shing Wang
> DCOM 不還是 Internat Draft 的階段而已嗎?
"Distributed Component Object Model Protocol -- DCOM/1.0", 03/11/1998,
<draft-brown-dcom-v1-spec-03.txt>
的確還在 draft.
RFC, 嘿.
ms...@oboe.cs.nchu.edu.tw
四眼的王蟲 (dy...@ms1.hinet.net) 提到:
: >推出一個CORBA來對抗Microsoft? CORBA又花了多少年才制定出來?
: 這種說法有問題吧, COM 是在 1993 年 Microsoft 隨著 OLE2 一起
: 發表出來的, 而 CORBA 1.0 卻是在 1991 年就已經制定出來了, 這樣
: 能說是 CORBA 是為了對抗 COM 才制定出來的嗎? 我看是相反才對。
底層基礎? 如果我沒記錯, OLE是首先出現在Word/Excel for Mac 4.0上,
差不多就在Mac OS 7.0發表的那一段時間裡頭。
在過去幾年裡, 你有看過Microsoft拿COM跟CORBA相比較嗎?
SOM vs. COM, OpenDoc vs. COM, 這類的爭論在1995年以前看了不少,
大多時候也是拜許多人不認為Win95有OO的成分在內, 或者是OS/2 or
Mac的擁護者用來將Win95當作一個較爛的OS而提出來的－其中又有
大部分的討論者只是將SOM或OpenDoc當作圖騰來膜拜。COM vs. CORBA,
差不多可以說在Java開始hot起來, MSIE又加入web browser戰場後才
開始熱門起來。
提到OpenDoc, 我不能不說我之前忘了提它。會忘了的原因很簡單,
OpenDoc SDK還在beta階段, Apple, IBM, Borland這幾個最主要支持
它的廠商就放棄他了。Apple提出一個構想, 往往都是基於實際應用上
的需要, 諸如Truetype, Rich Text File (right, it's a joint work
from Apple and Microsoft), Subscribe and Publish, AppleScript,
and, OpenDoc. OpenDoc最早的構想是, Apple想提出一個叫做Bentou的
文件格式, 能夠支援不同的資料型態的整合, 你也可以把物件放進去－
bentou者, 便當也, 純日文發音。
結果? OpenDoc始終只聞樓梯響, 一直到去年才公開OpenDoc SDK for Mac beta.
(compared to OLE SDK for Win 3.x, 在1992年已經可以在M$的FTP
site上找到了) 然後這個苦命的孩子就被爹娘給拋棄了, 連Apple
都宣佈放棄這個東西。以後倒是可以等著看Mac OS X有什麼新東西。
OK, 有個很現實的問題, OLE是先有實作跟應用, 然後才整理出規格,
(所以要說OLE零亂也不奇怪, 一路修改過來跟增加的介面就夠人頭暈)
而CORBA卻是一堆人訂出來的－誰先實作出來呢? IBM說SOM也有遵循
CORBA的規範, 推動OpenDoc的人們也說OpenDoc會遵循CORBA的規範。
這是蠻令人疑惑的, 因為按照這種說法, OLE/COM/DCOM也算是分別
遵循CORBA 2.0跟2.1的溝通方式了(2.0/2.1分別納入跟COM/DCOM合作
的特性)。
: Microsoft 又是為甚麼不願意支持 CORBA 這個標準而自己搞一套
: COM/DCOM 出來? 是否真的 COM/DCOM 的技術優於 CORBA 呢?
: 我是不這麼認為。 Microsoft 即使支持一項標準也是常常多加一些
: 有的沒有的東西就像 Java 的情形那樣, 目的是要將大家綁死在
: Windows 上。
我也不認為COM在OO上的完整性會比CORBA好, 不過在我的觀念裡
(my personal view, yes), CORBA就好像一個妥協出來的產物,
每個成員都想從裡頭得到自己想要的東西, 於是IBM也可以宣稱SOM
遵循CORBA的規範, 而OpenDoc也可以說自己遵循CORBA的規範,
連Microsoft都可以說COM跟CORBA可以互通(一點也不意外吧?),
那在這裡的問題就是, 互通是互通到哪種程度呢? 遵循又是遵循
到哪種程度? 而真正實作出來的系統, 又作出了多少符合標準的東西?
如果到處可以看到sorry, not implemented yet or not defined yet,
那當然是很有趣的一件事了, 就好像Sun當初也宣稱Java支援CORBA,
結果反倒是M$先讓它在實作上支援COM了。
大家制定規格時, 本來就是為了實作上的需求與實際上的需要。
M$在M$ JDK裡頭加入國際化的語文支援方案後, Sun一直到JDK 1.1
才有完整的支援; JNI/RMI的功能, 也是M$先實作自己的辦法出來實踐。
還有其他幾項Java特定功能的解決方案, 往往都是M$跑在Sun之前。
你覺得該怪M$在Java上亂加自己的東西? 我還想怪Sun制定標準的速度太慢。
至於Java支援CORBA的功能, 大家去看看J Builder 2.0的功能,
再回頭看看Sun JDK.
: >現在RFC裡頭有DCOM, 可是沒有CORBA.
: DCOM 不還是 Internat Draft 的階段而已嗎?
這倒是我失察了, 很抱歉。 :)
ps. 我很歡迎大家來糾正我記憶與觀念不清楚的地方, 但是謝絕肚爛。
嵐雲
==> 在 ms...@oboe.cs.nchu.edu.tw () 的文章中提到:
: 四眼的王蟲 (dy...@ms1.hinet.net) 提到:
: : 這種說法有問題吧, COM 是在 1993 年 Microsoft 隨著 OLE2 一起
: : 發表出來的, 而 CORBA 1.0 卻是在 1991 年就已經制定出來了, 這樣
: : 能說是 CORBA 是為了對抗 COM 才制定出來的嗎? 我看是相反才對。
: OLE2是在1993年發表, 不過OLE呢? 可以想想, OLE又是拿什麼東西當
: 底層基礎? 如果我沒記錯, OLE是首先出現在Word/Excel for Mac 4.0上,
OLE 的底層是透過 DDE.....
DDE 底層則是透過一些 Window Merssage 的傳送..
並沒有 COM 這種 model...
就我覺得,
OLE 到 OLE2 的改變, 就如
Win3.1 到 WinNT 的改變,
就有 外觀上,上層變化不大, 而底層是完全不同的.
: 差不多就在Mac OS 7.0發表的那一段時間裡頭。
: 在過去幾年裡, 你有看過Microsoft拿COM跟CORBA相比較嗎?
: SOM vs. COM, OpenDoc vs. COM, 這類的爭論在1995年以前看了不少,
bbs 上, 我好像也寫一些 :)
小明
哈，有趣，大家來講古 :)
《 在 ms...@oboe.cs.nchu.edu.tw () 的大作中提到: 》
: 在這種大環境下, 你覺得有人會認為讓一個程式能夠和其他程式以物件導向
: 的方式跟其他程式合作是一個很重要的特性嗎? 當年的JOOP上要看到一個
: object model的字眼都還不容易哩, 大部分的討論都還是在述說C++要有哪
: 些特性(To collect garbage or not? To handle exceptions or not?),
: STL? 那時候有這種東西?
Object Model 的字眼很早就有了吧? 不然 OMT 是幹什麼的? :)
而且說實在的，在一些物件導向程式語言中，程式間的物件共享是個基本功能呢。
STL? 那更早了，早在 C++ 剛有 template 的時候，就有人提出這樣的概念了。
當然，有概念、甚至已經做出來了，事實上不會有太大的作用，
在 Windows 3.1 推出的前後，我們一票人就在討論 DLC (Dynamic Linkage
Class) 了，而且就有討論到跨平台和分散式物件，為此還想做 general 的
VM，這是幾年前的事呢? Java 也不過如此不是嗎?
然後聽說 Borland 要做，結果搞了老半天也沒看到。
今天你說大公司的歷史如此，但大公司之外許多研究者的努力，
就這樣埋沒在歷史的煙塵裡。
class library
dynamic linkage class/object
standard dynamic class/object
standard distrubuted class/object
事實上這樣的概念一路下來，是很自然的，接下來還有一堆東西可做，
如今在很多年後變成了一堆名字漂亮的標準。我一直覺得不爽說。
: Borland一向標榜自己是PC上OO的盟主, 無論哪一個版本的BC++ compiler
: 在推出時都擁有當時獨一無二最先進的C++特性, 甚至連AT&T本家的C++
: to C translator可能都沒有的特性, BC++都有了。Turbo Pascal for
: Windows跟BC++最早有OWL 這樣的OO application framework.
: 可是到這裡為止, Borland跟其他廠商一樣, 都只思考到怎樣讓OO在單一
: 軟體計劃裡頭加強programmer的效率－而不是勾繪出一個應用程式間的
: OO溝通方式與環境。Who did this? Microsoft. 也許IBM最先想到要有
: 個object model來讓應用程式間能夠以OO的方式溝通跟合作, 也許還有
: 其他廠商或組織要更早想到, 可是Microsoft最早把這個COM大眾化商用。
這裡牽涉到 OLE 的問題，Microsoft 在 Visual C++ 中用 virtual table
直接和 OLE 合在一起，記得為此 Stroustrup 還公開罵微軟，
後來還找 Symantec 推出標準的 C++ compiler。Borland? 別提了，
這兩家公司眼中都只有 PC ，根本不把程式語言的標準看在眼裡。
一般化的物件標準，特別是給應用程式之間分享的架構，
從來是學術討論中的題目，而 Java 事實上也是一個還可以的實作。
在許多物件導向支持者的眼中，application 這件事根本只是一些物件的包裝，
一個最佳的物件訊息傳遞系統才是問題。
我們今天看得到的軟體產業，事實上落後學術討論許多，
不管是正統的學術，還是一些非學術界的研究者。
微軟的問題是蠻幹，像個原始人一樣，看到什麼就衝，
我們還在細細研究如何避免某些可能很嚴重的問題以提出好的標準的時候，
微軟就推出新東西了，所有討論過的弊病全都犯盡，但它又強力推銷，
明明較好的概念就這樣任意被浪費掉了，真的很令人生氣。
然後一堆公司又要拿研究者的未完成品，打包成另一個標準以對抗微軟，
唉，粗暴的電腦產業，什麼都在搶最早，最早就好嗎? 能夠商用當然好，
但先把品質做到自己滿意才對吧，為什麼軟體的世界就可以不講品質?
而這居然還發生在一個小地方弄錯就可能造成重大災難的高科技產業裡。
我喜歡 IETF，它是研究人員對抗這些混蛋公司的團結象徵，
而且終於站上台面做個公正的評判者。但軟體技術還沒有人做這樣的事，
到現在大家都還是開口閉口就是那些軟體公司。
我自己很想做，但力量不夠。
: 很多人到現在都還不了解為什麼OO很重要, 不是嗎?
很多人到現在眼中都還只有這些大型軟體公司的身影，
我希望人們能多尊重在這些身影背後，或者不在這些身影遮庇下的研發人員。
他們的夢想才是科技世界進步的動力。
所有這些新技術，世界上都有數以千計的研究人員在各地早就想到了，
只是你未必認識他們，或者很可能只看見他們在期刊上寫的東西。
今天有誰知道 Alan Kay 呢?
微軟是做了很多事，但它也是這群混蛋中的一個混蛋老大。
--
我不搞這些東西很久了，只是忍不住講講話
--
[m [1;36m※ 來源:‧蛋捲廣場 bbs.tku.edu.tw‧[FROM: 163.13.93.101] [m
北丐洪七公
※ 引述《ms...@oboe.cs.nchu.edu.tw ()》之銘言：
: ps. 我很歡迎大家來糾正我記憶與觀念不清楚的地方, 但是謝絕肚爛。
我現在鄭重為這點抱歉。
大家說出那麼多的歷史和對歷史的觀感，是很有益處的事情。
請大家(有空的)繼續多寫些。
我會找時間把有意義的內容剪到maxwell的精華版。
不過我還是想說一句，我第一篇post可沒有賭爛的成分，
大家不要反應過度。天氣熱，大家多喝杯茶把它忘了吧！
心裡賭不賭爛，那是個人感受，不要再把它帶出來了。
握個手交個朋友吧！
ms...@oboe.cs.nchu.edu.tw
嵐雲 (EightCl...@csie.nctu.edu.tw) 提到:
: OLE 和 OLE2 差多了,
: OLE 的底層是透過 DDE.....
: DDE 底層則是透過一些 Window Merssage 的傳送..
: 並沒有 COM 這種 model...
在OLE2的環境下使用了, 所以舊的OLE API必須繼續保留下來。
可是證諸Win32 API各環節, 或者更往前推, 16-bit WIN API,
OLE2有增加新function call, 可是沒有刪除舊的function call.
我比較有興趣的是, OLE/COM怎樣進行不同process之間的marshaling. :p
是不是使用DDE來進行, 應該是很好觀測到的, 因為DDE就提供了application
monitor的功能, 讓一個應用程式可以監督整個系統上所有的DDE動作。
: : 差不多就在Mac OS 7.0發表的那一段時間裡頭。
: : 在過去幾年裡, 你有看過Microsoft拿COM跟CORBA相比較嗎?
: : SOM vs. COM, OpenDoc vs. COM, 這類的爭論在1995年以前看了不少,
: bbs 上, 我好像也寫一些 :)
看很久了....:)
嵐雲
: : OLE 和 OLE2 差多了,
: : OLE 的底層是透過 DDE.....
: : DDE 底層則是透過一些 Window Merssage 的傳送..
: : 並沒有 COM 這種 model...
: 有漏洞, 如果有基礎上的API改變, 過去的OLE application就不可能
: 在OLE2的環境下使用了, 所以舊的OLE API必須繼續保留下來。
它本就是要隱含實際系統的 implemnetation,
同樣使用 Win32 API, NT 和 Win95 是完全不同的東西,
同樣是 NT kernel, 可以透過不同的 subsystem, 提供
OS/2, Win32, POSIX 等 API!
何陋居主
>> DCOM 不還是 Internat Draft 的階段而已嗎?
> 這倒是我失察了, 很抱歉。 :)
而且, 談開放物件系統, 不先提到 OMG, 甚至 ODMG, 反而提 RFC...
相當奇怪的一件事... :p
--
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
≡ 何陋居 ≡ 一個人的最佳讀書狀態大多產生在中年以後，
但能否取得這種狀態則取決於青年時期的準備。 《余秋雨台灣演講》
-- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
--
* Origin: ★ 交通大學資訊科學系 BBS ★ <bbs.cis.nctu.edu.tw: 140.113.23.3>