>>>  名人論史——近當代作家的史學觀點  >>>

簡體     傳統

1997.04

我整理了最近幾篇讀者來函，希望與大家分享。其中有對 SDK、MFC、RAD 的看法與疑惑，有與我的談心，也有對我個人的贊美。關於後者，我放上來是為了讓大家知道，一顆努力執著的心，可以獲得怎樣巨大的回響，以此安慰并鼓勵所有心系理想的資訊人。這些信件經過「依媚兒」的往返，展現出一問一答的形式。

發信人: moli (咸酥雞beta v1.0)
標 題: 有關 RAD
日 期: Mon Feb 24 21:25:48 1997
來源站: 成大工科忘情小筑 來源地: 140.116.110.151

侯 sir 你好，有個問題一直想問您。現在的 RAD 產品那麼多，編譯出來的程式碼已經夠快，尤其是 Borland C++Builder 出來後。那麼，有什麼理由還要使用 MFC 或 OWL 呢？是不是有些東西還是用 RAD 無法完成的呢？我相信很多人都想知道，畢竟，如果投資了很多心力，人家卻能用 RAD 短時間的學習曲線就能做出相同的東西，心情似乎會不太好過。所以想麻煩您解決一下大家心中的疑問。謝謝您！

問得好。

Programming 的過程不應該是一種自我虐待。有更好的工具上來，一定是為了提升生產力。如果用得上手，自然應該舍繁就簡。

關鍵在於何人曰「簡」？這要看 RAD 的使用者根基有多少。我用過C++Builder，很棒，我想我因為已有相當的技術基礎，所以能夠輕松駕馭。如果不是有 property、event、method 的觀念、對軟體元件有使用基礎，不可能很快進入狀況；C++ 的基礎則就更不消說了（每次講到這個我就想起以前有人問我不懂 C++ 而學會 MFC 有沒有可能）。MFC 和 OWL 的使用經驗，也為我在學習的路上帶來幫助，當別人在 RAD 上運鼠如飛，我也運腦如飛地思想 MFC 的可能作法。這一思考，我對 RAD 說不定就有更深刻的看法，或起碼，學習印象也要強化十幾個百分點吧。

所以，如果你上得了手，工作目標又可以 RAD 達成，當然要盡量使用 RAD。Programming 的過程可不是一種自我虐待。基礎不夠，跌下馬來，那就回頭把根基扎好。開花結果通常在深耕的泥土上。

『是不是有些東西還是用 RAD 無法完成的呢？』噢，那當然。我從沒看過 Matt Pietrek（Windows 95 System Programming SECRETS 一書作者）用過 RAD，連 MFC 或 OWL 他都沒用過。他寫的東西不需要繁復的 UI 畫面，他需要長驅直入系統核心的 APIs：SetThreadContext、CreateRemoteThread、ReadProcessMemory...，很少聽過這些 API 吧！與其花腦筋想這些 API 該安插在MFC（OWL）或 RAD 為我們產生的碼的什麼地方，直接采用 SDK 程式風格才最快最乾凈。Matt 的工作性質，需要一把利劍，但不需要一把象牙柄帶雕花的利劍。寫驅動程式的朋友們，則恐怕連 SDK 都不碰，他們碰的是 DDK。RAD 之於他們正是「不知有漢，無論魏晉」。

前兩天我動手寫一個簡易的 backup 軟體給自己日常使用。根本就沒想過要寫 Windows 版，命令列形式反而方便好用。後來我發現以前習慣使用的C runtime 函式庫的 findfirst 和 findnext 兩函式已經不存在於 32 位元工具中，只好改弦易轍寫 Win32 console 程式，還好這和寫 DOS 程式一樣簡單。我用任何一種編譯器和聯結器，下一個最簡單的命令，就把程式制造出來了。

做什麼事情，用什麼工具！「用對工具」比「把工具用對」更先決、更前提。

那麼，您覺得現在 MFC 或 OWL 的存在，
除了為老程式員留後路，或用來開發低階的 device driver 之外，
是否還有存在的必要？微軟的 VC++ 5.0 就要出來了，
不知道微軟會不會以 MFC 做底子，開發一套像 C++Builder 的東西。
依您所說，只要懂 Windows 程式的運作原理就好了呀！
只要懂得 event driven 的原理，就可以去駕馭 C++Builder，
那麼，去學習 MFC 或 OWL 是否真的沒有必要了。
我突然有點疑惑，因為買了很多書（您的幾乎都買了），也包括
您介紹的原文書。
在下學習 MFC 已有一年多了，可是發現一些只有 SDK 基礎的人，
利用幾個禮拜的時間就可學會用 C++Builder 做出比我還要好很多
倍的程式（我確定他們的資質不見得比我好）。
所以，突然為自己以前的投資覺得有些失落...

