Enterprise Just Builder

Solution for Enterprise Software Architecture

API

将 Win32 枚举型 APIs 转换为 STL 迭代器

原文1

操作系统都有许多 API 用于存取实体集合的,比方说 Unix 的 opendir()/readdir() 函数。Win32 API 也提供了许多函数用来枚举集合内的元素,通常采用的模型无外乎下面几种:回调函数 (如 EnumChildWindows), get-first/get-next (取第一个/取下一个 比如FindFirst/NextFile), 或 get-nth (取第n个 如 RegEnumValue) — 其语义和前二者完全不同。

现在 C++ 社区正在逐步朝着符合 STL 的通用编码格式迈进,如使用容器 (序列和关联)、迭代器、泛函 (或函子或函数对象)、算法和适配器等等。这一做法的最大好处是可以采用一种通用的方法操纵不同的实体, 大大减少开发者的工作量, 同时提高健壮性、可维护性和重用。

STL 技术未被广泛运用的原因之一是除了标准库所提供的类和函数 (list, vector, for_each 等) 之外, 缺少可用的 STL 兼容库, 特别对于操作系统 API。原因之一是这涉及编程模型之间迁移转换的复杂性, 特别是对于集合和序列。本文通过将两种 Win32 枚举模型实际转换 STL 序列, 创建封装了 Win32 API 的轻量级序列类, 并提供了可按 STL 标准算法来操纵枚举实体的迭代器。

本文所演示的类是 WinSTL 库的一部分,WinSTL 则是 STLSoft 的子项目。STLSoft 是个开源组织,一直致力于将 STL 概念运用到多种技术和操作系统中去。

>>> 阅读全文

 

, , , ,

为 Windows NT 内核扩展 API

与 Unix 基于中断的系统调用接口类似, Windows NT 提供了大量未经文档化的基础系统服务,即原生 API (Native API)。这些内核模式的系统服务被 Win32、 Posix 和 OS2 等环境子系统用于在 NT 微内核(Windows NT 是个修改过的微内核体系结构的操作系统)之上实现其运行环境。在 Win32 下,原生 API 通过 NTDLL.DLL 的导出函数提供给其他 API 和程序使用,如 KERNEL32.DLL 中的许多函数只是简单地重定向到 NTDLL.DLL 中。

事实上 NTDLL.DLL 那些调用系统服务的函数不过是个存根函数,它们只是对 SysEnter/SysCall(早些版本使用 INT 2EH)1等系统调用接口的简单包装。以 NtCreateFile 函数为例:(Windows 7 SP1 64位):2 ,它的具体实现如下:

mov     r10,rcx ;保存 rcx 的值,rcx 将被置为 rip(返回值)
mov     eax,52h ;系统调用号
syscall
ret
nop     dword ptr [rax+rax]

存根函数负责在 EAX 中填入系统调用号,随后执行本机调用接口实现从用户态向内核态的跳转。EAX 中的调用号将用以查找并调用系统服务以完成 API 的最终功能。每个原生 API 的调用号各不同,例子中 NTCreateFile 的调用号是 0x52h,且随着 Windows 的版本和架构不尽相同,有兴趣的话可以查询 Windows X86 系统调用表Windows X86-64 系统调用表

执行 SYSCALL 或 SYSENTER 时,CPU 并不会象执行 CALL一样保存返回地址和状态信息,所以需要存根函数来保存返回信息。3

当从原生 API 进入内核态以后,后续则交由 NCI 派发器 (NCI Dispatcher)处理。 NCI 派发器在微内核中(NTOSKRNL.EXE) 实现的, NCI 派发器( _KiSystemService ) 本质上就是 INT 2EH 的处理函数(handler)。NCI 派发器通过系统服务描述符表 (System Service Descriptor Table — SSDT) 来查找并调用某个服务的相应处理函数,函数参数则通过 NCI 传递。(一些内核调试器比如 IMHO 或者 NuMega Soft-ICE 可以通过 NTCALL 命令来显示 SSDT)。 微软并未提供文档来说明如何扩展原生 API,并通过 NCI 来调用自己的内核服务。所以本文试图通过变通的办法来解决这一问题。不过在此之前,我们还是大致看一下来如何通过 NCI 来调用原生 API 服务,或者其他 NCI 服务。

>>> 阅读全文

 

, , , ,

Windows事件追踪入门与使用方法

文章评价:
大多数 Windows 开发者或多或少都知道 Windows 事件追踪(Event Tracing for Windows,ETW),ETW 是由 Windows 操作系统提供的一种通用的,系统开销较低(与性能日志和警报相比)的事件追踪手段,用以监控具有负载的系统的性能, 它在内核中运行,可以追踪用户模式应用程序、操作系统内核和内核模式设备驱动引发的事件。此外,ETW 还能够动态地启用或者禁用日志记录,便于进行详细的追踪,而无需重新启动操作系统或者应用程序。
一些操作系统核心组件和第三方应用程序使用 Windows 事件追踪来提供事件日志记录和追踪。

ETW 是随着 Windows 2000 中第一次出现在其发布版本中的,对于后续的 Windows 来说, ETW 已经是内置工具。

