Win:D

引用:

原帖由 肥料森 於 2012-1-7 23:25 發表

幾多年後的事?

Win:D

岩岩睇完龍虎門 訓覺

Win:D

引用:

原帖由 肥料森 於 2012-1-8 21:21 發表

點解正係win7先用到架

桌面冇乜用架  你要咁諗

你平時上網 都睇唔到桌面 係開機先睇到 睇得個1分鐘 好少架  唔洗咁張緊

Win:D

引用:

原帖由 碎．星 於 2012-1-8 21:47 發表
+1 如果機廢 怕LAG死你

你同我講有得用 我都整左一個 win7先可以整多幾個..

Win:D

引用:

原帖由 碎．星 於 2012-1-8 21:55 發表
WIN7 好煩架BO

問題好得多 唔似xp 答一次搞店

Win:D

引用:

原帖由 碎．星 於 2012-1-8 22:01 發表
唉 好想變反XP

win7好型  不過係煩少少...接受下啦..

Win:D

引用:

原帖由 肥料森 於 2012-1-8 22:04 發表

點先可以有win7?

買碟囉 再唔係燒碟...

Win:D

引用:

原帖由 碎．星 於 2012-1-8 22:05 發表
好型咩                             .

相對xp黎講 型架..

Win:D

引用:

原帖由 碎．星 於 2012-1-8 22:06 發表
出面有一個POST 係少時 有條友勁煩 我就快忍唔到

比個2條友係地9up
有支持 就會有反對

Win:D

引用:

原帖由 　ゞ.__κJa1. 於 2012-1-8 22:06 發表
仲有人用xp= =

我宜加用緊xp  買新機都唔知win7好定xp好

win7有人可以借碟比我裝 ...

Win:D

引用:

原帖由 碎．星 於 2012-1-8 22:09 發表
新機最好係WIN7

佢個隻碟 32bit  
有d唔係咁想用...down game都煩過人

勁舞啊 個d

Win:D

引用:

原帖由 碎．星 於 2012-1-8 22:08 發表
野小孩 E條友 我忍唔到

你唔好回 等佢回乜

Win:D

引用:

原帖由 碎．星 於 2012-1-8 22:12 發表
如果 32BIT煩 64BIT叫咩

http://zh.wikipedia.org/wiki/32%E4%BD%8D%E5%85%83
http://zh.wikipedia.org/wiki/64%E4%BD%8D%E5%85%83

2者唔關煩唔煩事

Win:D

引用:

原帖由 碎．星 於 2012-1-8 22:18 發表
係你話DOWN GAME煩-_-
其實64係唔係勁過32?

咁就當然

down勁舞 win7要down哂佢d更新 慢慢更新
仲要整相容性 轉反xp

Win:D

引用:

原帖由 碎．星 於 2012-1-8 22:22 發表
明白了
64勁32 D咩? 容量大左?

