主题: ezgdi测试版 (2010/10/10 更新r87和今后的发展公告) 查看单个帖子
dipplum 帅哥
极客II
级别:3 | 在线时长:99小时 | 升级还需:1小时级别:3 | 在线时长:99小时 | 升级还需:1小时级别:3 | 在线时长:99小时 | 升级还需:1小时
注册日期: 2008-09
帖子: 72
致谢: 17
2010/10/10说在前面的话

毕业后把开发用机器上交实验室就没了开发环境, 近半年多没有更新ezgdi. 即使ezgdi仍然有许多没有解决的问题, 还是有很多用户关注ezgdi. 因此感觉很有必要说明一下ezgdi目前的现状, 和我对ezgdi未来的想法.

首先, ezgdi目前还是有很多尚未解决的严重问题, 如假死, 蓝屏. 在这些严重问题解决之前, 很想像任何小功能的更新可以为用户带来实际的好处. 而遗憾的是, ezgdi仅仅是gdi++的一个很小的改进, 只是将一个底层库detours换到了easyhook, 相关代码仅有100多行, 而这方面的改进, 我很难以想象会引起假死和蓝屏这样严重的错误. 所以ezgdi假死和蓝屏的问题, 有更大的可能是源自于原先gdi++的bug, 只不过在换到easyhook之后, bug发作的后果变得更加严重了而已.

如果ezgdi这种严重的bug是我的修改引进的, 那还好办, 我了不起把我修改过的几百行代码重头到尾看10遍, 总归能找到一点蛛丝马迹. 如果是gdi++遗留的bug, 那可能就不是一朝一夕可以解决的. 一个例子就是gdi++有一个诡异的bug: 经常是单个字母或者数字, 如9, 不能渲染, 这个bug一直到今年2月份我才改正.

至于ezgdi蓝屏和死机的原因, 我目前是一点头绪都没有. 主要是我用的机器基本上没有出现蓝屏的情况, 但我的确在别人的机器上见过这个现象, 所以无法复现. 什么时候能解决, 更是无法保证. 很遗憾, 目前来讲, 我的建议是, 如果你的机器有这个症状, 那只好尽量换到其他的平台, 如MacType, 和gdipp, 这两个项目的维护者FlyingSnow和CrendKing对字体渲染和gdi++的理解, 都比我要深, 花的时间也比我多的多. 虽然与ezgdi相比, MacType不支持64位, 而gdipp虽然支持64位和32位渲染, 但与gdi++之间的差异还比较大, ezgdi本应成为用户在两者之间有效的补充, 但很遗憾ezgdi自身稳定性拖了后腿, 也因为我的个人时间有限, 不能及时的改进.

不过, 我个人还是有意愿在这方面继续研究改进下去的. 尤其是在Windows平台上, 截获系统调用的方法渲染字体的适用范围正在逐步的缩小, IE9, Office 2010, Visual Studio 2010等一系列软件, 都有这样或者那样的部分无法通过截获系统调用的方法解决.

我最近正好有一点业余时间, 我会考虑持久的花在这方面, 一步一个脚印走下去. 但结果和时间不好保证, 有可能是进一步改进ezgdi, 有可能是改进gdipp和MacType, 甚至是新的尝试.

对于目前的ezgdi来说, 还是在alpha测试状态, 在严重错误进一步修正之前, 我不建议用在生产系统中. 虽然, 我这这段时间内只要有进展, 还是会持续的更新ezgdi, 我也会一直在我的系统中打开ezgdi的渲染效果.

ezgdi测试版下载

4. 2010-10-10更新 ezgdi r87():修正部分软件下hook失效的错误, 增加Windows Server 2008下激活使用的注册表文件win2008-enable.reg
1. 2010-02-15更新 ezgdi测试第2版():修复explorer.exe右键崩溃
(第三版之后可能包含严重的内存泄漏bug,导致机器蓝屏,使用请小心,目前尚未解决)
2. 2010-02-18更新 ezgdi测试第3版:实现FontLoader=0模式下的字体链接机制(感谢FlyingSnow的热心指点)
3. 2010-02-23更新 ezgdi r82:修正Symbol字体在Shadow模式下的黑影;修正9,&,<等符号在Firefox不能渲染的问题;修改版本号叫法。
3. 2010-02-24更新 ezgdi r83():修改FontLink处理机制;修正dwn.exe不能渲染的问题;修正两个很愚蠢的bug。


为了和Windows默认行为一致,现在ezgdi不再读取MS Shell Dlg这个字体的FontLink并添加到每个字体的FontLink之后,而是读取Tahoma的FontLink键值的第一条(一般是SimSun)并把该字体(SimSun)默认链接到每个字体。

ezgdi说明

ezgdi我发起的将gdi++ freetype版从detours移植到easyhook的分支项目,目前已经基本可以同时支持Windows下64位程序和32位程序的渲染,可以小范围内部测试了。

ezgdi简介

