由MFC程序是否能够在Linux上运行谈起

首先，必须面对的现实是，不经修改的mfc程序是不能在linux下运行的，道理很简单，mfc的基石是windowsAPI，而linux上不可能有他。

那么mfc开发的程序就没办法在linux上重用了吗？下面这篇文章为我们提供了一种方法：
将MFC 应用程序移植到Linux

当然，如果你在编写软件的一开始就知道自己的程序需要运行在window和linux下，那么有人会建议你放弃mfc，而直接使用GTK+做为基础类库进行开发：
GTK+简介

关于MFC与GTK+的对比有此一家之言：
GTK+与MFC不完全对比

可以看到，MFC程序经过改造是可以移植到linux下的，不过，更直接的方法就是使用移植性强的类库，比如GTK+。

==========================摘录==========================

将 MFC 应用程序移植到 Linux

将Windows 应用程序移植到 Linux不必涉及再培训的痛苦经历。MarkusNeifer 演示了如何使用wxWindows 移植 MFC，指导读者使用 wxWindows 这一开放源码工具箱，并循序渐进地向读者介绍了一个完整的移植示例。

您可能仍然在维护用微软基础类库（MicrosoftFoundation Classes（MFC））构建的旧的 Windows 应用程序，而现在却有客户要求 Linux版本，该怎么办呢？在您的团队中可能有技术熟练的 MFC 开发人员，但如何达到加速 Linux 开发呢？别急；本文就是针对您这种情况而写的。依靠 wxWindows（一种用于 C++ 和 Python的可移植 GUI 工具箱）的帮助，我将以多文档界面（Multiple Document Interface(MDI)）文本编辑器为例向您演示如何将仅Windows 的 MFC 应用程序移植到 Linux。类似这样的小型应用程序有助于我们将讨论集中在移植框架的具体细节上，从而避免我们迷失在代码的汪洋中。可以在本文后面的 参考资料一节中获取完整的 MFC 应用程序和 wxWindows 应用程序的源代码。

文档／视图概述

我将演示的应用程序使用众所周知的文档／视图体系结构，因为它可以象大多数应用程序一样处理文档。即使您的应用程序不使用文档／视图体系结构，我也建议您读下去。只要您已在转向这种框架，您就可能想要添加这项功能。

在我的关于wxWindows 的 前一篇文章中，曾经指出过 MFC 和 wxWindows 之间具有某些相似性。字符串类 CString 、 wxString 和事件系统之间都非常相似。但还不止这些相似性。wxWindows 工具箱还提供对文档／视图体系结构的类 MFC 支持。

我将从核心类的比较开始。下表列出了两种框架的文档／视图体系结构所涉及的类。

表 1. 文档／视图类比较

类	MFC 类	wxWindows 类
文档（Document）	CDocument	wxDocument
视图（View）	CView	wxView
编辑视图（Edit view）	CEditView	n/a
模板类（Template class）	CMultiDocTemplate	wxDocTemplate
MDI 父框架（MDI parent frame）	CMDIFrameWnd	wxDocMDIParentFrame
MDI 子框架（MDI child frame）	CMDIChildWnd	wxDocMDIChildFrame
文档管理器（Document manager）	n/a	wxDocManager

除编辑视图类以外，每个 MFC 类都有其对应的 wxWindows 类。（最后一项中 MFC 的部分为空，因为 MFC 没有独立的文档管理器类。由应用程序类 CWinApp 内部处理文档。）下列 UML 图演示了这些类之间的关系：

图 1. MFC 类


图 2. wxWindows 类

回页首

 

应用程序

每个框架都提供一个表示应用程序本身的类。MFC 应用程序类声明了一个构造器、一个用于初始化的方法、一个用于事件处理的方法和一个消息映射表。您需要这个消息映射表声明和事件处理方法，因为应用程序的“about”对话框将由该类处理。

应用程序类：MFC

class CPortMeApp : public CWinApp             {             public:             CPortMeApp();             virtual BOOL InitInstance();             afx_msg void OnAppAbout();             DECLARE_MESSAGE_MAP()             };

 

注：最初创建 MFC 应用程序时，我使用 Microsoft Visual Studio 所包含的应用程序向导来创建，但在我的代码片段中，我将不给出由向导生成的、有时会使人迷惑的注释（ //{{AFX_MSG 及类似的东西）。完整的源代码，请参阅 ZIP 压缩文档。

对应的wxWindows 类看起来略微有些不同。它也声明了一个构造器及一个用于初始化的方法，但却不需要任何东西来处理消息。如同您随后将看到的一样，在主框架类中处理“about”对话框。

