相關閱讀 |
>>> 名人論史——近當代作家的史學觀點 >>> | 簡體 傳統 |
发表日期 : 1994.04
Application Framework 和 OLE2
的的确确在软体界称的上具有革命精神。
Application Framework 提升软体生产力,
OLE2 促成软体合作时代的来临,
同时也是物件导向作业系统的基础。
今天我为大家介绍 Visual C++ 和 OLE2 方面两本不错的书。
演化 (evolution) 永远在进行,这个世界却不是每天都有革命性 (revolution) 的事物发生。动不动宣称自己 (或自己的产品) 是划时代的革命性的,带来的影响就像时下满街跑的大师一样使我们渐渐无动於衷 (大师不可能满街跑) ! 但是 Application Framework 和 OLE2 的的确确在我们软体界称的上具有革命精神。
什麽是 Application Framework ? Framework 有组织、框架、体制的意思,Application Framework (这名称太长了,以下我以 Framework 代表之) 不仅仅是一般性的泛称,它其实还是物件导向 (Object Oriented) 领域中的一个专有名词。
基本上你可以说Framework 是一个完整的程式模型,具备标准应用软体所需的一切基本功能,像是档案功能、列印功能、资料交换功能 (在 Windows 中指的是 Clipboard) ...,以及这些功能的使用介面 (在 Windows 中这是 toolbar、status bar、menu 以及相关的 dialogs)。如果更以术语来说,Framework 就是由一整组合作无间的objects 架构起来的大模型。喔不,这个时期它还只是有形无体,所以应该说是一组合作无间的 classes 架构起来的大模型。
这带来什麽好处呢 ? 程式员只要带个购物袋到「Classes 超级市场」采买,随你要买 MDI 或 OLE 或 ODBC 或Printing Preview,回家後就可以轻易拼凑出一个色香味俱全的大餐。
「Classes 超级市场」就是 ClassLib,以产品而言在 Microsoft 是 MFC,在 Borland 是 OWL。这组 ClassLib 不只是函式库而已。传统的函式库 (C Runtime Lib 或 Windows API DLL) 提供的是生鲜超市中的一条鱼一支葱一颗大白菜,彼此之间没有什麽关联,主掌中馈的你必须自己选材自己调理。能够称的上 Framework 的ClassLib 提供的则是火锅拼盘 (不知道 ?! 大男人应该陪陪老婆买菜了),依你要的是白菜火锅鱼头火锅或是麻辣火锅,菜色带调理包都给你配好。当然这样的火锅拼盘是不能够就地吃的,你得给它加点能量。放把火烧它吧,这火就是所谓的 Application Object (在 MFC 程式中就是衍生自 CWinApp 的一个global object)。是这个 App Object 引起的连锁反应,使每一个形 (class) 有了真正的体 (object),把整个 Framework 带动起来。一切因缘全由是起。
Framework 带来的革命精神是,程式模型已经存在,程式员只要依个人需求加料就好 (也就是改写 Derived Class 的 virtual function,或在Derived Class 中加上 member function),这很像你在火锅拼盘中依个人口味加盐添醋。由於这个缘故,整体性的软体开发工具 (像 Visual C++ 或 Borland C++) 就很容易诞生了,因为程式码的初期规模十分一致 --- 什麽样风格的程式应该含入什麽 Class 是一成不变的;而修改程式以符合私人需要的动作过程也很一致,不外乎是改写 Class 的 virtual function 或增加 data member 或增加 member function。你动不了 Framework 的大架构,也不需要动,这是福利不是约束。在 Visual C++ 中制作初期程式码的工作 (也就是让你开采买单) 由 AppWizard 负责, ClassWizard 负责的工作是让你方便修改零件,加盐添醋。
应用程式码一致化的结果,使优良的软体开发工具 (code generator、CASE tool) 容易开发出来。由於你的程式码大架构掌握在 Framework 设计者的手上,小猴子怎麽也翻不出如来佛手掌心,Framework 设计者於是就有能力制作出整体开发工具了。
有人说工学院中唯一保有人文气息的只剩建筑系,我总觉得资讯系也勉强可以算上。带艺术气息的软体创作行为 (我一直是这麽认为的) 将在 Framework 出现後逐渐成为工匠技术,而我们都将只是软体 IC 装配厂里的男工女工。其实也没什麽好顾影自怜,功成名就的冠冕从来也不曾落在程式员头上;我们可能像纽约街头的普普 (POP) 工作者(注),自认为艺术家,可别人怎麽看呢 ? 不得而知 ! 话说回来,把开发软体这件事情从艺术降格到工技,对人类只有好没有坏。不是亨利福特,我们又如何能够享受大众化的汽车 ? 或许以後会出现「纯手工精制」的软体(有谁感兴趣不得而知,我自己从来不嫌机器馒头难吃)。
(注 : 普普艺术是 1950-1960 年代盛行於欧美的一种新艺术运动。将俗不可耐的海报、看板、招牌、漫画、照片等大众传播的图形,大胆引用於绘画,是对现代文明庸俗性的抗议)
达达(DATA)与普普(POP)
如果要三言两语点出 Framework 的特质,我会这麽说 : 我们取用别人早写好的一整个程式 (MFC 或 OWL) 之中的一部份,给个引子 (Application object) 使它具象化动起来,并被允许修改其中某些零件使这程式更符合私人需求,如是而已。
那麽 OLE 的革命精神又在哪里呢 ? 从有电脑以来所有坐在显示器前面的人想像他的工作是 : 我用什麽软体,载入什麽档案,进行什麽步骤。为了让成果 (所谓 Document) 得以完成,我因此必须选择功能强大到足够应付这 Document 每一项需求的软体。如果 Document 希望表现文字、动画、影像、语音,我的选择必定是一只大雷龙。换个方向出发 : 我有一份 Document 要完成,谁完成其中的小元件 (文字动画影像语音) 我不在意,如果有各个专精工具完成这些小元件,那麽我希望有一个容器 (container) 可以容纳它们,并且做点布局管理贮存之事。这些元件都称为 object (和 C++ 所说的 object 意义不尽相同)。软体使用者想对各元件做细部动作时 (例如编辑或播放),容器必须有能力启动元件的原主人 (server)。这些 objects 可能分散在各个档案(.TXT,.BMP, .AVI, .WAV),与容器 (即 Document) 之间只以指标相连,这种情况称为物件联结 (Object Linking);也可能各个 object 都复制一份放到 Document 中,这情况称为物件内嵌 (Object Embedding)。
上述思维把我们从原先以软体为中心 (Application Center) 的观念转变到以产品为中心 (Document Center)。如果能够定义出一种协定 (protocol),遵循这协定的软体可以做物件联结与内嵌,那麽应用软体的开发观念就由庞杂通吃转变为小巧精美,使用者也因此可以以调配的方式完成 Document 而受益。
这样的协定在 OLE 1 已经完成。但是软体使用者在制作 Document 过程中,看见不同的 server 随着各个 object 的编辑 (或播放) 需求而出现、而运作、而消失回到container,使用者仍然没有办法感受到「只需面对而一份 Document 而不需面对不同的 Application」! 於是 OLE2 又发展出所谓的即地动作 (In-Place Activation,也称为 Visual Editing),使 Document Center 的观念更具说服力,更落实在用户手上。藉由 OLE 协定,软体竟然可以操作它不了解、甚至目前还未诞生的资讯型态,从此达到无国界的状态。
Framework 提升软体生产力,OLE 促成软体合作时代的来临,同时也是物件导向作业系统的基础。 Chicago 的用户已经可以不必考虑使用应用软体或载入档案之事,他们想到的是如何管理 Document,这正因为有 OLE2 做为Chicago 的脊椎骨。这一期我就为大家介绍 Visual C++ 和 OLE2 方面两本不错的书籍。
背景资料 :
书名 Inside Visual C++
作者 David J.Kruglinski
出版 Microsoft Press
页数 26 章,598 页
售价 US$ 39.95 (含磁片)
Part I Windows, Visual C++, and Application Framework Fundamentals
1. Microsoft Windows and Visual C++
2. The Microsoft Foundation Class Library Application Framework
Part II The Class Library View Class
3. Getting Started with AppWizard - "Hello, world"
4. Basic Event Handling - Using ClassWizard
5. The Graphics Device Interface (GDI)
6. The Modal Dialog
7. The Modeless Dialog and the COMMDLG Dialog Classes
8. Visual Basic Controls
9. Windows Memory Management - Just Say "New"
10. Bitmaps
11. Bitmap Buttons, The Timer, and On-Idle Processing
Part III The Document-View Architecture
12. Menus and Keyboard Accelerators
13. Toolbars and Status Bars
14. A Reusable Base Class
15. Separating the Document from its View
16. Reading and Writing Documents - SDI
17. Reading and Writing Documents - MDI
18. Printing and Print Preview
19. Splitter Windows and Multiple Views
20. Context-Sensitive Help
21. A Practical Windows-Based Application
Part IV Advanced Topics
22. Microsoft Foundation Class Library Version 2.0 Programs Without Documents or Views
23. Storing Bitmaps in a Document - DIBs and the Clipboard
24. Database Management with Microsoft ODBC
25. Object Linking and Embedding (OLE)
26. Dynamic Link Libraries (DLLs)
Appendix A. A Personal View of the C++ Language
Appendix B. Message Map Functions in the
Microsoft Foundation Class Library
Appendix C. Microsoft Windows Functions Used in This Book
Appendix D. Visual C++, Windows NT Edition
各家厂商包括 Microsoft、Borland、Symantec 等等都有 Framework 产品。重量级产品的捉对厮杀往往具有「一棒击沉」的威力,厂商无不卯尽全力吹嘘自己、打击对手。近几个月来在重要技术期刊如 MSJ、DDJ 的每一期封面里页广告上我们都会看到迷人的夏威夷海滩照,Symantec 公司为其客户准备了一个特殊的旅游折价卷 (双人的哟),意思是如果你使用了他的产品,就有剩馀的时间来一个愉快的夏威夷假期。Framework 产品肉搏战之激烈可想而知。
身为名门之後,Visual C++ 比其他厂牌的Framework 接受更多的目光与评论。国际论坛对 Visual C++ 有十分热烈的反应,1993.03 推出之後,网路消息一下子大幅增加。反应分为两派,一派认为 Visual C++ 不过是另一套 ClassLib,没有什麽值得大书特书;另一派把 Visual C++ 捧上天。有一封网路消息说,Visual C++ 好的如此令人惊喜,不知道下一次 Microsoft 的 C/C++ 9.0 是不是要带来具备虚拟实景 (Virtual Reality) 的工具 ?! (注 : 不论 VC++ 1.0 或是 VC++ 1.5,其编译器版本都是 C/C++ 8.0)
Visual C++ 这套 Framework 的核心正是 MFC,本书为我们解释MFC 2.0 架构、最基础的数个 Classes、使用这些 Classes 的方式、以及 VC++ 中的软体开发工具。阅读时最好把 VC++ 所附的 MFC Class 架构图放在手边,随时叁阅,这张架构图熟记於心是学习 MFC 的头一件必要情事。本书封面没有说明VC++ 版本,那是因为出书时 VC++ 才刚开始 1.0 版,作者对於 Microsoft 在1.0 推出後的九个月快速推出 1.5 版想必也感吃不消。你无法从本书得到VC++ 1.5 最重要的两项补强技术 : ODBC 和 OLE2。但是已经拥有 VC++ 1.5 的你也不必担心本书是否落伍,两个版本的其馀一切都相容。(好消息,台湾微软已於二月开始出货 VC++ 1.5,没收到的快去催)。
作者毫不隐藏他对 MFC 的热爱,说这是他等了十年才盼到的软体开发环境。十年有点跨张,但功能强大却是不假。这本书明确划分为四大部份。第一部份介绍 Framework 的观念以及 Visual C++ 套件的各项成份。第二部份真正进入 MFC 程式设计,但局限在CView (Framework 的主要 Class 之一)。在这里作者尝试以 C++ 和 MFC 完成一些功能简单的程式,像是简易绘图、图形卷动、Truetype 字形输出、对话盒制作、利用 GRID VBX 制作简易试算表等等。由於 VC++ 的三个wizards 有「程式产生器」的能力,程式员可以省掉许多苦役,这是厂商集中火力宣扬之处。
第三部份才真正进入 MFC 2.0 的核心,也就是 Document-View 架构。这里的 Document 和前面所提的 OLE Document 有点关联却又不是完全相同,暂时不要把它们视为一物。Document-View 架构是 MFC 2.0 不同於 MFC 1.0 的最大特质。当你学会如何使用 Document 并且把它和 View 连接起来後,你会非常惊讶资料的档案动作和印表动作 (包括预视) 是多麽的容易。我在前面提过,MFC 这个 Framework 早把一切设计好了,如果你的资料能套用 MFC 的 Class (例如以 CObList 表达你的串列),自然而然也就享有这些功能。从十三章开始,读者开始接触 MFC 2.0 新提供的图形使用介面,包括toolbars、status bars、splitter frames、context-sensitive help。这些漂亮宝贝诞生过程之简易正是当初深深吸引我对 VC++ 兴趣的最主要原因。
第四部份是杂烩,读者可以学习完全不需 Document-View 架构的程式写法 (可是我不认为这实用),以及 ODBC、OLE、DLL 等高级主题。ODBC 超过了 VC++ 1.0 的能力范围,如果你要实作第二十四章程式,另需要 ODBC SDK。二十五章介绍的不是 OLE2 而是 OLE 1,这也必须特别注意一下。
本书定位为 MFC 的入门书,每一章的范例程式都只示范些小动作,如果拿来和 Charles Pezold 的 Programmer Windows 3.1 以及 Jeffrey M.Richter 的 Windows 3.1 : A Developer's Guide 相比,本书比较像前者。(注 : 前者的程式都小小的,示范特定动作;後者的程式都大大的,功能度以及漂亮度与市面商业软体遑不多让)。
开始阅读本书之前如果没有 C++ 基础,或是早就看过但很久没摸了,心中忐忑不安,那麽不妨先到附录 A 热身一下。附录 A 是一篇为已经看过 C++ 课本但又觉得资料太丰 (要五毛给一块 ?) 的人准备的小品,31 页,是作者自己的 C++ 私房话。目前关於 MFC 或 OWL 书籍的一个习惯作法就是在书中加一小章 C++ 基础观念,为的是 C++ 嚷了很久,C 程式员的数量还是占极大优势。关於这一点稍後我另有看法。
传统对於程式的编译联结程序是以 makefile 说明,本书并不这麽做。MFC 程式并非没有 TEXT 格式的 makefile,但十分庞大而且很难看懂 (还有多少人懂那些奇奇怪怪的 $ @ << 符号呢)。本书配合 Visual Workbench 的画面,以这些画面取代 makefile。换句话说在 VC++ 中你学习「制造」程式的方法是 : 「先在 AppWizard 上选这个按那个,然後你会得到这个和这个;再进入 ClassWizard, 按下这个和那个,它会跳到一个编辑器,游标一闪一闪出现在这里,你就开始打...」,我有一种被物化的惆怅感觉。
本书磁片内含不少程式 (45 个),安装软体非常令人失望,一点也配不上「Visual」的气势。没有「百分比棒」告诉我们安装到什麽程度了,也没有自动为我们产生 group 并添加可执行档的 icon --- 这都只不过是 Windows 程式安装过程中的起码要求。事实上,本书的 INSTALL.EXE 根本是个 DOS EXE。安装後的 921 个档案总共需要 2.4M 硬碟空间,其间没有可执行档,你必须一个一个自行编译联结。虽说VC++ 建立可执行档的过程很简单,时间却得花不少,这一点 Precompile Header 帮不上忙,因为你是在不同的 project 中工作。所有的 EXE 产生後,磁碟空间需求量暴涨两倍以上。编译联结一个 MFC 程式需要相当时间 (最主要原因是各个 afx_.h 档都得编译),第三章最後面提出将时间尽量缩短的作法,值得叁考。
VC++ 安装後你可以在其 group 中找到一个 "Tech Note" icon,其中有 35 篇十分深入的文章,值得全部印出装订成册。本书在讲到相关资讯时,会告诉我们从哪一篇 Tech Note 中获得更多资讯,这一点很有价值。VC++ 套件中有 23 个 MFC 范例程式,做为本书之後的深造对象不错。此外 VC++ 本身附的手册 Programmer's Guide 也是一本很不错的书,内有三个部份 :
○ C++ Tutorial - 介绍 C++ 语言基础。
○ Class Library User's Guide - 以 MFC 范例程式 Scribble 为例,详细解释 步骤一至步骤五的程式化过程。最终可以获得一个 MDI 风格的应用程式,以 滑鼠为输入装置,允许在视窗上自由画图,资料可以贮存在档案中,可以输出 到印表机,也可以在列印之前先预视。这个范例几乎示范了一般应用软体写作 过程中所需的各种代表性 Classes。
○ Programming Techniques - 讨论 precompiled header、C/C++ 程式中的 记忆体管理、Prolog/Epilog 码、QuickWin、移植性等主题。
把这些资料 K 完,你应该是 VC++ 的专家了。还想再深入些 ?! MSVC\MFC\SRC 中有 MFC 原始码大刑伺候,123 个档案,1.4M 大小,够呛的了。
MFC 有许多优点,可是我得提醒你,十分钟选选按按获得一个程式虽然很有速食文化的精神,玩具程式终究要修修改改才拿的出去。不把 C++、SDK 的底子扎深一些,对那些由 AppWizard 产生出来十分精简的码铁定无下箸处。如果有人光以程式码的多寡比较不同程式方法 (C/SDK 与 C++/MFC) 之间的优劣,这种人顶好去看无字天书。
想进入 Windows 程式设计领域的人,总有不知从何开始的犹豫与困惑。当入门愈来愈困难愈来愈复杂,我们的犹豫愈来愈多困惑愈来愈深。SDK 给人的印象是起码六个月的学习 (我个人并不这麽认为),各家 Framework 广告却一再强调轻轻松松快快乐乐。我的天,没有含泪播种哪来含笑收割 ? 本书作者 Kruglinski 的论点是,不论你从SDK 开始或从 MFC 开始,反正都需要很长的学习曲线,那麽何不从 MFC 开始 ? 关於此点我持怀疑态度,基本上学习 MFC 的速度得视你的 SDK 以及 C++ 程度而定。如果具备这两种基础的高手说『学习 MFC 程式设计不怎麽难嘛』,你得当心,念完博士学位的人总是说 :『博士没什麽啦,孵也孵出一个』;考上研究所的人则是:『考前三个月我才开始 K』,或者是『准备预官考时我就顺便准备了一下』。
对於已经有 SDK 经验的人,我的建议是,你要弄清楚为什麽在 MFC 程式中看不到WinMain()、WndProc() ? 为什麽没有 RegisterClass() 也没有 CreateWindow() ? 为什麽没有 Message Loop、没有 switch-case 却跑出个什麽 BEGIN_MESSAGE_MAP()、END_MESSAGE_MAP() ? 为什麽所有熟悉的东东都不见了 ? 你因为对讯息流向的掌握而弄清楚了 SDK 程式设计,你也将因为把隐藏在 CWinApp、CFrameWnd、以及所谓Message Map 背後的来龙去脉一一映射到 SDK 而因此对 MFC 程式设计云霁风清豁然开朗。可惜,本书不谈这些,而我也没看到哪一本书谈论它们。在这样的书问世之前,你得自己去查 MFC source code(VC++ 磁片上有)。
学习物件导向程式设计,有识之士都说要完全舍弃传统的程式方法,要直接以物件导向的方式来思考,最好这个人一开始接触的语言就是 C++(或 Smalltalk, Objective C...)。是啊是啊,但理想如果不向实际做点妥协,理想就会归於尘土。中华民国还得需十次革命,物件导向怎能把一切传统都抛开?对於为数众多的 SDK guy,我认为唯有让你看到你已经很习惯而且也认为很理所当然的 WinMain()、WndProc() 被MFC 如何包装,你才能够扎扎实实没有疑虑地成为一个 MFC guy,大步向 OO Windows programming 迈进。
关於 C++,我自己开 Windows 课程时很感兴趣座中来自各软体公司的菁英到底有多少人使用 C++。每次这问题提出来课堂就弥漫一股紧张气氛,学员眼神中有着惊恐,手举的半高不高表示已开始学习...但似乎...还不够实在。每个程式员都担心自己是还没有拥抱 C++ 歌颂 C++ 的最後一人。四面八方的资讯告诉我们,全世界软体公司都已经移转到 C++,或在 C++ 移转过程之中,或至少正在移转计划的最後阶段。连你八十岁的老阿妈都知道要提醒你快快从 C 进入 C++。於是,C++、OOP 成为软体人员「必须背负」的责任。洋洋得意的同侪,排山倒海的资讯,C 程式员四面楚歌! 结果是,每位 C 先生桌上都摆有一本 (至少一本) C++。OO 大 愈举愈高,终至没有人看得清楚上面写些什麽,大家只一劲儿摇旗呐喊 OO 和 ++。
OO 大 愈举愈高,终至没有人看得清楚上面写些什麽,
大家只一劲儿摇旗呐喊 OO 和 ++
其实最好的态度是找一个最适合而不是最时髦的语言与工具。有人天生就是不适合 data flow 而对 function flow 甘之如饴。但话说回来,即便只为了MFC,也值得学习 C++。你犯不着把自己弄的紧张兮兮,不妨把 C++ 学到一个基本程度,有能力以 MFC 架建你的程式大架构 (MDI、OLE、各种 UI),然後在其中仍然以 SDK API 写程式,光是这样使用 VC++ 就已经值回票价了。慢慢经验多了信心建立起来了,下一个 project 再开始全盘「欧」化。
人的学习没有 version control,我其实已经很难想像如果没有 SDK 经验并且没有把 SDK 与 MFC 的内部关系弄懂的话,自己是否进得了 MFC 殿堂。我所认识的每一位使用MFC 的朋友都有 SDK 基础。这里倒有一个难得的临床实验 : 我的朋友小曾的朋友没有 SDK 经验却想学习 Windows 程式设计,小曾介绍这本 Inside Visual C++ 给他,花了一个月看完,他说懂是懂但没有感觉;於是小曾再推荐 Charles Petzold 的 Programming Windows 3.1 给他,这回又花了一个月,他说有感觉了,可以动手了。
使用 Framework,我想大概再不能够拎着我那 20MB 硬碟的单色阳春小手提到梅园一边野餐一边写程式了。我的隐忧是程式写作因为太倚重整合环境,程式员因此被绑在办公室动弹不得,离开办公室後就像鱼离了水。即使我的小手提扩充到 200MB,我也不知道如何常保两个环境的一致性。
笑话一则。猫在老鼠洞口张牙舞爪,老鼠吓的不敢动弹。未几忽闻汪汪声,老鼠大喜,自忖狗来猫躲,於是从容出洞,却被猫一掌攫住。鼠问猫为何未逃,猫曰 : 这年头不会两种语言还想混饭吃吗 ? 基本上我同意猫的说法。如果你想在 C 之外学第二种语言,我的建议一是 Visual Basic,一是 C++。
最後一段闲话 : 你有没有看 83/02/27 的新闻挢 ? 那一天的主题是:「标题必须与内容吻合,不能刻意误导或模糊读者观感」。如果甲男和乙女一起夜游的传闻已经证实为误,记者就不应该以「甲男和乙女传出绯闻 ?」为题,意欲吸引读者却又以斗大的问号为自己脱罪。如果你看到一本封面有斗大Visual C++ 字样,内容却只是 C++ 语言甚而只是 C 语言的书,你会不会在心中暗骂 *&#%@! ?!。司马昭之心路人皆知,这不过是想沾 VC++ 的风采。语言书使用哪一种编译工具当然要交待清楚,这种情况下 Visual C++ 只宜放为副标甚至小标。你同意我的看法吗 ? 电脑书不像 PlayBoy 用塑胶套包的像肉粽,所以你还是可以验明正身,可咱心里头就是不爽。这样的中文书有好几本,客倌照子放亮一点。
老侯夫妇也走了┅好像每个人都在进化,只有我们例外。
背景资料 :
书名 Inside OLE2
作者 Kraig Brockschmidt
出版 Microsoft Press
页数 16 章,977 页
售价 US$ 49.95 (含磁片两片)
Section I Windows Objects
1. An Overview of OLE2
2. Conventions, C++, and Sample Code
3. Objects and Interfaces
4. Component Objects
Section II Object Oriented System Features : Files and Data Transfer
5. Structured Storage and Compound Files
6. Uniform Data Transfer Using Data Objects
7. Clipboard Transfers Using Data Objects
8. Drag-and-Drop Operations Using Data Objects
Section III Compound Documents : OLE
9. Compound Documents and Embedded Containers
10. Compound Documents and Embedded Object Servers (EXEs)
11. In-Process Object Handlers and Servers
12. Monikers and Linking Containers
13. Moniker Binding and Link Sources
14. Conversion, Emulation, and Compatibility with OLE 1
Section IV Compound Documents : In-Place Activation
15. Visual Editing : In-Place Activation and In-Place Containers
16. In-Place Activation for Compound Document Objects
一个伟大的观念得配上一个伟大好念的名字,这名字就是 OLE (抱歉,Petzold 先生,借用你的句型)。「台湾女孩都像奶这样年轻漂亮吗...」,没错,就这个发音,重音摆在後面,欧累!。
目前书坛关於 OLE2 的书不多,这本是最深入的了。这时段懂 OLE2 技术的人仍属罕见,Windows/DOS Developer's Journal 原计划的 1994/03 OLE 主题竟因为没有稿件而腰斩,主编说他不知道大家是对此题目兴趣缺缺呢,还是每一个了解 OLE 的人都忙着写程式忙到没有时间做任何其他事情 (那表示程式很难写)。本书作者 Brockschmidt 在 Microsoft 任职,有机会碰触 OLE 的原始码,他的现身说法十分深入 (他说自己已经达到了OLE 的涅 境界)。作者在 MSJ 上有三篇文章 :
○ Introducing OLE 2.0, Part I : Windows Objects and the Component Object Model (1993/08)
○ OLE 2.0, Part II : Implementing a Simple Windows Object Using Either C or C++ (1993/09)
○ Implementing OLE 2.0, Part III : Uniform Data Transfer with Data Objects (1993/12)
如果你有该杂志,我建议先看文章再看书,压力会小一点,毕竟这是 1000 页巨着。如果你还想了解 OLE 建筑师 Tony Williams 的心路历程,MSJ 也有一篇深入的访谈报导 :
○ An MSJ Interview with Microsoft's Chief Architect of of OLE, Tony Williams (1993/10)
这本书最重要的是第一章,对 OLE 整体架构做个介绍。图一摘自书中最重要的一张图,对照章名之後你会发现本书目的就是要把图一的每一个模组介绍给你。由於 OLE 工程是如此浩大,观念是如此新颖,入门之际把几个重要的关键性名词弄清楚是顶重要的事。尤其 OLE 的许多名词和一般定义不尽相同 (比方说 Interface 和 Object),如果你掉以轻心就要糟糕。把自己想像是老师,对着学生做这些名词解释,不能用想的,要用说的,说到自己觉得满意,神功练就。我常常这麽训练自己。
图一 OLE2 架构 (摘自 Inside OLE2)
本网站略
根据我的观察,几本常看的软体技术期刊中最常出现的名词排行是 : Windows、Microsoft、OLE (object 这种字眼不算在内)。从 OLE1 以来不断轰炸的结果,大概我们脑中对 OLE 这个字的直觉等号就是Compound Document,但 OLE2 远比这多的多,直逼半个作业系统的复杂度。OLE2 已经建立起一个在 Windows 之下的物件导向程式设计的巨大系统,这个系统包含了记忆体配置、档案管理、资料传输...,Compound Document 只不过是其中集大成的一部份而已。事实上一个人可以不需要接触 Compound Document 而使用OLE2 的其他技术,举个例子,未来版本的 Windows 档案系统将百分之百相容於OLE2 的 Compound File。
我想分别就内容、文字以及磁片三方面评论本书。在内容上这并不是一本教导如何撰写 OLE 程式的书籍,本书更深一些,探讨背景理论、架构模型。我并不是说你从中学习不到如何写 OLE 程式,事实上本书的范例程式非常丰富,这些程式除了三个 DLL (分别负责 toolbar、status bar) 之外,都是以 C++ 完成,但并不架构在 MFC 之上,而是使用作者自己的ClassLib (本书出版更在 VC++ 1.5 之前,根本没有 MFC 2.5 (支援 OLE2) 可用)。这个 ClassLib 的规模当然远比正规的 Framework 小的多 (只提供 12 个 Classes),因此我们依然可见熟悉的 WinMain() 和 WndProc()。所以懂 SDK 以及 C++ 但还没学习 MFC 的人可以略松口气,不过对已经移转到 MFC 的人是大利空。
本书以两个程式 (一个 client 一个 server) 由一般应用程式成长为 OLE2 程式的过程来说明各项 OLE2 性质以及实作方式。这两个程式是真正的「全由轮子造起」,基础部份 (包括 ClassLib 以及前面提到负责漂亮 UI 的三个 DLL) 和 OLE2 无关,但如果你感兴趣的话其实对物件导向技术颇有助益。作者在第三章甚至示范分别以 C 语言和 C++ 语言做出两版 Windows Object,我把 OLE1 的程式方法 (许多VTBL、许多 callback 函式的那一套) 和这两个版本比较,颇有一些启发。
文字方面,本书长句子很多,并不是本容易阅读的书,至少我看的很辛苦。作者常常旁徵博引一些不知道是不是名人的话,如果你真的博学,应该可以增加不少读书趣味。我只认识莎士比亚、达尔文、萧伯纳,其他就一概不知了。据闻书商有意将此书中文化,我对之充满期待。除了对技术的期待,也好奇译者怎麽处理这些技术以外的文字。如果这些有趣的东西都跳过不译,那就太可惜了。一位译者最怕的就是原作者太博学,大仲马把他一辈子的见闻与挥霍通通放到基度山恩仇记里去,可苦了全世界的译者。
关於磁片,我只能给 59 分,事实上它使我七窍生烟。本书附磁片两张,全是压缩过的,安装起来需 6MB 硬碟空间。更吓人的是,6MB 之中没有可执行档。如果你制造 debug 版,全部做出来需要 80MB (乖乖),如果是 retail 版,好一点,50MB「而已」。安装过程和 Inside Visual C++ 一样差劲,前面我已经骂过了。执行 MAKEALL.BAT 之前,一定一定要把第二章最後面Sample Code 那一节看一遍,因为你得修改 PATH 以及其他环境变数 (为什麽作者不加一个 batch 档呢,技术上很简单的嘛)。如果你想反正本书不使用 MFC,用 VC++ 1.0 编译看看,错 ! 除了基础程式 (DLL 以及二、三章),其他程式都需要 OLE2 SDK。没有多少人知道这玩意儿在哪里以及里面是什麽,MSDN Level 2 光碟片 (请看二月份无责任书评) 上有,Visual C++ 1.5 光碟片上也有。VC++ 1.5 安装时会把下列档案拷贝到你的 \Windows\System 目录 :
COMPOBJ.DLL (Component Objects)
STORAGE.DLL (Compound Files)
OLE2.DLL
OLE2CONV.DLL
OLE2DISP.DLL
OLE2NLS.DLL
OLE2PROX.DLL
TYPELIB.DLL
OLECLI.DLL (OLE Client API,原本就有)
OLESVR.DLL (OLE Server API,原本就有)
於是你的 Windows 3.1 就可以执行 OLE2 了;软体开发过程中的 .H 以及 .LIB 则放在 \MSVC\LIB 和 \MSVC\INCLUDE 中。
你可以在磁片安装後的根目录 \INOLE2 中执行 MAKEALL.BAT,作出所有 EXE 程式。makefile 写的很糟糕,编译联结过程中常常就给来一个 "file not found" 讯息,弄的人提心吊胆,生怕前功尽弃。全部完成需至少 50M,谁会闲着这麽大的硬碟空间呢 ? (墨菲定律说不论硬碟有多大,你永远只剩 10% 可用)。一种作法是以MAKEALL 完成前三章程式,然後以 CTRL-C 中断之,将赘馀档案清理清理 (好多赘馀档案,这是 makefile 写的不好的又一个明证),然後随你喜欢进入某个子目录(例如 INOLE2\CHAP07) 再执行其 makefile。问题是,萤幕没有显示 MAKEALL 进行到哪一章,何时 CTRL-C 只好自己拿捏 (怎麽拿捏 ?!)。如果你因某些失误以致必须重新执行 MAKEALL,你将发现全部档案竟然重新来过,完全没有发挥 makefile 的功效。
作者说最好选在午餐时间 MAKEALL,那麽我想你将因此有时间享用一顿丰盛的午餐。由於得使用 VC++ 1.5 编译联结,而几乎每个人是以 Minimum Installation 方式来灌VC++ 1.5 (注),许多档案仍在光碟上,结果是整个 MAKEALL 过程中我又吃了晚餐。(注 : 这种作法占用 12MB 空间。如果是 Typical Installation,需 52MB 空间)
经历这麽多不顺遂之後,下面这个消息也就不会太震憾了 : 15 章程式有误,OleUIAddVerbMenu() 应该有九个叁数,PAGE.CPP 档以及书上 544 页的说明都只有八个叁数。我很难相信这种事会疏忽发生,可能是 OLE2 规格改变所致。
Microsoft Press 另有两本书在你上路时候用的着 : OLE 2 Programmer's Reference,分为两册,上册主讲OLE2 API (960 页,US$ 29.95),下册主讲 Automation (368 页,US$ 24.95,注)。这两本书我还没有看过,书商刚到货,我想你看到这篇文章时书店架上应该已有了。VC++ 1.5 的光碟书中也有这两本 (我对能够在电脑萤幕前看电子书的人至感钦佩,我自己看书时手上一定得有一支笔)。VC++ 1.5 已经在 MFC 2.5 中增加了 OLE2 的 Classes,并提供一本小册 : OLE 2 Classes,如果你想学习以 MFC 2.5 写 OLE2 程式,就这本了。可惜这套编译器因采 CD-ROM 版本,书籍需另购,而且糟的是如果你不想花三千多元买与 VC++ 1.0 大部份雷同的手册,而只是想要其中的 OLE2 或 ODBC 两本新书,不能够。
注 : Automation 也是 OLE2 的一支技术,但与 OLE2 的任何其他部份都没有关联。此一技术已超出了 Inside OLE2 的范围。Automation 的终极目标是要使「系统巨集程式工具」的诞生成为可能。遵循它,你不再需要为自己的软体开发专属的巨集语言给用户使用。用户的利益则是以单一工具 (巨集语言) 即可行遍天下,畅行所有 Automation 软体。Microsoft 选择 Visual Basic 为此一巨集语言。这世界快要被 Microsoft 统一了我看 !!) |
我引用作者在本书第一章的开场白希望引起你对 OLE2 的重视 :
许多年之後,电脑界的达尔文可能会回顾并惊讶 Windows 如何地由一个API 作业系统演化为物件导向作业系统。OLE2 是这个演化的滥觞,它将改变你写 Windows 程式的方法,甚至改变你如何使用 Windows。
不过,这实在是一本难读的书。革命尚未成功,同志仍需努力 !!
侯捷 2010-07-15 08:32:57
稱謂:
内容: