(摘自
http://www.cppblog.com/flagman/archive/2010/12/01/thinking_of_api_design.html)
最近正好在思考系统API设计中考量的一些问题,
引用
【某网友讨论到】
: 那地址是不是同一个地址呢。我现在的理解是这样的,假设有巨大的真实内存。windows首先将高2G的内存自己占了,用作各种内核对象。这2G内存共享给每个进程,但进程不能直接访问,只能通过windows给定的函数访问。
: 然后每个进程都给他2G内存,进程如果创建自己的对象就放到自己那2G内存里面,如果要建立内核对象就放到共享的那高2G里面去。
: 所以不同进程如果可以访问高2G内存的话,任何进程访问到同一个高地址实际上都是访问到同一个对象。但如果访问低2G地址的话,不同进程是对应不同的对象的。
在不同的进程中,询问同一个内核对象的实际地址(无论是线性地址还是物理地址),是无意义的:
首先,内核对象只能由在内核态下的例程才能直接访问,在我们日常的代码中,所调用的Windows API,比如CreateFile, (注意调用刚开始时是处于用户态下的),一般都会在ntdll.dll中找到对应的内核函数或例程,接着系统切换到内核态,开始调用实际对应的内核函数(KiCreateFile),这个时候才会去访问内核对象的实际地址,然后建立一个该内核对象对应当前进程的Handle,并把它返回给caller,同时切换回用户态;因此,对于用户态程序来说,只要且只能知道该内核对象在当前进程中的对应的Handle就可以对其进行操作了;
其次,这样的设计是出于对OS核心数据结构(当然包括我们正在讨论的内核对象)的保护;如果用户态程序可以轻易的获取内核数据结构的实际地址,那么对于整个OS的安全和稳定显然构成很大的问题;一个用户态的误操作可以轻易的引起整个OS的崩溃,而有了这一层的保护,崩溃的只是当前进程而不是整个系统;
接着上面这点,也可以看出,内核对象的如此设计达到了接纳OS本身的平滑演进的目的。从Windows 3.0到95/98,从NT到Win2k/XP,再到眼下的Vista/Win7,Windows操作系统本身发生了巨大的变化和进步,采纳了无数的新技术新方法,但是它基本的系统应用编程接口,也就是我们所熟知的windows API,却并没有发生太大的改变,很多Win 3.0 这个16位OS时代的程序代码只要当初设计规范编码规范,稍许修改就可以在最新版的OS上运行如飞;是什么做到了这些?也就是所谓的极为重要的向后兼容性,我个人认为,把操作系统的重要/主要功能抽象成内核对象,并通过一套极为solid的API暴露出来,达成了这个目标。
这是一种更高层次上的面向对象,把实现的细节,把系统的复杂,简单而优雅的封装了起来。你只要调用CreateFile去建个文件或管道或邮槽,不用担心当前OS是Windows 3.0还是Win7,获得的Handle,你也不用去关心它以及它所指向的内核对象是Windows 3.0的实现还是Win7的实现。
Windows上所有的精彩几乎都是基于这套通过内核对象概念抽象并暴露的API基础之上,COM/OLE,这个二十年前震撼性的ABI和IPC范畴的技术规范,其中很多的设计思路也是植根于内核对象的设计理念,如COM对象的引用计数和内核对象引用计数,IUnknown和Windows Handle(前者是指向某个二进制兼容的组件对象,后者引用或间接指向某个内核对象,都是对于某个复杂概念的一致性抽象表述),等等;
十年前的.net,本来是作为COM的升级版本推出,把COM/OLE的实现复杂性封装在了虚拟机平台CLR里面,而从这个虚拟机的开源实现SSCLI,我们可以看到大量的COM机制在.net的具体实现里面起了举足轻重的作用。在这些VM中大量symbol有着COR的前缀或者后缀,COR指代什么?Common Object Runtime, 原来CLR/SSCLI的设计思路也是把OS通过虚拟机VM的形式,并通过common object向应用程序暴露功能。
小结一下,
● OS内核对象API,三十年前系统级别的对象抽象;
● COM/OLE,二十年前二进制组件级别的对象抽象;
● .net/CLR, 十年前虚拟机平台级别的对象抽象;
写到这里倒是引起了我其他的一些思考,
软件工业界一直以来对面向对象OO是热火朝天,特别是语言层面,从C++/Java/C#到Python/JScript,不一而足;但是我们有没有从根本性的设计理念上对面向对象,察纳雅言了呢?
如果现在设计Windows这套API的任务放在大家面前,会采用内核对象/Handle方案还是直接指向OS内部数据结构的方式来暴露功能?
从三十年前的这套API的设计中,我们真的可以学到很多。
分享到:
相关推荐
《C++ API设计》探索了常常被忽视的技术性和非技术性问题,有助于推动成功的设计决策,从而产生高质量的、健壮的而且可以长期使用的API。” ——Eric Gregory,Pixar动画工作室软件架构师 “《C++ API设计》面向中...
操作系统 课程设计 API windows接口
API演示系统API演示系统API演示系统API演示系统API演示系统
API有哪些品质要求,有哪些关键要素,有哪些通用的技巧,设计时要遵循哪些原则……这些问题都能在本书中找到答案。 本书主要内容。 第1章:API简介。阐释API的概念及其独特之处,概览全书内容。 第2章:特征。解答...
RESTful API设计规范
对于这一软件工程上的难题,martin reddy 凭借长期的从业经验,对优质api 所应具备的各要素进行了全面分析,针对api 的不同风格及模式,以及大型长期项目的内在需求,给出了种种最佳设计策略,从而对api 设计过程的...
系统API大全,常用的系统API函数介绍,比较详细的。
API 设计面临的挑战千差万别,很难有处处适用的准则,所以在讨论原则和最佳实践时,无论这些原则和最佳实践是什么,一定有适应的场景和不适应的场景。因此我们在下文中不仅提出一些建议,也尽量去分析这些建议在什么...
关于数据库的api设计.rar
博文链接:https://handmu.iteye.com/blog/38870
基于百度地图API的安徽省地震灾情调查系统设计研究.docx基于百度地图API的安徽省地震灾情调查系统设计研究.docx基于百度地图API的安徽省地震灾情调查系统设计研究.docx基于百度地图API的安徽省地震灾情调查系统设计...
C++ API设计.pdf
微服务API设计的实践与思考总结.docx
我们从百亿流量交易系统 API 网关(API Gateway)的现状和面临问题出发,阐述微服务架构与 API 网关的关系,理顺流量网关与业务网关的脉络,带来最全面的 API 网关知识与经验。内容涉及: 百亿流量交易系统 API ...
《ASP.NET Web API设计》依托ASP.NET Web API阐述API设计与开发的通用技术,是一本全面介绍如何构建真实可演化API的实践指南。本书共分三部分。第一部分介绍Web/HTTP和API开发的基础知识,介绍ASP.NET Web API,为...
RESTful API后台系统架构设计(Java)
本书帮助你解决API 设计方面的问题,共分3 个部分,分别指出学习API 设计是需要进行科学的训练的、Java 语言在设计方面的理论及设计和维护API 时的常见情况,并提供了各种技巧来解决相应的问题。 本书作者是...
基于AdventNet SNMP API的网络管理系统的设计与开发
本书是从事Microsoft Windows操作系统开发和应用人员的必备参考书 ,也可作为大专院校相关专业师生自学、教学参考用书。 资源是PDF格式的完整书本,总共14章,资源里面不含随书代码,代码可以在很多地方下载到,...
Java API Design Checklist,如何设计api,设计api规范