Tao.Platform.Windows WinNT binding for .NET, implementing Windows NT-specific functionality. Intel i386 processor. Intel i486 processor. Intel Pentium processor. Intel IA64 processor. AMD X86 64 processor. MIPS R4000, R4101, R3910 processor. Alpha 210 64 processor. PPC 601 processor. PPC 603 processor. PPC 604 processor. PPC 620 processor. Hitachi SH3 processor. Hitachi SH3E processor. Hitachi SH4 processor. Motorola 821 processor. SHx SH3 processor. SHx SH4 processor. StrongARM processor. ARM 720 processor. ARM 820 processor. ARM 920 processor. ARM 7TDMI processor. MSIL processor. Intel architecture. MIPS architecture. Alpha architecture. PPC architecture. SHX architecture. ARM architecture. IA64 architecture. Alpha64 architecture. MSIL architecture. AMD64 architecture. IA32 On Win64 architecture. Unknown architecture. In rare circumstances, on a Pentium, a floating-point precision error can occur. Floating-point operations are emulated using a software emulator. The compare and exchange double operation is available (Pentium, MIPS, and Alpha). The MMX instruction set is available. Unknown. Unknown. The SSE instruction set is available. The 3D-Now instruction set is available. The RDTSC instruction is available. The processor is PAE-enabled. The SSE2 instruction set is available. Kernel binding for .NET, implementing Windows-specific kernel functionality. Binds functions and definitions in kernel32.dll. Specifies Kernel32's native library archive. Specifies kernel32.dll for Windows. Specifies the calling convention. Specifies . The Beep function generates simple tones on the speaker. The function is synchronous; it does not return control to its caller until the sound finishes. Frequency of the sound, in hertz. This parameter must be in the range 37 through 32,767 (0x25 through 0x7FFF). Windows 95/98/Me: The Beep function ignores this parameter. Duration of the sound, in milliseconds. Windows 95/98/Me: The Beep function ignores this parameter. If the function succeeds, the return value is true. If the function fails, the return value is false. To get extended error information, call . Terminal Services: The beep is redirected to the client. Windows 95/98/Me: On computers with a sound card, the function plays the default sound event. On computers without a sound card, the function plays the standard system beep. The FreeLibrary function decrements the reference count of the loaded dynamic-link library (DLL). When the reference count reaches zero, the module is unmapped from the address space of the calling process and the handle is no longer valid. Handle to the loaded DLL module. The or function returns this handle. If the function succeeds, the return value is true. If the function fails, the return value is false. To get extended error information, call . Each process maintains a reference count for each loaded library module. This reference count is incremented each time is called and is decremented each time FreeLibrary is called. A DLL module loaded at process initialization due to load-time dynamic linking has a reference count of one. This count is incremented if the same module is loaded by a call to . Before unmapping a library module, the system enables the DLL to detach from the process by calling the DLL's DllMain function, if it has one, with the DLL_PROCESS_DETACH value. Doing so gives the DLL an opportunity to clean up resources allocated on behalf of the current process. After the entry-point function returns, the library module is removed from the address space of the current process. It is not safe to call FreeLibrary from DllMain. For more information, see the Remarks section in DllMain. Calling FreeLibrary does not affect other processes using the same library module. The GetDllDirectory function retrieves the application-specific portion of the search path used to locate DLLs for the application. Size of the output buffer, in characters. Pointer to a buffer that receives the application-specific portion of the search path. If the function succeeds, the return value is the length of the string copied to buffer, in characters, not including the terminating null character. If the return value is greater than bufferLength, it specifies the size of the buffer required for the path. If the function fails, the return value is zero. To get extended error information, call . The GetModuleFileName function retrieves the fully qualified path for the specified module. To specify the process that contains the module, use the GetModuleFileNameEx function. Handle to the module whose path is being requested. If this parameter is NULL, GetModuleFileName retrieves the path for the current module. Pointer to a buffer that receives a null-terminated string that specifies the fully-qualified path of the module. If the length of the path exceeds the size specified by the size parameter, the function succeeds and the string is truncated to size characters and null terminated. The path can have the prefix "\\?\", depending on how the module was loaded. Size of the filename buffer, in TCHARs. If the function succeeds, the return value is the length of the string copied to the buffer, in TCHARs. If the buffer is too small to hold the module name, the string is truncated to size, and the function returns size. If the function fails, the return value is zero. To get extended error information, call . If a DLL is loaded in two processes, its file name in one process may differ in case from its file name in the other process. For the ANSI version of the function, the number of TCHARs is the number of bytes; for the Unicode version, it is the number of characters. Windows Me/98/95: This function retrieves long file names when an application's version number is greater than or equal to 4.00 and the long file name is available. Otherwise, it returns only 8.3 format file names. The GetModuleHandle function retrieves a module handle for the specified module if the file has been mapped into the address space of the calling process. To avoid the race conditions described in the Remarks section, use the GetModuleHandleEx function. Pointer to a null-terminated string that contains the name of the module (either a .dll or .exe file). If the file name extension is omitted, the default library extension .dll is appended. The file name string can include a trailing point character (.) to indicate that the module name has no extension. The string does not have to specify a path. When specifying a path, be sure to use backslashes (\), not forward slashes (/). The name is compared (case independently) to the names of modules currently mapped into the address space of the calling process. If this parameter is NULL, GetModuleHandle returns a handle to the file used to create the calling process. If the function succeeds, the return value is a handle to the specified module (IntPtr). If the function fails, the return value is NULL (IntPtr.Zero). To get extended error information, call . The returned handle is not global or inheritable. It cannot be duplicated or used by another process. The GetModuleHandle function returns a handle to a mapped module without incrementing its reference count. Therefore, use care when passing the handle to the function, because doing so can cause a DLL module to be unmapped prematurely. This function must be used carefully in a multithreaded application. There is no guarantee that the module handle remains valid between the time this function returns the handle and the time it is used. For example, a thread retrieves a module handle, but before it uses the handle, a second thread frees the module. If the system loads another module, it could reuse the module handle that was recently freed. Therefore, first thread would have a handle to a module different than the one intended. The GetProcAddress function retrieves the address of an exported function or variable from the specified dynamic-link library (DLL). Handle to the DLL module that contains the function or variable. The or function returns this handle. Pointer to a null-terminated string that specifies the function or variable name, or the function's ordinal value. If this parameter is an ordinal value, it must be in the low-order word; the high-order word must be zero. If the function succeeds, the return value is the address of the exported function or variable. If the function fails, the return value is NULL (IntPtr.Zero). To get extended error information, call . The spelling and case of a function name pointed to by processName must be identical to that in the EXPORTS statement of the source DLL's module-definition (.def) file. The exported names of functions may differ from the names you use when calling these functions in your code. This difference is hidden by macros used in the SDK header files. The processName parameter can identify the DLL function by specifying an ordinal value associated with the function in the EXPORTS statement. GetProcAddress verifies that the specified ordinal is in the range 1 through the highest ordinal value exported in the .def file. The function then uses the ordinal as an index to read the function's address from a function table. If the .def file does not number the functions consecutively from 1 to N (where N is the number of exported functions), an error can occur where GetProcAddress returns an invalid, non-NULL address, even though there is no function with the specified ordinal. In cases where the function may not exist, the function should be specified by name rather than by ordinal value. The GetProcessWorkingSetSize function retrieves the minimum and maximum working set sizes of the specified process. Handle to the process whose working set sizes will be obtained. The handle must have the PROCESS_QUERY_INFORMATION access right. Pointer to a variable that receives the minimum working set size of the specified process, in bytes. The virtual memory manager attempts to keep at least this much memory resident in the process whenever the process is active. Pointer to a variable that receives the maximum working set size of the specified process, in bytes. The virtual memory manager attempts to keep no more than this much memory resident in the process whenever the process is active when memory is in short supply. If the function succeeds, the return value is true. If the function fails, the return value is false. To get extended error information, call . The "working set" of a process is the set of memory pages currently visible to the process in physical RAM memory. These pages are resident and available for an application to use without triggering a page fault. The minimum and maximum working set sizes affect the virtual memory paging behavior of a process. The GetSystemDirectory function retrieves the path of the system directory. The system directory contains system such files such as dynamic-link libraries, drivers, and font files. This function is provided primarily for compatibility. Applications should store code in the Program Files folder and persistent data in the Application Data folder in the user's profile. Pointer to the buffer to receive the null-terminated string containing the path. This path does not end with a backslash unless the system directory is the root directory. For example, if the system directory is named Windows\System on drive C, the path of the system directory retrieved by this function is C:\Windows\System. Maximum size of the buffer, in TCHARs. This value should be set to at least MAX_PATH+1 to allow sufficient space for the path and the null terminator. If the function succeeds, the return value is the length, in TCHARs, of the string copied to the buffer, not including the terminating null character. If the length is greater than the size of the buffer, the return value is the size of the buffer required to hold the path. If the function fails, the return value is zero. To get extended error information, call . Applications should not create files in the system directory. If the user is running a shared version of the operating system, the application does not have write access to the system directory. The GetSystemInfo function returns information about the current system. To retrieve accurate information for a Win32-based application running on WOW64, call the GetNativeSystemInfo function. Pointer to a structure that receives the information. The GetSystemWindowsDirectory function retrieves the path of the shared Windows directory on a multi-user system. Pointer to the buffer to receive a null-terminated string containing the path. This path does not end with a backslash unless the Windows directory is the root directory. For example, if the Windows directory is named Windows on drive C, the path of the Windows directory retrieved by this function is C:\Windows. If the system was installed in the root directory of drive C, the path retrieved is C:\. Maximum size of the buffer specified by the buffer parameter, in TCHARs. This value should be set to at least MAX_PATH+1 to allow sufficient space for the path and the null-terminating character. If the function succeeds, the return value is the length of the string copied to the buffer, in TCHARs, not including the terminating null character. If the length is greater than the size of the buffer, the return value is the size of the buffer required to hold the path. If the function fails, the return value is zero. To get extended error information, call . On a system that is running Terminal Server, each user has a unique Windows directory. The system Windows directory is shared by all users, so it is the directory where an application should store initialization and help files that apply to all users. With Terminal Services, the GetSystemWindowsDirectory function retrieves the path of the system Windows directory, while the function retrieves the path of a Windows directory that is private for each user. On a single-user system, GetSystemWindowsDirectory is the same as . Windows NT 4.0 Terminal Server Edition: To retrieve the shared Windows directory, call and trim the "System32" element from the end of the returned path. The GetTickCount function retrieves the number of milliseconds that have elapsed since the system was started. It is limited to the resolution of the system timer. To obtain the system timer resolution, use the GetSystemTimeAdjustment function. The return value is the number of milliseconds that have elapsed since the system was started. The elapsed time is stored as a DWORD value. Therefore, the time will wrap around to zero if the system is run continuously for 49.7 days. If you need a higher resolution timer, use a multimedia timer or a high-resolution timer. To obtain the time elapsed since the computer was started, retrieve the System Up Time counter in the performance data in the registry key HKEY_PERFORMANCE_DATA. The value returned is an 8-byte value. The GetWindowsDirectory function retrieves the path of the Windows directory. The Windows directory contains such files as applications, initialization files, and help files. This function is provided primarily for compatibility. Applications should store code in the Program Files folder and persistent data in the Application Data folder in the user's profile. Pointer to the buffer to receive the null-terminated string containing the path. This path does not end with a backslash unless the Windows directory is the root directory. For example, if the Windows directory is named Windows on drive C, the path of the Windows directory retrieved by this function is C:\Windows. If the system was installed in the root directory of drive C, the path retrieved is C:\. Maximum size of the buffer specified by the buffer parameter, in TCHARs. This value should be set to MAX_PATH. If the function succeeds, the return value is the length of the string copied to the buffer, in TCHARs, not including the terminating null character. If the length is greater than the size of the buffer, the return value is the size of the buffer required to hold the path. If the function fails, the return value is zero. To get extended error information, call . The Windows directory is the directory where an application should store initialization and help files. If the user is running a shared version of the system, the Windows directory is guaranteed to be private for each user. If an application creates other files that it wants to store on a per-user basis, it should place them in the directory specified by the HOMEPATH environment variable. This directory will be different for each user, if so specified by an administrator, through the User Manager administrative tool. HOMEPATH always specifies either the user's home directory, which is guaranteed to be private for each user, or a default directory (for example, C:\USERS\DEFAULT) where the user will have all access. Terminal Services: If the application is running in a Terminal Services environment, each user has a unique Windows directory. If an application that is not Terminal-Services-aware calls this function, it retrieves the path of the Windows directory on the client, not the Windows directory on the server. The GlobalMemoryStatus function obtains information about the system's current usage of both physical and virtual memory. To obtain information about the extended portion of the virtual address space, or if your application may run on computers with more than 4 GB of main memory, use the GlobalMemoryStatusEx function. Pointer to a structure. The GlobalMemoryStatus function stores information about current memory availability into this structure. You can use the GlobalMemoryStatus function to determine how much memory your application can allocate without severely impacting other applications. The information returned by the GlobalMemoryStatus function is volatile. There is no guarantee that two sequential calls to this function will return the same information. On computers with more than 4 GB of memory, the GlobalMemoryStatus function can return incorrect information. Windows 2000 and later report a value of -1 to indicate an overflow. Earlier versions of Windows NT report a value that is the real amount of memory, modulo 4 GB. For this reason, use the GlobalMemoryStatusEx function instead. On Intel x86 computers with more than 2 GB and less than 4 GB of memory, the GlobalMemoryStatus function will always return 2 GB in the member of the structure. Similarly, if the total available memory is between 2 and 4 GB, the member of the structure will be rounded down to 2 GB. If the executable is linked using the /LARGEADDRESSWARE linker option, then the GlobalMemoryStatus function will return the correct amount of physical memory in both members. The IsProcessorFeaturePresent function determines whether the specified processor feature is supported by the current computer. Processor feature to be tested. This parameter can be one of the following values: Value Description The 3D-Now instruction set is available. The compare and exchange double operation is available (Pentium, MIPS, and Alpha). Floating-point operations are emulated using a software emulator. This function returns true if floating-point operations are emulated; otherwise, it returns false. Windows NT 4.0: This function returns false if floating-point operations are emulated; otherwise, it returns true. This behavior is a bug that is fixed in later versions. Pentium: In rare circumstances, a floating-point precision error can occur. The MMX instruction set is available. The processor is PAE-enabled. The RDTSC instruction is available. The SSE instruction set is available. The SSE2 instruction set is available. If the feature is supported, the return value is true. If the feature is not supported, the return value is false. The LoadLibrary function maps the specified executable module into the address space of the calling process. Pointer to a null-terminated string that names the executable module (either a .dll or .exe file). The name specified is the file name of the module and is not related to the name stored in the library module itself, as specified by the LIBRARY keyword in the module-definition (.def) file. If the string specifies a path but the file does not exist in the specified directory, the function fails. When specifying a path, be sure to use backslashes (\), not forward slashes (/). If the string does not specify a path, the function uses a standard search strategy to find the file. See the Remarks for more information. If the function succeeds, the return value is a handle to the module (IntPtr). If the function fails, the return value is NULL (IntPtr.Zero). To get extended error information, call . Windows Me/98/95: If you are using LoadLibrary to load a module that contains a resource whose numeric identifier is greater than 0x7FFF, LoadLibrary fails. If you are attempting to load a 16-bit DLL directly from 32-bit code, LoadLibrary fails. If you are attempting to load a DLL whose subsystem version is greater than 4.0, LoadLibrary fails. If your DllMain function tries to call the Unicode version of a function, LoadLibrary fails. LoadLibrary can be used to map a DLL module and return a handle that can be used in to get the address of a DLL function. LoadLibrary can also be used to map other executable modules. For example, the function can specify an .exe file to get a handle that can be used in FindResource or LoadResource. However, do not use LoadLibrary to run an .exe file, use the CreateProcess function. If the module is a DLL not already mapped for the calling process, the system calls the DLL's DllMain function with the DLL_PROCESS_ATTACH value. If the DLL's entry-point function does not return TRUE, LoadLibrary fails and returns NULL. (The system immediately calls your entry-point function with DLL_PROCESS_DETACH and unloads the DLL.) It is not safe to call LoadLibrary from DllMain. For more information, see the Remarks section in DllMain. Module handles are not global or inheritable. A call to LoadLibrary by one process does not produce a handle that another process can use — for example, in calling . The other process must make its own call to LoadLibrary for the module before calling . If no file name extension is specified in the fileName parameter, the default library extension .dll is appended. However, the file name string can include a trailing point character (.) to indicate that the module name has no extension. When no path is specified, the function searches for loaded modules whose base name matches the base name of the module to be loaded. If the name matches, the load succeeds. Otherwise, the function searches for the file in the following sequence: The directory from which the application loaded. The current directory. The system directory. Use the function to get the path of this directory. The 16-bit system directory. There is no function that obtains the path of this directory, but it is searched. Windows Me/98/95: This directory does not exist. The Windows directory. Use the function to get the path of this directory. The directories that are listed in the PATH environment variable. Windows Server 2003, Windows XP SP1: The default value of HKLM\System\CurrentControlSet\Control\Session Manager\SafeDllSearchMode is 1 (current directory is searched after the system and Windows directories). Windows XP: If HKLM\System\CurrentControlSet\Control\Session Manager\SafeDllSearchMode is 1, the current directory is searched after the system and Windows directories, but before the directories in the PATH environment variable. The default value is 0 (current directory is searched before the system and Windows directories). The first directory searched is the one directory containing the image file used to create the calling process (for more information, see the CreateProcess function). Doing this allows private dynamic-link library (DLL) files associated with a process to be found without adding the process's installed directory to the PATH environment variable. The search path can be altered using the function. This solution is recommended instead of using SetCurrentDirectory or hard-coding the full path to the DLL. If a path is specified and there is a redirection file for the application, the function searches for the module in the application's directory. If the module exists in the application's directory, the LoadLibrary function ignores the specified path and loads the module from the application's directory. If the module does not exist in the application's directory, LoadLibrary loads the module from the specified directory. The QueryPerformanceCounter function retrieves the current value of the high-resolution performance counter. Pointer to a variable that receives the current performance-counter value, in counts. If the function succeeds, the return value is true. If the function fails, the return value is false. To get extended error information, call . On a multiprocessor machine, it should not matter which processor is called. However, you can get different results on different processors due to bugs in the BIOS or the HAL. To specify processor affinity for a thread, use the SetThreadAffinityMask function. The QueryPerformanceCounterFast function retrieves the current value of the high-resolution performance counter. Pointer to a variable that receives the current performance-counter value, in counts. If the function succeeds, the return value is true. If the function fails, the return value is false. This version of is slightly faster. It does not set the last Windows error. Use with care. On a multiprocessor machine, it should not matter which processor is called. However, you can get different results on different processors due to bugs in the BIOS or the HAL. To specify processor affinity for a thread, use the SetThreadAffinityMask function. The QueryPerformanceFrequency function retrieves the frequency of the high-resolution performance counter, if one exists. The frequency cannot change while the system is running. Pointer to a variable that receives the current performance-counter frequency, in counts per second. If the installed hardware does not support a high-resolution performance counter, this parameter can be zero. If the installed hardware supports a high-resolution performance counter, the return value is true. If the function fails, the return value is false. To get extended error information, call . For example, if the installed hardware does not support a high-resolution performance counter, the function fails. Note The frequency of the high-resolution performance counter is not the processor speed. The SetDllDirectory function modifies the search path used to locate DLLs for the application. Pointer to a null-terminated string that specifies the directories to be added to the search path, separated by semicolons. If this parameter is NULL, the default search path is used. If the function succeeds, the return value is true. If the function fails, the return value is false. To get extended error information, call . The SetDllDirectory function affects all subsequent calls to the and LoadLibraryEx functions. After calling SetDllDirectory, the DLL search path is: The directory from which the application loaded. The directory specified by the pathName parameter. The system directory. Use the function to get the path of this directory. The name of this directory is System32. The 16-bit system directory. There is no function that obtains the path of this directory, but it is searched. The name of this directory is System. The Windows directory. Use the function to get the path of this directory. The directories that are listed in the PATH environment variable. To revert to the default search path used by and LoadLibraryEx, call SetDllDirectory with NULL. The SetProcessWorkingSetSize function sets the minimum and maximum working set sizes for the specified process. Handle to the process whose working set sizes is to be set. The handle must have the PROCESS_SET_QUOTA access right. Minimum working set size for the process, in bytes. The virtual memory manager attempts to keep at least this much memory resident in the process whenever the process is active. If both minimumWorkingSetSize and maximumWorkingSetSize have the value -1, the function temporarily trims the working set of the specified process to zero. This essentially swaps the process out of physical RAM memory. Maximum working set size for the process, in bytes. The virtual memory manager attempts to keep no more than this much memory resident in the process whenever the process is active and memory is in short supply. If both minimumWorkingSetSize and maximumWorkingSetSize have the value -1, the function temporarily trims the working set of the specified process to zero. This essentially swaps the process out of physical RAM memory. If the function succeeds, the return value is true. If the function fails, the return value is false. To get extended error information, call . The working set of a process is the set of memory pages currently visible to the process in physical RAM memory. These pages are resident and available for an application to use without triggering a page fault. The minimum and maximum working set sizes affect the virtual memory paging behavior of a process. The working set of the specified process can be emptied by specifying the value -1 for both the minimum and maximum working set sizes. If the values of either minimumWorkingSetSize or maximumWorkingSetSize are greater than the process' current working set sizes, the specified process must have the SE_INC_BASE_PRIORITY_NAME privilege. Users in the Administrators and Power Users groups generally have this privilege. The operating system allocates working set sizes on a first-come, first-served basis. For example, if an application successfully sets 40 megabytes as its minimum working set size on a 64-megabyte system, and a second application requests a 40-megabyte working set size, the operating system denies the second application's request. Using the SetProcessWorkingSetSize function to set an application's minimum and maximum working set sizes does not guarantee that the requested memory will be reserved, or that it will remain resident at all times. When the application is idle, or a low-memory situation causes a demand for memory, the operating system can reduce the application's working set. An application can use the VirtualLock function to lock ranges of the application's virtual address space in memory; however, that can potentially degrade the performance of the system. When you increase the working set size of an application, you are taking away physical memory from the rest of the system. This can degrade the performance of other applications and the system as a whole. It can also lead to failures of operations that require physical memory to be present; for example, creating processes, threads, and kernel pool. Thus, you must use the SetProcessWorkingSetSize function carefully. You must always consider the performance of the whole system when you are designing an application. The MEMORYSTATUS structure contains information about the current state of both physical and virtual memory. The function stores information in a MEMORYSTATUS structure. MEMORYSTATUS reflects the state of memory at the time of the call. It reflects the size of the paging file at that time. The operating system can enlarge the paging file up to the maximum size set by the administrator. On computers with more than 4 GB of memory, the MEMORYSTATUS structure can return incorrect information. Windows reports a value of -1 to indicate an overflow, while Windows NT reports a value that is the real amount of memory, modulo 4 GB. If your application is at risk for this behavior, use the GlobalMemoryStatusEx function instead of the function. Size of the MEMORYSTATUS data structure, in bytes. You do not need to set this member before calling the function; the function sets it. Approximate percentage of total physical memory that is in use. Windows NT: Percentage of approximately the last 1000 pages of physical memory that is in use. Total size of physical memory, in bytes. Size of physical memory available, in bytes. Size of the committed memory limit, in bytes. Size of available memory to commit, in bytes. Total size of the user mode portion of the virtual address space of the calling process, in bytes. Size of unreserved and uncommitted memory in the user mode portion of the virtual address space of the calling process, in bytes. The SYSTEM_INFO structure contains information about the current computer system. This includes the architecture and type of the processor, the number of processors in the system, the page size, and other such information. Union for the OemId, ProcessorArchitecture, and Reserved fields of the SYSTEM_INFO structure. See . Page size and the granularity of page protection and commitment. This is the page size used by the VirtualAlloc function. Pointer to the lowest memory address accessible to applications and dynamic-link libraries (DLLs). Pointer to the highest memory address accessible to applications and DLLs. Mask representing the set of processors configured into the system. Bit 0 is processor 0; bit 31 is processor 31. Number of processors in the system. An obsolete member that is retained for compatibility with Windows NT 3.5 and earlier. Use the SystemInfoUnion.ProcessorArchitecture, ProcessorLevel, and ProcessorRevision members to determine the type of processor. Windows Me/98/95: Specifies the type of processor in the system. This member is one of the following values: Granularity with which virtual memory is allocated. For example, a VirtualAlloc request to allocate 1 byte will reserve an address space of AllocationGranularity bytes. This value was hard coded as 64K in the past, but other hardware architectures may require different values. System's architecture-dependent processor level. It should be used only for display purposes. To determine the feature set of a processor, use the function. If SystemInfoUnion.ProcessorArchitecture is , ProcessorLevel is defined by the CPU vendor. If SystemInfoUnion.ProcessorArchitecture is , ProcessorLevel is set to 1. If SystemInfoUnion.ProcessorArchitecture is , ProcessorLevel is of the form 00xx, where xx is an 8-bit implementation number (bits 8-15 of the PRId register). The member can be the following value: Value Description 0004 MIPS R4000 If SystemInfoUnion.ProcessorArchitecture is , ProcessorLevel is of the form xxxx, where xxxx is a 16-bit processor version number (the low-order 16 bits of a version number from the firmware). The member can be one of the following values: Value Description 21064 Alpha 21064 21066 Alpha 21066 21164 Alpha 21164 If SystemInfoUnion.ProcessorArchitecture is , ProcessorLevel is of the form xxxx, where xxxx is a 16-bit processor version number (the high-order 16 bits of the Processor Version Register). The member can be one of the following values: Value Description 1 PPC 601 3 PPC 603 4 PPC 604 6 PPC 603+ 9 PPC 604+ 20 PPC 620 Architecture-dependent processor revision. The following table shows how the revision value is assembled for each type of processor architecture: Processor Description Intel 80386 or 80486 A value of the form xxyz. If xx is equal to 0xFF, y - 0xA is the model number, and z is the stepping identifier. For example, an Intel 80486-D0 system returns 0xFFD0. If xx is not equal to 0xFF, xx + 'A' is the stepping letter and yz is the minor stepping. Intel Pentium, Cyrix, or NextGen 586 A value of the form xxyy, where xx is the model number and yy is the stepping. Display this value of 0x0201 as follows: Model xx, Stepping yy. MIPS A value of the form 00xx, where xx is the 8-bit revision number of the processor (the low-order 8 bits of the PRId register). ALPHA A value of the form xxyy, where xxyy is the low-order 16 bits of the processor revision number from the firmware. Display this value as follows: Model A+xx, Pass yy. PPC A value of the form xxyy, where xxyy is the low-order 16 bits of the processor version register. Display this value as follows: xx.yy. Union for the OemId, ProcessorArchitecture, and Reserved fields of the structure. An obsolete member that is retained for compatibility with Windows NT 3.5 and earlier. New applications should use the ProcessorArchitecture branch of the union. Windows Me/98/95: The system always sets this member to zero, the value defined for . System's processor architecture. This value can be one of the following values: Windows NT 3.51: Windows NT 4.0 and earlier: Windows NT 4.0 and earlier: 64-bit Windows: , , Reserved for future use. Injects supplied MSIL into the method's body. This is a hack as the C# compiler does not allow inline MSIL. This is extracted and the appropriate MSIL injected by the PostProcessTao utility. Injects the supplied MSIL into the tagged method's body. The MSIL to inject. Creates a System.Delegate that can be used to call an OpenGL function, core or extension. The name of the OpenGL function (eg. "glNewList") The signature of the OpenGL function. A System.Delegate that can be used to call this OpenGL function, or null if the specified function name did not correspond to an OpenGL function. Loads all OpenGL functions (core and extensions). This function will be automatically called the first time you use any opengl function. There is Call this function manually whenever you need to update OpenGL entry points. This need may arise if you change the pixelformat/visual, or in case you cannot (or do not want) to use the automatic initialization of the GL class. Tries to reload the given OpenGL function (core or extension). The name of the OpenGL function (i.e. glShaderSource) True if the function was found and reloaded, false otherwise. Use this function if you require greater granularity when loading OpenGL entry points. While the automatic initialisation will load all OpenGL entry points, in some cases the initialisation can take place before an OpenGL Context has been established. In this case, use this function to load the entry points for the OpenGL functions you will need, or use ReloadFunctions() to load all available entry points. This function returns true if the given OpenGL function is supported, false otherwise. To query for supported extensions use the IsExtensionSupported() function instead. Creates a System.Delegate that can be used to call a dynamically exported OpenGL function. The name of the OpenGL function (eg. "glNewList") The signature of the OpenGL function. A System.Delegate that can be used to call this OpenGL function or null if the function is not available in the current OpenGL context. Determines whether the specified OpenGL extension category is available in the current OpenGL context. Equivalent to IsExtensionSupported(name, true) The string for the OpenGL extension category (eg. "GL_ARB_multitexture") True if the specified extension is available, false otherwise. Contains DllImports for the core OpenGL functions. Build a string->MethodInfo map to speed up extension loading. Windows Multimedia binding for .NET, implementing Windows-specific multimedia functionality. Binds functions and definitions in winmm.dll. Specifies Winmm's native library archive. Specifies winmm.dll for Windows. Specifies the calling convention. Specifies . Synchronous playback of a sound event. PlaySound returns after the sound event completes. The sound is played asynchronously and PlaySound returns immediately after beginning the sound. To terminate an asynchronously played waveform sound, call PlaySound with sound set to NULL. No default sound event is used. If the sound cannot be found, PlaySound returns silently without playing the default sound. A sound event's file is loaded in RAM. The parameter specified by sound must point to an image of a sound in memory. The sound plays repeatedly until PlaySound is called again with the sound parameter set to NULL. You must also specify the flag to indicate an asynchronous sound event. The specified sound event will yield to another sound event that is already playing. If a sound cannot be played because the resource needed to generate that sound is busy playing another sound, the function immediately returns FALSE without playing the requested sound. If this flag is not specified, PlaySound attempts to stop the currently playing sound so that the device can be used to play the new sound. If the driver is busy, return immediately without playing the sound. The sound parameter is a system-event alias in the registry or the WIN.INI file. Do not use with either or . The sound parameter is a predefined sound identifier. The sound parameter is a filename. The sound parameter is a resource identifier; mod must identify the instance that contains the resource. Sounds are to be stopped for the calling task. If sound is not NULL, all instances of the specified sound are stopped. If sound is NULL, all sounds that are playing on behalf of the calling task are stopped. You must also specify the instance handle to stop events. The sound is played using an application-specific association. Timer base identifier. Successful. Resolution specified is out of range. First joystick button is pressed. Second joystick button is pressed. Third joystick button is pressed. Four joystick button is pressed. Joystick has z-coordinate information. Joystick has rudder (fourth axis) information. Joystick has u-coordinate (fifth axis) information. Joystick has v-coordinate (sixth axis) information. Joystick has point-of-view information. Joystick point-of-view supports discrete values (centered, forward, backward, left, and right). Joystick point-of-view supports continuous degree bearings. The PlaySound function plays a sound specified by the given filename, resource, or system event. (A system event may be associated with a sound in the registry or in the WIN.INI file.) A string that specifies the sound to play. If this parameter is NULL, any currently playing waveform sound is stopped. To stop a non-waveform sound, specify in the soundFlags parameter. Three flags in soundFlags (, , and ) determine whether the name is interpreted as an alias for a system event, a filename, or a resource identifier. If none of these flags are specified, PlaySound searches the registry or the WIN.INI file for an association with the specified sound name. If an association is found, the sound event is played. If no association is found in the registry, the name is interpreted as a filename. Handle to the executable file that contains the resource to be loaded. This parameter must be NULL unless is specified in soundFlags. Flags for playing the sound. The following values are defined: Value Description The sound is played using an application-specific association. The sound parameter is a system-event alias in the registry or the WIN.INI file. Do not use with either or . The sound parameter is a predefined sound identifier. The sound is played asynchronously and PlaySound returns immediately after beginning the sound. To terminate an asynchronously played waveform sound, call PlaySound with sound set to NULL. The sound parameter is a filename. The sound plays repeatedly until PlaySound is called again with the sound parameter set to NULL. You must also specify the flag to indicate an asynchronous sound event. A sound event's file is loaded in RAM. The parameter specified by sound must point to an image of a sound in memory. No default sound event is used. If the sound cannot be found, PlaySound returns silently without playing the default sound. The specified sound event will yield to another sound event that is already playing. If a sound cannot be played because the resource needed to generate that sound is busy playing another sound, the function immediately returns FALSE without playing the requested sound. If this flag is not specified, PlaySound attempts to stop the currently playing sound so that the device can be used to play the new sound. If the driver is busy, return immediately without playing the sound. Sounds are to be stopped for the calling task. If sound is not NULL, all instances of the specified sound are stopped. If sound is NULL, all sounds that are playing on behalf of the calling task are stopped. You must also specify the instance handle to stop events. The sound parameter is a resource identifier; mod must identify the instance that contains the resource. Synchronous playback of a sound event. PlaySound returns after the sound event completes. Returns TRUE if successful or FALSE otherwise. The sound specified by sound must fit into available physical memory and be playable by an installed waveform-audio device driver. PlaySound searches the following directories for sound files: the current directory; the Windows directory; the Windows system directory; directories listed in the PATH environment variable; and the list of directories mapped in a network. For more information about the directory search order, see the documentation for the OpenFile function. If it cannot find the specified sound, PlaySound uses the default system event sound entry instead. If the function can find neither the system default entry nor the default sound, it makes no sound and returns FALSE. The timeBeginPeriod function sets the minimum timer resolution for an application or device driver. Minimum timer resolution, in milliseconds, for the application or device driver. Returns if successful or if the resolution specified in period is out of range. Call this function immediately before using timer services, and call the function immediately after you are finished using the timer services. You must match each call to timeBeginPeriod with a call to , specifying the same minimum resolution in both calls. An application can make multiple timeBeginPeriod calls as long as each call is matched with a call to . The timeEndPeriod function clears a previously set minimum timer resolution. Minimum timer resolution specified in the previous call to the function. Returns if successful or if the resolution specified in period is out of range Call this function immediately after you are finished using timer services. You must match each call to with a call to timeEndPeriod, specifying the same minimum resolution in both calls. An application can make multiple calls as long as each call is matched with a call to timeEndPeriod. The timeGetTime function retrieves the system time, in milliseconds. The system time is the time elapsed since Windows was started. Returns the system time, in milliseconds. The only difference between this function and the timeGetSystemTime function is that timeGetSystemTime uses the MMTIME structure to return the system time. The timeGetTime function has less overhead than timeGetSystemTime. Note that the value returned by the timeGetTime function is a DWORD value. The return value wraps around to 0 every 2^32 milliseconds, which is about 49.71 days. This can cause problems in code that directly uses the timeGetTime return value in computations, particularly where the value is used to control code execution. You should always use the difference between two timeGetTime return values in computations. Windows NT/2000: The default precision of the timeGetTime function can be five milliseconds or more, depending on the machine. You can use the and functions to increase the precision of timeGetTime. If you do so, the minimum difference between successive values returned by timeGetTime can be as large as the minimum period value set using and . Use the and functions to measure short time intervals at a high resolution. Windows 95: The default precision of the timeGetTime function is 1 millisecond. In other words, the timeGetTime function can return successive values that differ by just 1 millisecond. This is true no matter what calls have been made to the timeBeginPeriod and timeEndPeriod functions. The joyConfigChanged function informs the joystick driver that the configuration has changed and should be reloaded from the registry. Reserved for future use. Must equal zero. Returns JOYERR_NOERROR if successful. Returns JOYERR_PARMS if the parameter is non-zero. This function causes a window message to be sent to all top-level windows. This message may be defined by applications that need to respond to changes in joystick calibration by using RegisterWindowMessage with the following message ID: #define JOY_CONFIGCHANGED_MSGSTRING "MSJSTICK_VJOYD_MSGSTR" The joyGetDevCaps function queries a joystick to determine its capabilities. Identifier of the joystick to be queried. Valid values for uJoyID range from -1 to 15. A value of -1 enables retrieval of the szRegKey member of the JOYCAPS structure whether a device is present or not. For Windows NT 4.0, valid values are limited to zero (JOYSTICKID1) and JOYSTICKID2. Pointer to a structure to contain the capabilities of the joystick. Size, in bytes, of the JOYCAPS structure. Returns JOYERR_NOERROR if successful or one of the following error values: - The joystick driver is not present. Windows NT/2000/XP: The specified joystick identifier is invalid. - An invalid parameter was passed. Windows 95/98/Me: The specified joystick identifier is invalid. Use the function to determine the number of joystick devices supported by the driver. Windows NT/2000/XP: This method fails when passed an invalid value for the cbjc parameter. Windows 95/98/Me: This method succeeds when passed an invalid value for the cbjc parameter. The joyGetNumDevs function queries the joystick driver for the number of joysticks it supports. The joyGetNumDevs function returns the number of joysticks supported by the current driver or zero if no driver is installed. Use the function to determine whether a given joystick is physically attached to the system. If the specified joystick is not connected, joyGetPos returns a error value. The joyGetPos function queries a joystick for its position and button status. Identifier of the joystick to be queried. Valid values for uJoyID range from zero () to 15, except for Windows NT 4.0. For Windows NT 4.0, valid values are limited to and . Pointer to a structure that contains the position and button status of the joystick. Returns if successful or one of the following error values. - The joystick driver is not present. - An invalid parameter was passed. - The specified joystick is not connected to the system. For devices that have four to six axes of movement, a point-of-view control, or more than four buttons, use the function. The joyGetPosEx function queries a joystick for its position and button status. Identifier of the joystick to be queried. Valid values for uJoyID range from zero () to 15, except for Windows NT 4.0. For Windows NT 4.0, valid values are limited to and . Pointer to a structure that contains extended position information and button status of the joystick. You must set the dwSize and dwFlags members or joyGetPosEx will fail. The information returned from joyGetPosEx depends on the flags you specify in dwFlags. Returns JOYERR_NOERROR if successful or one of the following error values. Returns JOYERR_NOERROR if successful or one of the following error values. - The joystick driver is not present. - An invalid parameter was passed. Windows 95/98/Me: The specified joystick identifier is invalid. - Windows 95/98/Me: The specified joystick identifier is invalid. - The specified joystick is not connected to the system. - Windows NT/2000/XP: The specified joystick identifier is invalid. This function provides access to extended devices such as rudder pedals, point-of-view hats, devices with a large number of buttons, and coordinate systems using up to six axes. For joystick devices that use three axes or fewer and have fewer than four buttons, use the joyGetPos function. The joyGetThreshold function queries a joystick for its current movement threshold. Identifier of the joystick. Valid values for uJoyID range from zero () to 15, except for Windows NT 4.0. For Windows NT 4.0, valid values are limited to and . Pointer to a variable that contains the movement threshold value. Returns JOYERR_NOERROR if successful or one of the following error values. - The joystick driver is not present. - An invalid parameter was passed. The movement threshold is the distance the joystick must be moved before a joystick position-change message (, , , or ) is sent to a window that has captured the device. The threshold is initially zero. The joyReleaseCapture function releases the specified captured joystick. Identifier of the joystick. Valid values for uJoyID range from zero () to 15, except for Windows NT 4.0. For Windows NT 4.0, valid values are limited to and . Returns if successful or one of the following error values. - The joystick driver is not present. - Windows 95/98/Me: The specified joystick device identifier uJoyID is invalid. Windows NT/2000/XP: The specified joystick identifier is valid, but the joystick has not been captured. - Windows NT/2000/XP: The specified joystick device identifier uJoyID is invalid. Windows 95/98/Me: This method returns JOYERR_NOERROR when passed a valid joystick identifier that has not been captured. The joySetCature function captures a joystick by causing its messages to be sent to the specified window. Handle to the window to receive the joystick messages. Identifier of the joystick. Valid values for uJoyID range from zero () to 15, except for Windows NT 4.0. For Windows NT 4.0, valid values are limited to and . Polling frequency, in milliseconds. Change position flag. Specify TRUE for this parameter to send messages only when the position changes by a value greater than the joystick movement threshold. Otherwise, messages are sent at the polling frequency specified in uPeriod. Returns JOYERR_NOERROR if successful or one of the following error values. - The joystick driver is not present. - Windows 95/98/Me: Invalid joystick ID or hwnd is NULL. - Cannot capture joystick input because a required service (such as a Windows timer) is unavailable. - The specified joystick is not connected to the system. - Windows NT/2000/XP: Invalid joystick ID or hwnd is NULL. This function fails if the specified joystick is currently captured. Call the joyReleaseCapture function to release the captured joystick, or destroy the window to release the joystick automatically. The joySetThreshold function sets the movement threshold of a joystick. Identifier of the joystick. Valid values for uJoyID range from zero () to 15, except for Windows NT 4.0. For Windows NT 4.0, valid values are limited to and . New movement threshold. Returns JOYERR_NOERROR if successful or one of the following error values. - The joystick driver is not present. - The specified joystick device identifier uJoyID is invalid. The movement threshold is the distance the joystick must be moved before a joystick position-change message (, , , or ) is sent to a window that has captured the device. The threshold is initially zero. The JOYCAPS structure contains information about the joystick capabilities. Requirements Windows NT/2000/XP: Included in Windows NT 3.1 and later. Windows 95/98/Me: Included in Windows 95 and later. Header: Declared in Mmsystem.h; include Windows.h. Unicode: Declared as Unicode and ANSI structures. Manufacturer identifier. Manufacturer identifiers are defined in Manufacturer and Product Identifiers. Product identifier. Product identifiers are defined in Manufacturer and Product Identifiers. Null-terminated string containing the joystick product name. Minimum X-coordinate. Maximum X-coordinate. Minimum Y-coordinate. Maximum Y-coordinate. Minimum Z-coordinate. Maximum Z-coordinate. Number of joystick buttons. Smallest polling frequency supported when captured by the function. Largest polling frequency supported when captured by . Minimum rudder value. The rudder is a fourth axis of movement. Maximum rudder value. The rudder is a fourth axis of movement. Minimum u-coordinate (fifth axis) values. Maximum u-coordinate (fifth axis) values. Minimum v-coordinate (sixth axis) values. Maximum v-coordinate (sixth axis) values. Joystick capabilities The following flags define individual capabilities that a joystick might have: - Joystick has z-coordinate information. - Joystick has rudder (fourth axis) information. - Joystick has u-coordinate (fifth axis) information. - Joystick has v-coordinate (sixth axis) information. - Joystick has point-of-view information. - Joystick point-of-view supports discrete values (centered, forward, backward, left, and right). - Joystick point-of-view supports continuous degree bearings. Maximum number of axes supported by the joystick. Number of axes currently in use by the joystick. Maximum number of buttons supported by the joystick. Null-terminated string containing the registry key for the joystick. Null-terminated string identifying the joystick driver OEM. The JOYINFO structure contains information about the joystick position and button state. Requirements Windows NT/2000/XP: Included in Windows NT 3.1 and later. Windows 95/98/Me: Included in Windows 95 and later. Header: Declared in Mmsystem.h; include Windows.h. Current X-coordinate. Current Y-coordinate. Current Z-coordinate. Current state of joystick buttons. According to one or more of the following values: - First joystick button is pressed. - Second joystick button is pressed. - Third joystick button is pressed. - Fourth joystick button is pressed. The JOYINFOEX structure contains extended information about the joystick position, point-of-view position, and button state. The value of the dwSize member is also used to identify the version number for the structure when it's passed to the function. Most devices with a point-of-view control have only five positions. When the JOY_RETURNPOV flag is set, these positions are reported by using the following constants: - Point-of-view hat is pressed backward. The value 18,000 represents an orientation of 180.00 degrees (to the rear). - Point-of-view hat is in the neutral position. The value -1 means the point-of-view hat has no angle to report. - Point-of-view hat is pressed forward. The value 0 represents an orientation of 0.00 degrees (straight ahead). - Point-of-view hat is being pressed to the left. The value 27,000 represents an orientation of 270.00 degrees (90.00 degrees to the left). - Point-of-view hat is pressed to the right. The value 9,000 represents an orientation of 90.00 degrees (to the right). The default joystick driver currently supports these five discrete directions. If an application can accept only the defined point-of-view values, it must use the JOY_RETURNPOV flag. If an application can accept other degree readings, it should use the JOY_RETURNPOVCTS flag to obtain continuous data if it is available. The JOY_RETURNPOVCTS flag also supports the JOY_POV constants used with the JOY_RETURNPOV flag. Size, in bytes, of this structure. Flags indicating the valid information returned in this structure. Members that do not contain valid information are set to zero. - Equivalent to setting all of the JOY_RETURN bits except JOY_RETURNRAWDATA. - The dwButtons member contains valid information about the state of each joystick button. - Centers the joystick neutral position to the middle value of each axis of movement. - The dwPOV member contains valid information about the point-of-view control, expressed in discrete units. - The dwPOV member contains valid information about the point-of-view control expressed in continuous, one-hundredth degree units. - The dwRpos member contains valid rudder pedal data. This information represents another (fourth) axis. - Data stored in this structure is uncalibrated joystick readings. - The dwUpos member contains valid data for a fifth axis of the joystick, if such an axis is available, or returns zero otherwise. - The dwVpos member contains valid data for a sixth axis of the joystick, if such an axis is available, or returns zero otherwise. - The dwXpos member contains valid data for the x-coordinate of the joystick. - The dwYpos member contains valid data for the y-coordinate of the joystick. - The dwZpos member contains valid data for the z-coordinate of the joystick. - Expands the range for the neutral position of the joystick and calls this range the dead zone. The joystick driver returns a constant value for all positions in the dead zone. The following flags provide data to calibrate a joystick and are intended for custom calibration applications. - Read the x-, y-, and z-coordinates and store the raw values in dwXpos, dwYpos, and dwZpos. - Read the rudder information and the x-, y-, and z-coordinates and store the raw values in dwXpos, dwYpos, dwZpos, and dwRpos. - Read the rudder information and the x-, y-, z-, and u-coordinates and store the raw values in dwXpos, dwYpos, dwZpos, dwRpos, and dwUpos. - Read the raw v-axis data if a joystick mini driver is present that will provide the data. Returns zero otherwise. - Read the joystick port even if the driver does not detect a device. - Read the rudder information if a joystick mini-driver is present that will provide the data and store the raw value in dwRpos. Return zero otherwise. - Read the x-coordinate and store the raw (uncalibrated) value in dwXpos. - Reads the x- and y-coordinates and place the raw values in dwXpos and dwYpos. - Reads the y-coordinate and store the raw value in dwYpos. - Read the z-coordinate and store the raw value in dwZpos. - Read the u-coordinate if a joystick mini-driver is present that will provide the data and store the raw value in dwUpos. Return zero otherwise. - Read the v-coordinate if a joystick mini-driver is present that will provide the data and store the raw value in dwVpos. Return zero otherwise. Current X-coordinate. Current Y-coordinate. Current Z-coordinate. Current position of the rudder or fourth joystick axis. Current fifth axis position. Current sixth axis position. Current state of the 32 joystick buttons. The value of this member can be set to any combination of JOY_BUTTONn flags, where n is a value in the range of 1 through 32 corresponding to the button that is pressed. Current button number that is pressed. Current position of the point-of-view control. Values for this member are in the range 0 through 35,900. These values represent the angle, in degrees, of each view multiplied by 100. Reserved; do not use. Reserved; do not use. User binding for .NET, implementing Windows-specific user functionality. Binds functions and definitions in user32.dll. Specifies User32's native library archive. Specifies user32.dll for Windows. Specifies the calling convention. Specifies . The ChangeDisplaySettings function changes the settings of the default display device to the specified graphics mode. To change the settings of a specified display device, use the ChangeDisplaySettingsEx function. Pointer to a structure that describes the new graphics mode. If devMode is NULL, all the values currently in the registry will be used for the display setting. Passing NULL for the devMode parameter and 0 for the flags parameter is the easiest way to return to the default mode after a dynamic mode change. The member of must be initialized to the size, in bytes, of the structure. The member of must be initialized to indicate the number of bytes of private driver data following the structure. In addition, you can use any or all of the following members of the structure: Value Description Bits per pixel. Pixel width. Pixel height. Mode flags. Mode frequency. dmPosition Windows 98/Me, Windows 2000/XP: Position of the device in a multimonitor configuration. In addition to using one or more of the preceding members, you must also set one or more of the following values in the member to change the display setting: Value Description Use the value. Use the value. Use the value. Use the value. Use the value. see cref="Gdi.DM_POSITION" Windows 98/Me, Windows 2000/XP: Use the dmPosition value. Indicates how the graphics mode should be changed. This parameter can be one of the following values: Value Description 0 The graphics mode for the current screen will be changed dynamically. see cref="Gdi.CDS_FULLSCREEN" The mode is temporary in nature. Windows NT/2000/XP: If you change to and from another desktop, this mode will not be reset. see cref="Gdi.CDS_GLOBAL" The settings will be saved in the global settings area so that they will affect all users on the machine. Otherwise, only the settings for the user are modified. This flag is only valid when specified with the see cref="Gdi.CDS_UPDATEREGISTRY" flag. see cref="Gdi.CDS_NORESET" The settings will be saved in the registry, but will not take affect. This flag is only valid when specified with the see cref="Gdi.CDS_UPDATEREGISTRY" flag. see cref="Gdi.CDS_RESET" The settings should be changed, even if the requested settings are the same as the current settings. see cref="Gdi.CDS_SET_PRIMARY" This device will become the primary device. see cref="Gdi.CDS_TEST" The system tests if the requested graphics mode could be set. see cref="Gdi.CDS_UPDATEREGISTRY" The graphics mode for the current screen will be changed dynamically and the graphics mode will be updated in the registry. The mode information is stored in the USER profile. Specifying see cref="Gdi.CDS_TEST" allows an application to determine which graphics modes are actually valid, without causing the system to change to that graphics mode. If see cref="Gdi.CDS_UPDATEREGISTRY" is specified and it is possible to change the graphics mode dynamically, the information is stored in the registry and see cref="Gdi.DISP_CHANGE_SUCCESSFUL" is returned. If it is not possible to change the graphics mode dynamically, the information is stored in the registry and see cref="Gdi.DISP_CHANGE_RESTART" is returned. Windows NT/2000/XP: If see cref="Gdi.CDS_UPDATEREGISTRY" is specified and the information could not be stored in the registry, the graphics mode is not changed and see cref="Gdi.DISP_CHANGE_NOTUPDATED" is returned. The ChangeDisplaySettings function returns one of the following values: Value Description see cref="Gdi.DISP_CHANGE_SUCCESSFUL" The settings change was successful. see cref="Gdi.DISP_CHANGE_BADDUALVIEW" Windows XP: The settings change was unsuccessful because system is DualView capable. see cref="Gdi.DISP_CHANGE_BADFLAGS" An invalid set of flags was passed in. see cref="Gdi.DISP_CHANGE_BADMODE" The graphics mode is not supported. see cref="Gdi.DISP_CHANGE_BADPARAM" An invalid parameter was passed in. This can include an invalid flag or combination of flags. see cref="Gdi.DISP_CHANGE_FAILED" The display driver failed the specified graphics mode. see cref="Gdi.DISP_CHANGE_NOTUPDATED" Windows NT/2000/XP: Unable to write settings to the registry. see cref="Gdi.DISP_CHANGE_RESTART" The computer must be restarted in order for the graphics mode to work. To ensure that the structure passed to ChangeDisplaySettings is valid and contains only values supported by the display driver, use the returned by the function. When the display mode is changed dynamically, the WM_DISPLAYCHANGE message is sent to all running applications with the following message parameters: Value Description wParam New bits per pixel. LOWORD(lParam) New pixel width. HIWORD(lParam) New pixel height. Windows 95/98/Me: If the calling thread has any windows, ChangeDisplaySettings sends them the WM_DISPLAYCHANGE message immediately (for windows in all other threads, the message is sent when the thread can receive nonqueued messages). This may cause the shell to get its message too soon and could squash icons. To avoid this problem, have ChangeDisplaySettings do resolution switching by calling on a thread with no windows, for example, a new thread. seealso cref="CreateDC" The ChangeDisplaySettings function changes the settings of the default display device to the specified graphics mode. To change the settings of a specified display device, use the ChangeDisplaySettingsEx function. Pointer to a structure that describes the new graphics mode. If devMode is NULL, all the values currently in the registry will be used for the display setting. Passing NULL for the devMode parameter and 0 for the flags parameter is the easiest way to return to the default mode after a dynamic mode change. The member of must be initialized to the size, in bytes, of the structure. The member of must be initialized to indicate the number of bytes of private driver data following the structure. In addition, you can use any or all of the following members of the structure: Value Description Bits per pixel. Pixel width. Pixel height. Mode flags. Mode frequency. dmPosition Windows 98/Me, Windows 2000/XP: Position of the device in a multimonitor configuration. In addition to using one or more of the preceding members, you must also set one or more of the following values in the member to change the display setting: Value Description Use the value. Use the value. Use the value. Use the value. Use the value. see cref="Gdi.DM_POSITION" /> Windows 98/Me, Windows 2000/XP: Use the dmPosition value. Indicates how the graphics mode should be changed. This parameter can be one of the following values: Value Description 0 The graphics mode for the current screen will be changed dynamically. see cref="Gdi.CDS_FULLSCREEN" The mode is temporary in nature. Windows NT/2000/XP: If you change to and from another desktop, this mode will not be reset. see cref="Gdi.CDS_GLOBAL" The settings will be saved in the global settings area so that they will affect all users on the machine. Otherwise, only the settings for the user are modified. This flag is only valid when specified with the see cref="Gdi.CDS_UPDATEREGISTRY" flag. see cref="Gdi.CDS_NORESET" The settings will be saved in the registry, but will not take affect. This flag is only valid when specified with the see cref="Gdi.CDS_UPDATEREGISTRY" flag. see cref="Gdi.CDS_RESET" The settings should be changed, even if the requested settings are the same as the current settings. see cref="Gdi.CDS_SET_PRIMARY" This device will become the primary device. see cref="Gdi.CDS_TEST" /> The system tests if the requested graphics mode could be set. see cref="Gdi.CDS_UPDATEREGISTRY" /> The graphics mode for the current screen will be changed dynamically and the graphics mode will be updated in the registry. The mode information is stored in the USER profile. Specifying see cref="Gdi.CDS_TEST" /> allows an application to determine which graphics modes are actually valid, without causing the system to change to that graphics mode. If see cref="Gdi.CDS_UPDATEREGISTRY" /> is specified and it is possible to change the graphics mode dynamically, the information is stored in the registry and see cref="Gdi.DISP_CHANGE_SUCCESSFUL" /> is returned. If it is not possible to change the graphics mode dynamically, the information is stored in the registry and see cref="Gdi.DISP_CHANGE_RESTART" /> is returned. Windows NT/2000/XP: If see cref="Gdi.CDS_UPDATEREGISTRY" /> is specified and the information could not be stored in the registry, the graphics mode is not changed and see cref="Gdi.DISP_CHANGE_NOTUPDATED" /> is returned. The ChangeDisplaySettings function returns one of the following values: Value Description see cref="Gdi.DISP_CHANGE_SUCCESSFUL" /> The settings change was successful. see cref="Gdi.DISP_CHANGE_BADDUALVIEW" /> Windows XP: The settings change was unsuccessful because system is DualView capable. see cref="Gdi.DISP_CHANGE_BADFLAGS" /> An invalid set of flags was passed in. see cref="Gdi.DISP_CHANGE_BADMODE" The graphics mode is not supported. see cref="Gdi.DISP_CHANGE_BADPARAM" An invalid parameter was passed in. This can include an invalid flag or combination of flags. see cref="Gdi.DISP_CHANGE_FAILED" /> The display driver failed the specified graphics mode. see cref="Gdi.DISP_CHANGE_NOTUPDATED" /> Windows NT/2000/XP: Unable to write settings to the registry. see cref="Gdi.DISP_CHANGE_RESTART" /> The computer must be restarted in order for the graphics mode to work. To ensure that the structure passed to ChangeDisplaySettings is valid and contains only values supported by the display driver, use the returned by the function. When the display mode is changed dynamically, the WM_DISPLAYCHANGE message is sent to all running applications with the following message parameters: Value Description wParam New bits per pixel. LOWORD(lParam) New pixel width. HIWORD(lParam) New pixel height. Windows 95/98/Me: If the calling thread has any windows, ChangeDisplaySettings sends them the WM_DISPLAYCHANGE message immediately (for windows in all other threads, the message is sent when the thread can receive nonqueued messages). This may cause the shell to get its message too soon and could squash icons. To avoid this problem, have ChangeDisplaySettings do resolution switching by calling on a thread with no windows, for example, a new thread. seealso cref="CreateDC" /> The GetDC function retrieves a handle to a display device context (DC) for the client area of a specified window or for the entire screen. You can use the returned handle in subsequent GDI functions to draw in the DC. The see cref="GetDCEx" /> function is an extension to GetDC, which gives an application more control over how and whether clipping occurs in the client area. Handle to the window whose DC is to be retrieved. If this value is null, GetDC retrieves the DC for the entire screen. Windows 98/Me, Windows 2000/XP: To get the DC for a specific display monitor, use the see cref="EnumDisplayMonitors" /> and see cref="Gdi.CreateDC" /> functions. If the function succeeds, the return value is a handle to the DC for the specified window's client area. If the function fails, the return value is null. Windows NT/2000/XP: To get extended error information, call . The GetDC function retrieves a common, class, or private DC depending on the class style of the specified window. For class and private DCs, GetDC leaves the previously assigned attributes unchanged. However, for common DCs, GetDC assigns default attributes to the DC each time it is retrieved. For example, the default font is System, which is a bitmap font. Because of this, the handle for a common DC returned by GetDC does not tell you what font, color, or brush was used when the window was drawn. To determine the font, call see cref="GetTextFace" />. Note that the handle to the DC can only be used by a single thread at any one time. After painting with a common DC, the function must be called to release the DC. Class and private DCs do not have to be released. must be called from the same thread that called GetDC. The number of DCs is limited only by available memory. Windows 95/98/Me: There are only 5 common DCs available per thread, thus failure to release a DC can prevent other applications from accessing one. seealso cref="GetDCEx" /> seealso cref="GetTextFace" /> seealso cref="GetWindowDC" /> The ReleaseDC function releases a device context (DC), freeing it for use by other applications. The effect of the ReleaseDC function depends on the type of DC. It frees only common and window DCs. It has no effect on class or private DCs. Handle to the window whose DC is to be released. Handle to the DC to be released. The return value indicates whether the DC was released. If the DC was released, the return value is true. If the DC was not released, the return value is false. The application must call the ReleaseDC function for each call to the see cref="GetWindowDC" /> function and for each call to the function that retrieves a common DC. An application cannot use the ReleaseDC function to release a DC that was created by calling the see cref="Gdi.CreateDC" /> function; instead, it must use the see cref="Gdi.DeleteDC" /> function. ReleaseDC must be called from the same thread that called GetDC. seealso cref="Gdi.CreateDC" /> seealso cref="Gdi.DeleteDC" /> seealso cref="GetWindowDC" /> Provides a simple OpenGL control allowing quick development of Windows Forms-based OpenGL applications. Constructor. Creates contexts and sets properties. Disposes the control. Was the disposed manually called? Loads the bitmap from the assembly's manifest resource. Required for designer support. Initializes the control's styles. Sends an see cref="UserControl.Invalidate" command to this control, thus forcing a redraw to occur. Creates the OpenGL contexts. Paints the control. The paint event arguments. Paints the background. Gets the number of logical pixels or dots per inch (dpi) in X-direction Gets the number of logical pixels or dots per inch (dpi) in Y-direction Gets and sets the OpenGL control's accumulation buffer depth. Gets and sets the OpenGL control's color buffer depth. Gets and sets the OpenGL control's depth buffer (Z-buffer) depth. Gets and sets the OpenGL control's stencil buffer depth. Gets and sets the OpenGL control's automatic sending of a glGetError command after drawing. Gets and sets the OpenGL control's automatic sending of a glFinish command after drawing. Gets and sets the OpenGL control's automatic forcing of the rendering context to be current before drawing. Gets and sets the OpenGL control's automatic sending of a SwapBuffers command after drawing. Overrides the control's class style parameters. GDI binding for .NET, implementing Windows-specific GDI functionality. Binds functions and definitions in gdi32.dll. Specifies GDI's native library archive. Specifies gdi32.dll for Windows. Specifies the calling convention. Specifies . RGBA pixels. Each pixel has four components: red, green, blue, and alpha. Color-index pixels. Each pixel uses a color-index value. The layer plane is double-buffered. A layer plane can be double-buffered even when the main plane is single-buffered and vice versa. The layer plane is stereoscopic. A layer plane can be stereoscopic even when the main plane is monoscopic and vice versa. The layer plane supports GDI drawing. The current implementation of OpenGL doesn't support this flag. The layer plane supports OpenGL drawing. The layer plane shares the depth buffer with the main plane. The layer plane shares the stencil buffer with the main plane. The layer plane shares the accumulation buffer with the main plane. In a double-buffered layer plane, swapping the color buffer exchanges the front buffer and back buffer contents. The back buffer then contains the contents of the front buffer before the swap. This flag is a hint only and might not be provided by a driver. In a double-buffered layer plane, swapping the color buffer copies the back buffer contents to the front buffer. The swap does not affect the back buffer contents. This flag is a hint only and might not be provided by a driver. Contains a transparent color or index value that enables underlying layers to show through this layer. All layer planes, except the lowest-numbered underlay layer, have a transparent color or index. RGBA pixels. Each pixel has four components in this order: red, green, blue, and alpha. Color-index pixels. Each pixel uses a color-index value. The layer is the main plane. The layer is the overlay plane. The layer is the underlay plane. The buffer is double-buffered. This flag and are mutually exclusive in the current generic implementation. The buffer is stereoscopic. This flag is not supported in the current generic implementation. The buffer can draw to a window or device surface. The buffer can draw to a memory bitmap. The buffer supports GDI drawing. This flag and are mutually exclusive in the current generic implementation. The buffer supports OpenGL drawing. The pixel format is supported by the GDI software implementation, which is also known as the generic implementation. If this bit is clear, the pixel format is supported by a device driver or hardware. The buffer uses RGBA pixels on a palette-managed device. A logical palette is required to achieve the best results for this pixel type. Colors in the palette should be specified according to the values of the cRedBits, cRedShift, cGreenBits, cGreenShift, cBluebits, and cBlueShift members. The palette should be created and realized in the device context before calling . Defined in the pixel format descriptors of hardware that supports one hardware palette in 256-color mode only. For such systems to use hardware acceleration, the hardware palette must be in a fixed order (for example, 3-3-2) when in RGBA mode or must match the logical palette when in color-index mode. When this flag is set, you must call see cref="SetSystemPaletteUse" /> in your program to force a one-to-one mapping of the logical palette and the system palette. If your OpenGL hardware supports multiple hardware palettes and the device driver can allocate spare hardware palettes for OpenGL, this flag is typically clear. This flag is not set in the generic pixel formats. Specifies the content of the back buffer in the double-buffered main color plane following a buffer swap. Swapping the color buffers causes the exchange of the back buffer's content with the front buffer's content. Following the swap, the back buffer's content contains the front buffer's content before the swap. PFD_SWAP_EXCHANGE is a hint only and might not be provided by a driver. Specifies the content of the back buffer in the double-buffered main color plane following a buffer swap. Swapping the color buffers causes the content of the back buffer to be copied to the front buffer. The content of the back buffer is not affected by the swap. PFD_SWAP_COPY is a hint only and might not be provided by a driver. Indicates whether a device can swap individual layer planes with pixel formats that include double-buffered overlay or underlay planes. Otherwise all layer planes are swapped together as a group. When this flag is set, is supported. The pixel format is supported by a device driver that accelerates the generic implementation. If this flag is clear and the flag is set, the pixel format is supported by the generic implementation only. The buffer supports DirectDraw drawing. The requested pixel format can either have or not have a depth buffer. To select a pixel format without a depth buffer, you must specify this flag. The requested pixel format can be with or without a depth buffer. Otherwise, only pixel formats with a depth buffer are considered. The requested pixel format can be either single- or double-buffered. The requested pixel format can be either monoscopic or stereoscopic. The ChoosePixelFormat function attempts to match an appropriate pixel format supported by a device context to a given pixel format specification. Specifies the device context that the function examines to determine the best match for the pixel format descriptor pointed to by ppfd. Pointer to a structure that specifies the requested pixel format. In this context, the members of the PIXELFORMATDESCRIPTOR structure that ppfd points to are used as follows: nSize
Specifies the size of the PIXELFORMATDESCRIPTOR data structure. Set this member to sizeof(PIXELFORMATDESCRIPTOR). nVersion
Specifies the version number of the PIXELFORMATDESCRIPTOR data structure. Set this member to 1. dwFlags
A set of bit flags that specify properties of the pixel buffer. You can combine the following bit flag constants by using bitwise-OR.

