最传统、也是应用最广泛的配置方法就是INI控制，下面是一个实际的例子：

    对象控制
    [object]
    Memory=Yes;是否检测内存
    Sectors=Yes;是否检测引导扇区
    Files=Yes;是否检测文件系统
    Packed=Yes;是否脱壳
    Archives=Yes;是否检测包裹
    MailBases=Yes;是否检测邮件文件
    MailPlain=Yes;是否检测编码文件
    FileMask=2;扩展名检测范围
    UserMask=;用户定制扩展名
    Exclude=No;是否不检测定制的扩展名
    ExcludeMask=;不检测扩展名的定义

    行为控制
    [Actions]
    InfectedAction=0;是否清除病毒
    InfectedCopy=No;是否备份病毒
    InfectedFolder=Infected;备份目录
    SuspiciousCopy=No;是否备份可疑文件
    SuspiciousFolder=Suspicious;备份目录
    Report=Yes;是否生成日志
    ReportFileName=Report.txt;日志文件名

    效力控制
    [Options]
    Warnings=Yes；近似警告开关
    CodeAnalyzer=Yes；代码分析开关
    RedundantScan=Yes；多重扫描开关

    对于传统的反病毒工具工作环境，这样的控制粒度是足够的，但对于更复杂的环境，已经显现了问题。

    下面我将举例说明——

    应用案例一  同一个引擎，作为单机反病毒软件使用和邮件服务器反病毒模块的要求显然是不同的。

    I-Worm.Nimda.e是一个感染式的蠕虫，在Local处理的时候，应该作为一个PE感染式文件处理，但对邮件服务器，则可以抛弃。

    Win95.CIH是一个感染式病毒，当检测到这个病毒，无论对于Local还是邮件服务器，则都需要进行感染式病毒的清除操作，还原出原有文件。

    这样区别的性质在于，Win95.CIH没有mail发送自身的特性，如果出现在网上，应该是用户主要发送的可执行程序。而Nimda则反之。这种处理粒度的要求，已经对不同类别的病毒在不同环境下进行不同处理，超出了传统引擎控制粒度的能力。

    应用案例二    如果一台网络病毒检测设备，有若干响应模块：

•     消息告知
•     追加式邮件告知
•     反馈式邮件告知
•     断连接
•     …

    这些响应模块必然要工作与某种策略之下，才能达到比较好的效果。

    比如一些邮件蠕虫发件人是随机的，采用反馈式发送不仅毫无意义，反而制造了大量流量，而一些邮件蠕虫的收件人是bot生成的，即使在SMTP中检测到，那么追加式发送的结果也是会造成大量无意义的流量消耗。客观来说，确实有时我们收到莫名其妙的来信，说我们对外发出了病毒。或者收到了病毒。

    理性的用户会要求如表一的控制粒度。 

表一：邮件蠕虫通知模块控制开关表

    从这些案例可以看出，工作于复杂环境之下的反病毒引擎，对控制与细粒度处理的能力都超出了传统。