源码剖析——深入Windows句柄本质

参考资料:

1. http://www.codeforge.cn/read/146318/WinDef.h__html

windef.h头文件

2. http://www.codeforge.cn/read/146318/WinNT.h__html

winnt.h头文件

3. https://msdn.microsoft.com/en-us/library/windows/desktop/aa383681%28v=vs.85%29.aspx

微软官网中关于STRICT的内容

4.http://wenku.baidu.com/link?url=j0ubLizIjhgmxthACfwBa4IpXrdqyyFg84a9MPmwusN4XhalR94kVaDAeR6GlFCMVD_AQORTLyfEC84-tqUWo27dziBXKjNdAqXe8Ich0eu

C语言宏中"#"和"##"的用法

5. http://www.cnblogs.com/kerwinshaw/archive/2009/02/02/1382428.html

typedef和#define的用法与区别

6. http://blog.csdn.net/geekcome/article/details/6249151

void及void指针含义的深刻解析

写在前面:

本文是对在下上一篇文章《图解说明——究竟什么是Windows句柄》的扩充。同样地,本文依然是面向初学者的。让编程语言变得平易,让初学者学起来你更加舒服,在交流中与广大读者同勉共进,是在下的一贯宗旨和追求。所以,在对源码的解释中,在下会尽可能做到详细,具体到句,对于与句柄不是特别相关的内容,也会加以解释说明。和上一篇一样,我们仍然把窗口、位图、画笔等统称为对象。

还有一点必须要交代,在下对Windows句柄这一细节的研究,还存在一些疑问,这将在文末进一步说明。

先看winnt.h中关于HANDLE(句柄)的定义:

typedef void *PVOID;

#ifdef STRICT

typedef void *HANDLE;

#define DECLARE_HANDLE(name) struct name##__ {

int unused;

};

typedef struct name##__ *name

#else

typedef PVOID HANDLE;

#define DECLARE_HANDLE(name) typedef HANDLE name

#endif

以上代码typedef void *PVOID;来自winnt.h(参考资料2)中的第178行,其余代码来自winnt.h中的第285~293行,考虑到易读性,在下对代码格式稍稍做了调整。

在分析源代码之前,再说一点,那就是typedef和#define的区别的问题。typedef用来定义一个标识符及关键字的别名,而#define是宏定义,简单说,就是字符串替换。如果有读者还不是很明白,可以参阅参考资料5。在下面的叙述中,我们将两者都译为“定义”。因为在下觉得这样可以带来叙述上的方便,并且如果大家理解了typedef和#define的区别,这样做并不会造成理解上的误会。

下面我们开始逐句分析代码。

首先,typedef void *PVOID;,这里将PVOID定义为void*型,以后,PVOID a,b;就相当于void *a,*b;(注意不是void *a,b;)。这里再简单说一下void*,简单说,void *就是“无类型指针”,可以指向任何数据类型,详情可参阅参考资料6。

下面的一段总体上是if——else结构。我们先看if部分。

#ifdef STRICT

如果定义了STRICT,就执行后面的代码。关于STRICT,在后面我们还会进行详细的讲解,这里我们暂时将其跳过,先看条件成立时的代码。

#define DECLARE_HANDLE(name) struct name##__ {

int unused;

};

这里是一个带参数的宏定义,name是参数,##为粘贴符号,表示把左右两边的内容连接起来。关于带参数的宏定义和##,读者可以参阅参考资料4。

这里将结构体

struct name##__

{

int unused;

};

定义为

DECLARE_HANDLE(name)。

接下来,

typedef struct name##__ *name

定义一个指针name,指向上面的结构体name##__。

下面我们以窗口句柄HWND为例,进一步说明。

在windef.h头文件(见参考资料1)的第196行有代码

DECLARE_HANDLE            (HWND);

我们将宏展开,就是

struct HWND__

{

int unused;

};

同样,根据typedef struct name##__ *name

