Windows 9X and 2K (OS support library: wgl)
Sections
Getting the Current Screen Mode
Handling Alt Tab (Task Swapping)
DirectPlay, DirectInput, DirectSound, DirectSetup
DirectShow / ActiveMovie / DirectMPEG / Quartz
Accelerators for Windows 95 / 98
ATI: Rage Pro, Rage 128, Rage Fury MAXX.
Intel: Intel 740, Intel 752, Intel 810.
Matrox: G200, G400.
3dfx: Voodoo 1, Voodoo 2, Voodoo Rush, Banshee, Voodoo 3 (including Voodoo 3 3500TV).
NVidia: Riva 128 / 128ZX, Riva TNT / TNT 2 / TNT Ultra, GeForce 256.
S3: Savage 3, Savage 4, Savage 2000.
3DLabs: Permedia 2, Permedia 3, Oxygen.
Rendition: V2100, V2200.
SiS: 6326
(Note that as of 2nd December 1999 the current driver for the SiS 6326 exports a version string of 1.0. It does, however, appear to be a 1.1 implementation. Note also that the hardware on this card isn't very fast.)
The Videologic Neon 250 (Series 2) board has an OpenGL mini driver only. The Series 3 cards are supposed to have a full OpenGL 1.1 driver when they're released.
The board names given above are for reference boards designed by IHVs, which are then often manufactured and sold by OEMs under a variety of other names. OEMs often modify the drivers, but unfortunately rarely improve them I strongly suggest that if you are developing on 9X you use Chris Hecker's GLSetup to install the appropriate IHV reference drivers. GLSetup will auto-detect your card type, and is free to distribute on games CDs so that you can ensure that end users have the same drivers installed.
Core OpenGL functionality (which enables full drivers other than standalone ones - see below - and provides the default software renderer to be used if a mode selected by the application cannot be accelerated) is available on Windows NT / 2K from NT v 3.51 (inclusive) and on 9X from Win95 OSR2 (inclusive). The required dlls are opengl32.dll and glu32.dll (for glu support). See External Links for details of how to add core OpenGL support to Windows 95 release 1.
Windows full (not mini) drivers can be ICDs (installable client drivers, for which any part of the generic Microsoft provided pipeline may be replaced by the driver), MCDs (mini client drivers, for which only part of the pipeline can be replaced by the driver, which are only supported on NT, and which are generally faster for IHVs to write but slower running than ICDs) or "standalone" drivers. "Standalone" drivers exist for the 3dfx Voodoo 1, 2 and Rush only. The issue here is that the ICD mechanism cannot support 3d only hardware, and wgl (the Windows specific OpenGL interface library) cannot support multiple 3d cards present in the same machine (as is possible with Voodoo 1 and 2 boards).
Assuming that a hardware accelerated non standalone driver is present, the choice of accelerated rendering (via an ICD or MCD) or default software rendering will only be made after the Win32 window's pixelformat has been set and a context created, since it is only at that point that the system can determine whether the requested mode can be accelerated. For example, on a Voodoo Banshee ICD (for which the hardware can only accelerate 16 bit modes) any request for a 32 bit colour mode will cause a default to the Microsoft software renderer.
An MCD will set the PFD_GENERIC_FORMAT and PFD_GENERIC_ACCELERATED flags in a PIXELFORMATDESCRIPTOR returned by DescribePixelFormat. A full software implementation (which might be invoked if no hardware acceleration is present, or the pixel format requested cannot be accelerated at all) should set PFD_GENERIC_FORMAT only. An ICD should set neither flag.
Here is some sample code showing how to enumerate all the available pixel formats yourself rather than use the ChoosePixelFormat / wglChoosePixelFormat (see below) functions.
Note that not only can the pixel format of a window only be successfully set to a format which matches the colour depth of the current desktop, but the identification of formats as accelerated or not depends on the current desktop colour depth. Thus, on a Riva TNT calling DescribePixelFormat for a format with 32 bits of colour, 24 bits of z and 1 bit of stencil will return a PIXELFORMATDESCRIPTOR which describes it as unaccelerated if the current desktop colour depth is 16 bit, but accelerated via an ICD if the desktop is in a 32 bit colour mode.
The standalone driver for Voodoo 1, 2 and Rush (3dfxvgl.dll) will not accelerate applications linked to the normal Microsoft opengl library (opengl32.lib) or the SGI library (opengl.lib; see below). In order to use the 3dfxvgl library you can statically link to a library made from the standalone driver, for whicb see Downloads, and have two executables (one to run on the 3dfx standalone driver and one to run on cards accelerated via the Microsoft implementation, linked to opengl32.lib). Alternatively, you can dynamically load either the Microsoft opengl32.dll or 3dfxvgl.dll using LoadLibrary, depending on which driver you want to use, and access the OpenGL bindings using GetProcAddress. Sample code for dynamic loading should appear soon in the developer section of the GLSetup web site. Failing that, a complete system which can be plugged into an existing project with minimal code reorganisation, including dynamic loading of the OpenGL driver (whether 3dfx standalone, normal OpenGL or mini driver) and the glu dll, is available in the downloads section. Also, a less complete dynamic loading example can be found in the Unreal OpenGL driver source code.
One important point about dynamic loading is that the GDI / wgl functions (ChoosePixelFormat, SetPixelFormat,DescribePixelFormat, GetPixelFormat and SwapBuffers) will only work with an opengl dll called opengl32.dll, due to the way gdi32.dll has been linked to opengl32.dll. If you dynamically load the 3dfxvgl.dll, you should import the equivalent wgl functions (wglChoosePixelFormat, wglSetPixelFormat, wglDescribePixelFormat, wglGetPixelFormat and wglSwapBuffers) from 3dfxvgl.dll and call them directly. If you dynamically load the SGI opengl dll (opengl.dll; see below) you should probably import the versions of ChoosePixelFormat et al exported by that dll and use them instead of either the GDI ones or the wgl ones, since they are different to the GDI ones and you are expected to use the opengl dll's versions if you statically link to it using opengl.lib (see SGI OpenGL below). The dynamic loading code samples linked above will do this for you.
Note that the best strategy is generally to use the "wgl" functions (such as wglChoosePixelFormat etc) when running on the 3dfxvgl standalone driver, but the "GDI" ones (ChoosePixelFormat etc) when using Microsoft's opengl32.dll or SGI's opengl.dll. If you do this you are calling the functions that the writers of the dlls concerned intended you to call, whether they were thinking in terms of dynamic or static linking. Calling the "wgl" functions in all cases, though possible (since opengl32.dll exports them), may cause unexpected and hard to trace bugs, since the "GDI" functions do perform actions other than simply calling the equivalent "wgl" functions.
Note that dynamic loading is the solution suggested by 3dfx, and is the only approach that allows the user to choose between the 3dfx standalone driver and an installed ICD driver at runtime within a single executable (if e.g. a Voodoo 1 and another 3d graphics accelerator are both installed). Note also that if the opengl dll (opengl32.dll, 3dfxvgl.dll, or other) is dynamically loaded, the glu dll must also be dynamically loaded if you want to use glu (glu32.dll is the appropriate dll for the Microsoft implementation; see Downloads for a glu dll which can be used with 3dfxvgl.dll until 3dfx supply one). Ryan Haksi's dynamic loading code (in the downloads section) will do this for you, but if you want to use the standalone glu dll in the downloads section you will need to change the name of the standalone glu dll loaded by Ryan Haksi's code from 3dfxvglu.dll (the projected name for 3dfx's version) to vx3dfxglu.dll (the name of the dll in the downloads section). Alternatively, you can change the name of the dll in the downloads section
The presence of 3dfxvgl.dll on a given machine does not guarantee the presence of appropriate 3dfx hardware, since it may have been removed after driver installation, and loading 3dfxvgl.dll if no 3dfx cards are present will cause a runtime failure on Glide initialisation. This situation can be avoided by dynamically loading Glide2x.dll (if present) using LoadLibrary, importing the grSstQueryBoards function using GetProcAddress, and using that to check for actual installed hardware without initialising Glide. Code to do this can be found in the snippets section.
Finally, while it is true that Videologic's PCX 1 and PCX 2 cards are also 3d only and could not have ICD drivers, they do not in fact have any OpenGL driver support other than Quake mini-drivers and D3D wrappers (see External Links, or Downloads for the source to one such wrapper which works on PCX 2 if "optimised rendering" is turned off from the driver control panel). It seems that 3d only cards have gone out of style in any case; at least, the new cards from both 3dfx and Videologic are 2d / 3d and can have normal ICD drivers.
3dfx drivers on Win9X have gone through a number of versions. The Beta 2.1 publically available driver ("3dfxopengl.dll") is now obsolete, and does not quite support the full OpenGL 1.1 specification (e.g. textured polygons cannot be fogged). The new codebase for 3dfx cards is the "Quake 3 compatible" drivers (these are actually full OpenGL 1.1 drivers with extensions, but were initially described as "Quake 3 compatible" because they contained a number of bugs - now fixed, with some possible exceptions on the Voodoo 1, 2 and Rush - and had only been tested with Quake 3.) It is these new "Quake 3 compatible" drivers which install 3dfxvgl.dll on Voodoo 1, 2 and Rush.
Note also that the 3dfx drivers for Voodoo 1, 2 and Rush cannot accelerate rendering in a window. This is not really a driver limitation; the hardware is 3d only (with the exception of the Rush, for which the 2d card is not really integrated with the 3d one) and does not support windowed rendering natively regardless of the API or driver used. The same problem would appear with the Videologic PCX 1 and PCX 2 (also 3d only cards), except that they do not have full OpenGL 1.1 drivers in any case (you must use a D3D wrapper - see below - or a mini GL on these two cards).
If you want to do windowed rendering on a Voodoo 1, 2 or Rush for debugging purposes, at the expense of some loss of speed, WinGlide is a wrapper for the normal Glide dll which copies the offscreen 3d buffer back into a window on the normal desktop (see external links for details of how to get WinGlide). However, as of December 1999 there were still serious outstanding problems with using WinGlide with the Glide version supplied with current 3dfx drivers.
Alternatively, the Mesa driver for 3dfx / Windows includes much the same functionality as WinGlide internally, controlled by an environment variable. A prebuilt binary of this driver and more details on using it to render in a window can be found in the downloads section.
Consumer card drivers now universally support a number of "game oriented" extensions, especially those used by Quake3, e.g. EXT_compiled_vertex_array. A number of IHVs, especially 3dfx and NVidia, seem to be taking a much more active approach to pushing new game related extensions as of November 1999, and the ARB appears to be much more willing to approve such extensions quickly. Information on the new extensions available in NVidia drivers as of November 1999 can be downloaded from the NVidia developer site.
A useful list of extensions supported by different Win32 drivers, plus a program which can tell you what extensions a driver supports, can be found in Druid's GL Journal.
A full list of the specifications of the various "officially registered" extensions can be found in the OpenGL extensions registry, maintained by Jon Leech. Notes on several others are available in the documents area.
Code to create Win32 windows suitable for OpenGL acceleration is widely available on the net. Another (fullscreen) example is available from Ryan Haksi's web page, and here is a useful summary of how Windows is integrated with OpenGL. However, one issue that is sometimes missed is the importance of CS_OWNDC. This flag should be set in the style field of the WNDCLASS structure when you register your windows class to allocate a unique windows device context for each window in the class, or you may experience "unexpected" behaviour on Windows drivers.
Note also that you may wish to call CreateWindowEx rather than CreateWindow, and specify the WS_EX_TOPMOST flag, when making an OpenGL "fullscreen" window, to ensure that the taskbar is always invisible.
Note that if CS_OWNDC is used there is no obvious reason to get the windows device context and release it every frame, rather than getting a DC when your program initialises and releasing it at the end. Keeping the DC for the minimum length of time was originally a strategy recommended by Microsoft for designing a program intended to cooperate with other running executables on old pre Win32 versions of Windows, where the number of available shared DCs was strictly limited.
The Win32 ChangeDisplaySettings and EnumDisplaySettings functions can be used to set the screen resolution for an OpenGL game. If you then create your Win32 window to the same resolution, you have fullscreen mode. ChangeDisplaySettings and SetWindowPos can be used to change the resolution of a running OpenGL program on some video cards without having to destroy the window.
Changing resolution on some cards, however, or changing the colour depth, stencil depth, or z buffer depth of the current window (i.e. any case in which you want to change the PIXELFORMATDESCRIPTOR) will require you to destroy and recreate the rendering window (i.e. the window with an OpenGL context attached) if you want to do it reliably (note that for the case of a PIXELFORMATDESCRIPTOR change, the documentation for SetPixelFormat states that it can only be called safely once for any given window).
Note that on Windows 95 release 1 and with many drivers on Windows 95 OSR2 ChangeDisplaySettings cannot be used to change screen colour depth without a user controlled reboot. Note also that resolutions lower than 640x480 can in general be set using ChangeDisplaySettings, and tested for validity using the CDS_TEST mode of ChangeDisplaySettings, but will not be reported by EnumDisplaySettings (since they are not "official" Windows modes).
Sample code using ChangeDisplaySettings and EnumDisplaySettings is available from Ryan Haksi's page.
Getting the Current Screen Mode
Since it is generally unwise to use DirectDraw with OpenGL on Windows, the Win32 SDK is normally used to get the current display settings. The results of calls to EnumDisplaySettings with the ENUM_CURRENT_SETTINGS parameter unfortunately seem to be unreliable on Windows 95, but the current screen resolution can be obtained using the GetSystemMetrics function. Sample code to get the current colour depth without using either DirectX or EnumDisplaySettings is available in the code snippets area.
Handling Alt Tab (Task Swapping)
In general, it is probably best to handle a user alt tabbing your application gracefully, by minimising to the task bar and then restoring the window when your game is activated again. To do this, you need to intercept the windows message WM_ACTIVATEAPP in your windows procedure and either suspend processing or restart it depending on the values of the parameters passed with the message.
If you are minimised and want to gracefully release your OpenGL related resources back to the system, at minimum you will need to release your drawing context on minimisation (call wglMakeCurrent(NULL, NULL)) and then recapture it on maximisation (call wglMakeCurrent(hDC, hRC), where hDC and hRC are the Windows device context and HGLRC of your rendering window).
However, it may be more secure to handle minimisation by the following procedure:
When you are minimised, free the OpenGL context completely, i.e. call wglMakeCurrent(NULL, NULL), followed by wglDeleteContext(hRC) and then ReleaseDC(hWnd, hDC), where hRC and hDC have the values described above and hWnd is the handle of your Win32 window. (Note: this code assumes that when you originally created the OpenGL context you are freeing, you used GetDC rather than CreateDC to obtain a Windows device context).
Then, when you are maximised again, destroy the rendering window, create a new rendering window, and create the OpenGL context for that window from scratch, using the same process you normally use to create the context on startup. Note that if this involves dynamically loading OpenGL (see "Standalone Drivers" above), you will presumably want to unload the loaded dlls when you free the context on minimisation. In any case, you will need to reload all your textures from some form of backing store (hard drive, CD etc), rebuild any display lists, etc, when you create the new context.
It may also be worth noting that if you are using DirectX components such as DirectInput or DirectSound (see below), I would suggest shutting these down before destroying the window (perhaps before you free the OpenGL context on minimisation), and then recreating them when you have recreated your window and OpenGL context on maximisation.
It should also be noted that minimising your window during game shutdown (i.e. responding to any WM_ACTIVATE or WM_ACTIVATEAPP messages that you may receive as a result of destroying the window by minimising your window to the taskbar by calling ShowWindow(hWnd, SW_MINIMISE) or similar, where hWnd is your window handle) can result in a "ghost" button being left on the system taskbar. This button should disappear when clicked on, but the problem can be avoided by not minimising your window during game shutdown.
Finally, in some circumstances you may want to disable task swapping completely, e.g. to avoid problems with synchronisation in real time networked games or to prevent "pop up" programs capturing focus from the game. Information on disabling task switching can be found in Microsoft's documentation (thanks to Noel Llopis for pointing me to this document). In brief, under Windows 9X you can disable task switching with:
UINT nPreviousState; SystemParametersInfo (SPI_SETSCREENSAVERRUNNING, TRUE, &nPreviousState, 0);and reenable it with
SystemParametersInfo (SPI_SETSCREENSAVERRUNNING, FALSE, &nPreviousState, 0);Under Windows 2000, specific key combinations which trigger task swapping (e.g. CTRL-ESC, ALT-TAB) can be disabled by installing a low level keyboard hook using SetWindowsHookEx.
In general, the hardware gamma ramp can be manipulated for 2d / 3d cards using the Win32 SetDeviceGammaRamp and GetDeviceGammaRamp functions. On 3dfx standalone cards there is an extension, WGL_EXT_gamma_control. See the documents section for a detailed description of this extension and the code snippets section for gamma handling code.
The screen refresh swap interval can be controlled using the WGL_EXT_swap_control extension, on drivers that export this, by passing appropriate values as the parameter for wglSwapIntervalEXT. Some drivers also have registry values that allow this behaviour to be manipulated, but there is no standard registry key which can be used for more than one driver (or even more than one revision of the same driver), so the registry entries are probably best avoided except for testing purposes.
As of December 1999 rendering to texture on consumer card drivers on Win32 can only be done in hardware by rendering to the back buffer and using glCopyTex(Sub)Image to transfer the data to a texture. On some cards this may be slower than you would hope, either because there is no hardware route between the frame buffer and texture memory without travelling through system memory (e.g. Voodoo 1), or because the ability of the 9X kernel to destroy all textures in video memory without warning forces a copy of the new texture to be made in system memory in order to maintain current OpenGL semantics. Various proposals to deal with this problem have been made, e.g. by Tim Sweeney of Epic.
Rendering to a texture on a software renderer (only) can be achieved using the PFD_DRAW_TO_BITMAP flag in the PIXELFORMATDESCRIPTOR to draw to a Windows DIB.
Rendering to an offscreen surface can be done under Windows using the WGL_EXT_pbuffer extension plus the WGL_EXT_make_current_read extension. If both of these extensions are available it is possible to render to an offscreen surface and then use glCopyTex(Sub)Image to transfer the results to a texture, similarly to the back buffer rendering process described above. This path can be optimised to avoid actual data copying, although it is likely that implementations will need to know exactly which formats to use for the pbuffer and the texture so that they can be sure of using any "no copies" fast path which might be available. As of December 1999 pbuffer functionality is only available on Windows on "high end" systems such as an SGI Visual Workstation, but some consumer vendors (e.g. NVidia) have plans to introduce support for it in a driver revision in the near future.
Many current PC consumer cards can only provide hardware accelerated stencil operations if the colour depth is set to a specific value (usually 32 bit). Sometimes they also require a specific setting for the z buffer depth (e.g. 24 bit).
The 3DLabs Permedia 2 appears to provide stencil support by stealing a bit from the z buffer, so this sort of issue does not occur on that card.
As of December 1999 no PC consumer card actually implements accumulation buffers in hardware, although the "T Buffers" which 3dfx intends to provide on Voodoo 4 and 5 hardware are similar. T buffers, however, will get their own extension (3DFX_TBuffer).
GDI and OpenGL do not cooperate properly if used in the same window. This is an operating system limitation. Also, on Voodoo 1, 2 and Rush (which are fullscreen only in OpenGL due to the nature of the hardware), GDI cannot be used at all.
I would suggest not using DirectDraw to set screen mode and resolution on 9X / 2K. Many OpenGL drivers use DirectDraw internally, and if the application uses DirectDraw unfortunate consequences often follow. The Win32 functions ChangeDisplaySettings and EnumDisplaySettings can be used instead.
The "Supported 3D Accelerators" pages on the GLSetup web site now have notes on which 9X drivers DirectDraw is known to definitely not work with.
DirectPlay, DirectInput, DirectSound, DirectSetup
All these DirectX Foundation components can be used safely with an OpenGL game. If, however, you are going to destroy and recreate the window to e.g. change colour depth (see above), I would suggest shutting down any DirectInput, DirectPlay or DirectSound objects attached to that window. Some OpenGL drivers appear to crash if this is not done, possibly because the drivers use DirectDraw and other DirectX components are linked to DirectDraw internally.
DirectShow / ActiveMovie / DirectMPEG / Quartz
This can be used safely as an intro FMV player for an OpenGL game, but the DirectShow player must exist in a separate process to the game, presumably to avoid arguments over who owns DirectDraw on some OpenGL drivers. The game process can be launched from the original process after the FMV has terminated.
SGI have written an alternative core implementation of OpenGL for Windows, "SGI OpenGL for Windows". This can be downloaded from a number of sites (see the External Links section). The software renderer in this version is very much faster than the Microsoft one, and bug free (software rendering is actually done using autogenerated code to assemble the fastest rasteriser etc for the supplied data at runtime, and is fast enough to be worth considering for use in a game). Note, however, that if any OpenGL ICD or MCD drivers are present in the system, SGI's OpenGL for Windows will actually default to the Microsoft software renderer if the user asks for a mode which cannot be accelerated by the ICD / MCD. The SGI driver is thus probably useful primarily as a software rendering only mode. Note that it can be prevented from using any hardware accelerated drivers which may be present by setting a registry key (see the documentation in the download) or renaming it from "opengl.dll" to "opengl32.dll".
Note also that it seems that SGI OpenGL cannot invoke hardware acceleration via the ICD or MCD mechanisms on Windows 2000, though the software renderer still works.
Considered as a software renderer, there are two main ways in which the SGI opengl.dll can be used: indexed (256 colours) mode and truecolour mode. The driver contains special extensions (documented in the download) to make indexed mode rendering in OpenGL possible to the level of quality expected for games. In either mode the performance of the rasteriser is competitive with that of dedicated game engines. Note that it is important to be aware of which paths through the code are accelerated by the "autogen" runtime assembly system; performance on the autogen path is very much superior to performance off it. Specifically, z buffering, alpha blending, perspective corrected texturing and truecolour rendering are on the fast path, but alpha testing is off it.
The SGI opengl dll is accelerated by MMX, but not by 3DNow! or Katmai. Given that it is no longer being upgraded, it is unlikely that support for these instructions will be added.
The core Microsoft opengl dll (opengl32.dll) is OpenGL 1.1 compliant. Microsoft are planning to release an upgrade with OpenGL 1.2 entry points in the "second service pack for Win2K" (perhaps six months after Win2K ships) and a service pack for 9X "in the same timeframe". In the meantime, a number of "high end" cards on Win32 such as the FireGL 1 support full OpenGL 1.2 drivers, and NVidia's GeForce 256 drivers support those parts of OpenGL 1.2 which NVidia (presumably) felt were appropriate for games and / or their hardware. It seems likely that more consumer cards will support OpenGL 1.2 in the future.
Since the entry points for 1.2 are not present in the core opengl32.dll, however, OpenGL 1.2 functions must be loaded as extensions on these cards. A driver which supports all the 1.2 core functionality should have "1.2" at the start of its version string. A driver which supports only part of the 1.2 specification should export those parts as specific extensions.
The open source clone of OpenGL, Mesa, is OpenGL 1.2 compliant, but there is no guarantee that functionality available in 1.2 but not in 1.1 will be accelerated on any given piece of hardware.
The open source clone of OpenGL, Mesa, can be compiled for Win32 support. However, due to historical NDA issues, the only available hardware accelerated drivers are 3dfx (via Glide) and D3D (see below). The D3D driver is only for Mesa 3.0 as of 4th December 1999, while the 3dfx driver works with current (3.1/3.2/3.3) source trees. The Mesa software renderer is essentially bug free but quite slow.
Binaries for Mesa 3.1 and 3.2 built for Win32 / 3dfx support can be found in the downloads section. Note that compiling Mesa for Win32 produces a binary called opengl32.dll; to avoid problems with the operating system, this should be put in a position where the application will load it before the Microsoft dll in windows \ system (e.g. in the application directory) but not actually copied over the Microsoft version.
Current Mesa development is concentrating largely on Linux support, where Mesa is the main implementation. It is possible that at some stage some of the new Linux drivers based on open releases of the chip specifications by the board manufacturers will be ported to Windows.
Two separate generic OpenGL 1.2 to Direct3D wrappers are available on 9X: the (free) Mesa 3.0 D3D driver and SciTech's commercial GLDirect. See External Links for details, and the downloads section for source for the most recent version of the Mesa wrapper. NB: the binary for the Mesa driver is called altogl.dll; the normal way of using it is to rename it to opengl32.dll and treat it as any other Mesa for Win32 dll (see above).
Note that GLDirect installs a replacement for the normal Microsoft opengl32.dll into the windows \ system directory on 9X to allow users to switch between GLDirect and normal ("ICD") rendering. If GLSetup is run on a machine on which GLDirect has been installed, it will recognise that the installed opengl32.dll is non standard and ask for permission to overwrite it. If permission is denied, GLSetup will refuse to install any drivers. If permission is given, GLDirect will report that you have switched to "ICD" style rendering the next time you start its control panel. GLDirect will, however, deal with this situation gracefully (i.e. switching back to the wrapper from the GLDirect panel will still work)
Many people find that if they repeatedly "stop debugging" in Windows, i.e. break out of an application without shutting down normally, they will eventually "lose hardware acceleration" until they reboot. This seems to only happen on some systems. No one knows why. It only affects debugging.
When using the debugger, you may see multiple messages reporting a first chance exception (access violation) in gdi32.dll. This is apparently a side effect of how wgl and the ICD mechanism work, and is safe. I have no idea exactly what causes this, but if anyone else does, I'd be interested in finding out
In Windows 95 and 98, all hardware acceleration via the ICD mechanism will be disabled in a PC with two monitors.
I believe multi monitor acceleration can be enabled in Win2K, but the IHV's OpenGL driver must be specifically written to support this. All multi monitor behaviours are handled by the driver in this model.
As of December 1999 it seems that OpenGL drivers will not be shipped on the Win2K install CDs. However, the core Microsoft dlls (opengl32.dll and glu32.dll) are present, and many vendors have already produced OpenGL ICD drivers for Win2K, some of which work very well. It seems likely that relatively old cards (e.g. the Matrox G200) will not get Win2K OpenGL drivers.
As of March 2000, almost all "current" cards have full OpenGL 1.1 IHV drivers for Win2K.
Note that it seems that SGI's (essentially obsolete) OpenGL for Windows cannot invoke hardware acceleration via the ICD or MCD mechanisms on Windows 2000, though the software renderer still works.
Official OpenGL 1.2 entry points in the Microsoft opengl32.dll are promised for the second service pack after the final Win2K release.
This link points to Microsoft's FAQ on OpenGL support in Win2K. At this time it seems likely that, even if the "Microsoft standard ICD" mentioned in the FAQ is produced, only a minority of IHVs will actually use it to supply games support rather than writing their own drivers from scratch, for a number of reasons.