由于一个朋友在博客里留言, 才意识到我的MySpy软件已经x年没有更新了, 也谢谢这位朋友的支持, 让我重新从老硬盘里翻出这段代码, 很久以前(03年)是用BCB6花了一个星期完成的软件, 后来发布到网络上, 没有想到今天还有朋友喜欢, 再找出来的已经不能使用BCB6编译了, 不得已升级到BCB2010， 修改了一个在xp以上系统锁机会crash的bug, 重新发布.

没新功能, 只有一段回忆, 谢谢支持.

下载地址.

昨天实在太困, 而且今天要工作, 没有看完世界杯比赛, 今早起来第一件事就是看看比赛结果, 如果是2:1荷兰胜西班牙, 那么那个传说中的未来哥将会成为万众期待的救世主,可惜一切都是传说, 再次来到2012吧看到了未来哥的帖子,说是做梦梦到了荷兰西班牙会师决赛,于是便有了那个神奇的预言,当谜底解开的时候,遭到光大网友的一致讨伐,而我却仍坚信未来哥的说辞,一是这样的猜中的概率非常小,我大概算了了下,这个概率大概在1/100左右, 如果能同时预测到比赛结果和进球人物那这个概率就更低了;二是因为我也有做梦梦到将来发生的事情,当时没有感觉,真的发生的时候才想起原来以前做梦梦到过. 我无法解释这种现象的原因, 但我相信发生过类似事情的朋友一定很多, 只是未来哥做梦能记住内容并把他发到了网上.

今早拖着疲倦的身体去上班, 发现公司大门紧闭, oh my lady gaga, 忘记了公司为了鼓励大家看世界杯决赛, 决定今天放假半天.

由于市场部的大大需要Discuz!X的新功能, 用于建立玩家群和互动, 这几天忙着升级Discuz!X, 升级之前认为这是一个简单的工作, 但实施起来才发现痛苦万分, 最后不得已放弃了升级, 但最后的关键时刻还是完成了升级工作, 等日后Dx稳定了再考虑切换过来吧.

这里说说升级过程遇到的问题, 以帮助其他有同样需求的朋友, 原先Discuz安装的是7.0版, 数据库采用的latin1编码, 这是一个历史遗留问题, 由于开始直接采用package安装mysql, 这样默认是不支持gbk编码的, 所以论坛从一开始就是latin1编码, 当需要安装Dx的时候, 官方仅提供了gbk和utf8的包, 迫不得已手动重新编译mysql用于支持gbk编码,这样Dx附带的convert工具可以自动转换编码并升级数据库, 但这样转换仅仅针对论坛数据,却不包括用户(uc_server)数据, 于是我简单的认为只要修改uc_server的配置修改为latin1并使用原来的uc_server就可以ok, 事实也是如此, 大部分都是ok的, 包括中文用户的认证, 但还是有2个问题:

1) 站内通知都是乱码?

2) 如果刷新缓存会导致模板错误,直接花屏, 同时论坛会访问一些根本不存在的文件, 一度以为论坛被黑了?

这2个问题我都不知道原因, 因为本人对php不是很熟悉, 也没有时间仔细看代码, 就这样一直卡着无法继续, 但玩家却在期盼着论坛开服, 这样的压力可想而知, 最终暂时决定使用原版本先开服, 在内部继续解决问题.

这样接下来的问题是把latin1编码的数据库转换为gbk(包括uc_server部分),虽然我现在也还不认为上面的2个问题是由于编码导致的, 这步花了很多时间,按照google各种"完美latin1转gbk*******"文档的说明操作,都不能解决问题,或者是数据无法导入,或者是乱码, 就在今天联系了discuz的朋友, 寻求技术支持, 结果人家丢我tools.php 工具, 上面提供了数据库转码功能, 这样直接转换了数据库ok在升级Dx, 发现一切ok, 目前新论坛在内部测试.