应用程序类：wxWindows

class PortedApp : public wxApp             {             public:             PortedApp();             bool OnInit();             int OnExit();             protected:             wxDocManager* m_docManager;             };

 

正如下面所描述的那样，这个类需要一个 wxDocManager 属性来处理在初始化方法 OnInit() 中创建的模板。应用程序退出时，清理方法 OnExit() 将删除这个 wxDocManager 对象。

所有应用程序都需要其入口点（也称为 main() 或 WinMain() ）。在实现这一点的方法上，两种框架略微有些不同。在 MFC 中，象这样创建应用程序类的静态对象：

CPortMeApp theApp;

 

在wxWindows 中，则象这样使用 IMPLEMENT_APP() 宏：

IMPLEMENT_APP(PortedApp)

 

如果对该宏所做的事情感兴趣，请查看头文件 wx/app.h 中它的定义，在可下载的源代码中找到该头文件。基本上，它是为所使用的平台插入适当的入口点函数。创建了应用程序类的对象之后，需要对其进行初始化。对于 MFC，Microsoft 建议不使用应用程序对象的构造器来初始化对象。而是应该使用其 InitInstance() 方法。要执行任何清理，请实现 ExitInstance() 方法。

虽然应用程序初始化有很多事情要做，这里我将只着重讨论与文档／视图有关的代码。要建立文档／视图框架， InitInstance() 方法必须创建一个 CMultiDocTemplate ，如下所示：

创建文档／视图代码：MFC

CMultiDocTemplate* pDocTemplate;             pDocTemplate = new CMultiDocTemplate(             IDR_PORTMETYPE,             RUNTIME_CLASS(CPortMeDoc),             RUNTIME_CLASS(CChildFrame),             RUNTIME_CLASS(CPortMeView));

 

wxWindows应用程序提供 OnInit() 方法来做任何初始化工作，并提供 OnExit() 用于清理。要在 wxWindows 应用程序中建立文档／视图框架， OnInit() 方法必须象这样创建 wxDocTemplate ：

创建文档／视图代码：wxWindows

m_docManager = new wxDocManager();             wxDocTemplate* pDocTemplate;             pDocTemplate = new wxDocTemplate(             m_docManager, "Pom", "*.pom", "", "pom", "Pom Doc", "Text View",             CLASSINFO(PortedDoc),             CLASSINFO(PortedView));

 

MFC 和 wxWindows 所做的事情基本上相同。框架需要关于哪个文档同哪个视图有关以及这个组合处理哪种文档的信息。类型包括文档的描述性名称以及这类文档的文件扩展名。两种框架都使用模板来处理这一问题（请注意这与标准 C++ 模板没有什么关系）。

MFC CMultiDocTemplate 也保存关于同文档相关联的子框架的信息，并且该模板被添加到管理该模板的应用程序对象中。wxWindowswxDocTemplate 额外需要一个管理模板的 wxDocManager 对象。请记住， wxDocManager 是 wxWindows 应用程序的应用程序类的一个属性。

完成文档／视图框架初始化之后，就创建了应用程序的主框架。在 MFC 应用程序的 InitInstance() 方法中，按如下创建一个主框架：

创建主框架：MFC

CMainFrame* pMainFrame = new CMainFrame;             if (!pMainFrame->LoadFrame(IDR_MAINFRAME))             return FALSE;             m_pMainWnd = pMainFrame;             pMainFrame->ShowWindow(m_nCmdShow);             pMainFrame->UpdateWindow();

 

调用 pMainFrame->LoadFrame(IDR_MAINFRAME) 从资源文件装入所有关于主框架的信息。

在wxWindows 中，可以从资源文件建立菜单、对话框以及控件，或者可以在代码中创建它们。我更喜欢在代码中创建它们，但如果您愿意将代码同资源分离，就应该看一看wxWindows 资源系统（请参阅wxWindows 文档中的主题概述）。

创建主框架：wxWindows

m_mainFrame = new MainFrame(m_docManager, (wxFrame*) NULL, "DocView Demo",             wxPoint(0, 0), wxSize(500, 400),             wxDEFAULT_FRAME_STYLE);             // Set up menu bar...             m_mainFrame->SetMenuBar(menu_bar);             m_mainFrame->Centre(wxBOTH);             m_mainFrame->Show(TRUE);             SetTopWindow(m_mainFrame);

 

在查看应用程序初始化完成后发生了什么事情之前，让我向您演示每个框架的文档和视图类。

 

回页首

 

文档

