You misinterpreted what I said.
I didn't say usermode reports as being Win7, I said it can and should target features of Win7.
Usermode should and does report as NT5.2.
It actually doesn't have a choice as the APIs which you use in usermode to discover the version (GetVersionEx, VerifyVersionInfo) actually query hardcoded values stored in the kernel.
Ged
On 13 November 2010 18:07, Colin Finck
<mail@colinfinck.de> wrote:
Kernel targets 2k3 (additionally with any newer architecture if possible
/ applicable.
Usermode targets the latest version of Windows.
Unfortunately, this isn't always the case as demonstrated e.g. by r39384. For some reason, the VMware Tools Installer (which of course supports NT 5.x), tried to import NT6-specific functions like wcsncpy_s from msvcrt.dll.
It's most-likely related to the fact that our msvcrt.dll still had the version number 42.4.0.0 at that time, but shows a problem that can arise if we mix targets.
The version number of msvcrt.dll has been changed to that of the corresponding DLL in 2k3 SP1 later on, but let's assume that we had implemented all NT6-specific functions in msvcrt.dll and changed the version number to that of the Vista DLL.
Some poorly written application might assume that it runs on Vista now and expect much more from the whole system: Other DLLs should be the Vista versions as well, some Vista-specific features might be requested and it might even attempt to use the NT6 version of a bundled driver.
This is of course a very specific case, but we cannot reliably say that no such Windows application exists.
We can only prevent these problems by providing an OS targetting a single Windows version from kernel-mode up to user-mode.
Therefore I appreciate Jérôme's option 3) for targetting a single Windows version (NT 5.2) while at the same time enabling us to add code for a later target change.
Most of our DLLs still have that 42.4.0.0 version number by the way, so this should be another thing to fix to ensure compatibility.
Cheers,
Colin