2015-11-10 2 views
3

Последняя версия Windows 10 (в настоящее время Insider Preview) является маркой как:Извлечение Windows, версия "1511"

Version 1511 (OS сборки 10586,3)

при поиске в "О Windows" (Пуск> Выполнить>winver)

Использование консольного приложения appropriately manifested, версия для Windows вернулся из System.Environment.OSVersion.Version является 10.0.10586.0, который не содержит ни «1511» или».3" компоненты версии сообщили по winver.

В реестре, как представляется, имеются строки в диапазоне HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion, такие как ReleaseId, которые будут предоставлять эту информацию, однако это будет связано с детализацией реализации, а не с контрактом API.

Короче говоря, существует ли (документированный) API, который предоставляет версию Windows 10, как показано winver, и/или Справка> О программе в компонентах Windows, таких как Блокнот, который можно вызвать из приложения .net?

+0

«Использование надлежащим образом проявленного консольного приложения» Возможно, это не будет правильным проявлением для 1511? Может появиться дополнительный GUID GUIDEOS. –

+0

В общем, вы не должны заботиться. Это «Windows 10» в отношении конечных пользователей и «10.0.10586.0'» в отношении данных телеметрии/поддержки. –

ответ

4

FWIW, Process Monitor предполагает, что winver просто запрашивает ReleaseId. Так что, возможно, это действительно все, что касается брендинга «Версия 1511».

23:59:30,6022870 winver.exe 7004 RegQueryValue HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ReleaseID SUCCESS Type: REG_SZ, Length: 10, Data: 1511 

Изменение значения реестра к чему-то случайному немедленно отражается при повторном запуске winver. Удаление значения приводит к тому, что winver показывает пустую строку.

Таким образом, в то время как не красиво завернутые в API и, возможно, без поддержки, это, кажется, сделать трюк сейчас:

using (var hklmKey = Microsoft.Win32.Registry.LocalMachine) 
using (var subKey = hklmKey.OpenSubKey(@"SOFTWARE\Microsoft\Windows NT\CurrentVersion")) 
{ 
    if (subKey != null) 
    { 
     string release = subKey.GetValue("ReleaseId") as string; 

     if (release != null) 
      retVal += " Version " + release; 
    } 
} 
+0

Спасибо, что нашли время, чтобы понять, что происходит с диспетчером процессов (и, таким образом, подтверждая мою теорию о том, откуда могут поступать данные). Я не собираюсь это принимать, хотя, поскольку мой вопрос специфичен в запросе API для этого, это важная информация, хотя =) Запуск sysinternals «строк» ​​по winver.exe, и это MUI-файл не находит ссылок на «ReleaseId», поэтому он похоже, что это может вызвать API в конце концов ... – Rob

4

Вот некоторые косвенные доказательства того, что нет нет API, чтобы получить «1511 "string (кроме чтения его значения реестра" ReleaseId "). Это не абсолютное доказательство, и, возможно, это не тот ответ, который вы искали, но это то, что у меня есть на данный момент.

Регистрация «winver» выполняется с помощью sysinternals ProcMon показывает, что раздел реестра действительно запрашивается, как уже указывал @ Sören Kuklau.

winver.exe RegQueryValue HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ReleaseID SUCCESS Type: REG_SZ, Length: 10, Data: 1511 

стек вызовов в точке этого RegQueryValueExW для «ReleaseID» заключается в следующем, как сообщает ProcMon.

0 ntoskrnl.exe NtQueryInformationFile + 0x3d50 
1 ntoskrnl.exe NtOpenThreadTokenEx + 0x258c 
2 ntoskrnl.exe setjmpex + 0x3963 
3 ntdll.dll  ZwQueryValueKey + 0x14 
4 KernelBase.dll MapPredefinedHandleInternal + 0x729 
5 KernelBase.dll RegQueryValueExW + 0xed 
6 SHCore.dll  SHQueryValueExW + 0xdd 
7 SHCore.dll  SHQueryValueExW + 0x32 
8 shell32.dll Ordinal897 + 0x86f 
9 shell32.dll Ordinal897 + 0xb8b 
10 shell32.dll Ordinal897 + 0x304 
11 user32.dll  IsDialogMessageW + 0x76e 
12 user32.dll  IsDialogMessageW + 0x941 
13 user32.dll  IsDialogMessageW + 0x866 
14 user32.dll  DispatchMessageW + 0x689 
15 user32.dll  SendMessageW + 0x395 
16 user32.dll  SetWindowLongPtrA + 0x979 
17 user32.dll  DialogBoxIndirectParamAorW + 0x18c 
18 user32.dll  DialogBoxIndirectParamAorW + 0x52 
19 user32.dll  DialogBoxParamW + 0x85 
20 shell32.dll SHELL32_PifMgr_OpenProperties + 0x223d 
21 shell32.dll ShellAboutW + 0x72 
22 winver.exe  winver.exe + 0x11d3 
23 winver.exe  winver.exe + 0x1516 
24 kernel32.dll BaseThreadInitThunk + 0x22 
25 ntdll.dll  RtlUserThreadStart + 0x34 

Так, winver.exe называет ShellAboutW из shell32.dll, которая открывает диалоговое окно и заполняет в данных. При этом он считывает значение реестра «HKLM \ SOFTWARE \ Microsoft \ Windows NT \ CurrentVersion \ ReleaseID», которое возвращает «1511».

Имя значения «ReleaseID» действительно найдено в виде строки с жестким кодом в shell32.dll. Кроме того, единственными другими DLL System32, которые содержат строку ReleaseId, являются SettingsHandlers_nt.dll и WSShared.dll, но ни один из них не загружен winver.exe, и оба имеют разные значения для «ReleaseID» (нижний регистр «d» в конце, для одной вещи). Это сильно указывает на то, что:
(a) строка, переданная в RegQueryValueExW, является одной из жестко закодированных в shell32.dll;
(b) другой код MS имеет аналогичную строку hardcoded, предположительно потому, что для ее получения нет API.

Это все еще оставляет открытым то, что одна и та же информация «1511» (или, по крайней мере, имя значения «ReleaseID») могла бы быть открыта оболочкой shell32.dll через какой-либо другой API. Возможно, например, что один из вызовов «Ordinal897» в смещениях 8, 9, 10 в стеке вызовов может фактически быть функцией типа «GetWin10RelID (LPTSTR lpRellD, int nMaxChars)»; и также возможно, что он может экспортироваться по имени вместо порядкового номера и быть документирован в будущих SDK. Однако на данный момент это анонимные функции, экспортируемые по порядковым номерам, без документации, и не гарантируют, что они будут хранить один и тот же порядковый номер в следующий раз, когда обновится shell32.dll.

Смежные вопросы