文档保存应用程序处理的基于文件的数据。它负责从文件装入该数据，并在必要的时候将该数据保存回文件。该 MFC 类的声明类似于这样：

文档类声明：MFC

class CPortMeDoc : public CDocument             {             protected:             CPortMeDoc();             DECLARE_DYNCREATE(CPortMeDoc)             public:             virtual BOOL OnNewDocument();             virtual void Serialize(CArchive& ar);             virtual ~CPortMeDoc();             DECLARE_MESSAGE_MAP()             };

 

请注意：该类有一个受保护（protected）的构造器。决不要直接创建该类的任何对象；相反，框架使用序列化来创建文档。因此，需要使用 DECLARE_DYNCREATE() 宏。wxWindows 类的声明类似于这样：

文档类声明：wxWindows

class PortedDoc : public wxDocument             {             public:             virtual bool OnSaveDocument(const wxString& filename);             virtual bool OnOpenDocument(const wxString& filename);             virtual bool IsModified() const;             virtual void Modify(bool mod);             private:             DECLARE_DYNAMIC_CLASS(PortedDoc)             };

 

DECLARE_DYNAMIC_CLASS() 宏是必需的，因为 wxWindows 就象 MFC 一样动态地创建该类的对象。

 

回页首

 

视图

如果 MFC 应用程序处理文本文档，那么从 CEditView 派生视图类是一个好主意。该类已经在其客户机窗口内提供了基本的编辑功能和文本控件。这里我遵循自己的建议，MFC 视图类的声明类似于这样：

视图类声明：MFC

class CPortMeView : public CEditView             {             protected:             CPortMeView();             DECLARE_DYNCREATE(CPortMeView)             public:             CPortMeDoc* GetDocument();             virtual void OnDraw(CDC* pDC);             virtual BOOL PreCreateWindow(CREATESTRUCT& cs);             virtual ~CPortMeView();             DECLARE_MESSAGE_MAP()             };

 

在wxWindows 中，（还）没有专门的编辑视图。但是创建您自己的编辑视图却很容易。只需在视图框架内有一个由 wxTextCtrl 派生的文本控件。视图类将控件和框架都当作类属性来处理。因此wxWindows 声明类似于这样：

视图类声明：wxWindows

class PortedView : public wxView             {             public:             MyTextCtrl* textsw;             PortedView();             bool OnCreate(wxDocument* doc, long flags);             void OnDraw(wxDC* dc);             bool OnClose(bool deleteWindow = TRUE);             private:             wxMDIChildFrame* CreateChildFrame(wxDocument* doc, wxView* view);             wxFrame* frame;             DECLARE_DYNAMIC_CLASS(PortedView)             };

 

除了常见的用于窗口创建、窗口重画以及窗口关闭的事件处理程序之外，该类还有一个创建框架并填充其菜单栏的方法。

虽然拥有公共（public）属性不是一个好主意，但是为简单起见，我在这里还是这么做。在您的应用程序中应该避免这么做（我将在以后的版本中除去它）。

 

回页首

 

主框架

既然已经有了处理和显示数据的文档和视图类，并且也有了处理文档／视图框架的应用程序类，现在需要一个主框架类来同用户交互。同样，两种框架提供类似的功能，而实际实现有略微不同。MFC 主框架类将一个状态栏和一个工具栏作为属性保存，同时 MFC 主框架类还提供一些方法来处理窗口创建，以及声明消息映射表。请注意：该类是从 CMDIFrameWnd 派生而来的，因为该应用程序有一个 MDI 界面。

主框架类：MFC

class CMainFrame : public CMDIFrameWnd             {             public:             CMainFrame();             virtual ~CMainFrame();             virtual BOOL PreCreateWindow(CREATESTRUCT& cs);             protected:             CStatusBar  m_wndStatusBar;             CToolBar    m_wndToolBar;             afx_msg int OnCreate(LPCREATESTRUCT lpCreateStruct);             DECLARE_MESSAGE_MAP()             private:             DECLARE_DYNAMIC(CMainFrame)             };

 

wxWindows主框架类将菜单作为属性保存，还具有创建其工具栏的方法，以及声明一个事件表外加一个处理应用程序的 about对话框的方法。因为这个应用程序有一个 MDI 界面，所以该类是从 wxDocMDIParentFrame 派生而来。

主框架类：wxWindows

class MainFrame : public wxDocMDIParentFrame             {             public:             wxMenu* editMenu;             MainFrame(wxDocManager* manager, wxFrame* frame, const wxString& title,             const wxPoint& pos, const wxSize& size, long type);             void OnAbout(wxCommandEvent& event);             void RecreateToolbar();             private:             DECLARE_CLASS(MainFrame);             DECLARE_EVENT_TABLE();             };

 