有typedef struct HWND__ *HWND。

即句柄HWND是一个指针,指向结构体struct HWND__。

其它句柄的定义与HWND类似,这里不再赘述,读者可以参阅参考资料1中从195行往后的代码。

注意这里我们忽略了一个细节,那就是结构体中的int unused。关于这一点,我们先暂时忽略,在后面的“尚未解决”板块,在下将对这一问题作出交代。

有了前边的经验,分析else部分的代码就变得容易了,让我们一起来看。

typedef PVOID HANDLE;

由于前边有typedef void *PVOID;,所以这里HANDLE被定义为void*型。

接着,

#define DECLARE_HANDLE(name) typedef HANDLE name

这里将

typedef HANDLE name

定义为

DECLARE_HANDLE(name)。

还以HWND为例,在这种情况下,

DECLARE_HANDLE            (HWND);

宏展开为

typedef HANDLE HWND,

即此时HWND为void*型。

好了,说完这些,我们着重说一下STRICT。相关内容请参阅参考资料3。

在windef.h头文件的第13~17行定义了STRICT,源代码如下:

#ifndef NO_STRICT

#ifndef STRICT

#define STRICT 1

#endif

#endif /* NO_STRICT */

这里仅仅是将STRICT定义为数值1,看不出什么名堂。关键在于编译器(注意不是系统)对STRICT的“解释”。

顾名思义,STRICT是“严格”、“严厉”的意思。当编译器“看到”定义了STRICT后,就会对Windows 应用程序中使用的句柄进行严格的类型检查。Windows官网中的原文为Enabling STRICT redefines certain data types so that the compiler does not permit assignment from one type to another without an explicit cast.

也就是说,如果定义了STRICT,除非显式强制类型转换,否则不允许将数据从一种类型转化到另一种类型。换句话说,定义STRICT可以禁止隐式类型转换。

那么,这是怎么实现的,又有什么用处呢? 以窗口句柄HWND和钩子句柄HHOOk为例。在windef.h头文件的第196、197行定义了HWND和HHOOK:

DECLARE_HANDLE            (HWND);

DECLARE_HANDLE            (HHOOK);

通过前面的分析,我们知道,如果定义了STRICT,那么自然执行#ifdef STRICT后的代码,这样,HWND就是HWND__*型的指针,而HHOOK就是HHOOK__*型的指针,两者类型不同。如果没有定义STRICT,那么将执行#else后的代码,可以发现,这段代码直接将所有句柄都定义为HANDLE,即PVOID,也就是void*型。在这种情况下,上面的HWND和HHOOK都是void*型,类型相同。那么,两种情况下有什么差别呢?我们举例说明。

现在一个函数要求一个HHOOK类型的参数,而我们传给它一个HWND类型的参数。在没有define STRICT的情况下,这将是合法的,因为HHOOK和HWND都是void*类型。而如果我们定义了STRICT,HHOOK和HWND就是两个不同类型的指针,上面的参数传递将变为不合法,并且在编译阶段就会报错,这就避免了直到程序出现了运行时错误,程序员才知道代码有错的情况。

顺便说一句,现在VC、VS都define了STRICT,即都默认进行严格的类型检查。

至此,相信大家已经明白了STRICT的作用以及为什么不直接用int unused而要用结构体将其封装起来。

最后,让我们一言以蔽之,来总结一下Windows句柄的本质:

      Windows句柄本质上就是一个指向结构体的指针(define STRICT的情况下)

而所谓“指针的指针”的说法并不正确,这只是一个逻辑上的理解。

尚未解决:

现在,让我们回到前面忽略掉的关于int unused的问题上来。

如果有读者看过了在下的上一篇文章《图解说明——究竟什么是Windows句柄》,那么相信有人会和在下最初的想法一样,认为这里的unused就是我们说的区域A。句柄指向一个结构体,而这个结构体中唯一的数据unused中存放着对象的地址(虽然unused不是指针类型,但int和指针同为4个字节,将对象的地址存到unused里,将来再用某种方式通过unused找到该对象,这也是可以实现的),这与我们先前的图示恰好吻合。但稍加琢磨,我们发现这样解释在某些地方还是有些说不过去的。理由起码有2:

①首先是名字问题,相信稍微细心的读者就会发现这一问题。通过前边的源代码看,每一个名字都恰如其分地反映了它应有的意义,照这么看,结构体中的int变量存放了一个有用的地址,那它就不应该叫unused。

②如果unused相当于区域A的话,在define STRICT的情况下,句柄指向了区域A,而在没有define STRICT的情况下,并没有定义结构体,句柄被定义为void*型,那么,这种情况下的区域A又在哪里,句柄又如何指向它?

所以,综合前面的分析,在下认为,unused并不是区域A。关于int unused,在下的一个猜想是:

进程创建时,系统在内存的一个地方存放各个对象的地址,同时系统为各个对象指定句柄,存放在内存中另一个地方,并使各个句柄指向相应对象的地址(即区域A)。至于如何指向,很可能是这样:

对于未define STRICT的情况,直接指向就可以,因为此时句柄是void*型。而对于define了STRICT的情况,可能采用强制类型转换或是相似的手段来使原先指向结构体的句柄指向一个32位的地址。注意到,原先句柄指向一个结构体,而这个结构体中只有一个int型数据,从内存的角度看,句柄其实指向了一段4字节的内存,而后来,句柄指向32位的地址,同样是指向一段4字节的内存。而如果我们去掉intunused,只保留一个空结构体,我们知道,空结构体占1个字节(对这一点有疑问的读者,可以写一个空结构体,用sizeof()函数实测一下),此时句柄指向1个字节的内存,而现在要让它指向4个字节的内存(32位地址),很可能会无法“转化”。然而,如果转化前后,句柄都指向4个字节的内存,那很可能就能够转化。所以,int unused的作用就是使句柄指向一个4字节的内存,以便将来句柄指向对象的地址时能够顺利“转化”。而从始至终,unused从来没有被显式地使用过,所以取名为unused。显然,这里unused的意思是“未被使用的”,而非“没用的”。

至此,所有关于windows句柄这一细节的内容都讲解完了。

写在后面:

1.在下知识浅薄、能力有限,讲解过程中难免有错误疏漏之处,这里恳请大家务必批评指正,在下先行谢过。

2.遗憾的是,到最后,还是有一些疑问没有解决。这里在下请求路过的大神不吝赐教,也诚望广大读者各抒己见,让我们一起思考,共同进步。

时间: 2024-10-08 00:51:23

源码剖析——深入Windows句柄本质的相关文章

【Java集合源码剖析】HashMap源码剖析

转载请注明出处:http://blog.csdn.net/ns_code/article/details/36034955 HashMap简介 HashMap是基于哈希表实现的,每一个元素是一个key-value对,其内部通过单链表解决冲突问题,容量不足(超过了阀值)时,同样会自动增长. HashMap是非线程安全的,只是用于单线程环境下,多线程环境下可以采用concurrent并发包下的concurrentHashMap. HashMap 实现了Serializable接口,因此它支持序列化,

HashMap(2) 源码剖析(推荐)

今天看代码,想到去年发生的HashMap发生的CPU使用率100%的事件,转载下当时看的三个比较不错的博客(非常推荐) 参考:http://coolshell.cn/articles/9606.html   http://github.thinkingbar.com/hashmap-analysis/ http://developer.51cto.com/art/201102/246431.htm 在 Java 集合类中,使用最多的容器类恐怕就是 HashMap 和 ArrayList 了,所以

DICOM医学图像处理:storescp.exe与storescu.exe源码剖析,学习C-STORE请求