32 與 64 位元從 32 位元到 64 位元架構的改變是一個根本的改變，因為大多數作業系統必須進行全面性修改，以取得新架構的優點。其它軟體也必須進行移植，以使用新的效能；較舊的軟體一般可藉由硬體相容模式（新的處理器支援較舊的 32 位元版本指令集）或軟體類比進行支援。或者直接在 64 位元處理器裡面實作 32 位元處理器核心（如同 Intel 的 Itanium 處理器，其內含有 x86 處理器核心，用來執行 32 位元 x86 應用程式）。支援 64 位元架構的作業系統，一般同時支援 32 位元和 64 位元的應用程式。
明顯的例外是 AS/400，其軟體執行在虛擬的指令集架構，稱為 TIMI（技術獨立機器介面），它會在執行之前，以低階軟體轉換成原生機器碼。低階軟體必須全部重寫，以搬移整個 OS 以及所有的軟體到新的平台。例如，當 IBM 轉移較舊的 32/48 位元「IMPI」指令集到 64 位元 PowerPC（IMPI 完全不像 32 位元 PowerPC，所以這比從 32 位元版本的指令集轉移到相同指令集的 64 位元版本的規模還要龐大）。
64 位元架構無疑可應用在需要處理大量資料的應用程式，如數位視訊、科學運算、和早期的大型資料庫。在其它工作方面，其 32 位元相容模式是否會快過同等級的 32 位元系統，這部分已有很多爭論。在 x86-64 架構（AMD64 和 Intel 64）中，主要的 32 位元作業系統和應用程式，可平滑的執行於 64 位元硬體上。
Sun 的 64 位元 Java 虛擬機的啟動速度比 32 位元虛擬機還慢，因為 Sun 仍假定所有的 64 位元機器都是伺服器，而且只有為 64 位元平台實作「伺服器」編譯器（C2）。[1]「客戶端」編譯器（C1）產生較慢的代碼，不過編譯較快速。所以儘管在 64 位元 JVM 的 Java 程式在一段很長的週期會執行的較好（一般為長時間運作的「伺服器」應用程式），它的啟動時間可能更久。對於短生命期的應用程式（如 Java 編譯器 javac）增加啟動時間可控制執行時間，使 64 位元的 JVM 整體變慢。
應當指出，在比較 32 位元和 64 位元處理器時，速度並不是唯一的考量因素。應用程式，如多工、應力測試（stress testing）、叢集（clustering）（用於HPC）可能更適合 64 位元架構以正確部署。為了以上原因，64 位元叢集已廣泛部署於大型組織，如 IBM、Vodafone、HP、微軟。
[编辑]優缺點一個常見的誤解是：除非電腦安裝的記憶體大於 4 GB，否則 64 位元架構不會比 32 位元架構好。這不完全正確：

• 部分作業系統保留了一部分行程位址空間供作業系統使用，減少使用者程式可用於對映記憶體的位址空間。例如，Windows XP DLL 以及 userland OS 元件對映到每一個行程的位址空間，即使電腦裝有 4 GB 的記憶體，也僅剩下 2 至 3.8 GB（端視其設定）的可用位址空間。這個限制在 64 位元 Windows 中不會出現。
• 檔案的記憶體對映不再適合 32 位元架構，尤其是相對便宜的 DVD 燒錄技術的引入。大於 4 GB 的檔案不再罕見，如此大的檔案無法簡單的對映到 32 位元架構的記憶體，只能對映檔案的一部分範圍到位址空間，並以記憶體對映存取檔案。當有需要時，就必須將這些範圍對映進或對映出位址空間。這是一個問題，因為充裕的記憶體對映仍是從軟碟至記憶體最有效率的存取方法，如果作業系統能適當實行的話。

64 位元架構主要的缺點是，相對於 32 位元架構，佔用相同的資料會消秏更多的記憶體空間（由於腫漲的指標，以及其它型態和對齊補白等可能）。這會增加行程對記憶體的需求，且可能會影響高效能處理器快取的使用。解決方法之一是維持一部分 32 位元模型，且大致合理有效。高效能導向的 z/OS 作業系統便採取這個方法，要求程式代碼存放在 32 位元位址空間的任一數字，資料物件則可（選擇性）存放在 64 位元區域。
目前主要的商業軟體是建立在 32 位元代碼，而非 64 位元代碼，所以不能取得在 64 位元處理器上較大的 64 位元位址空間，或較寬的 64 位元暫存器和資料路徑的優點。然而，免費或自由軟體作業系統的使用者已經可以使用專有的 64 位元運算環境。並非所有的應用程式都需要大量的位址空間或操作 64 位元資料項，所以這些程式不會享受到較大的位址空間或較寬的暫存器和資料路徑的好處；主要受益於 64 位元版本的應用程式，並不會享受到使用 x86 的版本，會有更多的暫存器可以使用。



我唔睇 你自己睇