ETW的架构
ETW 主要包含四种类型的组件,其核心体系架构如图1-1 所示:

  • 事件提供程序
  • 控制器
  • 使用者
  • 事件跟踪会话

事件跟踪会话(Session) 负责缓存和日志记录,会话接受事件并创建一个跟踪文件。ETW 会话可以使用多种日志记录模式。例如,可以对会话进行配置,直接向使用者应用程序传送事件,或在文件达到特定大小时通过回绕在某个文件中重写旧事件。为每个会话创建的单独写线程会将这些事件刷新到文件或实时使用者应用程序中。如果要实现高性能,还可以使用每服务器的缓冲区,这样无需在日志记录路径中设置锁定。

事件提供程序 (Provider)指的是一种可以将事件写入 ETW 会话的逻辑实体。任何可记录的重要活动均可作为事件,每个活动由记录到 ETW 中的一个事件表示。事件提供程序可以是用户模式应用程序、托管应用程序、驱动程序或任何其他软件实体。唯一的要求是,事件提供程序必须通过注册 API 向 ETW 注册一个提供程序 ID。提供程序首先向 ETW 注册,然后调用 ETW 日志记录 API 如EventWriteEx, EventWriteString 或者 EventWriteTransfer 写入来自代码内多个点的事件。

>>> 阅读全文

 

, , ,

编写 ScanX – 注册表清理工具

简介
理论上注册表只是一种树状数据库,用来存储操作系统和安装的组件的各种信息。最初,它的设计目的是只存储 COM 组件配置信息,后来为了减少.ini 文件的依赖,注册表逐渐成为外围应用程序存储的一种媒介,然后现在…似乎我们正朝着另一个方向,回到模块化的设计原则,将应用程序数据存储在该应用程序的程序集中。但是,无论如何,注册表在以后一段时间内仍将扮演 windows 操作系统中的核心要素。

那么注册表清理具体是做什么的?我真的需要自己写一个吗?注册表清理主要是做的事是路径测试,包括文件系统中的路径和注册表中的元素之间的联系。我所以会注意到这个,是因为这几年前,我碰巧需要清理注册表…朋友的电脑遇到了一个特别讨厌的病毒,这个病毒禁用了防病毒软件,并把自己提升到了系统级别的访问权限。我设法将其删除,但删除其组件后,网络就不再工作。该病毒已将自身插入网络堆栈,由于不知道这些注册表项是什么或是在哪,我需要一个注册表清洁器来帮助修复它。我用的那个清洁器马上就正确完成这个任务了(由于未购买这个工具,我不得不手动删除这些注册表项 …但也进而导致我写此应用程序的第一个版本)。它是从那时我开始研究匹配项并试图找出这些应用程序是如何工作,并开始了解各种不同的注册表项之间的复杂关系。

我打算用长篇累牍来介绍注册表的工作原理,网上有很多教程,维基百科的介绍就不错。我要做的是给你鸟瞰此应用程序是如何工作的,如果您要深入了解此应用程序,你需要进行认真的调试,并阅读每个类的注释…

通过 API 访问注册表
本应用程序的核心是注册表类 cLightning,我很多年前用 VB6 写的,并将其翻译到 C# 。通过该类,你可以访问到 advapi.dll 中的大多数数据类型和注册表 api。此外还有一大批像 RunAs、 ShellOpen、 Rot13、 和访问 escalation routines 的有用方法。

枚举数以十万计的注册表项需有 ‘极品飞车’ 的速度,因此内建的注册表方法是解决问题的最佳途径,(使用 PInvoke 获得了至少两倍的速度优势)。对于每种数据类型都有其独立的方法:

>>> 阅读全文

 

, , ,

基于Azure开发和发布PHP应用

云计算是当今IT世界的头等大事。云计算(Cloud Computing)是网格计算、分布式计算、并行计算、网络存储、虚拟化、负载均衡等传统计算机技术和网络技术发展融合的产物。提供资源的网络被称为“云”。

“云”中的资源在使用者看来是可以无限扩展的,并且可以随时获取,按需使用,随时扩展,按使用付费。

简单的说云计算简化了企业 IT 的基础架构且给企业提供了更大的可配置性和灵活性。在原有模式下如果构建一个小型的应用,你需要租用服务器、需要考虑租用服务器的安全和稳定因素等。如果构建一个中大型的应用,我们需要花巨资购买硬件来集群,然后花巨额资金购买所需的系统软件并且聘用一些人员来维护系统。

现在云平台能提供我们程序所需的硬件设备和软件设备,用户所要做的只是根据自己的需要租用这些已有的资源,上传应用程序并修改配置文件,就可以灵活扩展或收缩所占用的资源,以达到合理利用资源的目的,同时也减少了维护这些软硬件的成本。

在这篇文章中,我们将关注云平台之一 — 微软的 Windows Azure,并演示如何在此平台上部署 PHP 应用,虽然我们不打算深入去了解云技术的方方面面,但是我会尽量提供相关的信息和资源,为你今后的学习打下基础。

>>> 阅读全文

 

, , , , , , , , ,