回页首

 

全部工作原理

移植完成了。我来回顾一下实现这一点所需做的事情。MFC 应用程序类（派生自 CWinApp ）移植到派生自 wxApp 的应用程序类，包括初始化代码。将 MFC 文档类（派生自 CDocument ）移植到派生自 wxDocument 的文档类。将 MFC 视图类（派生自 CView ）移植到派生自 wxView 的文档类。除了这些同文档／视图有关的类之外，将 MFC 主框架类（派生自 CMDIFrameWnd ）移植到派生自 wxDocMDIParentFrame 的类。

在其目前的版本中，该应用程序已经能够做很多工作。可以处理多个文本文件。可以打开、编辑并保存这些文件，并且应用程序保持最近打开文件的历史记录。如果不得不从头编写这些功能，那么将需要更多行代码 ― 更多行代码意味着要测试和维护更多行。在两种框架中，都使用了专门的命令标识符来处理常用的同文档／视图有关的命令。常用的文件命令是新建、打开和保存。常用的编辑命令是剪切、复制和粘贴。其它经常使用的命令有打印命令（这个应用程序中还没有实现该命令）和帮助命令。下表列出了这两种框架结构的文档／视图体系结构所包含的命令标识符。

表 2. 标准的命令标识符

MFC	wxWindows
ID_FILE_OPEN	wxID_OPEN
ID_FILE_CLOSE	wxID_CLOSE
ID_FILE_NEW	wxID_NEW
ID_FILE_SAVE	wxID_SAVE
ID_FILE_SAVE_AS	wxID_SAVEAS
ID_EDIT_CUT	wxID_CUT
ID_EDIT_COPY	wxID_COPY
ID_EDIT_PASTE	wxID_PASTE
ID_APP_EXIT	wxID_EXIT
ID_EDIT_UNDO	wxID_UNDO
ID_EDIT_REDO	wxID_REDO
ID_HELP_INDEX	wxID_HELP
ID_FILE_PRINT	wxID_PRINT
ID_FILE_PRINT_SETUP	wxID_PRINT_SETUP
ID_FILE_PRINT_PREVIEW	wxID_PREVIEW

 

回页首

 

窗口管理器

如果您对 Linux开发真的很感兴趣，则可能已经做了一些研究，发现 Linux上有不同的窗口管理器。曾经是 MFC 开发人员的您可能觉得这很奇怪。在进行 Windows 开发时，您无须操心不同的窗口管理器，因为只有一个窗口管理器。

开始wxWindows 开发时，您可能想知道您的应用程序是否将运行在两个主流的窗口管理器 ― K 桌面环境（K Desktop Environment (KDE)）和 GNOME ― 之上。我已经在Microsoft Windows NT 4.0、使用公共桌面环境（CommonDesktop Environment (CDE)）的 SunSolaris 2.6 以及使用 KDE 的 Linux 2.2 上使用了wxWindows 工具箱，没有任何问题。由于wxWindows 仅仅是一个建立在其它低级别 GUI 工具箱上的高级别层次，所以可以选择如何构建 Linux 应用程序。可以使用 Motif 版本（或者还要更好一些的，免费Lesstif）或者 wxWindows 的 GTK+ 版本。GTK+ 是 GNOME 使用的基础窗口构件工具箱，但是它在 KDE 下也运行得非常好。我建议您使用 GTK+ 版本，因为它通常更新，有许多开发人员对它进行开发，而且有用户在使用它。因此，如果您希望获得更多帮助，则可以求助于邮件列表或新闻组，询问关于 GTK+ 版本的问题。

下面是前前后后的抓屏，可以让您对移植的应用程序有一个大致的认识。

图 3. 原始的 MFC 应用程序


图 4. Windows 上的 wxWindows 应用程序


图 5. Linux/KDE 上的 wxWindows 应用程序

回页首

 

真实的故事

wxWindows工具箱不只是书呆子的另一个玩具。它成熟、稳定，并且人们在实际应用程序中用它来解决实际问题。

