WWDC 2005 相關討論請至此留言！

內容

Watcher! · #181 文章由 **Watcher!** » 06/13/2005 4:42 am

我可能憂慮的比較偏囉！冰狐發言的語氣不太像是在討論哩！這倒是鶴立雞群呀！哈哈！冰上的狐狸都比較優秀吧？還是在這塊園區的稀有異族呢？呵呵！

icefox · #182 文章由 **icefox** » 06/13/2005 9:30 am

janusng 寫:
icefox 寫:...當年 Apple 的 OS 7 夠複雜夠獨特了吧？裡面還一堆 68K 的組合語言，Apple 只花了四五個月十多個工程師也都 port 到 486 上去跑了。...
未聽過，有佐證嗎？

Star Trek 計畫

http://www.macdevcenter.com/pub/a/mac/2 ... tml?page=1

更有意思的是 "and Star Trek running on an Intel 486-based system ran faster than Macintosh System 7 running on a PowerPC."

還有 part1 提到 NeXT 曾一度在短時間內 port 到四個平台上，將 porting 視作該公司的 business model! 也就是有名的 Fat Binaries，那時候大家就已經為 porting 難易和 performance 問題早就吵過了。爾後，NeXT 就一直保有良好的 portability... 所以很快就能 port 到 PPC 上頭，只是為了解決
1. 封閉架構的缺乏 documents
2. classic/carbon 相容性
3. JAVA APIs
才讓 Mac OS X 需要花這麼長時間來進行改版，同時改進整體效率，到現在才有餘力轉換平台了。事實上 Apple 早在 2002/2003 時就已經透露只要 Mac OS X 逼近過半 (40%) 就會認真考慮搬家到 INTEL 平台上頭的事情。

janusng · #183 文章由 **janusng** » 06/13/2005 10:41 am

icefox 寫:Star Trek 計畫

http://www.macdevcenter.com/pub/a/mac/2 ... tml?page=1
...

Star Trek 是有聽過，但除了知道他是一個 Mac OS x86 porting 的傳聞外，從未知得如此詳細！

謝謝啦！

aladdin · #184 文章由 **aladdin** » 06/13/2005 11:05 am

icefox 寫: 4. 連 Mathematica 這麼複雜古舊的程式只要搞兩小時就搞定了，幹麼讓開發商有一年可以混？而且還有 Rosetta 可以對中小型程式頂一頂。或許是為了讓今年買 Mac Mini 的人不要太難過。但是在商言商，佈陣這麼久，不是在等死嗎？Steve 在想啥？

如果我是Steve Jobs，已經搞了那麼多年的double life，為什麼挑這個時候明著搞琵琶別抱？

答案很簡單：iPod。如果你已經有了一個東西可以讓你撐起你的利潤，不在這個時候換，要在什麼時候換？

是的，mac的主機銷售會降低，但是有ipod頂著，今年可以對股東交代得過去。而且我怎麼看，switch到Intel都是利多。不要忘記，Apple在這個時間點，是全世界公認最強勢的品牌，主機賣得比Sony、IBM貴一大截都有道理。買部mac跑個windows，放在高階主管的桌上，是非常「讚」的炫耀性消費——至少比擺部黑不溜秋，難看得要命的IBM要有品味（是的，我就打算這麼幹）。所以，過了今年的硬體銷售低潮，明年強勢推intel mac，Steve Jobs可以保持蘋果的股價在可操作的範圍。

icefox · #185 文章由 **icefox** » 06/13/2005 11:12 pm

一個 macrumors.com 的網友 MagnusDredd 的深入分析，正好解釋了我這幾篇發言的觀念。文末還正好提到剛拿到 Apple Design Award 的 Best Mac OS X User Experience 的 "有用" "Mac 專屬" 程式只花了 40 秒就 port 完成，我估計這個月我們會聽到很多諸如此類的故事。

觀點不同或疑問大可以提出來討論，如果沒頭沒腦罵人笨蛋，又說不出個所以然來，只能說是自取其辱。

PPC, Cell, x86 (part 1)
The switch to Intel is the obvious result of what is, and has been going on with regards to the companies in question.

