|
|
| 第 17 行： |
第 17 行： |
| Windows 95（当时称为“Chicago”）也添加了此 API 调用，并引入了 DIB 引擎（在 1992 年的 Chicago 规范中首次详细介绍了与 DIB DC 相关的 API 调用，并早在 1992 年 7 月实施）。DIB 引擎旨在简化 Windows 95 显示驱动程序的开发，允许视频卡供应商简单地提供一个“微型驱动程序”，此驱动程序提供设置视频模式的代码并提供指向帧缓冲区的指针，而 DIB 引擎将处理其他所有事情。DIB 引擎针对打包像素 8/16/24/32 位帧缓冲排列进行了优化，因为这些帧缓冲与 Windows DIB 的格式相同（而许多以前的卡具有不寻常的帧缓冲排列，包括多平面图形）。 | | Windows 95（当时称为“Chicago”）也添加了此 API 调用，并引入了 DIB 引擎（在 1992 年的 Chicago 规范中首次详细介绍了与 DIB DC 相关的 API 调用，并早在 1992 年 7 月实施）。DIB 引擎旨在简化 Windows 95 显示驱动程序的开发，允许视频卡供应商简单地提供一个“微型驱动程序”，此驱动程序提供设置视频模式的代码并提供指向帧缓冲区的指针，而 DIB 引擎将处理其他所有事情。DIB 引擎针对打包像素 8/16/24/32 位帧缓冲排列进行了优化，因为这些帧缓冲与 Windows DIB 的格式相同（而许多以前的卡具有不寻常的帧缓冲排列，包括多平面图形）。 |
|
| |
|
| DIB 引擎允许 GDI 将整个屏幕视为一个大的GDI位图 —— 一个大的 DIB（并允许应用程序和 GDI 访问相同的位图），并且许多驱动程序（特别是那些用于倾斜 SVGA 适配器的驱动程序）使用 VFLATD 来实现此目的，但许多驱动程序也使用 DCI 或显示控制接口，这也是 VfW 技术浪潮的一部分。DCI 在 VFLATD 的基础上进行了扩展，允许支持多个屏幕外表面和大小超过 1MB 的帧缓冲区。DCI 主要为数字视频而设计，因此支持 YUV 等色彩空间以及视频解压缩和拉伸的加速。DCI 受到 Apple 法律诉讼的阻碍，Apple 声称 DCI 中使用的代码是由第三方公司为他们开发的，目的是为了加快 QuickTime for Windows 的视频性能，同一家公司后来与英特尔签订了合同。 | | DIB 引擎允许 GDI 将整个屏幕视为一个大的 GDI 位图 —— 一个大的 DIB（并允许应用程序和 GDI 访问相同的位图），并且许多驱动程序（特别是那些用于倾斜 SVGA 适配器的驱动程序）使用 VFLATD 来实现此目的，但许多驱动程序也使用 DCI 或显示控制接口，这也是 VfW 技术浪潮的一部分。DCI 在 VFLATD 的基础上进行了扩展，允许支持多个屏幕外表面和大小超过 1MB 的帧缓冲区。DCI 主要为数字视频而设计，因此支持 YUV 等色彩空间以及视频解压缩和拉伸的加速。DCI 受到 Apple 法律诉讼的阻碍，Apple 声称 DCI 中使用的代码是由第三方公司为他们开发的，目的是为了加快 QuickTime for Windows 的视频性能，同一家公司后来与英特尔签订了合同。 |
|
| |
|
| DCI was implemented with display drivers (including DVA.386 and DCISVGA.DRV) implementing a "DCI provider", which communicated with the DCI Manager (DCIMAN.DLL / DCIMAN32.DLL) client DLL via message passing. In most cases, DCI clients would be libraries such as WinG or Video for Windows, but applications could call into the DCI Manager directly to open the DCI provider and access the framebuffer. | | DCI 是通过显示驱动程序（包括 <code>DVA.386</code> 和 <code>DCISVGA.DRV</code>）实现的）实现“DCI 提供程序”，此提供程序通过消息传递与 DCI 管理器（<code>DCIMAN.DLL</code> / <code>DCIMAN32.DLL</code>）客户端 DLL 进行通信。在大多数情况下，DCI 客户端是 WinG 或 Video for Windows 等库，但应用程序可以直接调用 DCI 管理器以打开 DCI 提供程序并访问帧缓冲区。 |
|
| |
|
| '''WinG''' was a port of an early version of the Chicago DIB engine to Windows 3.1x, and most of its functions are parallels to GDI calls added in Windows 95 / NT 3.5. On Windows 3.1, a <code>WinGDC</code> is distinct from an <code>HDC</code>, as is a <code>WinGBitmap</code> from an <code>HBITMAP</code>, and <code>WinGBitBlt</code>/<code>WinGStretchBlt</code> vs <code>BitBlt</code>/<code>StretchBlt</code>, since WinG uses its own video path despite hooking into GDI through <code>WINGDIB.DRV</code>, but on NT 3.50 / 95, they're interchangeable. This places some limitations on what you can do with WinG on Windows 3.1; standard GDI <code>BitBlt</code> functions cannot blit between WinG DCs and GDI DCs, and the DIB engine (<code>WINGDE.DLL</code>) acts as a GDI driver to allow standard GDI operations onto WinGDCs. Meanwhile, one must use WinG to blit from a WinGDC (with a DIB selected onto it) to a GDI (display/screen) DC, as WinG will then obtain a pointer to the framebuffer of the GDI DC and draw onto it, or fall back to <code>StretchDIBits</code> if required.
| | WinG 是 Chicago DIB 引擎早期版本到 Windows 3.1x 的端口，它的大部分功能与 Windows 95 / NT 3.5 中添加的 GDI 调用相似。在 Windows 3.1 上，<code>WinGDC</code> 与 <code>HDC</code> 不同，<code>WinGBitmap</code> 与 <code>HBITMAP</code> 不同，<code>WinGBitBlt</code>/<code>WinGStretchBlt</code> 与 <code>BitBlt</code>/<code>StretchBlt</code> 也是如此，因为 WinG 使用自己的视频路径，尽管通过 <code>WINGDIB.DRV</code> 挂接到 GDI，但在 NT 3.50 / 95 上，它们是可以互换的。这对你可以在 Windows 3.1 上使用 WinG 执行的操作施加了一些限制；标准 GDI <code>BitBlt</code> 函数无法在 WinG DC 和 GDI DC 之间进行 blit，DIB 引擎（<code>WINGDE.DLL</code>）充当 GDI 驱动程序，以允许对 WinGDC 执行标准 GDI 操作。同时，必须使用 WinG 从 WinGDC（上面选择了 DIB）到 GDI（显示/屏幕）DC，因为 WinG 将获取指向 GDI DC 帧缓冲区的指针并绘制到它上面，或者在需要时回退到 <code>StretchDIBits</code>。 |
|
| |
|
| Many early Windows 95 games, such as '''WinDoom''' and '''Fury 3''', use WinG (often in conjunction with Win32s), but it was soon discontinued and replaced with DirectDraw. One well-known application using WinG acceleration is [[Microsoft Bob]].
| | 许多早期的 Windows 95 游戏（如 WinDoom 和 Fury 3）都使用 WinG（通常与 Win32s 结合使用），但很快就停止了使用，取而代之的是 DirectDraw。使用 WinG 加速的一个著名应用程序是 [[Microsoft Bob]]。 |
|
| |
|
| Microsoft did port DCI to 32-bit Windows, including Windows NT 3.51 (to a limited extent), and DCI 2.0 evolved into DirectDraw (DirectDraw in fact identifies itself as DCI 2.0, and the APIs with the concept of onscreen and offscreen primary surfaces is the same, with the DirectDraw design team starting from DCI), with the DCI API being subsumed into DirectX (which used a COM-based interface as opposed to a C-based API), with some structures, enumerations, error codes, and return values being shared. When a DirectDraw driver is unavailable on a Windows 9x operating system, it can fall back to use DCI if available via the Hardware Emulation Layer (and then it will fall back to the DIB engine as a last resort). Additionally, <code>OPENGL32.DLL</code> (the software OpenGL 1.1 renderer for Windows) used DCI to draw to the screen, as did the original version of GDI+, because the same redistributable DLL file had to be able to work not only on NT systems, but also on the 9x family, where very old drivers without DirectDraw support could be installed. On Windows 9x, DirectDraw will also use <code>DISPDIB.DLL</code> to draw fullscreen graphics in any VGA-compatible modes (i.e. 320x200x256 ''Mode 13h'' or 320x240x256 ''Mode X''). | | Microsoft 确实将 DCI 移植到 32 位 Windows，包括 Windows NT 3.51（在有限程度上），DCI 2.0 演变为 DirectDraw（DirectDraw 实际上将自己称为 DCI 2.0，具有屏幕内外主表面概念的 API 是相同的，DirectDraw 设计团队从 DCI 开始），DCI API 被归入 DirectX（它使用基于 COM 的接口，而不是基于 C 的 API）， 共享一些结构、枚举、错误代码和返回值。当 DirectDraw 驱动程序在 Windows 9x 操作系统上不可用时，如果通过硬件仿真层可用，它可以回退到使用DCI（然后它将回退到 DIB 引擎作为最后的手段）。此外，<code>OPENGL32.DLL</code>（适用于 Windows 的软件 OpenGL 1.1 渲染器）使用 DCI 绘制到屏幕上，就像 GDI+ 的原始版本一样，因为相同的可再发行 DLL 文件不仅必须能够在 NT 系统上工作，而且在 9x 系列中也必须能够工作，其中可以安装不支持 DirectDraw 的非常旧的驱动程序。在 Windows 9x 上，DirectDraw 还将使用 <code>DISPDIB.DLL</code> 在任何 VGA 兼容模式（即 320×200×256 ''模式 13h'' 或 320×240×256 ''模式 X''）下绘制全屏图形。 |
|
| |
|
| Starting with Windows NT 4.0, Microsoft began stripping out DCI support from the operating system, removing several DCI-related exports from <code>GDI32.DLL</code>, removing support for DCI from display drivers, and reimplementing the DCI Manager APIs on top of DirectDraw and GDI. The reason for this was simple; NT 4.0's video architecture had been redesigned, moving large parts of GDI and USER (and the new DirectDraw, which started work on NT shortly after NT 4.0's development began) into the kernel-mode module <code>WIN32K.SYS</code>, meaning that the NT 3.x display drivers that implemented DCI directly would be incompatible, so a clean break could be made to supplant DCI. Several DCI functions closely map to DirectDraw equivalents, such as <code>DCIBeginAccess</code> being implemented on top of <code>IDirectDrawSurface_Lock</code>, and <code>DCICreatePrimary</code> mapping to <code>IDirectDraw_CreateSurface</code>. DCI surfaces are implemented as a thin wrapper over DirectDraw surfaces, but the API is heavily stripped down, only supporting a single surface. Meanwhile, Windows 95/98/Me continued to have full native support for DCI as a peer to DirectDraw, since DCI display drivers were still supported. Vestigial DCI Manager support remains in modern versions of Windows NT despite the absence of the lower-level components. DirectDraw development began in 1994 (after the early WinG betas) for Windows 95 as the first serious effort to make graphics performance on Windows competitive with DOS, enabling games to shift over to Windows.
| | 从 Windows NT 4.0 开始，Microsoft 开始从操作系统中剥离 DCI 支持，从 <code>GDI32.DLL</code> 中删除了几个与 DCI 相关的导出，从显示驱动程序中删除了对 DCI 的支持，并在 DirectDraw 和 GDI 之上重新实现了 DCI 管理器 API。原因很简单；NT 4.0 的视频体系结构经过重新设计，将 GDI 和 USER（以及新的 DirectDraw，它在 NT 4.0 的开发开始后不久就开始在 NT 上工作）的大部分移动到内核模式模块 <code>WIN32K.SYS</code>，这意味着直接实现 DCI 的 NT 3.x 显示驱动程序将不兼容，因此可以彻底中断以取代 DCI。多个 DCI 函数紧密映射到 DirectDraw 等效项，例如在 <code>IDirectDrawSurface_Lock</code> 之上实现的 <code>DCIBeginAccess</code>，以及映射到 <code>IDirectDraw_CreateSurface</code> 的 <code>DCICreatePrimary</code>。DCI 图面作为 DirectDraw 图面的精简包装器实现，但 API 被严重剥离，仅支持单个图面。同时，Windows 95/98/Me 继续作为 DirectDraw 的对等体对 DCI 提供完全的本机支持，因为 DCI 显示驱动程序仍然受支持。尽管缺少较低级别的组件，但 Vestigial DCI Manager 支持仍保留在现代版本的 Windows NT 中。DirectDraw 开发始于 1994 年（在早期的 WinG 测试版之后），用于 Windows 95，作为使 Windows 上的图形性能与 DOS 相媲美的第一次认真努力，使游戏能够转移到 Windows。 |
|
| |
|
| Development on Video for Windows-related technologies and WinG as out-of-band updates to the operating system did not continue after Windows 95, at which point they were integrated into the OS as core components.
| | Windows 95 之后，Windows 相关技术和 WinG 作为操作系统的带外更新的视频开发没有继续，此时它们作为核心组件集成到操作系统中。 |
|
| |
|
| ==Components== | | ==Components== |