wxWindows项目创始人 Julian Smart 目前致力于 Red Hat，他已经将 eCos 配置工具（eCos Configuration Tool）移植到了 wxWindows。eCos 配置工具是一个配置 eCos 嵌入式操作系统的图形工具。人们已将最初的 MFC 应用程序移植到了 wxWindows，尤其是在 Linux上（参阅 参考资料）。SciTech Software 的人员也已经使用wxWindows 来全部重新开发用于SciTech Display Doctor 产品的前端 GUI。IBM 已经获得了SciTech Display Doctor 的一个专门版本的许可证，IBM 现在将其作为 IBM 所有基于 OS/2Warp 的操作系统（包括 WarpClient、Workspace On Demand 及 Warp Server for e-business）的主要显示驱动程序来分发。SciTech Software 对 wxWindows 社区做出了积极的贡献，它提交了扩展包wxApplet、wxUniversal 和 wxMGL。使用 wxMGL，wxWindows 应用程序甚至可以运行在 DOS 和其它嵌入式操作系统之上，例如 QNX、RT-Target、SMX 等等。SciTech Software 全力资助wxUniversal 和 wxMGL项目（参阅 参考资料）。

 

回页首

 

结束语

本文演示了使用wxWindows 工具箱将 MFC 文档／视图框架的 Windows 应用程序移植到 Linux的基本原理。wxWindows 工具箱同 MFC 框架有一些相似性，从而帮助 MFC 开发人员可以达到加速 Linux 开发。有了这些基础知识，您应该能够将最棒的应用程序移植到 Linux。但不要忘了：wxWindows 不是只能用于 Linux。也许该是考虑在其它 UNIX 或者甚至 Macintosh 上来运行您的应用程序一个版本的时候了。

 

参考资料

• 您可以参阅本文在 developerWorks 全球站点上的 英文原文.
• 从 Markus 的主页下载本文所演示的原始应用程序和移植的应用程序的 完整源代码。
  
  
• 有关 wxWindows 的概述，请阅读 Markus 的文章 细述 wxWindows（ developerWorks，2001 年 2 月）。
  
  
• wxWindows 主页是 wxWindows 社区成员要去的主要场所。它提供关于 wxWindows 的信息及对它的支持，包括下载、邮件列表、样本应用程序以及与 wxWindows 有关的工具。
  
  
• Coding with KParts讨论了 K 桌面环境（K Desktop Environment）图形组件的 KParts 体系结构（ developerWorks，2002 年 2 月）。
  
  
• 有关更多关于 K 桌面环境的内容，请访问 KDE 主页。
  
  
• 有关更多关于 GNOME 的信息，请查看 GNOME 主页。
  
  
• 在 Red Hat 站点上可以找到更多关于 Red Hat eCos 配置工具的内容。
  
  
• 可以在 SciTech Software 站点上获取更多关于 SciTech Display Doctor的信息。
  
  
• 可以在 OS/2 Warp 页面上找到更多关于 OS/2 设备驱动程序包（它使用 SciTech Display Doctor）的信息。
  
  
• 在 developerWorksLinux 专区里可以找到 更多 Linux 文章。

 

关于作者

	Markus Neifer 最初使用 LOGO 教学语言来编程，后来他使用过多种 BASIC 语言。在研究地理信息学期间，他学了一些 C，但很快又转向了 C++ 和 Java，因为这两种语言具有面向对象的本质。他曾在研发领域工作过，期间他出版过关于科技软件的面向对象开发的文章。目前，他是地理信息系统领域的软件工程师。可以通过 [email protected]和 Markus 联系。

GTK+

　　最初，GTK+ 是作为另一个著名的开放源码项目 —— GNU Image Manipulation Program (GIMP) —— 的副产品而创建的。在开发早期的 GIMP 版本时，PeterMattis 和 Spencer Kimball 创建了 GTK（它代表 GIMPToolkit），作为 Motif 工具包的替代，后者在那个时候不是免费的。（当这个工具包获得了面向对象特性和可扩展性之后，才在名称后面加上了一个加号。）

　　这差不多已经 10 年过去了。今天，在 GTK+ 的最新版本 ——2.8 版上，仍然在进行许多活动，同时，GIMP 无疑仍然是使用 GTK+ 的最著名的程序之一，不过现在它已经不是惟一的使用 GTK+ 的程序了。已经为 GTK+ 编写了成百上千的应用程序，而且至少有两个主要的桌面环境（Xfce 和 GNOME）用 GTK+ 为用户提供完整的工作环境。

　　为什么使用 GUI 工具包？

　　使用 GTK+ 这样的库比起编写自己的 GUI 代码来有多个优势。例如，它可以显著节约开发时间，让开发人员把精力集中在项目真正重要和真正独特的地方，而不必重复公共的功能。对于用户来说，这意味着他们使用的应用程序之间具有更好的一致性：工具包能在哪使用，应用程序就能跟到哪里。就像使用 LEGO 一样，所有的人都使用同一兼容尺寸这一事实，意味着设计可以在使用库的人之间共享，不论他们在哪里使用它。