If any of the following flags are set, the ChoosePixelFormat function attempts to match pixel formats that also have that flag or flags set. Otherwise, ChoosePixelFormat ignores that flag in the pixel formats:

PFD_DRAW_TO_WINDOW
PFD_DRAW_TO_BITMAP
PFD_SUPPORT_GDI
PFD_SUPPORT_OPENGL

If any of the following flags are set, ChoosePixelFormat attempts to match pixel formats that also have that flag or flags set. Otherwise, it attempts to match pixel formats without that flag set:

PFD_DOUBLEBUFFER
PFD_STEREO

If the following flag is set, the function ignores the PFD_DOUBLEBUFFER flag in the pixel formats:

PFD_DOUBLEBUFFER_DONTCARE

If the following flag is set, the function ignores the PFD_STEREO flag in the pixel formats:

PFD_STEREO_DONTCARE
 iPixelType
Specifies the type of pixel format for the function to consider:

PFD_TYPE_RGBA
PFD_TYPE_COLORINDEX
 cColorBits
Zero or greater. cRedBits
Not used. cRedShift
Not used. cGreenBits
Not used. cGreenShift
Not used. cBlueBits
Not used. cBlueShift
Not used. cAlphaBits
Zero or greater. cAlphaShift
Not used. cAccumBits
Zero or greater. cAccumRedBits
Not used. cAccumGreenBits
Not used. cAccumBlueBits
Not used. cAccumAlphaBits
Not used. cDepthBits
Zero or greater. cStencilBits
Zero or greater. cAuxBuffers
Zero or greater. iLayerType
Specifies one of the following layer type values:

