freaky_jon wrote:
.NET應用程式執行的時候也是先編譯成native code才跑的，查一下NGen和JIT就知道了。
Microsoft已經展示過ARM版的Office，原則上應用程式只需要用能產生ARM machine code的compiler重新編譯就好了
managed code 有 managed code 的限制,
就算最終轉成 native code, 但還是有限制...
就像是 c++ code 最終還是改成 machine code,
而有些事, 還是要靠 assembly code 才能做得到.
(
memory 管理就是一個重大區別,
在 c++, 我可以 malloc 一大塊 memory, 不用初始化, 自行管理,
在 mangaed code 就不行..
(memory map of file 做檔案處理..)
)
freaky_jon wrote:
.NET從MTS->DCOM->COM+一路演化過來，規模已經不是問題
MTS/DCOM/COM+ 這些是屬於 OS平台 層級的, 且通常是 native code 的,
不是 .Net..
(mono 在 linux 上有 MTS/DOM/COM+ 嗎? 我不太清楚)
(如果有, mono 在 linux 上的 COM+ 上有提供跟 MS COM+ 上一樣的服務嗎?..)
(如果沒有, 那些 COM+ 很容易 porting 上嗎?)
(同樣的問題... WindowsPhone7 上有提供跟 M S在 windows COM+ 上一樣的服務嗎?..)
一個方式是 OS 在底層提共大量的原生原件(如 COM+, 需要效能, 最核心變化不多的)
在上層再有 managed code 原件去控制(能更有彈性)..
有點像在 managed code 把 IE 當成一個元件 (不過這個原件太大了...) 之類的...
這也是我前面寫的,
ec wrote:
不過, java 問題相對的比 .net 多,
.net 的出發點是能盡量發揮平台上的優勢,
而 java 是希望維持各平台上的相容性,
另外一個, 當初有一些計畫用 java 寫 browser, 也是失敗的.
james-bc wrote:
錯~swing 的 ...(恕刪)
嗯 各位大大說得都對 害小弟也癢起來想補充一下:
.NET程式其實就是為了要避開NATIVE CODE 所以它最後會被編譯成為可以一體通用(?)的CIL 然後讓號稱是VM的.NET FRAMEWORK來執行它 跟JAVA/J2EE原理相同
MS(挨罵了 就不寫$了)當初的野心是希望它的程式能像JAVA一樣跨機器跨平台 達成DCOM/COM+/DNA的宏大規劃 所以就發明了.NET FRAMEWORK這樣的東西來作為骨幹 打算正面與SUN的JAVA一決高下 小弟之前提到的MONO 其實就是.NET FRAMEWORK的LINUX野人版本 由IBM開發來作為LINUX跟其他系統下的.NET VM
可是 .NET程式還是會有執行效率的問題 並不見得比JAVA有更好的表現 而且.NET FRAMEWORK也沒有在一開始就達成相容性的目標 只因為它對COM的依存性太大 而COM並沒有真的做到各版本相容(跟DON BOX發明COM的原意又相違背了) 結果就連累了上層的.NET FRAMEWORK 使得早期的開發者對它幹聲連連 紛紛轉向了JAVA的懷抱...
.NET FRAMEWORK的許多功能其實是以COM WRAPPER的型式來達成 而不是重寫內容使之能夠獨立於WIN32跟COM之外 結果是沒有COM/WIN32的作業系統就安裝不了.NET FRAMEWORK 使它仍然受限於WINX的籌範之內 不能真的跨平台跨系統 最後還是成為WINX的寄生蟲(不是真正獨立的VM) 並敗給了J2EE...
WHY? 因為COM/WIN32和.NET FRAMEWORK不是OPEN SOURCE 所以人家就算有心也幫不了它 除非MS願意OPEN SOURCE或是非常努力地寫其他平台的WIN32/COM跟.NET FRAMEWORK 否則它永遠也比不贏JAVA...(後者的努力 人所共見)
MONO則是把.NET FRAMEWORK所有的底層重寫 使它成為完整的OPEN SOURCE VM 所以MONO有一大把的架構支援 詳情請參考:
http://www.ibm.com/developerworks/cn/linux/l-mono/index.html?ca=dwcn-newsletter-linux
呵呵 小弟功力差 就知道以上這些了...
另外 回ec大的話: MONO底下沒有COM 但有類似COM的東西 一樣是WRAP到各系統相對應的底層去了
還有 有人提到用.NET方式重寫MS OFFICE 老實說 .NET FRAMEWORK可能還沒有成熟到可以跑這麼大的東西 主要是它裏面的CONTAINER都還沒有完備 小弟覺得現階段的.NET FRAMEWORK實在不可能把OFFICE裏的所有元件完全再現 或許有人正在努力補完中也說不定...
MONO連MAC OSX跟WINXP/2K都能搞出支援用的JIT 算是大水沖倒龍王廟了 呵呵 不愧是IBM...
LeonHong wrote:
FRAMEWORK來執行它 跟JAVA/J2EE原理相同
J2EE 我印象中, 是跟 網路/Web/DB 比較有關的東西,
相對於 .net 相關的比較像是 WebService ...
如果說是要寫 local 平台的軟體, 像 office, browser,
用到的應該是 J2SE(手機的話, 就用 J2ME), 而不會用到 J2EE.
(
我寫過 J2SE 軟體,
也寫過 J2ME peronal profile 前身的 persnal java(是不是這個名字啊),
在 SonyErcisoon P800 上面可以跑的軟體, 但沒碰過 J2EE.
J2ME 的 MIDP 也寫過一些小程式測試
現在的 J2XX 也都改名叫 Java XX 了...
)
andorid 的 java 應該是自己改的, 不屬於這幾類吧!
ec wrote:
J2EE 我印象中,...(恕刪)
ec大 請查照:
Java EE
呵呵 小弟太久沒摸JAVA 竟沒注意到已經改名了(J6EE?) (-.-)#
嗯 爽快承認自己是寫錯字了 請您原諒... m(_ _)m
以Java來評.net有點不太客觀
現在微軟作業系統都開始C sharp化了,C sharp 化等同於 .NET化
理當其他的應用程式(IE, Visual Studio, office)也慢慢同理 .NET化
自然 non managed code會慢慢減少
.NET具有可移植性
所以後來的作業系統可支援的硬體會越來越多<----這方面就很像Java
=========================
我意思是
Java那邊很簡單的只要對應用程式做升級改版的動作就好
但是微軟這邊卻是要從更底層的作業系統層那裡開始改起
後來慢慢往上變動
所以會讓人覺得動作很慢
它又有向前相容的包袱.....
反正就是麻煩啦
chanmingtao wrote:
我感覺大大出身是走J...(恕刪)
chanmingtao大大您說得很對 可惜的是.NET FRAMEWORK的PORTABILITY其實並不是來自#化或MANAGED CODE 而是來自REMOVAL OF COM/WINX DEPENDENCY!!
很諷刺對不對? 你永遠擺脫不了COM跟WINX 即使你用的是.NET FRAMEWORK...
MONO就是在這樣的背景下誕生的產物 算是對MS的一種抗議? 徹底的REMOVAL OF COM/WINX DEPENDENCY!!
所以 ARM版的WIN8意義非常重大 這說明MS終於正式插手到消費跨平台這一塊領域了 以後跑NATIVE ARM INSTRUCTION SET COM/WIN32/WIN64 應該是很愉快的一件事 而且 #化跟MANAGED CODE終於要大力發揮它的作用了!! (MS你何時才會注意到消費跨系統呢? 嘆氣...)
至於難昇級的部份 當然也是來自.NET FRAMEWORK WRAPPER對COM/WINX的依存性 你不能只升級.NET FRAMEWORK WRAPPER 那樣是沒用的 你一定得動到底下的COM才能修正功能... 天啊 那是多大的工程!!
REGISTRY裏那一大堆GUID 說明了WINX有多依賴COM
可是當初DON BOX並不是這樣規劃的!!
幫他叫個屈先...
然後 偶覺得其實MS的COM MAP實在搞得太浮濫了 系統都沒有按照一開始的規劃去發展 然後搞繼承(就亂WRAPPING而已啦)亂拉一通生出一堆似是而非的表哥表弟 不但弄得版本號凌亂不堪 還會浪費記憶體又降低執行效率 更是妨礙了升級跟跨平台的可能性!!
應該把這一大堆COM元件都整併合成為較少個多功能的精英份子 這樣就會對執行期效率有明顯的幫助 尤其是已經過時的那一堆都併成單一個才好 然後把所有過時的INTERFACE跟FX都湊在它身上!! 為了相容性是應該留它不死 但是要用載入不用丟著 這樣不是很好嗎?
內文搜尋
從 APP 打開
X