　　在现实中，现代的 GUI 工具包做的工作不仅仅是避免重复。它们提供了许多高级功能，用户希望在他们的应用程序中拥有这些功能，但是用别的方法得不到这些功能，因为在这类工具包上所投入的时间和工作，要远远超过在单一应用程序上的花费。所以，如果在应用程序中使用 GUI 对您来说很重要，那么请使用工具包。除此之外别无他法。现在剩下的惟一问题就是，应当使用哪个工具包？

　　GTK+ 的优势

　　不论开发的需要是什么，GTK+ 可能就是您正在寻找的答案。GTK+ 提供了许多东西：

　　它既现代，而且得到了积极的开发与维护，围绕它有一个充满活力的社区。

　　它提供了广泛的选项，用于把工作扩展到尽可能多的人，其中包括一个针对国际化、本地化和可访问性的完善的框架。

　　它简单易用，对开发人员和用户来说都是这样。

　　它的设计良好、灵活而可扩展。

　　它是自由软件，有一个自由的开放源码许可。

　　它是可移植的，从用户和开发人员的角度都是这样。

　　现代的且开发积极的工具包

　　GTK+ 是采用软件开发中的最新技术开发的，只要发现缺陷（肯定有缺陷，因为没有任何软件是完美的），开发人员就会尽力在下一版本中修补缺陷。使用现代的软件意味着，您不会陷在过时的工作中，而跟不上时代的发展。

　　持续的维护和开发也意味着您拥有影响工具包的未来发展方向的能力。另外，在出现新的发行版时，会引入基于用户反馈的新特性和新功能，而旧的问题则得到修补。

　　国际化、本地化和可访问性

　　在创建要让所有人使用的软件的时候，请记住三个关键字：国际化、本地化和可访问性（通常分别缩写为 i18n、l10n 和 a11y）。

　　国际化 是将程序准备为被母语不是开发应用程序所采用的语言的人使用的过程，所以应用程序不依赖于对任何特定语言的任何假设。

　　i18n 远远不只是对程序使用的文本进行翻译。它还意味着要考虑所使用的不同脚本和字母表、不同的编写方向、显示许多语言所需要的特殊处理以及为用户提供输入文本的适当方法。不是每种语言都可以简单地把每个字母映射到键盘上的不同键，而且还必须实现更好的复杂性，例如确保在错误消息中使用正确的复数。

　　本地化 与 i18n 密切相关，因为为国际用户准备应用程序不仅仅是改变语言。程序还必须能够理解并尊重日期、货币显示、数字标注、文本排序所使用的不同习惯，以及许多可能不太注意的细节之处 —— 例如有些符号的使用，在世界的不同地方可能会被认为是不恰当的或无礼的。

　　正像 i18n，正确的 l10n 要求在代码中添加很多东西，而这些是事后很难轻松加入的。GTK+ 提供了针对 i18n 和 l10n 的恰当工具，会让代码（和二进制）可以在许多语言和地域上不加修改地运行。切换地域所需要的就是随操作系统（针对 l10n）或者一个可独立于实际的程序进行处理和发布的翻译文件（针对 i18n）一起发布的一组数据。带来的灵活性会得到开发人员、翻译者和用户的热爱。

　　可访问性 是让每个人都可以使用您的程序。有些用户的视力不佳，有些人可能不能用键盘或鼠标，而有些人可能只能移动他们的眼睛。要确保每个想使用您的应用程序的用户都能使用，需要做许多工作。幸运的是，GTK+ 提供了一个途径，可以通过一个完善的预先存在的 a11y 框架，立即得到这方面的支持，而您这边几乎什么工作也不需要做。使用这个框架（它是UNIX® 系统上的事实标准），可以把应用程序带给各类用户。

　　您也能享受 a11y 的许多优势 —— 例如执行自动 GUI 测试的能力。通过让特殊需求用户运行的可访问性软件可以使用您的应用程序，您也可以让测试软件可以访问它，例如，检查行为是否正确 —— 这在传统的 GUI 编程中会带来严重的问题。（还值得记住的是：现在，a11y 不再被当作 “好” 东西。许多法规 —— 例如有关美国政府用软件的规则 —— 实际上要求软件对特殊需求的用户有恰当的支持。）

