IT1102: Современные операционные системы: ОС Windows
Большинство приложений без проблем работают как в Windows ХР, так и в Windows 7. Но вполне может случиться так, что самое важное для вашей деятельности приложение откажется функционировать. Чтобы настроить такое приложение для работы в Windows 7, можно предпринять несколько шагов, начиная с простого автоматического подбора настроек совместимости до запуска приложения в режиме Windows ХР Mode — полностью виртуализованной среде ОС. Важно помнить, что всегда есть способ заставить несовместимое приложение работать на компьютере, использующем Windows 7, хотя для его поиска потребуется некоторое время и усилия.
Система диагностики проблем совместимости
Встроенные режимы и параметры совместимости
В Windows 7 включено несколько встроенных режимов совместимости, позволяющих при помощи ряда параметров частично воспроизводить среду ОС предыдущего поколения. Несмотря на это все-таки возможно, что приложение, исправно функционировавшее в одной из этих ОС, не будет нормально работать даже при использовании соответствующего режима совместимости. Чтобы настроить режим совместимости для приложения, воспользуйтесь вкладкой Совместимость (Compatibility) диалогового окна свойств приложения. Выберите в раскрывающемся списке один из следующих режимов совместимости:
На этой же вкладке размещены и другие параметры совместимости, в частности:
В процессе работы система диагностики пытается применить эти параметры, чтобы заставить приложение работать. Если ей это не удастся, вы сможете настроить их вручную. Нельзя настраивать параметры совместимости приложений, которые входят в состав ОС Windows. Если вам не удается при помощи перечисленных параметров заставить приложение работать, воспользуйтесь пакетом Application Compatibility Toolkit (ACT) для создания собственного режима совместимости, который будет настраиваться более детально для конкретных нужд того приложения, которое вы пытаетесь запустить.
Настраиваем подключения к удаленному рабочему столу
Настраиваем подключения к удаленному рабочему столуАрхив номеров / 2008 / Выпуск №10 (71) / Настраиваем подключения к удаленному рабочему столу
Давайте рассмотрим некоторые практические примеры, чтобы увидеть, как все это работает, и дать вам представление о том, что возможно. И вновь вы можете выбрать свою любимую языковую проекцию WinRT. На современном C++ компоновщик создается так: Аналогично то же самое можно сделать на C#: Вы даже можете использовать более колоритный синтаксис, предлагаемый C++/CX: Все это эквиваленты с точки зрения API и простое отражение различий в языковых проекциях. Сегодня вы можете писать UWP-приложения в основном двумя способами. По-видимому, самый распространенный подход — использование пространства имен Windows.UI.Xaml в ОС. Если XAML не особо важен в вашем приложении, вы также можете использовать нижележащую модель приложений напрямую безо всякой зависимости от XAML. Я описывал модель WinRT-приложений в своей рубрике за август 2013 года (goo.gl/GI3OKP). Применяя этот подход, вам просто нужна минимальная реализация интерфейсов IFrameworkView и IFrameworkViewSource, после чего вы готовы к дальнейшей работе. На рис. 3 дан базовый каркасный код на C#, который вы можете использовать для начала. Композиция Windows также предлагает глубокую интеграцию с XAML, но давайте начнем с простого приложения без XAML — так будет легче понять композицию. Я вернусь к XAML в этой статье несколько позже. Рис. 3. Модель приложения Windows Runtime на C# Компоновщик должен конструироваться в методе SetWindow объекта приложения (рис. 3). По сути, это самая ранняя точка в жизненном цикле приложения, где это возможно, так как компоновщик зависит от диспетчера окна, а это та самая точка, в которой окно и диспетчер начинают свое существование. Связь между компоновщиком и представлением приложения может быть после этого установлена созданием мишени композиции: Важно, чтобы приложение поддерживало существование мишени композиции, поэтому вы должны сделать ее переменной-членом вашей реализации IFrameworkView. Как упоминалось ранее, мишень композиции представляет связь между окном или представлением и его деревом визуальных элементов. Все, что вы можете сделать с мишенью композиции, — задать корневой визуальный элемент. Как правило, им будет визуал контейнера: Здесь я использую C++, в котором недостает языковой поддержки свойств, поэтому свойство Root проецируется как методы-аксессоры. Код на C# очень похож, но добавляется синтаксис свойств: DirectComposition предоставлял только один вид визуала, который поддерживал разные виды поверхностей для представления контента битовой карты. Windows-композиция предлагает небольшую иерархию классов, которая представляет разные виды визуалов, кистей и анимаций, тем не менее есть только один вид поверхности, и ее можно создать лишь на C++, потому что он является частью Interop API Windows-композиции, предназначенного для использования инфраструктурами вроде XAML и разработчиками более изощренных приложений. Иерархия визуальных классов показана на рис. 4. CompositionObject — это ресурс, поддерживаемый компоновщиком (compositor). Все объекты композиции потенциально иметь анимируемые свойства. Visual предоставляет уйму свойств для управления многими аспектами относительной позиции, внешнего вида, параметров отсечения и рендеринга визуала. Он включает свойство матричного преобразования, а также сокращения для масштабирования и поворачивания. Это мощный базовый класс. ContainerVisual, напротив, является сравнительно простым классом, который лишь добавляет свойство Children. Хотя вы можете создавать визуалы контейнера напрямую, SpriteVisual добавляет возможность сопоставлять кисть, чтобы визуальный элемент мог сам выполнять рендеринг своих пикселей.
Для корневого визуала контейнера можно создать любое количество дочерних визуалов: Они тоже могут быть визуалами контейнера, но более вероятно, что они станут спрайтовыми визуалами (sprite visuals). Я мог бы добавить три визуальных элемента как дочерние корневого визуала, используя цикл for в C++: Можно легко вообразить окно приложения на рис. 5, тем не менее этот код не приведет к рендерингу чего бы то ни было, поскольку с этими визуалами не сопоставлена кисть. Иерархия классов кистей представлена на рис. 6. CompositionBrush — это просто базовый класс для кистей, он не предоставляет никакой собственной функциональности. CompositionColorBrush — простейший производный класс, предлагающий только свойство color для рендеринга визуалов сплошным цветом. Возможно, это звучит не слишком захватывающе, но не забудьте, что к этому свойству можно подключать анимации. Классы CompositionEffectBrush и CompositionSurfaceBrush взаимосвязаны, но это более сложные кисти, так как они поддерживаются другими ресурсами. CompositionSurfaceBrush будет выполнять рендеринг поверхности композиции для любых подключенных визуалов. У него множество свойств, управляющих рисованием битовой карты, например интерполяцией, выравниванием, растягиванием, не говоря уже об операциях с самой поверхностью. CompositionEffectBrush принимает ряд кистей поверхности, создавая разнообразные эффекты.
Создание и применение цветной кисти — достаточно прямолинейная процедура. Вот пример на C#: Создать объект анимации и потом применить эту анимацию к конкретному объекту композиции на удивление легко. Структура Color предоставляется пространством имен Windows.UI и поддерживает альфа-канал, красный, зеленый и синий как 8-битовые значения цветов, что является отходом от предпочтения значений с плавающей точкой в DirectComposition и Direct2D. Удобство этого подхода к визуалам и кистям в том, что свойство цвета можно изменить в любой момент и любые визуалы, ссылающиеся на ту же кисть, будут автоматически обновлены. Кроме того, как я уже намекал, свойство Color можно даже анимировать. Как же это работает? Ответ на этот вопрос приводит нас к классам анимации. Иерархия классов анимации показана на рис. 7. Базовый класс CompositionAnimation предоставляет возможность сохранять именованные значения для использования в выражениях. Подробнее о выражениях я расскажу чуть позже. KeyFrameAnimation предоставляет типичные свойства анимации по ключевым кадрам (keyframe-based) вроде длительности, итерации и поведения окончания (stop behavior). Разные классы анимации по ключевым кадрам предлагают специфичные для типа методы вставки ключевых кадров, а также специфичные для типа свойства анимации. Например, ColorKeyFrameAnimation позволяет вставлять ключевые кадры с цветовыми значениями и управлять цветовым пространством для интерполяции между ключевыми кадрами.
Создать объект анимации и потом применить эту анимацию к конкретному объекту композиции на удивление легко. Допустим, я хочу анимировать прозрачность визуального элемента. Я мог бы задать прозрачность этого визуала равной 50% прямо в скалярном значении на C++: В качестве альтернативы можно создать объект скалярной анимации с ключевыми кадрами для получения переменной animation со значениями от 0.0 до 1.0, представляющими 0–100% прозрачности: Первый параметр InsertKeyFrame — относительное смещение от начала анимации (0.0) к ее концу (1.0). Второй параметр — это значение переменной animation в этой точке анимационной последовательности. Поэтому данная анимация будет плавно изменять значение от 0.0 до 1.0 в течение длительности анимации. Затем можно указать общую длительность этой анимации: Подготовив анимацию, достаточно подключить ее к объекту композиции и свойству на выбор: Метод StartAnimation на самом деле наследуется от базового класса CompositionObject, а значит, вы можете анимировать свойства множества различных классов. Это еще один отход от DirectComposition, где каждое анимируемое свойство предоставляло перегрузки для скалярных значений, а также объекты анимации. Windows-композиция предлагает гораздо более богатую систему свойств, которая открывает некоторые очень интересные возможности. В частности, она поддерживает возможность написания текстовых выражений, сокращающих количество кода, необходимого для более интересных анимаций и эффектов. Эти выражения разбираются в период выполнения, компилируются, а затем эффективно исполняются механизмом композиции в Windows. Вообразите, что вам нужно поворачивать визуальный элемент по оси Y и придать глубину его внешнему виду. Свойства RotationAngle визуального элемента, измеряемого в радианах, недостаточно, потому что оно не создаст преобразование, которое включает перспективу. По мере поворачивания визуала край, ближайший к человеческому глазу, должен выглядеть крупнее, а противоположный край — меньшим. На рис. 8 показан ряд вращающихся визуальных элементов, иллюстрирующих это поведение.
Как вы могли бы реализовать такой анимированный эффект? Что ж, давайте начнем со скалярной анимации по ключевым кадрам для угла поворота: Функция линейной плавности (linear easing function) переопределяет исходную функцию ускорения/замедления для создания непрерывного вращения. Затем нужно определить пользовательский объект со свойством, на которое можно ссылаться из выражения. Компоновщик предоставляет набор свойств как раз для этой цели: Набор свойств также является объектом композиции, поэтому можно использовать метод StartAnimation, чтобы анимировать пользовательское свойство так же легко, как любое встроенное: WinRT-классы могут реализовать дополнительные COM-интерфейсы, не видимые напрямую, если у вас есть лишь метаданные компонента в Windows. Теперь у меня есть объект, чье свойство Angle «находится в движении». Далее нужно определить матрицу преобразования для создания требуемого эффекта, в то же время делегируя его этому анимированному свойству для самого угла поворота. Знакомьтесь с выражениями (expressions): Анимация на основе выражения (expression animation) не является объектом анимации по ключевым кадрам, поэтому здесь нет относительных смещений по ключевым кадрам, на которые могли бы изменяться переменные, управляющие анимацией (с применением какой-либо функции интерполяции). Вместо этого выражения просто ссылаются на параметры, которые сами могут анимироваться в более традиционном смысле. Тем не менее, обязанность определения того, что такое «pre», «axis», «rotation» и «post», лежит на мне. Начнем с параметра axis: Метод CreateFromAxisAngle внутри выражения ожидает поворачивания оси, и это определяет ось вокруг оси Y. Он также ожидает передачи угла поворота и в этом мы можем положиться на набор свойств rotation с его анимируемым свойством Angle: Чтобы гарантировать поворачивание по центру визуального элемента, а не по левому краю, нужно заранее перемножить матрицу вращения, созданную CreateFromAxisAngle, с матрицей трансляции, которая логически смещает ось в точку вращения: Вспомните, что перемножение матриц не является перестановочным (commutative), поэтому матрицы pre и post действительно таковы, как есть. Наконец, после матрицы вращения можно добавить некоторую перспективу, а затем восстановить визуальный элемент в его исходном местоположении: Это удовлетворяет все параметры, на которые ссылается выражение, и теперь можно просто использовать анимацию на основе выражения, чтобы анимировать визуал, используя его свойство TransformMatrix: На данный момент я исследовал разнообразные способы создания, заполнения и анимации визуальных элементов, но как быть, если мне потребуется выполнять рендеринг визуалов напрямую? DirectComposition предлагал как предварительно выделенные поверхности (preallocated surfaces), так и разреженные битовые карты (sparsely allocated bitmaps), называемые виртуальными поверхностями, которые выделялись по запросу и были масштабируемыми. Windows-композиция, на первый взгляд, вообще не позволяет создавать поверхности. Есть класс CompositionDrawingSurface, но нет способа создать его без помощи извне. Ответ кроется в Interop API механизма композиции Windows. WinRT-классы могут реализовать дополнительные COM-интерфейсы, не видимые напрямую, если у вас есть лишь метаданные компонента в Windows. Зная об этих замаскированных интерфейсах, можно легко запросить их на C++. Естественно, это потребует несколько больше работы, когда вы шагнете за границы изящных абстракций, предоставляемых рядовым разработчикам через API композиции Windows. Так что первым делом мне нужно создать устройство рендеринга и использовать Direct3D 11, поскольку Windows-композиция пока не поддерживает Direct3D 12: Затем я установлю флаги создания устройства: Поддержка BGRA позволяет использовать более доступный Direct2D API для рендеринга с помощью этого устройства, а затем функция D3D11CreateDevice создает само аппаратное устройство: Далее нужно запросить DXGI-интерфейс устройства, так как это требуется для создания Direct2D-устройства: Теперь пора создать само Direct2D-устройство: Здесь я вновь разрешу применение отладочного уровня для дополнительной диагностики: Я мог бы сначала создать Direct2D-фабрику для создания устройства. Это было бы полезно, если бы я хотел создать аппаратно-независимые ресурсы. Здесь я просто использую сокращение, предоставляемое функцией D2D1CreateDevice: Поскольку CompositionGraphicsDevice является WinRT-типом, вновь можно использовать современный C++. Устройство рендеринга готово. У меня имеется Direct2D-устройство, которое можно использовать для рендеринга чего угодно. Теперь я должен сообщить механизму композиции Windows об этом устройстве. И здесь в игру вступают те самые замаскированные интерфейсы. Располагая компоновщиком, который я постоянно применял, я могу запросить интерфейс ICompositorInterop: ICompositorInterop предоставляет методы для создания поверхности композиции из DXGI-поверхности, что определенно было бы удобно, если бы я хотел включить существующую цепочку обмена в дерево визуальных элементов композиции. Но он содержит кое-что еще, куда более интересное. Его метод CreateGraphicsDevice создаст объект CompositionGraphicsDevice для данного устройства рендеринга. CompositionGraphicsDevice является обычным классом в API композиции Windows, а не замаскированным интерфейсом, но у него нет конструктора, поэтому придется создать его с помощью C++ и интерфейса ICompositorInterop: Поскольку CompositionGraphicsDevice является WinRT-типом, вновь можно использовать современный C++, а не указатели и ручную обработку ошибок. И именно CompositionGraphicsDevice наконец-то позволяет мне создать поверхность композиции: Здесь я создаю поверхность композиции размером 100 × 100 пикселей. Заметьте, что это физические пиксели, а не логические координаты с поддержкой DPI, предполагаемые и предоставляемые в остальной части Windows-композиции. Поверхность также обеспечивает рендеринг со смешиванием по 32-разрядному альфа-каналу, поддерживаемый Direct2D. Конечно, Direct3D и Direct2D пока не предоставляются через Windows Runtime, поэтому для рисования на этой поверхности придется вернуться к замаскированным интерфейсам: Во многом аналогично DirectComposition механизм композиции Windows поддерживает методы BeginDraw и EndDraw в интерфейсе ICompositionDrawingSurfaceInterop, которые заменяют типичные вызовы Direct2D-методов под теми же именами: Windows-композиция принимает исходное устройство рендеринга, переданное в момент создания устройства композиции, и на его основе создает контекст устройства или мишень рендеринга. При желании я могу передать отсекающий прямоугольник с размерами в физических пикселях, но здесь я просто выбираю неограниченный доступ к поверхности рендеринга. BeginDraw также возвращает смещение (вновь в физических пикселях), в том числе начало координат предполагаемой поверхности рисования. Оно не обязательно находится в левом верхнем углу мишени рендеринга, поэтому нужно позаботиться о подстройке или преобразовании любых команд рисования для корректного использования этого смещения. И вновь не вызывайте BeginDraw применительно к мишени рендеринга, поскольку механизм композиции Windows уже сделал это за вас. Эта мишень логически принадлежит API композиции, и следует быть осторожным, чтобы не удерживать ее после вызова EndDraw. Теперь мишень рендеринга готова, но не осведомлена о логическом или эффективном DPI для представления. Я могу использовать пространство имен Windows::Graphics::Display, чтобы получить логический DPI для текущего представления и задать DPI, который будет применяться Direct2D при рендеринге: Заключительный этап перед тем, как может начаться рендеринг, — та или иная обработка смещения в композиции. Одно из простых решений в том, чтобы использовать это смещение для создания матрицы преобразования. Вспомните, что Direct2D оперирует логическими пикселями, а значит, я должен использовать не только смещение, но и недавно заданное значение DPI: К этому моменту вы можете рисовать что угодно до вызова метода EndDraw применительно к interop-интерфейсу поверхности, чтобы быть уверенным в том, что любые пакеты Direct2D-команд рисования обрабатываются и изменения на поверхности отражаются в дереве визуальных элементов композиции: Конечно, я пока не сопоставил эту поверхность с визуальным элементом и, как упоминал ранее, у визуалов больше нет свойства content, а потому их рендеринг должен выполняться с помощью кисти. К счастью, компоновщик создаст кисть, представляющую уже подготовленную поверхность: Затем можно создать обычную спрайтовую кисть и использовать ее для того, что вытащить визуальный элемент на свет божий: Если вам по-прежнему недостаточно возможностей взаимодействия, вы можете даже взять XAML-элемент и получить нижележащий визуальный элемент композиции. Вот пример на C#: Несмотря на кажущийся временный статус, ElementCompositionPreview на самом деле готов к коммерческому использованию и может быть задействован в приложениях, передаваемых в Windows Store. Для любого UI-элемента статический метод GetElementVisual вернет визуальный элемент из нижележащего дерева визуальных элементов композиции. Заметьте, что он возвращает Visual, а не ContainerVisual или SpriteVisual, поэтому работать напрямую с дочерними визуальными элементами или применять кисть нельзя, но можно настраивать многие свойства визуальных элементов, предлагаемые Windows-композицией. Вспомогательный класс ElementCompositionPreview содержит некоторые дополнительные статические методы для добавления дочерних визуальных элементов под вашим контролем. Вы можете изменять смещение визуала и операции вроде проверки на попадание курсора в те или иные части UI (hit testing) по-прежнему будут работать на уровне XAML. Вы можете даже применять анимацию напрямую в Windows-композиции, не разрушая инфраструктуру XAML, которая опирается на нее. Давайте создадим простую скалярную анимацию для поворота кнопки. Мне нужно получить компоновщик от визуального элемента, а затем создать объект анимации, как и раньше: Сформируем простую анимацию для медленного вечного вращения кнопки с применением функции линейной плавности: Затем я указываю, что один полный поворот должен занимать три секунды, а вращение — продолжаться вечно: Наконец, я просто соединяя анимацию с визуальным элементом, предоставленным XAML, указывая механизму композиции анимировать его свойство RotationAngle: Хотя вы, возможно, сумеете вытянуть это из одного XAML, механизм композиции Windows предоставляет гораздо большую мощь и гибкость, учитывая, что он располагается на куда более низком уровне абстракции и, несомненно, обеспечивает более высокую производительность. Как еще один пример, Windows-композиция предоставляет кватернионные анимации (quaternion animations), в настоящее время не поддерживаемые XAML. Говорить о механизме композиции Windows можно и нужно гораздо дольше и подробнее. По моему скромному мнению, на сегодняшний день это самый прорывной WinRT API. Говорить о механизме композиции Windows можно и нужно гораздо дольше и подробнее. По моему скромному мнению, на сегодняшний день это самый прорывной WinRT API. Уровень его мощи просто ошеломляет, и в отличие от столь многих крупных API для UI и графики он не требует жертвовать производительностью и даже чрезмерно длительного освоения. Во многих отношениях Windows-композиция является наиболее репрезентативной среди всего того, что есть хорошего и интересного на платформе Windows. Следите за заметками группы Windows Composition в Twitter: @WinComposition. Кенни Керр (Kenny Kerr)— высококвалифицированный программист. Живет в Канаде. Автор учебных курсов для Pluralsight, обладатель звания Microsoft MVP. Ведет блог kennykerr.ca. Кроме того, читайте его заметки в twitter.com/kennykerr. Выражаю благодарность за рецензирование статьи экспертам Microsoft Марку Элдэму (Mark Aldham), Джеймсу Кларку (James Clarke), Джону Серна (John Serna), Джеффри Столлу (Jeffrey Stall) и Нику Уоггонеру (Nick Waggoner).  Привет, друзья! Сегодня мы с вами поговорим о замечательной  Привет, дорогие дети! Сегодня я хочу рассказать вам  Дорогие дети, сегодня мы поговорим о загадочной поговорке «  Привет, дорогие дети! Сегодня мы поговорим о забавной |
Иван Коробко
.png)
.png)
.png)
.png)
.png)
.png)
.png)