API:Application Programming Interface – 应用程序编程接口
SDK:Software Development Kit – 软件开发工具包
MFC:Microsoft Foundations Classes – 微软基础类
应用程序接口为:“计算机操作系统(Operating system)或程序库提供给应用程序调用使用的代码”。其主要目的是让应用程序开发人员得以调用一组例程功能,而无须考虑其底层的源代码为何、或理解其内部工作机制的细节。API本身是抽象的,它仅定义了一个接口,而不涉入应用程序如何实现的细节。
举个例子:当我们使用 C 语言编程,调用 printf(“Hello world\n”) 这个 API 函数向显示器输出字符串"Hello world"的时候,我们并不需要关注显示器是如何绘制这个字符串的,我们只需要知道调用 C 语言提供的 printf() 这个 API 函数即可。
Windows 程序设计有两种方式: C语言方式(SDK)和 C++方式(对SDK函数进行包装,如VC中的MFC、BCB中的VCL)。
一般是一些被软件工程师用于为特定的软件包、软件框架、硬件平台、操作系统等创建应用软件的开发工具的集合。
Windows SDK 编程简单的说就是使用 C 语言调用 Windows 提供的 API 函数的编程。例如下边这个对话框就是简单的调用 MessageBox() 这个函数实现的:
MFC 是一个微软公司提供的类库(class libraries),以 C++ 类的形式封装了 Windows API,并且包含一个应用程序框架,以减少应用程序开发人员的工作量。其中包含的类包含大量 Windows 句柄封装类和很多 Windows 的内建控件和组件的封装类。
简而言之,SDK 编程就是直接利用 Windows 提供的 API 函数进行编程,而 MFC 是利用类的概念对 API 函数进行封装,结合面向对象的继承、多态组成一个个类,共有一百多个类组成。
微软千辛万苦封装了个 MFC,但很多资深程序员反而警告初学者不要去学习 MFC,这是为什么呢?
对于程序员来说,操作系统的功能完全是由 API 来定义。也就是说,操作系统若能够完成的事情,都会提供相应的 API 供调用。因此,搞熟这些 API 对你理解 Windows 的运行机制非常有帮助。今后你无论使用什么来编写 Windows 程序,都是水到渠成。
API 函数本身就是进行了一层封装(例如上边我们提到的,我们根本不需要去理解如何在屏幕上显示字符串的原理),而 MFC 是再对 API 进行封装。因此初学者如果直接学习 MFC 编程,就很难理解 Windows 的运行原理,而不理解原理的学习就会显得亦步亦趋。
反过来,如果当你首先掌握了这些 API 函数以及 Windows 的运行机制,你再来学习 MFC,学习就会变得事半功倍了!
节选一:
对于程序员来说,操作系统的功能完全由 API 来定义。API 涵盖了应用程序所能调用的全部操作系统函数,以及相关的数据类型和结构。
节选二:
一般来说,Windows API 自 Windows 1.0 起就一直保持着很好的一致性。要说 API 的演变其实也就是不断地扩充。从当初 Windows 1.0 只能支持不到 450 个函数,到今天的 Windows 支持数千个。
节选三:
使用 C 语言调用基本的 API 并不是编写 Windows 程序的唯一方式,但这一方式为开拓 Windows 功能提供了最佳的性能、最强的功能和最大的多样性。所产生的执行代码相对来说也很小,不需要外部程序库就可以运行(当然,Windows 自己的 DLL 除外)。更重要的是,无论将来你用什么编写 Windows 程序,搞熟这些 API 都能让你对 Windows 的内部有更深刻的理解。
节选四:
显而易见,究竟用哪种方式编写 Windows 应用程序最好,其实并无一定之规。应用程序本身的特性应该是决定采用何种编程工具的最主要因素。但是无论将来你采用什么编程工具,通过了解 Windows API 从而深入理解 Windows 的工作原理,这本身就具有很重要的意义。
节选五:
Windows 是一个非常复杂的系统,在 API 之上加一层编程语言并不能消除其复杂性,最多不过是把复杂性隐藏起来而已。说不定什么时候,Windows 复杂的那一面迟早会蹦出来拖你的后腿,懂得 API 能让你到时候更快地挣脱困境。
节选六:
在基本 Windows API 之上的任何软件层或多或少都会限制你使用 Windows 的全部功能。比如,你或许发现采用 Visual Basic 来编写你的应用程序非常理想,但是就有那么一两项非常基本的功能 Visual Basic 无法支持。往往这种时候,你就非得调用基本 API。作为 Windows 程序员,我们的活动空间完全由 API 来规范,再没有什么其他方式能比直接调用 API 更有效、更灵活多样了。
节选七:
MFC 的问题尤其严重。尽管它极大地简化了某些工作(如OLE),但我经常发现自己会在某些其他功能上摔跟斗(比如让文档/视图的体系结构按照我的设想来工作)。并非像很多人一厢情愿期望的那样,MFC 始终没有能成为 Windows 编程的万灵宝药,几乎也没人认为它是一种很好的面向对象的设计模型。MFC 程序员通常受益最多的是对他们用的类定义的理解,他们总是经常不断地在查询 MFC 的源代码。而了解 Windows API 的好处之一就是能帮助你读懂 MFC 源代码。