1) Apple, started with the 68k, moved to PPC when it became apparent that 68k was not going anywhere. Had good luck on a few occasions, 603e hit 300Mhz before Intel or AMD. Altivec is damned powerful, in the uncommon cases that it's greatly useful. However when the G4 couldn't exceed 500Mhz for what seemed like forever... It began to really hurt. The IBM move was likewise an obvious choice at the time. Although the Legacy NeXT-based stuff was very portable, the albatross of classic was hanging around OSX's neck keeping it on PPC. At that time PPC was the only option. The IBM 970, all in all, is an incredible CPU with a great deal of promise. Fully utilized, it has the capacity to stomp anything Intel makes currently into the ground. Unfortunately GCC does not generate very optimized code for it, even after the work Apple did to make it better. IBM has XLC, as well as XLF, that generate code that will outperform GCC in nearly every instance by a mile, except that it was never made available for use by Cocoa or Carbon apps. The code can be optimized by hand, but that takes tons of develoepr time. PPC assmbly gurus are less plentiful than x86 ones, and since the Mac market is as small as it is, it's hard to convince a developer to spend tons of time optimizing by hand, since that can kill their profits. So while extremely optimized code would have made the CPU kick serious butt, very few apps are really seriously optimized to take full advantage. Furthermore the G5 generates too much heat to be moved into a laptop, and seemed to be that way for the forseeable future. Which leaves Apple using Motorola/Freescale chips which don't even have a DDR FSB yet, and while Motorola/Freescale does make CPUs that do have a better FSB, they are so seriously targeted for the embedded market that they cannot be used.