PFD_MAIN_PLANE
PFD_OVERLAY_PLANE
PFD_UNDERLAY_PLANE
 bReserved
Not used. dwLayerMask
Not used. dwVisibleMask
Not used. dwDamageMask
Not used. If the function succeeds, the return value is a pixel format index (one-based) that is the closest match to the given pixel format descriptor.

If the function fails, the return value is zero. To get extended error information, call see cref="Kernel.GetLastError" />. You must ensure that the pixel format matched by the ChoosePixelFormat function satisfies your requirements. For example, if you request a pixel format with a 24-bit RGB color buffer but the device context offers only 8-bit RGB color buffers, the function returns a pixel format with an 8-bit RGB color buffer.

The following code sample shows how to use ChoosePixelFormat to match a specified pixel format:

HDC hdc; int pixelFormat; Gdi.PIXELFORMATDESCRIPTOR pfd; // size of this pfd pfd.nSize = (ushort) sizeof(Gdi.PIXELFORMATDESCRIPTOR); // version number pfd.nVersion = 1; // support window, support OpenGL, double buffered pfd.dwFlags = Gdi.PFD_DRAW_TO_WINDOW | Gdi.PFD_SUPPORT_OPENGL | Gdi.PFD_DOUBLEBUFFER; // RGBA type pfd.iPixelType = Gdi.PFD_TYPE_RGBA; // 24-bit color depth pfd.cColorBits = 24; // color bits and shift bits ignored pfd.cRedBits = 0; pfd.cRedShift = 0; pfd.cGreenBits = 0; pfd.cGreenShift = 0; pfd.cBlueBits = 0; pfd.cBlueShift = 0; pfd.cAlphaBits = 0; pfd.cAlphaShift = 0; // no accumulation buffer, accum bits ignored pfd.cAccumBits = 0; pfd.cAccumRedBits = 0; pfd.cAccumGreenBits = 0; pfd.cAccumBlueBits = 0; pfd.cAccumAlphaBits = 0; // no stencil buffer pfd.cStencilBits = 0; // no auxiliary buffer pfd.cAuxBuffers = 0; // main layer pfd.iLayerType = Gdi.PFD_MAIN_PLANE; // reserved pfd.bReserved = 0; // layer masks ignored pfd.dwLayerMask = 0; pfd.dwVisibleMask = 0; pfd.dwDamageMask = 0; pixelFormat = Gdi.ChoosePixelFormat(hdc, &pfd); seealso cref="DescribePixelFormat" /> seealso cref="GetPixelFormat" /> The SetPixelFormat function sets the pixel format of the specified device context to the format specified by the iPixelFormat index. Specifies the device context whose pixel format the function attempts to set. Index that identifies the pixel format to set. The various pixel formats supported by a device context are identified by one-based indexes. Pointer to a structure that contains the logical pixel format specification. The system's metafile component uses this structure to record the logical pixel format specification. The structure has no other effect upon the behavior of the SetPixelFormat function. If the function succeeds, the return value is true.

