Windows Vista Logo. Практика
Проверка версии операционной системы
Работа в привилегированном режиме
Создание объектов в области Global
В данной статье мы рассмотрим различные практические вопросы создания приложений, отвечающих требованиям Windows Vista Logo. Два предыдущих материала — «Уроки чистописания. Создание приложений, корректно работающих под Windows XP, Windows Server 2003 и Windows Vista» и «Уроки чистописания. Часть 2. На пути к Windows Vista Logo» (в № 2 и № 5’2006 соответственно) — были посвящены общим вопросам написания корректно работающих приложений и обсуждению требований, выдвигаемых к приложениям, которые претендуют на получение логотипов «Certified for Windows Vista» и «Works with Windows Vista».
На этот раз мы рассмотрим основные проблемы, связанные с несовместимостью с Windows Vista, которые возникают в основном из-за несоблюдения рекомендаций по созданию приложений для операционной системы Windows. К наиболее часто возникающим проблемам несовместимости можно отнести некорректную проверку версии операционной системы, работу в привилегированном режиме, использование ресурсов Windows, включая рабочие каталоги операционной системы и реестр, и т.п. Мы приведем примеры некорректно работающих приложений и покажем, как устранить проблемы несовместимости — либо средствами, реализованными в операционной системе, либо путем внесения изменений в код приложения.
Данная статья поможет вам не только обеспечить работоспособность приложений, но и сделать их более стабильными и отвечающими требованиям совместимости с новой версией операционной системы — Windows Vista.
Проверка версии операционной системы
Рассмотрим следующий пример. Пусть мы выполняем проверку версии операционной системы, используя следующий код:
static private bool IsOSSupported()
{
OperatingSystem os = Environment.OSVersion;
Version vs = os.Version;
if ((vs.Major == 5) && (vs.Minor == 1))
{
return true;
}
else
{
MessageBox.Show(“This version of the
Operating System
is not supported. The application
requires Windows
XP.”, “Unsupported OS”);
return false;
}
}
В данном примере проверяется, запускается ли программа под управлением операционной системы Microsoft Windows XP. Естественно, при запуске программы под Windows Vista мы получим сообщение об ошибке (рис. 1).
Рис. 1. Сообщение об ошибке: несовместимая версия операционной системы
Исправить ситуацию можно двумя способами. Все зависит от того, насколько критично для конкретного приложения выполнение именно под управлением данной версии операционной системы — возможно, разработчики использовали какие-то особенности той или иной версии операционной системы (обычно — недокументированные и нерекомендуемые к применению!) или просто не совсем корректно выполнили проверку. В первом случае мы можем указать режим совместимости для выполнения данного приложения. Нажав правую кнопку мыши на исполняемом файле приложения и выбрав команду Properties, мы открываем одноименную диалоговую панель, в которой нас интересует вкладка Compatibility. В разделе Compatibility Mode укажем требуемую для данного приложения версию операционной системы и включим опцию Run this program in compatibility mode for, указав Windows XP (Service Pack 2) для нашего примера. Теперь при запуске приложения Windows Vista будет идентифицироваться как Windows XP Service Pack 2, и приложение запустится без сообщений об ошибках (рис. 2).
Рис. 2. Задание режима совместимости с предыдущими версиями
операционной системы
Если же мы не хотим использовать режим совместимости (либо применение каких-либо уникальных свойств конкретной версии операционной системы не предполагается), то можно исправить код проверки версии. В нашем случае мы должны заменить строку
if ((vs.Major == 5) && (vs.Minor == 1))
на
if ((vs.Major == 5) && (vs.Minor >= 1) || vs.Major
>= 6 )
и перекомпилировать приложение. В дальнейшем проблем с определением версии операционной системы не будет.
Работа в привилегированном режиме
Одна из новинок в Windows Vista, наиболее часто приводящая к несовместимости с другими приложениями, — это повышенные требования к безопасности, в соответствии с которыми пользователи работают под учетной записью standard user с пониженным набором разрешений (permissions) и привилегий. По умолчанию в Windows Vista каждый пользователь работает под учетной записью standard user, даже если он зарегистрировался как член группы администраторов. Соответственно, когда пользователь пытается запустить приложение, которое требует привилегий администратора, операционная система запрашивает подтверждение. Только приложения, выполняемые с привилегиями администратора, могут вносить изменения в глобальные настройки операционной системы. Этот механизм, впервые реализованный в Windows Vista, называется User Account Control (UAC).
Далее мы рассмотрим несколько примеров работы механизма User Account Control и приведем рекомендации по обеспечению совместимости существующих и создаваемых приложений с этим механизмом.
Запись в Program Files
В первом примере мы убедимся в том, что когда пользователь работает под учетной записью standard user, то задействуется механизм виртуализации некоторых системных ресурсов, включая области файловой системы и реестра.
Предположим, в нашем приложении есть код, который создает файл в папке Program Files и записывает в него какую-то информацию. Код выглядит следующим образом:
private void OnWriteToProgramFiles(object sender,
EventArgs e)
{
try
{
string folderPath =
Path.Combine(Environment.GetFolderPath(
Environment.SpecialFolder.ProgramFiles),
“WindowsVistaReadiness”);
if (!Directory.Exists(folderPath))
{
Directory.CreateDirectory(folderPath);
}
string filePath = Path.Combine(folderPath,
“log.txt”);
using (TextWriter tw = new StreamWriter
(filePath, true))
{
tw.WriteLine(“entry added “ + DateTime.Now);
}
MessageBox.Show(“Entry has successfully been
added to Log.txt”,
“Write To Program Files”, MessageBoxButtons.OK,
MessageBoxIcon.Information);
}
catch (System.Security.SecurityException secEx)
{
MessageBox.Show(string.Format(“SecurityException:
{0}”,
secEx.Message), “Write To Program Files”,
MessageBoxButtons.OK,
MessageBoxIcon.Error);
}
catch (UnauthorizedAccessException authEx)
{
MessageBox.Show(string.Format(“Unauthorized-
AccessException: {0}”,
authEx.Message), “Write To Program Files”,
MessageBoxButtons.OK,
MessageBoxIcon.Error);
}
catch (Exception ex)
{
MessageBox.Show(ex.Message, “Write To Program Files”,
MessageBoxButtons.OK, MessageBoxIcon.Error);
}
}
Вторая процедура, используемая в нашем примере, проверяет принадлежность пользователя к группе администраторов. Вот код этой процедуры:
private void OnIsAdministrator(object sender,
EventArgs e)
{
WindowsIdentity wi = WindowsIdentity.GetCurrent();
WindowsPrincipal wp = new WindowsPrincipal(wi);
if (wp.IsInRole(“Administrators”))
{
MessageBox.Show(“Yes, you are an Administrator.”,
“Is Administrator?”, MessageBoxButtons.OK,
MessageBoxIcon.Information);
}
else
{
MessageBox.Show(“No, you are not an Administrator!”,
“Is Administrator?”, MessageBoxButtons.OK,
MessageBoxIcon.Error);
}
}
В процедуре инициализации формы — OnFormLoad — добавим следующий код:
AppDomain.CurrentDomain.SetPrincipalPolicy
(PrincipalPolicy.WindowsPrincipal);
Запустим наше приложение и активируем функцию OnWriteToProgramFiles. В результате мы получим сообщение, подтверждающее успешную запись файла в папку Program Files. Однако файла в этой папке мы не обнаружим — сработал упомянутый выше механизм виртуализации ресурсов. На самом деле файл был записан в папку users — чтобы увидеть ее саму и ее содержимое, в Windows Explorer необходимо включить режим отображения файлов с атрибутом hidden. Для этого, как и в предыдущих версиях Windows, применяется команда Folder Options, вкладка View и опция Show Hidden Files and Folders. Папка, используемая для виртуализации, находится по адресу: c:\users\{user name}\AppData\Local\VirtualStore\Program Files\
И действительно, в ней мы обнаружим файл, который пытались записать в папку Program Files (рис. 3).
Рис. 3. Виртуализация системных ресурсов
Если же запустить наше приложение от лица администратора (опция Run As Administrator), нажав правую кнопку мыши на исполняемом файле, то вместо виртуального каталога файл будет записан непосредственно в папку Program Files (рис. 4).
Рис. 4. Запуск приложения от лица
администратора
Использование манифеста
Одно из требований, выдвигаемых к приложениям, претендующим на сертификацию под Windows Vista, — это наличие специального ресурса — манифеста, в котором, в частности, описываются требования по привилегиям, необходимым для запуска данного приложения. Манифест — это XML-файл, который выглядит следующим образом:
<?xml version=”1.0" encoding=”utf-8" ?>
<assembly xmlns=”urn:schemas-microsoft-com:asm.v1"
manifestVersion=”1.0">
<assemblyIdentity version=”1.0.0.0"
processorArchitecture=”X86"
name=”WindowsVistaReadiness”
type=”win32" />
<description>WindowsVistaReadiness Application</
description>
<trustInfo xmlns=”urn:schemas-microsoft-com:asm.v3">
<security>
<requestedPrivileges>
<requestedExecutionLevel level=”asInvoker” />
</requestedPrivileges>
</security>
</trustInfo>
</assembly>
В ветви trustInfo описывается требуемый для приложения уровень привилегий — он задается в виде атрибута level параметра requestedExecutionLevel. Этот атрибут может иметь три значения (см. таблицу).
Значения атрибута level
Включение манифеста в приложение требует выполнения нескольких шагов:
1. Добавить к проекту XML-файл (нажать правую кнопку мыши на проекте, выбрать команду Add ® New Item…, выбрать XML File).
2. Сохранить файл с именем проекта и расширением exe.manifest.
3. Добавить к проекту файл ресурса (нажать правую кнопку мыши на проекте, выбрать команду Add ® New Item…, выбрать Text File).
4. Сохранить файл с именем проекта и расширением *.rc.
5. Открыть файл ресурса (Open with… Source Code Editor) и добавить в него следующие строки:
#define RT_MANIFEST 24
#define APP_MANIFEST 1
APP_MANIFEST RT_MANIFEST App.exe.manifest
6. Заменить App.exe.manifest на имя файла манифеста из п. 2.
7. В свойствах проекта (нажать правую кнопку мыши на проекте, выбрать команду Properties) выбрать вкладку Build Events и в строке Pre-build event command line указать:
«path\rc.exe” $(ProjectDir)$(ProjectName).rc
8. Заменить path на местонахождение компилятора ресурсов — rc.exe, который может располагаться в одном из следующих каталогов:
- Program Files\Microsoft Visual Studio 8\SDK\v2.0\Bin;
- Program Files\Microsoft SDKs\Windows\ v1.0\Bin.
9. Добавить элемент MSBuild для включения ресурсов в исполняемый файл. Для этого необходимо открыть скрипт проекта в редакторе (нажать правую кнопку мыши на проекте, выбрать команду Unload Project, затем нажать правую кнопку мыши на проекте, выбрать команду Edit <Project name>.
10. Добавить в скрипт следующий элемент:
<PropertyGroup>
<Win32Resource>App.res</Win32Resource>
</PropertyGroup>
11. Выполнить команду Rebuild Solution.
После того как мы добавили к нашему приложению манифест, запустим приложение еще раз и убедимся в том, что указание параметра requestedExecutionLevel приводит к появлению ошибки — механизм виртуализации не работает (рис. 5).
Рис. 5. Ошибка доступа к системным ресурсам
Выполнение процедуры OnIsAdministrator покажет, что мы не является администратором (рис. 6).
Рис. 6. Проверка полномочий
Вернемся к манифесту приложения и заменим значение атрибута level параметра requestedExecutionLevel на highestAvailable. После этого выполним команду Rebuild Solution и запустим приложение. В этом случае мы получим запрос на подтверждение повышения полномочий для выполнения приложения (рис. 7).
Рис. 7. Запрос на повышение полномочий
Нажатие кнопки Allow приведет к повышению полномочий и выполнению нашего приложения — это можно проверить, вызвав процедуру OnIsAdministrator. Процедура записи файла в папку Program Files тоже будет выполняться (без использования механизма виртуализации), так как наше приложение теперь работает с привилегиями администратора. Отметим, что в диалоговой панели User Account Control указано, что приложение имеет атрибут Unidentified Publisher, — это связано с тем, что у приложения нет цифровой подписи. Наличие цифровой подписи у всех исполняемых файлов и их бинарных компонентов также является одним из обязательных требований для получения сертификации под Windows Vista и относится к файлам со следующими расширениями: *.exe, *.dll, *.ocx, *.sys, *.cpl, *.drv и *.scr. Для того чтобы проверить наличие цифровой подписи, можно воспользоваться следующей командой:
signtool verify /pa /v <AppName>
Утилита SignTool поставляется в составе Windows Server 2003 R2 Platform SDK — набора программных средств для создания Windows-приложений, который доступен для скачивания по адресу: http://msdn.microsoft.com/platformsdk/.
Использование токена Admin
Для определения режима работы приложения — под полным токеном Admin или под токеном с ограниченными полномочиями — воспользуемся утилитой Process Explorer (рис. 8) с сайта www.sysitnernals.com. Сначала изменим значение атрибута level параметра requestedExecutionLevel обратно на asInvoker, выполним команду Rebuild Solution и запустим приложение. Теперь запустим утилиту Process Explorer. В списке приложений найдем наш демо-пример (WindowsVistaReadiness).
Рис. 8. Утилита Process Explorer
Выберем приложение WindowsVistaReadiness и перейдем на вкладку Security. Обратите внимание на то, что опция Mandatory указывает на Medium Mandatory Level — у приложения имеется минимальный набор привилегий (рис. 9).
Рис. 9. Набор привилегий приложения
Завершим работу нашего приложения и запустим его еще раз, теперь использовав опцию Run as Administrator. Убедимся в том, что теперь уровень Mandatory приложения стал High Mandatory Level — у приложения появился набор дополнительных привилегий. В этом заключается отличие работы приложения под полным токеном Admin от работы под токеном с ограниченными полномочиями.
Отметим еще одну интересную особенность. Если мы запустим Internet Explorer и изучим его уровень Mandatory, то обнаружим, что он имеет значение Low Mandatory Level. Это отражает тот факт, что Internet Explorer работает с минимальными привилегиями, в частности не может посылать Windows-сообщения другим приложениям (рис. 10).
Рис. 10. Набор привилегий Internet Explorer
Mandatory Integrity Control
Mandatory Integrity Control (MIC) — это механизм Windows, позволяющий управлять коммуникациями между процессами за счет задания различных уровней целостности выполнения процессов. Как мы уже увидели, стандартное приложение, выполняемое под учетной записью standard user, имеет Medium Mandatory Level, тогда как приложение, выполняемое под учетной записью administrator, имеет High Mandatory Level и соответственно набор дополнительных привилегий. Изоляция процессов позволяет расширить модель авторизации на межпроцессные коммуникации.
Рассмотрим пример, в котором одно приложение посылает Windows-сообщение другому приложению. Вот код, применяемый для посылки сообщения, — обратите внимание на использование механизмов P/Invoke:
[DllImport(“user32”, SetLastError = true, CharSet =
CharSet.Auto)]
static extern System.IntPtr FindWindow(string
lpClassName, string lpWindowName);
[DllImport(“user32.dll”, SetLastError = true)]
static extern bool PostMessage(IntPtr hWnd, uint Msg,
IntPtr wParam, IntPtr lParam);
public const int WM_USER = 0x400;
public const int WM_IPC = WM_USER + 5001;
private void sendWindowsMessage_Click(object sender,
EventArgs e)
{
PostMessage(FindWindow(null, “WM Listener”),
WM_IPC, IntPtr.Zero, IntPtr.Zero);
}
Второе приложение «слушает» очередь сообщений через MessageFilter и реагирует на событие WM_IPC. Вот код этого приложения:
public class WindowsMessageHelper
{
[DllImport(“user32”, SetLastError = true, CharSet =
CharSet.Auto)]
static extern System.IntPtr FindWindow(string
lpClassName, string lpWindowName);
[DllImport(“user32.dll”, SetLastError = true)]
static extern bool PostMessage(IntPtr hWnd, uint Msg,
IntPtr wParam, IntPtr lParam);
public const int WM_USER = 0x400;
public const int WM_IPC = WM_USER + 5001;
public static void SendMessage(string title, IntPtr
wParam, IntPtr lParam)
{
PostMessage(FindWindow(null, title), WM_IPC, wParam,
lParam);
}
}
public class MessageFilter : IMessageFilter
{
private WMForm mainForm;
public MessageFilter(WMForm mainForm)
{
this.mainForm = mainForm;
}
public bool PreFilterMessage(ref Message m)
{
bool returnValue = false;
if (m.Msg == WindowsMessageHelper.WM_IPC)
{
MessageBox.Show(mainForm, “Got the message.”);
returnValue = true;
}
return returnValue;
}
}
Запустим оба приложения и убедимся в том, что сообщение корректно передается от одного приложения к другому. Если же теперь запустить приложение-приемник с опцией Run as Administrator, то сообщение до него не дойдет, так как сработает механизм изоляции процессов, имеющих разные привилегии, — для успешной отсылки сообщения необходимо запустить посылающее приложение также с опцией Run as Administrator.
Установка приложений
Как показывает практика, в большинстве случаев подразумевается, что инсталляционный пакет запускается под пользовательской записью administrator. В Windows Vista это может привести к тому, что установка приложения завершится неудачно.
Предположим, у нас есть инсталляционный пакет, рассчитанный на запуск под пользовательской записью administrator. Выполнение такого пакета под Windows Vista завершится с ошибкой — нам потребуется внести изменения в MSI-файл.
По умолчанию MSI-файл выполняется с уровнем привилегий asInvoker, если в манифесте не указан другой уровень. Предположим, наш пакет не имеет манифеста и соответственно выполняется под учетной записью Local User Account (LUA). Внутри пакета происходит попытка установки сервиса, которая требует привилегий администратора, — в результате установка приложения завершается с ошибкой.
Используя утилиту Orca, которая входит в состав Platform SDK, убедимся в том, что MSI-файл содержит вложенные custom actions (см. таблицу Custom Action) — это не соответствует одному из требований к сертификации приложений, где указано, что инсталляционные пакеты не должны содержать custom actions с кодами 7 (установка вложенного пакета), 23 (установка внешнего пакета) и 39 (установка уже установленного продукта). Для того чтобы наш инсталляционный пакет мог работать нормально, необходимо удалить указанные custom actions и перенести их в отдельные пакеты.
Изоляция Session 0
В Windows XP, Windows Server 2003 и более ранних версиях операционной системы Microsoft Windows все системные сервисы выполнялись в той же сессии, что и сессия, в которую загрузился первый пользователь системы, то есть в сессии 0 (Session 0). Выполнение сервисов и пользовательских приложений в сессии 0 приводило к определенным рискам, связанным с безопасностью: поскольку сервисы могли выполняться с повышенными привилегиями (например, под учетной записью Local System), вредоносные приложения пытались использовать их для повышения собственного уровня привилегий.
В операционной системе Windows Vista вышеописанные риски устраняются за счет того, что сервисы, выполняемые в сессии 0, изолированы и сама сессия не является интерактивной. В Windows Vista в сессии 0 выполняются только системные процессы и сервисы. Первый пользователь, подключающийся к системе, загружается в сессию 1, все последующие пользователи — в сессии с увеличивающимися номерами. Это означает, что сервисы никогда не выполняются в той же сессии, что и пользовательские приложения, — таким образом сервисы защищены от атак, которые могут происходить от вредоносных приложений.
Используя утилиту Task Manager, убедимся в том, что все сервисы Windows отделены от приложений и выполняются в сессии 0.
Запустим утилиту Task Manager, выберем вкладку Process и включим отображение колонки Session ID (команда View ® Select Columns). Активизируем опцию Show processes from all users для получения списка всех сервисов и убедимся в том, что они выполняются в отличной от приложений сессии — сессии 0 (рис. 11).
Рис. 11. Системные процессы выполняются в сессии 0
Изоляция сессии 0 может привести к проблеме с сервисами, которым необходимо отображение пользовательского интерфейса. Поскольку сервис теперь выполняется в другой сессии (по сравнению с Desktop), пользовательский интерфейс не будет виден конечным пользователям и интерактивный сервис может оказаться в «зависшем» состоянии (рис. 12).
Рис. 12. Сообщение об обнаружении
интерактивного сервиса
В Windows Vista решение этой проблемы состоит в том, что пользователям предоставляется возможность временного переключения в сессию 0 для взаимодействия с интерактивным сервисом. Нажатие кнопки Show me the message на показанной на рис. 12 диалоговой панели Interactive service dialog detection приведет к переключению в сессию 0.
Windows Resource Protection
Механизм Windows Resource Protection (WRP) предназначен для сохранения системы Windows в состоянии «только чтение», а следовательно, позволяет повысить стабильность, надежность и предсказуемость системы. Этот механизм предохраняет системные файлы, папки и ключи реестра. Обновления защищенных этим механизмом ресурсов возможны только с применением OS Trusted Installers, к которым относится, например, механизм Windows Servicing. Это позволяет защитить ключевые компоненты операционной системы от воздействия со стороны приложений и администраторов.
Ниже мы рассмотрим, как файлы операционной системы защищены от модификаций. Перейдем в папку \Windows\System32, выберем утилиту cmd.exe и при нажатии правой кнопки мыши выберем команду Properties. На вкладке Security убедимся в том, что полный доступ к утилите не имеют ни учетная запись System, ни запись Administrator (рис. 13).
Рис. 13. Контроль доступа к системному ресурсу
Теперь попробуем удалить утилиту cmd.exe — после подтверждения (кнопка Yes), диалоговой панели File Access Denied (кнопка Continue) и диалоговой панели User Account Control (кнопка Continue) мы получим сообщение о том, что данный файл удалить невозможно.
Как мы уже указали, только Trusted Installers могут модифицировать защищенные компоненты операционной системы (рис. 14).
Рис. 14. Windows Resource Protection в действии
Создание объектов в области Global
Для создания объектов, видимых в глобальном пространстве имен (Global Namespace) — пространстве имен, которое доступно из всех сессий Terminal Service Sessions, — пользователи должны иметь привилегию SeCreateGlobalPrivilege, которой не обладают учетные записи Standard User. В предыдущих версиях операционной системы префиксы пространства имен типа global\ и local\ игнорировались, если не были активизированы терминальные сервисы. В Windows Vista режим Fast User Switching является одной из опций терминальных сервисов, сами сервисы всегда активизированы и вышеупомянутые префиксы никогда не игнорируются. Приложения, которые могли создавать объекты в глобальном пространстве имен, теперь требуют выполнения только под учетной записью администратора. Ошибка возникает только в том случае, когда приложения пытаются создавать такие объекты, — доступ к глобальным объектам, созданным, например, системными сервисами, не ограничен.
Рассмотрим пример, в котором в глобальном пространстве имен создается проецируемый на память файл (memory mapped file). В результате выполнения приведенного ниже кода мы получим ошибку, поскольку стандартный пользователь не может создать такой файл. Вот код создания проецируемого на память файла:
[DllImport(“kernel32”, SetLastError = true, CharSet
= CharSet.Auto)]
public static extern UIntPtr CreateFileMapping(
UIntPtr hFile, UIntPtr lpAttributes, uint flProtect,
uint dwMaximumSizeLow, uint dwMaximumSizeHigh,
String lpName);
[DllImport(“kernel32”, SetLastError = true, CharSet
= CharSet.Auto)]
public static extern bool CloseHandle( UIntPtr
hHandle );
private void createSharedObject_Click(object sender,
EventArgs e)
{
string objName = “Global\” + “luademo_object”;
UIntPtr file = UIntPtr.Zero;
UIntPtr handle = CreateFileMapping(
file, //INVALID_HANDLE_VALUE
UIntPtr.Zero,
0x4, // PAGE_READWRITE
0, // dwMaximumSizeHigh
4, // dwMaximumSizeLow
objName);
if (handle != UIntPtr.Zero)
{
CloseHandle(handle);
}
Win32Exception exc = new Win32Exception(Marshal.
GetLastWin32Error());
MessageBox.Show(
“CreateFileMapping (“ + “Global\” + “ )\n\r\n\r” +
“Result: “+ exc.Message,
“Success: “ + (handle != UIntPtr.Zero));
}
При выполнении такого кода мы получим сообщение об ошибке — Access Denied. Если заменить строку
string objName = “Global\” + “luademo_object”;
на
string objName = “Local\” + “luademo_object”;
то код выполнится без проблем. Для того чтобы вышеприведенный код мог корректно выполняться, приложение следует запускать с опцией Run as Administrator.
Дополнительные ресурсы
Вот список дополнительных ресурсов, где можно получить более подробную информацию по рассмотренным темам:
- портал DevReadiness.org (http://devreadiness.org/) содержит множество материалов, которые можно использовать для подготовки к переносу приложений под Windows Vista или к написанию новых приложений с учетом упомянутых в данном обзоре требований. В частности, на этом портале есть исходные тексты приложений, которые мы обсуждали;
- темы, затронутые в данной статье, подробно разбираются в Windows Vista Application Compatability Cookbook на сайте MSDN по адресу: http://msdn.microsoft.com/windowsvista/default.aspx?pull=/;library/en-us/dnlong/html/AppComp.asp;
- описание программы Certified for Windows Vista Logo можно найти на партнерском сайте по адресу: http://microsoft.mrmpslc.com/VistaPlatformAdoption/Overview/CertifiedFor.aspx;
- обзор основных новинок Windows Vista сделан в материале «Top 10 Ways to Light Up Your Windows Vista Apps» на сайте MSDN по адресу: http://msdn.microsoft.com/windowsvista/top10/;
- основной ресурс для разработчиков — это раздел сайта MSDN, посвященный Windows Vista, — он находится по адресу: http://msdn.microsoft.com/windowsvista/.
 |
|