心情不太好而且有些失落的人：

１.修正你的觀念：MFC 或 OWL 并不能拿來開發裝置驅動程式。

２.我沒說「懂得 event driven 的原理，就可以去駕馭 C++Builder」。

３.我剛學會開車時，第一次在臺北上路。旁邊坐著我的哥哥。那是星期天上午的敦北大道。車少人稀，順暢無比，我不禁得意地說『在臺北開車也沒什麼難嘛！』我的哥哥對我說：『在美國鹽湖城開車更容易，哼！重要的是出現狀況時你的應變能力。』

４.到底該學習 MFC 或 OWL 或 C++Builder？這不是三言兩語能回答的問題。年輕朋友問我先工作再深造好，還是先完成學業再工作，這也不是三言兩語能回答的。如果使用的工具關系到工作的性質，我還想說『盍各言爾志』呢。

５.MFC 或 OWL 或 Visual Component Library（VCL）架構到底誰好，現在我還沒有能力置評。有的是技術層次高，物件導向性質佳；有的是層次簡化，容易學習。這些統統都應該考慮在「好」的范圍內。曲高和寡而未能占有市場，那麼這個產品和「無」是一樣的。不過，學習 C++Builder 不需要 MFC 或 OWL 基礎，殆無疑問。也許你會感到失望，因為表面上你失去了某種「登高臺觀浮生如蟻」的優勢。

６.但是你既不能怨艾自己比別人早生幾年，所以你也不要怨艾「我做了好些苦工，別人卻一步登頂」。否則只好現在什麼都不要動，等三年後一個不知是什麼但肯定比現在更好的東西出現。

７.何況世界上沒有一步登頂的事兒。凡走過的，必留下足跡。電腦界很多東西都可以觸類旁通。

送件者: William King
收件者: jjhou@ccca.nctu.edu.tw
主旨: SDK
日期: 1997年2月25日 AM 10:53

侯先生您好，因為工作的關系，我現在是用 SDK 開發程式，不過誠如
您所說的：『如果采用 SDK programming，則對作業系統需要相
當深度的涉獵，否則一知半解，恐怕臨淵履薄，狀況頻出。』
有時候執行上有問題，還真不知道錯誤出在哪里。不知可否給點建議，
如何能對作業系統有相當深度的了解？

這我該怎麼說呢？找一位好老師，找幾本好書，只能這樣了。作業系統不如 programming 那麼容易可以自修而成，許多細部觀念的養成，需要細細琢磨或經人點撥（我想起「分離位址空間」這題目）。如果你只能自修，那就只好努力多看書多思考了。對，多思考很重要，把書上的東西轉化為你自己的思想體系，一輩子跑不掉。

是有人指導，不過我也想自己看些書。市面上這類書并不多，我不求速成
但是也不想浪費時間在無法了解的書上，能否請您介紹幾本值得閱讀
的書呢？

RunPC 1997.03 的【無責任書評/Windows 系統深耕】，介紹了三本好書。

送件者: Lung Feng
收件者: jjhou@ccca.nctu.edu.tw
主旨: Thank you for publishing your Dissecting MFC.
日期: 1997年2月25日 PM 10:58

侯先生您好：

我是您的忠實讀友，從您1992年出版的「Windows程式設計」到現在的
「深入淺出 MFC」，我已花不少銀子買下數本您的大作。說真的
您的作品比其他國內出版的作品價格稍為高了一點，但我覺得很值
得，因為我可以感受出您真得非常用心在撰寫，初閱讀您的作品時，有時
不知其然，但只要用心品嘗，總是入味七分。有些書教人一邊看書
一邊上機實作，會是一個比較好的學習曲線，但我是一個從基隆到臺北
通車的上班族，花很多的時間在車上，在車上拜讀您的大作真是讓人
愉快的事情（我回到家已晚，也只有在車上能有時間充實自已）。
這段時間內，我無法上機，卻能從中受益。而且一次再一次去閱讀，
常會有新的收獲，真如古人所說溫故而能知新。當然若找時間上機心得會更多。

侯捷 2010-09-10 08:28:32