|
||
|
Major Member
 
加入日期: Feb 2005
文章: 116
|
我也來說一下個人拙見
1. C跟PHP、Perl、VB等語言比起來是低階了點， 但是也不能算在低階，我偏好說他是中階， 因為若他是高階，那我認為大部分高階語言就要改叫高高階了。 2. 很多人還在用ASM開發小軟體(實際上其工程也不小)，以特殊團體(C...er)為多。 3. 個人討厭MFC，還是API多用用或者自己寫函式實在點， 不過很多軟體都用MFC啦，程式是用來使工作輕鬆的，故節省時間亦無不可。 4. 一般來說，我們都說Linux由C寫成，沒看過有*.cpp(這裡單指我沒看過)，或許會包含asm吧， 而依我的想法，我認為不一定要用C， 或許就像執行檔的link那樣，編譯出來的二進制檔案還是可以結合在一起使用， 但這通常難以稱作標準Linux (結論：以C寫成是「普遍說法」) 5. MicroKernel 跟有沒有用C++我感覺不到有任何關聯，可否詳加說明？ 6. 我知道「Linux整個系統」之中有用C++寫的部分 ﹝看你怎麼定義「整個」，我也可以補一個Perl的程式上去，但它不是核心﹞ 7. 中文化通常改的是Resource； CXAT只屬於簡單的中文化工具﹝無可否認，它很好用﹞； 沒看過有人常用ollydbg中文化，它比較屬於debugger。 ollydbg我想很難再出新版本了，停滯了許久。 8. 用C寫GUI程式比ASM簡單許多(Win32)﹝至少不是差不多﹞ 9. 以上，因今天﹝現在快天亮了﹞有重要的事， 沒仔細看討論，只對幾個地方提出意見，人非聖賢，若有謬誤懇請指正， 小弟有十足的學習心，縱然天資不佳，但是仍然希望多與眾先進請益，感謝。 引用:
這篇十分中肯，我喜歡！ 引用:
這篇也講得很實在，認同... 但BSD與UNIX的故事不只就這麼簡單， 這又要說到AT&T、一些大學、BSD、FreeBSD、Linux之間錯綜複雜故事了。 引用:
有道理。 That's ALL !
__________________
##- ShaD -## 【燒錄】品質測試在不同讀取機器下無法比較【燒錄】讀取速度有時影響測試出的品質甚多【燒錄】測個幾片無法完全了解該種碟片的品質【燒錄】最要小心的不是燒完的讀取性，而是存放性【燒錄】不要相信Nero的資料驗證【燒錄】燒錄品質高不表示資料正確【程設】遞迴只應天上有，人間只能用迴圈【程設】迴圈轉遞迴為求簡便，遞迴轉迴圈累死神仙【程設】你永遠要做最多，使得電腦和使用者做最少【攝影】藝術價值無法只定義在相機規格上【攝影】感動因人而異【電腦】人生並非只有電腦【電腦】該去者去，該留者留【電腦】適可而止，懸崖勒馬【電腦】第一等人信任實際品質，第二等人知道參考口碑，第三等人盲目跟隨品牌 此文章於 2005-11-30 03:22 AM 被 shad 編輯. |
||||||||||
2005-11-30, 03:03 AM
#61
|
|
|
Major Member
加入日期: Sep 2002 您的住址: 高雄
文章: 115
|
引用:
不好意思  , 之前在做一些簡易的中文化時, 習慣性的把所有的工具都泛指為中文化工具了 (全部丟在一個文件夾, 然後文件夾名字就叫做中文化工具  )因為中文化一定需要用到脫殼工具, 而 ollydbg 又常被用來手工脫殼, 所以我就把 cxat, exeScope, VC++ 6.0, PEID, FI, ASpack/UPX 都簡單稱之為中文化 工具了 像是在做整合 XP 時需要的工具也一堆, 軟體自動安裝或者raid/scsi/sata 驅動安裝 或 Diskemu , Compression Bin, inno setup 我也是通通把它們丟在一個 『XXXXX XP相關資料』的文件夾裡  其實我知道功能是不一樣的啦, 不過就是懶了一點, 我想應該很多人都跟我有相同的習慣吧  關於shad兄其它的部份我覺得寫得很清楚, 讓小弟受益良多, 感激感激 此文章於 2005-11-30 04:11 AM 被 aq0127 編輯. |
|||
|
2005-11-30, 03:55 AM
#62
|
|
|
Major Member
加入日期: Feb 2005
文章: 116
|
引用:
不敢不敢，誠如我所引的引言， 我說的在之前就有先進先行說出了(而我打完了才發現)，豈敢居功。 
__________________
##- ShaD -## 【燒錄】品質測試在不同讀取機器下無法比較【燒錄】讀取速度有時影響測試出的品質甚多【燒錄】測個幾片無法完全了解該種碟片的品質【燒錄】最要小心的不是燒完的讀取性，而是存放性【燒錄】不要相信Nero的資料驗證【燒錄】燒錄品質高不表示資料正確【程設】遞迴只應天上有，人間只能用迴圈【程設】迴圈轉遞迴為求簡便，遞迴轉迴圈累死神仙【程設】你永遠要做最多，使得電腦和使用者做最少【攝影】藝術價值無法只定義在相機規格上【攝影】感動因人而異【電腦】人生並非只有電腦【電腦】該去者去，該留者留【電腦】適可而止，懸崖勒馬【電腦】第一等人信任實際品質，第二等人知道參考口碑，第三等人盲目跟隨品牌 |
|
|
2005-11-30, 04:35 AM
#63
|
|
|
New Member
加入日期: Oct 2005
文章: 6
|
引用:
UNIX like operating system 是 UNIX 喜歡作業系統 UNIX-like operating system 是像 UNIX 的作業系統 |
|
|
2005-11-30, 07:06 PM
#64
|
|
|
Regular Member
 加入日期: Aug 2003