把gdi++从detours移植到easyhook的原因在于,gdi++依赖于detours提供对Windows GDI32绘图函数的截获功能,实现对Windows文字的重新绘制,但detours库的64位版本不是免费的,阻碍了gdi++对64位Windows的程序的文字渲染。easyhook是可以替代detours的开源软件,并且可以支持64位程序。

ezgdi的代码基于gdi++ freetype 0850版公开的代码进行修改。ezgdi对gdi++代码的的修改非常有限,目前仅对移植到easyhook所必备的代码进行修正,尽量不影响gdi++现有的功能(修改的代码量大概在几百行左右)。因此,ezgdi的32位的dll,与gdi++0850版dll的功能应该是基本相同的,支持相同的配置文件格式、配置参数,当然也可能具有相同的bug。

ezgdi的64位dll,除了修正一些compile time error之外(主要是gdi用的一些32位内嵌汇编在64位下不能编译了),没有修改其他代码。这说明gdi++的原始代码已经比较64bit friendly,移植过程没有做非常大的调整。

目前ezgdi的代码放在GoogleCode上,有兴趣的童鞋可以去下载。

ezgdi的替代品

ezgdi并不是唯一的支持64位字体替换的程序,CrendKing同学开发的gdipp项目目前也已经支持64位程序的渲染,并且支持以系统服务的方式渲染桌面程序,没有修改注册表带来的危险,大家也不妨去试用下gdimm_64.dlll的渲染效果,,


ezgdi的稳定性

在我开发用机——Windows 7 x64上,基本上可以正确没有bug的渲染我手边大部分32位程序,同时可以正确渲染我手边有限的几个64位程序,包括Win7 x64的Desktop/Explorer/Notepad/IE 8。目前已经在我的机器上基本稳定运行了14天:),期间间或会有让程序退出的错误。

不过在有些机器会有引起explorer crash的情况,此bug目前应该已解决。还可能会导致机器蓝屏,鼠标键盘无响应等问题,该bug目前尚未解决。

ezgdi的当前问题

ezgdi已知问题如下,感谢wheatone,riverZ,oveage,Rerven, 2000320, currychan, 火烈鸟, 尤其是POKeDOLL的辛苦测试:

1. (测试第1版已修正)英文Win7 x64下IE8 x64打开的时候可能会crash,crash后出现的窗口很烦人,但我这里就出现一次,关掉以后一切正常,重启也没错
2. (测试第2版已修正)Win7 x64下explorer一些操作会crash,特别是在文件上右键会crash
3. (测试第3版已修正)fontloader=0时,系统的FontLink不起作用
4. (测试第3版已修正)QQ2010Beta退出时报错
5. (测试第3版已修正)符号与其他字体混合显示
5. 有时候,Win7开始菜单的快捷输入框、浏览器的搜索框只能看到一半文字,但日期时间显示正常了
6. fontloader=0时,右下角任务栏日期时间显示中文乱码
7. 窗口标题栏不能渲染/渲染效果不好
8. Windows Server 2008 R2没有渲染效果

ezgdi报告严重bug的方法

ezgdi导致程序莫名的崩溃的错误是最严重的错误,也是最难调试和定位的错误。目前Windows7和Windows Vista SP2支持用户程序的minidump功能,可以自动将crash程序的运行信息保存成文件,开发人员利用这个minidump文件迅速定位crash发生的位置,便于推测crash发生的原因。

如果使用ezgdi导致了程序的崩溃,如果有可能,遇到该bug的同学帮忙用下面的方法生成dump文件,上传或者发给我(quinn.liqin @ gmail.com)便于调试:

1. start -> run -> services.msc,然后启动Windows Error Reporting Service(Windows错误汇报服务)
2. 导入wer.reg(中)到注册表,会激活user-mode,也就是用户应用程序的minidump的功能
3. 到%LOCALAPPDATA%\LocalDumps (C:\Users\your_account\AppData\Local\CrashDumps)目录下找最新的dmp文件
4. 把dmp文件发给我,我可以用windbg和visual studio调试这个minidump文件。

ezgdi的下一步计划

1. 改进显示效果:上述部分显示效果问题很多都是gdi++的老问题了,很多在FlyingSnow提供的版本中已经解决了,我正在研究FlyingSnow发来的部分代码,希望下一步能够逐渐port到ezgdi。
2. 实现gditray的替代品:由于从detours换到了easyhook,原来的gritray对ezgdi已经不管用了,需要开发替代gditray的程序,或者扩展gditray的现有功能支持将ezgdi注入64位程序。
3. 重构gdi++的部分功能:希望可以在不影响稳定性的前提下,尽量优化gdi++的代码,便于以后的维护。

声望评价
  
  不给汝威望过意不去
  
  等这个等了很久了,加油!!
上传的图像
文件类型: png ezgdi-2010-02-11.png (558.2 KB, 1406 次查看)
此帖于 2010-10-10 15:50:05 被 dipplum 编辑.
回复时引用此帖