　　以上三点可能是使用工具包的充足理由 —— 特别是 GTK+，它在这三个领域都有优秀的支持。这个支持绝不完美，但在同类软件中是最好的，而且把这些关键字整合进应用程序的重要性并没有提到应有高度。在今天的世界中，计算机无处不在，用户众多而且独特，所以不能认为一个遗漏一整群用户的应用程序是一个完整的产品。

　　简单易用

　　这一点应当很明显，但是它实际上含义丰富。工具包对用户应当容易，这样才有可能创建简单的、直觉的和乐于使用的界面，哪怕针对的是新手。创建人机交互的正确模型不是一项简单的任务，GTK+ 正是长时间工作的结果，而且是众多的甚至困难的决策的结果。

　　GTK+ 对于开发人员也易于使用。它允许开发人员用简单的方式说出自己想要的东西，不会用所谓正规方式给开发人员带来负担，这些正规方式是计算机为了弥补它们固有的缺乏想像力的缺陷而施加给人类的负担。

　　设计良好、灵活和可扩展

　　编写 GTK+ 的方式允许在不扭曲基本设计的情况下，让维护人员添加新功能、让用户利用新功能。工具包也是可扩展的，这意味着可以向其中添加自己的块，并用使用内置块一样的方式使用它们。例如，可以编写自己的控制元素，比如说用于显示应用程序处理的科学数据，并让它正确地遵照用户选择的显示风格，就像 GTK+ 自身的控件那样。

　　更进一步，GTK+ 是可定制的，这样就可以让它适应自己的需求。GTK+ 有一个系统，可以在所有应用程序之间复制设置，包括主题的选择。主题 是一组一同发布的定制设置，会影响 GTK+ 使用的基本控件看起来的效果，甚至某种程度上的行为方式。使用主题，可以（例如）模拟另一个操作系统的观感。

　　带有自由开放源码许可的自由软件

　　自由软件 意味着每个人不仅可以自由地获得和使用这个工具包，还可以在满足某些条件的情况下修改并重新发布它。自由开放源码许可 意味着这些条件不是严格限制的，可以得到的自由程度是显著的。最重要的是，GTK+ 采用了 Lesser General Public License (LGPL) 许可，这是 GNU 许可家族中一个不太严格的许可。LGPL 允许自由地获取、修改和发布它覆盖的任何软件，只要对修改也保持自由即可。LGPL 还允许任何人使用该库提供的功能，而不 要求用户公开应用程序代码。（这对于许多工业应用来说很重要，因为由于以前的协议或许可，这种场合下一般不希望公开代码或者公开代码是显然不现实的。）使用 LGPL 许可，您既可以是开放源码社区的好伙伴也可以是好公民。

　　可移植

　　最后（但并不是最不重要），GTK+ 是可移植的。这意味着用户可以在许多平台和系统上运行它。另一方面，开发人员可以把软件提供给众多用户，却只要编写一次程序，还可以使用许多不同的编程和开发平台、工具和编程语言。所有这些都可以理解为更多的潜在用户，您可以利用更好地满足需求的更广泛的技能和工具。

　　所有这些优势组合在一起，让 GTK+ 成为软件开发的坚实基础。有了它，就能够把注意力集中在解决实际问题上，而不必重新发明轮子，而且您也可以确信创建的应用程序会按照用户预期的方式运作、解决他们的问题，而不必创建新的应用程序。

GTK+与MFC不完全对比

ChinaItLab absurd 2006-11-27 保存本文 推荐给好友 收藏本页

欢迎进入Linux社区论坛，与200万技术人员互动交流>>进入

   MFC已经江河日下，日渐式微，而GTK+可谓欣欣向荣，如日中天。这里无意于落井下石，痛打落水狗，贬MFC而尊GTK+。自己即在使用MFC也在使用GTK+，不会偏袒其中之任何一方。这个对比完全出于个人对两者的理解，说它是不完全对比，一方面只是一时兴起想做个笔记而已，另外一方面我对两者的理解也是有限的。

 

1.        两者都是基于面向对象设计的。尽管MFC是用C++写的，而GTK+是用C写的，但思想都是面向对象的。GTK+使用glib的对象机制，由于用C写的，其实现相对有点繁琐。

 

2.        两者都是基于消息驱动的。这是GUI系统的共性，消息可以是硬件上报的，如鼠标事件、键盘事件和触摸屏等等，也可以是程序产生，如一个窗口给另外一个窗口发送了一个消息。但两者并不完全相同，GTK+通过select挂在多个文件描述符上，可以同时等待多个事件源，比如socket、子进程退出和内核事件等等，而MFC只能通过GetMessage挂到消息队列上。

 

