I didn't know that !
Yes I wiki so whatSecurity issue
In January 2010, Google security researcher Tavis Ormandy revealed a serious security flaw in Windows NT's VDM implementation that allowed unprivileged users to escalate their privileges to SYSTEM level, noted as applicable to the security of all versions of the Windows NT kernel since 1993. This included all 32-bit versions of Windows NT, 2000, XP, Server 2003, Vista, Server 2008, and Windows 7. Ormandy did publish a proof-of-concept exploit for the vulnerability. Prior to Microsoft's release of a security patch, the workaround for this issue was to turn off 16-bit application support, which prevented older programs (those written for DOS and Windows 3.1) from running. 64-bit versions of Windows were not affected since they do not include the NTVDM subsystem.
Limitations
A limitation exists in the Windows XP 16-bit subsystem (but not in earlier versions of Windows NT) because of the raised per session limit for GDI objects which causes GDI handles to be shifted to the right by two bits, when converting them from 32 to 16 bits.[6] As a result, the actual handle cannot be larger than 14 bits and consequently 16-bit applications that happen to be served a handle larger than 16384 by the GDI system crash and terminate with an error message.[6]
In an x86-64 CPU, virtual 8086 mode is available as a sub-mode only in its legacy mode (for running 16- and 32-bit operating systems), not in the native, 64-bit long mode. Thus versions of Windows NT for 64-bit architectures (x86-64 and IA-64) do not include the NTVDM and are unable to run DOS or 16-bit Windows applications. The only possibility to run them is to use Windows XP Mode or other virtualization software.
In general, VDM and similar technologies do not satisfactorily run many older DOS programs on today's computers. Emulation is only provided for the most basic peripherals, often implemented incompletely[citation needed]. For example, sound emulation in NTVDM is very limited. NT-family versions of Windows only update the real screen a few times per second when a DOS program writes to it, and they do not emulate higher resolution graphics modes. Because software mostly runs native at the speed of the host CPU, all timing loops will expire prematurely. This either makes a game run much too fast or causes the software not even to notice the emulated hardware peripherals, because it does not wait long enough for an answer.
NT Virtual Device Driver, I wonder what the error is all about...
