由于 Windows 映像组件（WIC）编解码器将从 Windows shell 和照片库内调用，因此编解码器作者应尽一切努力确保其 WIC 编解码器中的高度可靠性和安全性。
编写可靠的代码在很大程度上取决于良好的编码做法、有效的代码评审以及全面的单元测试和方案测试。 此外，以下准则将有助于确保编解码器符合有关可靠性的 Windows Vista 策略。
启用 I/O 取消。
编解码器作者应为最终用户提供取消任何长时间运行的作的方法。 WIC 编解码器通过实现 IWICBitmapProgressNotification 来支持此功能。 这样，调用应用程序就可以为编解码器指定回调函数，以指定时间间隔调用，以通知调用方当前作的进度。 当应用程序从回调函数返回ERROR_CANCELLED时，编解码器必须取消正在进行的任何作，并将 HRESULT 传播回调用方。 这对于 RAW 编解码器尤其重要，因为解码全尺寸 RAW 映像可能需要几秒钟时间，应用程序需要一种方法来中止此处理。
确保代码在执行其函数所需的最小范围内运行。
编解码器作者必须确保编解码器不会消耗比必要资源多或具有比所需范围更大的资源。 WIC 中编解码器的范围是单个映像文件;加载映像文件时会创建编解码器，并在关闭映像时释放编解码器。 由于 WIC 是基于组件的可扩展平台，因此 WIC 编解码器将具有重叠的加载和卸载以及启动和停止（全部在同一进程中）。 如果编解码器的底层基础结构需要在大于单个映像的范围启动和停止作，可靠性将受到影响。 启用 WIC 的编解码器将由 Windows 资源管理器和其他应用程序使用。 因此，如果编解码器在进程的生存期内保持加载状态，内存将不会有效释放，编解码器的失败可能会挂起 Windows 资源管理器，并可能要求重启计算机。 （请考虑每次在 Windows 资源管理器中首次为图像缩略图时调用编解码器：这是一项轻型作至关重要。
使用静态和动态代码分析工具。
静态分析工具：
PREfix - 用于在编译时检测错误。
PREfast - 用于分析 bug 的代码。
动态分析工具：
AppVerifier - 它通过模拟常见的实际软件问题帮助应用程序更具弹性。
验证代码评审中的所有输入。
导出的方法和所有文件数据的所有参数必须仔细验证是否有效，并在有故障时可靠拒绝，以防止缓冲区溢出和不足、算术溢出和下溢以及意外类型。
使用文件模糊技术发现潜在的崩溃和挂起。
文件模糊是使用随机伪装输入测试编解码器的过程。
文件模糊有两种形式：无目录（随机）模糊和定向模糊。 无目录模糊执行一些随机位翻转，以查看随机输入是否会导致编解码器崩溃。 定向模糊化根据文件格式的一些知识来改变输入。 例如，如果字节偏移量为 32 的周期冗余检查 （CRC），则更改任何字节而不更新 CRC 可能会不执行大多数代码路径。 在此示例中，当修改任何字节时，定向模糊器应修复 CRC。
应创建用于文件模糊处理的映像的输入集，以便对解码器支持的每个参数组合进行测试。 例如，如果解码器支持 little-and big-endian 文件和三个压缩设置，则图像的输入集应包含每个压缩设置的 little-endian 文件以及每个压缩设置的 big-endian 文件。 此方法将生成要测试的大量但非常可靠的输入图像集。 即使没有相机生成每个组合，但解码器支持这些理论组合，编解码器作者也应该模糊这些输入。
通过在编解码器开发期间定期对图像文件执行模糊测试，可以极大地增强安全性。 编解码器应始终能够检测图像文件损坏，并在格式不正确的请求或格式不正确的数据的情况下正常失败。
强调代码。
通过持续在多个同时进程中运行编解码器，对每个受支持相机的不同大小（包括非常大的图像）执行所有可能序列中支持的作，从而对编解码器进行压力测试。
线程安全性。
从 Windows 7 开始，WIC 要求原始编解码器为 COM 单元类型“Both”。 这意味着必须在多线程方案中执行适当的锁定来处理跨单元调用方和呼叫者。 多线程单元（MTA）中的对象可由 MTA 中的任意数量的线程同时调用，从而在多核系统和某些服务器方案中提供更好的性能。 此外，位于 MTA 中的 WIC 编解码器可以调用位于 MTA 中的其他对象，而不会对位于不同 STA 单元中的线程之间的调用相关的封送成本。 在 Windows 7 中，所有现成 WIC 编解码器都已更新，以支持 MDA，包括 JPEG、TIFF、PNG、GIF、ICO 和 BMP。 不支持 MTA 的第三方编解码器将导致多线程应用程序中由于封送而产生显著的性能成本。 启用 MTA 支持需要在第三方 CODEC 中实现适当的同步。 这些同步技术的确切实现超出了本文的范围。 下面提供了用于同步 COM 对象的常规参考。
相关主题