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

簡體     傳統

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