3.        两者都不是线程安全的，即只有一个线程可以操作GUI资源。主要是出于性能的考虑，这个问题不大，因大多数应用程序都是单线程的。而且它们都提供一些机制，让其它线程可以在必要时操作GUI资源。在GTK+中可以通过idle函数来实现，在MFC中可以通过PostMessage来实现(附带说明一下：Win32原生的GUI API是线程安全的)。

 

4.        GTK+整合了一系列的基础函数库，功能强大，而MFC孤军做战，势单力薄。Glib是GTK+的基本库，里面实现了常见的容器和算法，可谓应有尽有，同时隔离了平台相关的功能。Pango是GTK+用于文字渲染的函数库，它负责控制不同文字的layout布局，而把字模的绘制交给freetype等字体函数库处理。MFC虽然实现了一些容器，但数量不多也不好用，除了对原生GUI API的包装外，没提供多少其它功能，与Microsoft Foundation Class Library这个名称一点都不相称。

 

5.        GTK+是跨平台的，而MFC则不是。GTK+在设计时就考虑了可移植性，它按分层模型来组织整个系统，Glib封装了依赖于OS平台的函数，提供一套抽象的接口，在不同的平台有不同的实现。GDK封装了依赖于输入/输出设备的功能，如键盘事件的获取和显示缓冲的输出，同时实现了基本的绘图功能。GTK+几乎可以在所有PC平台下运行，而MFC从来都没有考虑过可移植性，它是与Win32 GUI绑定在一起的。

 

6.        GTK+小巧，而MFC笨重。GTK+编译出来的可执行文件约3M左右，而MFC本身虽然不大，但它各种版本加在一起就可观了。MFC有ansi版本、有unicode版、有debug版、有release版、还有一些组合，如果你因此而晕倒了，那是很正常的。

 

7.        GTK+的使用简单，MFC的使用繁琐。GTK+的使用比较简单，即使在没有工具的帮助下，要写一个GTK+的应用程序也不难，实际上绝大多数GTK+应用程序都是一行代码一行代码的敲出来的。而MFC的使用则太麻烦了，很难想象没有VC的向导的帮助，写一个基于MFC的应用程序。即有了VC的向导，仍有大量的程序员说MFC很难用。

 

8.        GTK+使用signal机制，解开消息源与消息目标之间耦合。而MFC使用消息，将消息源与消息目标硬编码在一起。Signal的好处是，不需要知道目标是谁，谁关心谁就注册，这种出版订阅机制是解耦的最佳方式。而MFC的消息则是必须知道目标是谁，把消息源与消息目标死死的绑在一起。MFC提供了一套文档/视图框架，实现了类似出版订阅的功能，这本是设计者引以自豪的东西，结果因为太复杂不能被人理解，反而为开发人员所诟病。

 

9.        GTK+采用layout机制动态计算各子窗口的坐标位置，自适应屏幕大小的变化。而MFC要求子窗口的坐标位置硬编码，结果要适应不同分辨率的屏幕非常困难。GTK+在窗口布局时分为两个阶段，第一个阶段父窗口先询问子窗口的最佳大小，第二个阶段父窗口根据自己的大小计算子窗口的实际大小，子窗口根据实际大小进行调整。

 

10.    GTK+采用容器机制来合理分离控件的职责，MFC没有容器这个概念，很难实现递归组合。GTK+中差不多所有控件都是容器，都可以容纳其它任何控件，而MFC只有顶层窗口才是容器，可以容纳其它子控件。容器这个概念对代码重用的影响非常之大，这里举两个例子：其一是带图片的按钮(BitmapButton)，在GTK+中它就是GtkImage和GtkLabel的组合，而在MFC中，图片和文字都要自己绘制。前者的GtkImage和GtkLabel可以在很多地方重用，而后都的绘制代码和事件处理代码只有自己才能使用。其二是列表框，在GTK+中，它只是一个容器，你可以向里面放编辑器、下拉框和其它任何者你想得到的控件。而在MFC中，即使只是实现一个不同外观的列表框，你都要采用自绘的方式，代码重用非常困难，向列表框中加入其它控件就更麻烦了，要使用一些非同寻常的手段不可。

 

11.    GTK+采用容器机制优先使用组合而不是继承，符合现代设计的原则。MFC强制使用继承，使用麻烦而且耦合紧密。GTK+应用程序不需要继承任何窗口。MFC应用程序必须继承对话框或者其它顶层窗口才行，虽然可以采用中介者模式，把控件之间的交互集中在顶层窗口中，不需要继承控件，但仍然很麻烦。