问题：
====

Rav2011 文件和（或）木马监控特性存 Bug 致病毒误报及文件丢失。

例子文件是之前反馈的 《注意：Rav2011对已通过Rav2010检查的老文件报木马病毒》（http://bbs.ikaka.com/showtopic-8958495.aspx）。在贵公司修订了病毒库后启动该文件或用 Rav2011 扫描已不再报病毒。

但运行该例子程序执行其软件功能却又被 Rav2011 报木马病毒（后附截图），在示警对话框里不论执行 “阻止” 或 “允许” 操作，都导致目标文件丢失（回收站及病毒隔离区内均未发现目标文件）。

建议贵公司有关工程师工作能细致些，已确定不是病毒的文件应确保用户能不受 “打扰” 地运行或使用，以免用户本职工作受贵公司产品影响不能如常开展。

请当值工程师及时跟进解决。

值得一提的是，这些天为内部升级做准备而几次测试 Rav2011，发现 Rav2011 拖累机器性能的问题颇为突出！为此我们大致浏览了 Rav2011 部分模块的二进制代码，发现 Rav2011 不少代码亟待优化，甚至相当一部分二进制代码并无积极意义但对消耗处理器时间倒是令人印象深刻；而且 Rav2011 既定电脑防护策略的优化仍需进一步着力，如 RavMonD.exe 在文件解压缩完成时会 “过滤” 目标文件一次，用户将该目标文件送回收站的操作，又会触发 RavMonD.exe 对该目标文件再 “过滤” 一次。RavMonD.exe 为此消耗双倍的处理器时间，遇上目标文件是个大文件时，处理器浪费惊人！说 RavMonD.exe 目前是苦劳远大于功劳并不过分。事实上被 RavMonD.exe 第一次处理过的文件，只要其未被更改过（文件散列值未变）同一时段内就无须再行处理，计算一个大文件的散列值显然耗时要远低于扫描整个大文件，累积起来即可向操作系统归还相当可观的处理器时间，用户就不会对 Rav/RIS2011 拖累机器性能有明显感觉。

建议 Rising 公司不要过于迷信开发工具的编译器，对那些高频调用的产品模块还是应考虑使用低级语言如组合语言（汇编语言）进行开发。Rising 产品目前主要运行环境是视窗系统，所以使用组合语言开发关键模块不太会出现移植问题，产品性能却可获大幅提高。

同时建议 Rising 在内部测试环境里加大低配置机器的测试权重，将低配置机器上运行 Rav/RIS201x 的性能评测结果作为后续版本主要的性能改进指标。如果贵公司产品性能在低配置机器上都能有不俗表现，估计能体会到贵公司产品 “飞” 一样感觉的将是大部分用户，不限于那些拥有高配置机器的一部分用户。