This left Apple in a terrible predicament. However they had a wildcard, and that is that NeXTStep is the most multiplatorm friendly OS ever made. So they can move to an completely alien architecture, and with a few tweaks, most Cocoa apps are ready to go onto another platform in less than a day or so. What should be realized is that if Apple does the work (and it'd be quite a bit), it should be just as easy for a Cocoa developer to port their apps to Itanium, or Xscale, or whatever the next thing that comes around is. And have one copy of their app "just work" on all platforms without any issues by the end user at all. As a matter of fact, NeXTStep already had this ability (68k, PPC, x86, PA-Risc) years ago.

More on the other companies after I eat dinner....

Note: Delicous Library was Intel-Mac compatible with only a recompile, which reportedly took 40 seconds.

the real unknown · #186 文章由 **the real unknown** » 06/14/2005 4:57 am

這位文抄公。你這麼辛苦在網路上東抄西抄，還有時間寫 Mac 的程式嗎？

哦？你不寫 Mac 的程式？還是你的姐姐的兒子的老師的表姐的外婆的初戀情人的隣居路上不小心撞死的人寫了那三千個不同的 iTune 控制界面之一給你這麼多靈感？

我真的很佩服你可以這麼從別人的二手經驗推導出這麼鐵證如山的結論：「連 Mathematica 這麼複雜古舊的程式只要搞兩小時就搞定了，幹麼讓開發商有一年可以混？」

我有三個好幾打 source files 的 Mac only, byte-order sensitive 的程式要在這一年裡混出來，所以實在沒有時間和你白費力氣，光說不做的綀打字。你自己爽吧。爽完記得用衛生紙擦乾淨，不然會生病的。

icefox · #187 文章由 **icefox** » 06/14/2005 6:43 am

原來搞了半天，就只是幾隻不注意 endian 的破爛而已，沒什麼大不了的。那種石器時代遺留下來的程式不用再改了，真的。反正沒什麼鳥用，也賣不出去兩個錢。
在史前世代的機器上，或是 Rosetta 裡偶而還能跑一跑懷舊一下就可以了。
要改 endian 又不是天塌下來的大事，調整程式結構，寫幾個 bridge functions 或 macros 在資料進出不同 storages 時作作轉換，這些早就是一般的程式技巧而已。
哈，我的確是寫不出來這種綁死在 endian 架構上的 jun*。算了，不需要和幫前人擦屁股的可憐虫廢話太多。

ulysses · #188 文章由 **ulysses** » 06/14/2005 8:22 am

icefox 寫:那種石器時代遺留下來的程式不用再改了，真的。反正沒什麼鳥用，也賣不出去兩個錢。

原來通訊協定、序列控制和串流都是史前人類在用的東西。建議閣下把網路拔掉，把 QuickTime 砍掉，順便把 USB 封掉。做完這幾件事後，閣下或許可以獲選成為自由剛彈的駕駛員。

icefox · #189 文章由 **icefox** » 06/14/2005 11:23 am

ulysses 寫:
icefox 寫:那種石器時代遺留下來的程式不用再改了，真的。反正沒什麼鳥用，也賣不出去兩個錢。
原來通訊協定、序列控制和串流都是史前人類在用的東西。建議閣下把網路拔掉，把 QuickTime 砍掉，順便把 USB 封掉。做完這幾件事後，閣下或許可以獲選成為自由剛彈的駕駛員。

從頭到尾我可沒說 big endian 是垃圾，不用想亂套過來，如果你要幫他講話，也找點有料的講。之前我也搞過 USB host/device controller programming，network 和 host order 互轉，早就是這些程式的基本功能，在 x86/UNIX 上面早就有一堆對應的 code 了，不少都是 Open Source，程式多得不得了，隻隻都避開或解決 order 問題。想靠賣這些賺錢，難上加難！或許可以騙騙部份不熟 x86 的 users。

說點新鮮的來聽聽。那種十年八年前的活化石 code 就不用再提了。

還有，如果冰果室的管理員都是這等想要偏袒你們自己的老朋友，歪曲新朋友的意見，也難怪人氣越來越差。你也不看看這串討論是那個白爛先開始亂罵人的！！！

digdog · #190 文章由 **digdog** » 06/14/2005 11:57 am

icefox 寫: 還有，如果冰果室的管理員都是這等想要偏袒你們自己的老朋友，歪曲新朋友的意見，也難怪人氣越來越差。你也不看看這串討論是那個白爛先開始亂罵人的！！！

（屈服於淫威之下的管理員說道）那... 給 TRU 一點顏色瞧瞧吧～

#191 文章由 **Alex Tsai** » 06/14/2005 3:43 pm

icefox 寫:還有，如果冰果室的管理員都是這等想要偏袒你們自己的老朋友，歪曲新朋友的意見，也難怪人氣越來越差。你也不看看這串討論是那個白爛先開始亂罵人的！！！

在下是本版管理員，但向來支持自由討論，故並未吭聲，也應該沒有任何「偏袒」情事發生，還請明察，感激不盡。

關於冰果室討論區的人氣，其實並未變差，反而有更加熱絡的情況。按照在下經營黑秀網 heyshow.com 論壇的經驗，通常網站上有言語的交鋒與衝突，反而會激發流量，這一點來看冰果室這邊的情況，是可以得證的。

但在下寧可不要因為太過意氣的交鋒而爆出來的關切流量，而是良性的互動所引發的熱烈回響。所以在此還是呼籲大家：別用比較「鋒利」的言辭，畢竟銅板沒有兩個不會響。

還請大家摒棄惡言，回歸真正的討論，否則也只有學黑秀網另闢「練打字」專區，將討論太過激烈的主題移過去了。

icefox · #192 文章由 **icefox** » 06/14/2005 5:48 pm

Alex Tsai 寫:
在下是本版管理員，但向來支持自由討論，故並未吭聲，也應該沒有任何「偏袒」情事發生，還請明察，感激不盡。

我回覆的前一位 user 左方有個 label 說他是討論區管理員，如果不是本版的，那也請以後註明一下。我來這邊被吐得莫名其妙，結果發現那位老兄是個甚麼駐站打手，尤其喜歡消遣剛上站的新手，由來已久。搞得好幾個 users 從此不敢來了，敝人好歹也對技術略知一二，玩 Mac 也超過十年了，才不會被這等裝腔作勢唬住。

現在 CNET 的報導也跑來背書了，甚至還有公司開價幾百上千美金就幫你搞定，可見難度的確不高，還有利可圖。姑且不論敢不敢把 source 交給別人的問題，花點小錢請別人搞定，總比養個跩不啦嘰的 programmer 拿蹺來得好。

----------------------------
開發者先嚐Intel Inside蘋果電腦

CNET新聞專區：Ina Fried　　13/06/2005

自6月起，蘋果電腦公司開始以每月999美元的價格，把內建英特爾晶片的麥金塔電腦租給軟體開發者使用，協助程式設計師熟悉新環境，以便把應用程式移植到英特爾架構的麥金塔電腦(Mac)。

上周一宣布明年起換用晶片的大轉折後，蘋果電腦公司便邀請開發人員提早適應新環境。儘管內建英特爾晶片的麥金塔電腦要到明年才會出廠，但在上周於舊金山舉行全球開發者會議(WWDC)期間，蘋果向開放人員開放備用展示機器的實驗室，6日和8日開放到晚間9時，7日更開放到午夜。

Fetch Software公司總裁Jim Matthews說，他經歷過前幾次的轉換期，包括1990年代中期從摩托羅拉68000系列晶片過渡到PowerPC處理器那一次，以及最近從OS 9大舉遷徙到OS X作業系統。

Matthews對蘋果這次提早告知開發人員表示肯定。「蘋果給我們充分的時間和硬體作測試，有別於上一次的情況，」Matthews說。他還說，與前幾次過渡時期相比，「我認為，本公司這次的軟體遷陡可能是受創最輕的一次」。

在明年英特爾架構麥金塔問世前，軟體開發者需要多少工夫才能把程式準備妥當，是因人而異的問題。對相對較新的麥金塔電腦程式，例如在Mac OS X推出後為蘋果Cocoa環境而寫的程式，大概只需幾小時就可搞定，甚至更快。

Delicious Monster Software執行長Wil Shipley就說：「我們的軟體已準備就緒，隨時可移植到英特爾平台，現在只需要正式啟動按鈕，約莫40秒就大功告成。本公司的軟體在WWDC預展的英特爾麥金塔電腦上執行得好極了。」

但對其他開發者而言，轉換過程比較複雜。對原本為OS X之前的作業系統版本而寫，然後用Carbon系統化始在OS X環境執行的應用程式來說，轉換的工程就比較浩大。不過，蘋果說，開發者如果當初採用蘋果的Xcode工具，頂多只需要數周的工夫。但是，假如開發者用的是Metrowerks提供的工具，就必須先把程式碼用蘋果的開發工具調整過，然後再著手為支援英特爾晶片而修改軟體。

微軟就屬於最後那個陣營。麥金塔版的Virtual PC與Office軟體都是在Carbon系統環境下開發而成，而且使用Metrowerks的工具。微軟已表明，未來的Office版本會以原生軟體(native software)的狀態在英特爾架構的麥金塔電腦上執行，但微軟尚未詳細說明Virtual PC(讓Windows程式在麥金塔上執行必備的軟體)未來的計畫，也不清楚日後需要費多大的工夫。

微軟麥金塔事業部產品經理Scott Erickson說：「我們的開發者正在研究此事。」

不過，開發者似乎大多表示樂觀。Bare Bones Software執行長Rich Siegel說，該公司已成立特別小組在蘋果提供的英特爾機器上測試程式碼，初期測試結果大致證明轉換過程沒有想像中那麼大費周章。

「經過幾天的評估和分析之後，證明我們原先對順利轉換的預測大致正確，」Siegel透過電子郵件接受訪問時表示：「還有一些地方需要調整，但沒有特別艱鉅的任務。」

看來目前為止對蘋果的決定最不悅的一群，大概是受蘋果Mac OS X吸引的高階運算客戶。近日來，在蘋果郵寄清單上，科技運算開發人員面臨的挑戰引起熱烈討論。許多人設計的最佳化(optimizations)和程式碼專為PowerPC的AltiVec指令而寫。

小型軟體公司若不想投入時間，或支付1,000美元租用英特爾機器，可請Advenio公司代為移植軟體。該公司統一開價100美元，為客戶的Cocoa應用程式建立通用二元程式碼(universal binary)，把軟體Carbon系統化的費用從500美元起跳，視所需的任務複雜度而定。（唐慧文）

ulysses · #193 文章由 **ulysses** » 06/14/2005 8:37 pm

icefox 寫:我回覆的前一位 user 左方有個 label 說他是討論區管理員，如果不是本版的，那也請以後註明一下。我來這邊被吐得莫名其妙，結果發現那位老兄是個甚麼駐站打手，尤其喜歡消遣剛上站的新手，由來已久。搞得好幾個 users 從此不敢來了，敝人好歹也對技術略知一二，玩 Mac 也超過十年了，才不會被這等裝腔作勢唬住。

在下也被 TRU 兄猛力吐過，沒必要幫他講話。只是在下覺得你把程式的移植，尤其是 Endian 的處理，也看得太過輕描淡寫了。

舉個例子：

代碼: 選擇全部

void set_parameter(void *valPtr) {
    unsigned long data;
    ...
    data = *(unsigned long *)valPtr;
    ...
}

int main(void) {
    int i = 0;
    unsigned int a = 0x1234;
    ...
    set_parameter((void *)&a);
    ...
}

原本的 Code 是在下公司授權買來的，最初是在 32-bit x86 上執行。後來移植到 16-bit 的 Little Endian MCU 上執行，也可以動。但是當負責移植的小組想移植到 16-bit 的 Big Endian MCU 平台上時，無論如何就是不會動。你寫程式的在下也不必解釋為何會當；總之他們花了很多時間徒勞無功地 Trace 每一個 I/O function，前後搞了兩個多星期才搞清楚到底是怎麼回事，搞到所有人都人仰馬翻。

沒錯，這是小白寫法。但是埋藏在十萬行 Code 中，這種 Bug 有多難找你應該很清楚。

使用 Framework 開發的程式，理論上來說應該很容易移植。但是程式的規模越大，物件 Abstract 的程度越高，前人的包袱也越重。什麼地方給你埋一個這種地雷，一腳採上去之後才急急忙忙清掃戰場，消耗的人力與成本會有多可觀，應該不難想像。

所有程式設計師都知道，寫程式要遵循 Coding Rule，要考慮不同平台。但是有多人能夠保證自己寫的 Code 絕對不會出這種白癡問題？有多少程式設計師會自願要去替前人擦屁股？對於這種情況用石器時代來形容，是否有欠厚道？如果你從來沒碰過這種事，在下只能說：你運氣真好。

另外，把 Code 交給其他公司移植，這或許對自行開發自用軟體的小公司來說很划算，對一個軟體公司的管理階層來說，這是完全不可想像的事。『100 美金就能搞好？叫那個王ｘｘ還是黃ｘｘ這個週末留下來給我改！大不了 100 美金付他當加班費！』

現實與理想還是有一段差距的。

rlong · #194 文章由 **rlong** » 06/14/2005 10:22 pm

icefox 寫:微軟就屬於最後那個陣營。麥金塔版的Virtual PC與Office軟體都是在Carbon系統環境下開發而成，而且使用Metrowerks的工具。微軟已表明，未來的Office版本會以原生軟體(native software)的狀態在英特爾架構的麥金塔電腦上執行，但微軟尚未詳細說明Virtual PC(讓Windows程式在麥金塔上執行必備的軟體)未來的計畫，也不清楚日後需要費多大的工夫。

說實在的，Virtual PC 蠻期待的！

Metrowerks我從 v5一直買到 v9, v9以前都是 Mac/Win雙語版，v9只買得起Mac版，它也學微軟要線上“啟動“，真的很好用，PC我還是得靠v8。
以後Mac得跟Metrowerks說拜拜了。

icefox · #195 文章由 **icefox** » 06/14/2005 10:35 pm

ulysses 寫: 為了這種白癡錯誤，光是要在老闆面前低頭解釋為何他沒辦法做到夾不死說的兩小時移植完畢，已經夠可憐了，有必要用石器時代這種缺德的話來強調你比別人優越嗎？

endian 的問題的確囉哩八唆，但還是沒到難以應對的層面。你們遇到的問題其實是當初輕敵，這種典型的 endian 問題其實可以利用 compiler 的 warning messatges, 利用 script 去 parse，再加上寫幾隻測試程式作 unit testing，應該可以 filter 到。不過人之常情多半都是先跑再講，等到錯誤發生了，又急著抓虫見樹不見林，搞得欲速則不達。有幾次經驗後，工具準備周全，再操刀就順手多了！

前陣子碰到的一個 FAT32 驅動程式也夠吐血的勒，那隻程式可能當初為了強調跨平台，就寫了一個 endian 轉換函數，但寫程式的老兄有時候該轉不轉，不該轉卻又轉，搞這種程式才真的是折磨人。非得先把架構圖畫清楚，再一行一行地查。也是費了一番功夫，總算清乾淨了。不過寫 firmware 就是這樣，上一次當，學一次乖，下次遇到問題時，就知道方法了。No pain, no gain。

最近正好有個傢伙在說 Open Source 的計畫會 delay 都是因為要 port 來 port 去的，馬上就有人反應說 porting 來 porting 去往往才能抓出看不到的 bug。我是贊同後者的看法，bug 就是 bug，不是沒出現就當作沒 bug...

Apple 本來就不太需要為這種小白程式設計 bug 負責，就像是你們為了某個原因要轉換平台，冒出 bug 要怪誰？不然就別賣了。Apple 轉換平台對絕大多數的 developers 來說增加了市場換機潮和佔有率，搞不好程式還能多賣一個版本，多賺的錢難道要分 Apple？總要分層負責的吧！自家程式設計有缺陷，就認為所有公司都會一起遭殃，話不是這樣講的。

Apple 也在裡面努力弄了個 Rosetta，而之前為了這些舊包袱，Apple 也是搞了半天的 classic，拖慢了最佳化系統的時程。我們總不能要求 Apple 又要是一家創新的公司，又要往後相容所有產品。

我可沒說我特別優秀，是那位老兄笨蛋來笨蛋去的帽子亂飛，而且他老兄大放厥詞說 UNIX 的 code 都是些只有蛋頭用的沒效率的 code，可真是口氣不小阿！這個站上或許 Mac 使用者多可以隨便亂騙，去跟外頭的程式高手嗆看看嘛！

rlong 寫: 說實在的，Virtual PC 蠻期待的！

VMWare 應該比較快。

另外 INTEL 和一堆硬體公司有投資一家 Open Source 的 XenSource... （又是倫敦來的公司！）
http://taiwan.cnet.com/news/software/0, ... 601,00.htm

就列在本站新聞首頁的右邊欄位中，看起來也是 Mac 走向 x86 的幕後推(黑)手之一，這玩意才更值得期待。感覺上 INTEL 布局很大，拉了很多公司共同來推它的 dual cores 和 CPU virtualization...

詹姆士 · #196 文章由 **詹姆士** » 06/15/2005 3:43 am

小弟我還不是那個高級的工程師，不管在 PC 或是 Mac 上面，我比較關心的是就算到時候新款的 Apple 機器出來了，搭配上新版的 OS X，可以得到更好的效能，但是現在購買的呢？
在新的硬體核心上會有個 Rosetta 來作為舊有的軟體轉一媒介，那原來的 PowerPC 呢？可以執行新版的軟體或是 OS 嗎？
大家都討論在新型的電腦上面怎麼執行舊的軟體，那在舊有的硬體上面可以執行新版的軟體嗎？未來新版的軟體，也會跟著核心的架構改變而改變，真的會一次出兩套，給兩個版本的硬體用？
加上 Rosetta 後，舊款的機器本來跑起來就比新款的慢，又加上要透過轉譯的媒介而降低原本執行的效能，到底多少 % 到現在雖然是還沒有個定數，但是，一定不會是 100% 就是了。
我剛踏進 Apple 的領域才不過一個月，我沒有經歷過之前幾次大轉變的時期，但是我必須被強迫參加這一次的，最近買的機器，在未來新的...組合(不知道怎麼形容)...上面執行，不只因為硬體本來就慢，還要加上 Rosetta 這個東東對執行一樣的程式的效能來打折。
一旦新機器出來，新的軟體出來，為了執行它，本來就不快的電腦，要跑得更慢....
原本 1.67G 打個八折，變成實質上只能跑在約 1.34G 左右的速度，這還是一開始，慢慢的，不再出現支援舊版的 PowerPC 系列的軟體，如果要用，就要換機？

如果你說，再買一台新的呀？！當初為了買現在這台，已經撐了多久，Apple 的產品本來就比較屬於高消費，更別說在台灣...要像換 PC 一樣換掉 Mac...說來輕鬆容易。

一台 PowerBook 筆記型電腦，只能堪用兩年？如果在更短時間內出現新款的，剛買的筆記型電腦壽命就更加簡短了，花得錢不是一般 PC 型的價位，而是高於近乎兩倍的價位購買的，生命週期卻只有近乎一半....真是吃不消

ulysses · #197 文章由 **ulysses** » 06/15/2005 8:28 am

icefox 寫:endian 的問題的確囉哩八唆，但還是沒到難以應對的層面。你們遇到的問題其實是當初輕敵，這種典型的 endian 問題其實可以利用 compiler 的 warning messatges, 利用 script 去 parse，再加上寫幾隻測試程式作 unit testing，應該可以 filter 到。不過人之常情多半都是先跑再講，等到錯誤發生了，又急著抓虫見樹不見林，搞得欲速則不達。有幾次經驗後，工具準備周全，再操刀就順手多了！

呵呵...在下同事碰到的問題，會搞那麼久，最大的關鍵就是當初寫程式的老兄很細心的加了強制型別轉換，沒有 Warning Message。

目前 Apple 推的方式很明顯的是希望所有人都盡快轉換到 Universal Binary。其實在下也不認為 Cocoa 程式轉換過去會有多困難，這類隱藏的 Bug 不至於造成很大障礙。但是需要和周邊裝置溝通的驅動程式恐怕就不是那麼好搞了。別的不說，光是 Device Tree 就不同，可以想見修改福度會很大。

其實在下倒不認為 Rosetta 會發揮多少功用。Rosetta 的限制也不少，聽起來總覺得像是自我催眠的安慰劑，讓首批衝鋒陷陣的白老鼠服用。

icefox · #198 文章由 **icefox** » 06/15/2005 8:49 am

Rosetta 只會在 x86 上面跑來模擬 PPC... 所以你的 PB 不會有打八折去跑 x86 的機會。
只要 Apple 的 x86 一開始沒吹捧開發商大力支援新硬體（如 SSE2, H.264 之類），基本上同時照顧兩個硬體平台的責任落在 Apple 身上。Developers 只負責設定 XCode 的 compiler option 就好，沒有理由不出 PPC 的道理。

此外，現在很多好用的程式其實都是 OpenSource/Freeware/Shareware... 這些 developers 都比較願意支援多種版本。不是每家軟體公司都和 MS 一樣要靠壟斷平台來謀取商業利益。

所以我想你的 PPC 大概至少可以再撐五年。別忘了，2007 年都還會有人在買 G5... 哪天 IBM 和 Apple 價格談攏了，搞不好 G6 又冒出來了。

digdog · #199 文章由 **digdog** » 06/15/2005 9:43 am

詹姆士寫:在新的硬體核心上會有個 Rosetta 來作為舊有的軟體轉一媒介，那原來的 PowerPC 呢？可以執行新版的軟體或是 OS 嗎？

腦筋不要那麼死嘛，不是都說有 Universal Binary 可以用了？

而且 Rosetta 只給 x86 用，ppc 的機器根本不需要去想這種事情。

ulysses · #200 文章由 **ulysses** » 06/15/2005 1:34 pm

digdog 寫:
詹姆士寫:在新的硬體核心上會有個 Rosetta 來作為舊有的軟體轉一媒介，那原來的 PowerPC 呢？可以執行新版的軟體或是 OS 嗎？
腦筋不要那麼死嘛，不是都說有 Universal Binary 可以用了？
而且 Rosetta 只給 x86 用，ppc 的機器根本不需要去想這種事情。

在下猜想詹姆士的疑慮是怕到時候會有 For Intel Only 的 Feature，這樣就沒辦法照顧到 PPC 的老用戶了。就像 AltiVec for PPC only 一樣。