长话短说, 使用win7 无线共享访问 xp系统文件, 可能会出现"登陆失败：未知的用户名或密码错误", 可以通过设置win7系统, 本地安全策略-本地策略-安全选项-网络安全：LAN管理器身份验证级别，默认是“没有定义”，更改为“发送LM和NTLM响应！

这样就可以解决了.

最近一直在思考游戏资源包的设计, 在以前<天下贰>项目的打包方案中最大的问题是每个版本生成的patch文件都必须顺次运用, 而且之前的版本是基于2进制数据比较,产生一个补丁包,这对于频繁修改的美术资源,描述这个2进制数据比较的补丁包,很有可能比直接替换一个文件,尺寸要更大,不如直接在文件粒度上修改数据,而不是2进制的数据比较补丁.

这次的新项目想尝试一种的新的包结构, 经过慎重思考,打算采用sqlite作为包文件载体,sqlite是一种小型的桌面数据库,从官方的介绍来看,也有很多公司采用sqlite作为文件格式使用,甚至使用在便携式设备内,可见其经济小巧的设计.

简单来讲,游戏数据打包,就是把各种文件放入一个大文件管理,这样做的目的主要是加快磁盘io和减少磁盘碎片,当然还有一个目的是加密文件格式,不至于dds,model文件直接暴露在文件夹里. 对于sqlite来讲, 因为其支持blob格式的字段, 所以很简单就是创建一个表,把所有的文件以blob字段的形式放入表中,为了便于检索,在创建主键,主键可以直接是文件名或者hash(文件名)得到的数字, 这个表的sql语句就是:

create table fat ( id integer primary key, content blob );

这样文件打包/patch更新就完全交给sqlite, 使用sql语句就可以搞定那些复杂的数据插入,修改,原子性和文件系统的线程安全性.

目前这部分已经集成到了引擎文件系统里, 实际的io效率还有待测试, 说实话还是有点担心其select的操作同完全手写的map.find(id)有多大差别,下次经过测试,再写篇评测报告.

关于这个问题, 在看object-c手册的时候大概已经知道答案了,只是没有想到object-c的解决方法真的是这样,和一般的脚本语言差不多,只是通过编译器实现了一层运行时系统.

我们知道, 在object-c里消息(成员函数)是运行期绑定的,编译器把类似

[receiver message]

的函数调用转换为,消息发送:

objc_msgSend( receiver, selector )

这里的selector就是在运行期绑定的成员函数, 可以想象selector是通过在继承体系中递归向上查找的,object-c仅仅在找到后做了一个cache,当消息具有多个参数时,也有如下转换:

objc_msgSend( receiver, selector, arg1, arg2, … )

为了便于在运行期决定selector, 每个objc类都维护了一个dispatch table, 通过名为isa的指针指向, 所有从NSObject继承的类都自动拥有isa指针. 下图是object-c里关于查找selector的过程:

为了效率考虑, 在编译后的代码中不使用函数字符串作为key来查找selector, 而是用过一个objc编译器保证唯一的标识符来做key查找,当然程序员可以使用字符串来查找, 例如:

id someSelector = NSSelectorFromString( msgName );

同时可以反向操作, 从一个selector返回其对应的函数名字:

NSString* methodName = NSStringFromSelector( someSelector );

基本上, 具备这个两个操作, objc就具有内省能力了.

chrome有一个修改user-agent的插件 US spoofer, 但手动添加手机浏览器 agent 后, 貌似无效, 访问163.com还是被认为是计算机浏览.

其实可以在chrome程序加入启动参数 --user-agent, 就伪装为认为你想伪装的浏览器,前提是你知道该浏览器的UA字符串, 如下,伪装为iphone safari

chrome.exe --user-agent="Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en) AppleWebKit/420+ (KHTML, like Gecko) Version/3.0 Mobile/1A537a Safari/419.3"

这样访问163.com就可以正常识别为手机浏览了.