背景: 上一篇专栏博文中针对PACS终端(或设备终端,如CT设备)与RIS系统之间worklist查询进行了介绍,并着重对比分析了DICOM3.0中各部分对DICOM网络通讯服务的定义.此次通过结合早些时间的博文DICOM医学图像处理:基于DCMTK工具包学习和分析worklist,对DCMTK开源库中提供的storescp.exe和storescu.exe工具的源码进行剖析,从底层深入了解C-STORE服务的触发及响应. 分析思路: storescp.exe和storescu.exe分别充当着

GDAL源码剖析(一)(转载)

GDAL源码剖析(一) GDAL 前言:一直在使用和研究GDAL的相关东西,发现网上对GDAL的内容倒是不少,但是很少有系统的介绍说明,以及内部的一些结构说明,基于这些原因,将本人的一些粗浅的理解放在此处,形成一个系列,暂时名为<GDAL源码剖析>(名称有点大言不惭,欢迎大家口水吐之,板砖拍之),供大家交流参考,有什么错误之处,望大家不吝指正,本系列对于GDAL的使用均是在Windows平台下,对于Linux平台下的不在此系列讨论范围之内.此外,转载本博客内容,请注明出处,强烈鄙视转载后不注明

Nodejs事件引擎libuv源码剖析之:高效线程池(threadpool)的实现

声明:本文为原创博文,转载请注明出处. Nodejs编程是全异步的,这就意味着我们不必每次都阻塞等待该次操作的结果,而事件完成(就绪)时会主动回调通知我们.在网络编程中,一般都是基于Reactor线程模型的变种,无论其怎么演化,其核心组件都包含了Reactor实例(提供事件注册.注销.通知功能).多路复用器(由操作系统提供,比如kqueue.select.epoll等).事件处理器(负责事件的处理)以及事件源(linux中这就是描述符)这四个组件.一般,会单独启动一个线程运行Reactor实例来

STL&quot;源码&quot;剖析-重点知识总结

STL是C++重要的组件之一,大学时看过<STL源码剖析>这本书,这几天复习了一下,总结出以下LZ认为比较重要的知识点,内容有点略多 :) 1.STL概述 STL提供六大组件,彼此可以组合套用: 容器(Containers):各种数据结构,如:vector.list.deque.set.map.用来存放数据.从实现的角度来看,STL容器是一种class template. 算法(algorithms):各种常用算法,如:sort.search.copy.erase.从实现的角度来看,STL算法

通读《STL源码剖析》之后的一点读书笔记

[QQ群: 189191838,对算法和C++感兴趣可以进来] 直接逼入正题. Standard Template Library简称STL.STL可分为容器(containers).迭代器(iterators).空间配置器(allocator).配接器(adaptors).算法(algorithms).仿函数(functors)六个部分. 迭代器和泛型编程的思想在这里几乎用到了极致.模板或者泛型编程其实就是算法实现时不指定具体类型,而由调用的时候指定类型,进行特化.在STL中,迭代器保证了ST

转:【Java集合源码剖析】HashMap源码剖析

转载请注明出处:http://blog.csdn.net/ns_code/article/details/36034955   您好,我正在参加CSDN博文大赛,如果您喜欢我的文章,希望您能帮我投一票,谢谢! 投票地址:http://vote.blog.csdn.net/Article/Details?articleid=35568011 HashMap简介 HashMap是基于哈希表实现的,每一个元素是一个key-value对,其内部通过单链表解决冲突问题,容量不足(超过了阀值)时,同样会自动

转:【Java集合源码剖析】Hashtable源码剖析

转载请注明出处:http://blog.csdn.net/ns_code/article/details/36191279 Hashtable简介 Hashtable同样是基于哈希表实现的,同样每个元素是一个key-value对,其内部也是通过单链表解决冲突问题,容量不足(超过了阀值)时,同样会自动增长. Hashtable也是JDK1.0引入的类,是线程安全的,能用于多线程环境中. Hashtable同样实现了Serializable接口,它支持序列化,实现了Cloneable接口,能被克隆.