If the function fails, the return value is false. To get extended error information, call see cref="Kernel.GetLastError" />. If hdc references a window, calling the SetPixelFormat function also changes the pixel format of the window. Setting the pixel format of a window more than once can lead to significant complications for the Window Manager and for multithread applications, so it is not allowed. An application can only set the pixel format of a window one time. Once a window's pixel format is set, it cannot be changed.

You should select a pixel format in the device context before calling the function. The wglCreateContext function creates a rendering context for drawing on the device in the selected pixel format of the device context.

An OpenGL window has its own pixel format. Because of this, only device contexts retrieved for the client area of an OpenGL window are allowed to draw into the window. As a result, an OpenGL window should be created with the WS_CLIPCHILDREN and WS_CLIPSIBLINGS styles. Additionally, the window class attribute should not include the CS_PARENTDC style.

The following code example shows SetPixelFormat usage:

HDC hdc; int pixelFormat; Gdi.PIXELFORMATDESCRIPTOR pfd; // size of this pfd pfd.nSize = (ushort) sizeof(Gdi.PIXELFORMATDESCRIPTOR); // version number pfd.nVersion = 1; // support window, support OpenGL, double buffered pfd.dwFlags = Gdi.PFD_DRAW_TO_WINDOW | Gdi.PFD_SUPPORT_OPENGL | Gdi.PFD_DOUBLEBUFFER; // RGBA type pfd.iPixelType = Gdi.PFD_TYPE_RGBA; // 24-bit color depth pfd.cColorBits = 24; // color bits and shift bits ignored pfd.cRedBits = 0; pfd.cRedShift = 0; pfd.cGreenBits = 0; pfd.cGreenShift = 0; pfd.cBlueBits = 0; pfd.cBlueShift = 0; pfd.cAlphaBits = 0; pfd.cAlphaShift = 0; // no accumulation buffer, accum bits ignored pfd.cAccumBits = 0; pfd.cAccumRedBits = 0; pfd.cAccumGreenBits = 0; pfd.cAccumBlueBits = 0; pfd.cAccumAlphaBits = 0; // no stencil buffer pfd.cStencilBits = 0; // no auxiliary buffer pfd.cAuxBuffers = 0; // main layer pfd.iLayerType = Gdi.PFD_MAIN_PLANE; // reserved pfd.bReserved = 0; // layer masks ignored pfd.dwLayerMask = 0; pfd.dwVisibleMask = 0; pfd.dwDamageMask = 0; pixelFormat = Gdi.ChoosePixelFormat(hdc, &pfd); // make that the pixel format of the device context Gdi.SetPixelFormat(hdc, pixelFormat, &pfd); seealso cref="DescribePixelFormat" /> seealso cref="GetPixelFormat" /> Retrieves device-specific information for the specified device. Handle to the DC Specifies the item to return The DEVMODE data structure contains information about the initialization and environment of a printer or a display device. A device driver's private data follows the public portion of the DEVMODE structure. The size of the public data can vary for different versions of the structure. The dmSize member specifies the number of bytes of public data, and the dmDriverExtra member specifies the number of bytes of private data. The GLYPHMETRICSFLOAT structure contains information about the placement and orientation of a glyph in a character cell. The values of GLYPHMETRICSFLOAT are specified as notional units. Specifies the width of the smallest rectangle (the glyph's black box) that completely encloses the glyph. Specifies the height of the smallest rectangle (the glyph's black box) that completely encloses the glyph. Specifies the x and y coordinates of the upper-left corner of the smallest rectangle that completely encloses the glyph. Specifies the horizontal distance from the origin of the current character cell to the origin of the next character cell. Specifies the vertical distance from the origin of the current character cell to the origin of the next character cell. The PIXELFORMATDESCRIPTOR structure describes the pixel format of a drawing surface. Please notice carefully, as documented in the members, that certain pixel format properties are not supported in the current generic implementation. The generic implementation is the Microsoft GDI software implementation of OpenGL. Hardware manufacturers may enhance parts of OpenGL, and may support some pixel format properties not supported by the generic implementation. seealso cref="DescribePixelFormat" /> seealso cref="GetPixelFormat" /> Specifies the size of this data structure. This value should be set to sizeof(PIXELFORMATDESCRIPTOR). Specifies the version of this data structure. This value should be set to 1. A set of bit flags that specify properties of the pixel buffer. The properties are generally not mutually exclusive; you can set any combination of bit flags, with the exceptions noted. The following bit flag constants are defined: Value Meaning PFD_DRAW_TO_WINDOW The buffer can draw to a window or device surface. PFD_DRAW_TO_BITMAP The buffer can draw to a memory bitmap. PFD_SUPPORT_GDI The buffer supports GDI drawing. This flag and PFD_DOUBLEBUFFER are mutually exclusive in the current generic implementation. PFD_SUPPORT_OPENGL The buffer supports OpenGL drawing. PFD_GENERIC_ACCELERATED The pixel format is supported by a device driver that accelerates the generic implementation. If this flag is clear and the PFD_GENERIC_FORMAT flag is set, the pixel format is supported by the generic implementation only. PFD_GENERIC_FORMAT The pixel format is supported by the GDI software implementation, which is also known as the generic implementation. If this bit is clear, the pixel format is supported by a device driver or hardware. PFD_NEED_PALETTE The buffer uses RGBA pixels on a palette-managed device. A logical palette is required to achieve the best results for this pixel type. Colors in the palette should be specified according to the values of the cRedBits, cRedShift, cGreenBits, cGreenShift, cBluebits, and cBlueShift members. The palette should be created and realized in the device context before calling . PFD_NEED_SYSTEM_PALETTE Defined in the pixel format descriptors of hardware that supports one hardware palette in 256-color mode only. For such systems to use hardware acceleration, the hardware palette must be in a fixed order (for example, 3-3-2) when in RGBA mode or must match the logical palette when in color-index mode. When this flag is set, you must call SetSystemPaletteUse in your program to force a one-to-one mapping of the logical palette and the system palette. If your OpenGL hardware supports multiple hardware palettes and the device driver can allocate spare hardware palettes for OpenGL, this flag is typically clear. This flag is not set in the generic pixel formats. PFD_DOUBLEBUFFER The buffer is double-buffered. This flag and PFD_SUPPORT_GDI are mutually exclusive in the current generic implementation. PFD_STEREO The buffer is stereoscopic. This flag is not supported in the current generic implementation. PFD_SWAP_LAYER_BUFFERS Indicates whether a device can swap individual layer planes with pixel formats that include double-buffered overlay or underlay planes. Otherwise all layer planes are swapped together as a group. When this flag is set, wglSwapLayerBuffers is supported. You can specify the following bit flags when calling . Value Meaning PFD_DEPTH_DONTCARE The requested pixel format can either have or not have a depth buffer. To select a pixel format without a depth buffer, you must specify this flag. The requested pixel format can be with or without a depth buffer. Otherwise, only pixel formats with a depth buffer are considered. PFD_DOUBLEBUFFER_DONTCARE The requested pixel format can be either single- or double-buffered. PFD_STEREO_DONTCARE The requested pixel format can be either monoscopic or stereoscopic. With the glAddSwapHintRectWIN extension function, two new flags are included for the PIXELFORMATDESCRIPTOR pixel format structure. Value Meaning PFD_SWAP_COPY Specifies the content of the back buffer in the double-buffered main color plane following a buffer swap. Swapping the color buffers causes the content of the back buffer to be copied to the front buffer. The content of the back buffer is not affected by the swap. PFD_SWAP_COPY is a hint only and might not be provided by a driver. PFD_SWAP_EXCHANGE Specifies the content of the back buffer in the double-buffered main color plane following a buffer swap. Swapping the color buffers causes the exchange of the back buffer's content with the front buffer's content. Following the swap, the back buffer's content contains the front buffer's content before the swap. PFD_SWAP_EXCHANGE is a hint only and might not be provided by a driver. Specifies the type of pixel data. The following types are defined. Value Meaning PFD_TYPE_RGBA RGBA pixels. Each pixel has four components in this order: red, green, blue, and alpha. PFD_TYPE_COLORINDEX Color-index pixels. Each pixel uses a color-index value. Specifies the number of color bitplanes in each color buffer. For RGBA pixel types, it is the size of the color buffer, excluding the alpha bitplanes. For color-index pixels, it is the size of the color-index buffer. Specifies the number of red bitplanes in each RGBA color buffer. Specifies the shift count for red bitplanes in each RGBA color buffer. Specifies the number of green bitplanes in each RGBA color buffer. Specifies the shift count for green bitplanes in each RGBA color buffer. Specifies the number of blue bitplanes in each RGBA color buffer. Specifies the shift count for blue bitplanes in each RGBA color buffer. Specifies the number of alpha bitplanes in each RGBA color buffer. Alpha bitplanes are not supported. Specifies the shift count for alpha bitplanes in each RGBA color buffer. Alpha bitplanes are not supported. Specifies the total number of bitplanes in the accumulation buffer. Specifies the number of red bitplanes in the accumulation buffer. Specifies the number of green bitplanes in the accumulation buffer. Specifies the number of blue bitplanes in the accumulation buffer. Specifies the number of alpha bitplanes in the accumulation buffer. Specifies the depth of the depth (z-axis) buffer. Specifies the depth of the stencil buffer. Specifies the number of auxiliary buffers. Auxiliary buffers are not supported. Ignored. Earlier implementations of OpenGL used this member, but it is no longer used. Specifies the type of layer. Specifies the number of overlay and underlay planes. Bits 0 through 3 specify up to 15 overlay planes and bits 4 through 7 specify up to 15 underlay planes. Ignored. Earlier implementations of OpenGL used this member, but it is no longer used. Specifies the layer mask. The layer mask is used in conjunction with the visible mask to determine if one layer overlays another. Specifies the transparent color or index of an underlay plane. When the pixel type is RGBA, dwVisibleMask is a transparent RGB color value. When the pixel type is color index, it is a transparent index value. Ignored. Earlier implementations of OpenGL used this member, but it is no longer used. Specifies whether more than one pixel format shares the same frame buffer. If the result of the bitwise AND of the damage masks between two pixel formats is nonzero, then they share the same buffers. The POINTFLOAT structure contains the x and y coordinates of a point. Specifies the horizontal (x) coordinate of a point. Specifies the vertical (y) coordinate of a point. Flags for Device driver version Device classification Horizontal size in millimeters Vertical size in millimeters Horizontal width in pixels Vertical height in pixels Number of bits per pixel Number of planes Number of brushes the device has Number of pens the device has Number of markers the device has Number of fonts the device has Number of colors the device supports Size required for device descriptor Curve capabilities Line capabilities Polygonal capabilities Text capabilities Clipping capabilities Bitblt capabilities Length of the X leg Length of the Y leg Length of the hypotenuse Shading and Blending caps Logical pixels inch in X Logical pixels inch in Y Number of entries in physical palette Number of reserved entries in palette Actual color resolution Physical Width in device units Physical Height in device units Physical Printable Area x margin Physical Printable Area y margin Scaling factor x Scaling factor y Current vertical refresh rate of the display device (for displays only) in Hz Horizontal width of entire desktop in pixels Vertical height of entire desktop in pixels Preferred blt alignment