文章: 82
|
唉唉唉唉，果真是吵不完...
我承認我之前扯上 MicroKernel 與 C++ 的關聯純然是來亂的。我的立意是與其要把Kernel 改用 C++ 寫不如 先改成 MicroKernel。Kernel Develope group 連 MicroKernel 都弄不到了，還有可能用c++改寫嗎？ 另外 Linux Kernel 是 FSF管轄 的軟體，Linux Kernel 一定是 FreeSoftware。如果你要惡搞用VB全面改寫，Fine，但是你就不能夠稱之為 Linux Kernel。 另外我很好奇，網路上能夠找到用C++寫的Linux Kernel嗎？ 另外，我跟ABBACHEN的衝突源自於對於 "Linux"這個名詞的定義。我想ABBACHEN認為Linux是一套作業系統。這是錯的，Linux = Linus' minix kernel。故 Linux 只是一個 Kernel，所以用 Linux Kernel 來取代 Linux 是比較能夠避免爭議的作法。 那....那個 作業系統應該是？ 應該稱之為 GNU/Linux。你給的連結首頁寫的是 "The GNU Operating System"， GNU 計畫遠比 Linux Kernel 大的多。是誰寫了 top這程式？誰寫了 ls ？誰寫了 gcc，誰寫了 glibc ？ 用一個狹隘的"Linux"來稱呼整個計畫是不適切的作法。 我想你也知道，GNU Project真正的Kernel 不是 Linus 創造的.... |
|
2005-11-30, 07:52 PM
#65
|
|
|
Regular Member
加入日期: Jan 2005 您的住址: 台灣台北
文章: 80
|
引用:
je 是 jump equal 嗎 ?有的指令是先判斷再跳的, 不知這個是不是 |
|
|
2005-11-30, 09:13 PM
#66
|
|
|
Regular Member
加入日期: Jan 2005 您的住址: 台灣台北
文章: 80
|
引用:
不一定如此. 編譯器只要輸入, 也就是原始碼餵給編譯器, 然後編譯 輸出目的檔就可以了, 這個編譯器所產生的目的檔可以是for其它平台, 不需跟編譯器所在的平台一樣. 編譯器只需要其它平台相關的opcode和registers等知識即可. 這種編譯器就是cross-platform compiler. 此文章於 2005-11-30 09:36 PM 被 nagual 編輯. |
|
|
2005-11-30, 09:32 PM
#67
|
|
|
Major Member
加入日期: Jun 2003 您的住址: where the light is
文章: 271
|
引用:
why not? 另外什麼叫做 MicroKernel 弄不到? Mach microkernel 一堆 OS 都在用 引用:
linux kernel 並不是 FSF 管轄的，它只是使用 GPL 發佈而已 網路上並沒有用 C++ 寫的 linux kernel，但是這不代表作不到 |
||
|
2005-11-30, 09:46 PM
#68
|
|
|
Power Member
加入日期: Jan 2003 您的住址: Taipei
文章: 513
|
eCos是用C++寫的。
__________________
我的可愛女兒 http://www.flickr.com/photos/xiecolleen http://0rz.tw/321AC http://xiemark.blogspot.com/ |
|
2005-11-30, 10:01 PM
#69
|
|
|
Advance Member
  
加入日期: Apr 2002 您的住址: 台北市
文章: 325
|
引用:
原來如此，也就是說只要編譯器有某平台的opcode級registers等資訊即可在任何平台上編譯？ |
|
|
2005-11-30, 10:12 PM
#70
|
|
