Windows xp манифест в delphi


Содержание

Манифест Windows XP

Итак, начнем с манифеста. Он представляет собой документ в формате XML, содержащий всю информацию, необходимую для взаимодействия приложения и библиотеки ComCtl32.dll версии 6.

Следует отметить, что манифесты широко используются во многих продуктах и технологиях, работающих в операционных системах Microsoft. С полной схемой XML манифеста вы можете ознакомиться в документации Microsoft MSDN.

Пример манифеста представлен в листинге 6.1.

Листинг 6.1. Манифест Windows XP

Your application description here.

Обратите внимание, что в элементе

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

При загрузке приложения операционная система Windows XP считывает манифест (если он есть) и получает информацию о том, что для выполнения приложения потребуется библиотека ComCtl32.dll версии 6.

Помимо этой информации манифест может содержать и другие необходимые сведения о приложении и условиях его работы. Например, общая информация о приложении и его версии представлены элементом

Вы можете добавить манифест в ваше приложение двумя способами:

  • использовать компонент TxpManifest;
  • добавить манифест в ресурсы приложения вручную. Рассмотрим их.
НОВОСТИ ФОРУМА
Рыцари теории эфира
01.10.2020 — 05:20: ВОСПИТАНИЕ, ПРОСВЕЩЕНИЕ, ОБРАЗОВАНИЕ — Upbringing, Inlightening, Education ->
[center][Youtube]69vJGqDENq4[/Youtube][/center]
[center]14:36[/center]
Osievskii Global News
29 сент. Отправлено 05:20, 01.10.2020 г.’ target=_top>Просвещение от Вячеслава Осиевского — Карим_Хайдаров.
30.09.2020 — 12:51: ВОСПИТАНИЕ, ПРОСВЕЩЕНИЕ, ОБРАЗОВАНИЕ — Upbringing, Inlightening, Education ->
[center][Ok]376309070[/Ok][/center]
[center]11:03[/center] Отправлено 12:51, 30.09.2020 г.’ target=_top>Просвещение от Дэйвида Дюка — Карим_Хайдаров.
30.09.2020 — 11:53: ВОСПИТАНИЕ, ПРОСВЕЩЕНИЕ, ОБРАЗОВАНИЕ — Upbringing, Inlightening, Education ->
[center][Youtube]VVQv1EzDTtY[/Youtube][/center]
[center]10:43[/center]

интервью Раввина Борода https://cursorinfo.co.il/all-news/rav.
мой телеграмм https://t.me/peshekhonovandrei
мой твиттер https://twitter.com/Andrey54708595
мой инстаграм https://www.instagram.com/andreipeshekhonow/

[b]Мой комментарий:
Андрей спрашивает: Краснодарская синагога — это что, военный объект?
— Да, военный, потому что имеет разрешение от Росатома на манипуляции с радиоактивными веществами, а также иными веществами, опасными в отношении массового поражения. Именно это было выявлено группой краснодарцев во главе с Мариной Мелиховой.

[center][Youtube]CLegyQkMkyw[/Youtube][/center]
[center]10:22 [/center]

Доминико Риккарди: Россию ждёт страшное будущее (хотелки ЦРУ):
https://tainy.net/22686-predskazaniya-dominika-rikardi-o-budushhem-rossii-sdelannye-v-2000-godu.html

Завещание Алена Даллеса / Разработка ЦРУ (запрещено к ознакомлению Роскомнадзором = Жид-над-рус-надзором)
http://av-inf.blogspot.com/2013/12/dalles.html

[center][b]Сон разума народа России [/center]

[center][Youtube]CLegyQkMkyw[/Youtube][/center]
[center]10:22 [/center]

Доминико Риккарди: Россию ждёт страшное будущее (хотелки ЦРУ):
https://tainy.net/22686-predskazaniya-dominika-rikardi-o-budushhem-rossii-sdelannye-v-2000-godu.html

Завещание Алена Даллеса / Разработка ЦРУ (запрещено к ознакомлению Роскомнадзором = Жид-над-рус-надзором)
http://av-inf.blogspot.com/2013/12/dalles.html

[center][b]Сон разума народа России [/center]

Блог GunSmoker-а

. when altering one’s mind becomes as easy as programming a computer, what does it mean to be human.

11 февраля 2011 г.

DLL, DLL Hell, перенаправление DLL, S >

DLL (Dynamic Link Library — библиотека динамической компоновки) — понятие операционных систем Microsoft Windows и IBM OS/2; это библиотека, позволяющая многократное применение несколькими приложениями. K DLL относятся также элементы управления ActiveX и драйверы. В мире UNIX аналогичные функции выполняют т.н. shared objects («разделяемые объекты»). Формат файлов DLL придерживается тех же соглашений, что и формат исполняемых файлов, сочетая код и данные.

Введение

DLL Hell (DLL-кошмар, буквально: DLL-ад) — тупиковая ситуация, связанная с управлением динамическими библиотеками DLL в операционной системе Microsoft Windows. Аналогичная проблема в средах UNIX носит название Dependency Hell. Сущность проблемы заключается в конфликте версий DLL, призванных поддерживать определённые функции. По исходному замыслу, DLL должны быть совместимыми от версии к версии и взаимозаменяемыми в обе стороны. На практике однако оказалось, что достичь этого невозможно. Вы устанавливаете одну программу, и неожиданно перестает работать другая программа, казалось бы, совершенно не связанная с первой (это может быть сообщение вроде «не найдена библиотека», «не найдена процедура в библиотеке» или что-то более тонкое вроде неправильной работы программы, вылета или зависания). Это происходит потому, что, незаметно для вас, две программы объединены использованием одного файла библиотеки DLL. Для работы этих двух программ могут требоваться совершенно разные версии файла MSVCRT.DLL в системной папке. Или же одна программа может обновить элемент управления ActiveX, который используется другой программой, при этом вторая программа может быть не полностью совместима с этим обновлением.

Разве это применимо ко мне?

Вы можете подумать: ну, со мной такого никогда не случится, ведь я очень грамотно проектирую свои DLL, так что новая версия библиотеки всегда обратно совместима с предыдущей, и все существующие программы смогут безболезненно использовать новую версию DLL вместо старой. А мой установщик тоже весьма грамотен и никогда не перезапишет более новую версию DLL старым вариантом, так что в системе всегда будет только последний вариант библиотеки. И установщик никогда не удаляет мою DLL — так что я в порядке, да?

Вообще-то нет. Проблема в том, что даже если вы всё сделали правильно, обязательно найдутся люди, которые используют вас неправильно. Например, пусть ваша DLL экспортирует такую функцию:
Соглашение по вызову просто: функция вернула True — значит, она завершилась успешно и вы можете использовать данные в Buffer . Если же функция вернула False , то она завершилась ошибкой, а значение Buffer не определено. Казалось бы, простое и логичное правило: что тут может пойти не так?

Дело в том, что проверять результат работы функции — это же куча работы. Люди, как известно, ленивы. Поэтому они могут заметить, что ваша функция не трогает буфер Buffer , если она завершается неудачей. И они могут написать код вроде такого:
В этом куске кода подразумевается, что если функция Funcenstein завершится неудачно, то в Buf будут нули (ведь он не тронут). Нули — это допустимое значение (скажем, нуль-терминированная строка нулевой длины), поэтому мы просто продолжаем выполнение (функция DoSomething ).

Но нигде в контракте функции Funcenstein об этом не сказано, поэтому это — деталь реализации. Конечно же, вы и подумать не можете, что кому-то придёт в голову использовать вашу DLL таким образом. Поэтому в новой версии DLL (и функции) вы используете буфер Buffer для промежуточных вычислений. Вам нужен кусок памяти, а тут как раз он без дела болтается — так что вы используете его. Вы имеете полное право на это, вы всё делаете правильно. Вот только, когда вы установите на машину клиента новую версию своей DLL, как перестанет работать установленная программа другого человека, который использовал вашу DLL. Вина ваша? Нет. Но что скажет пользователь? «Не ставьте новую версию — из-за него ломается !», или: «Проклятый DLL Hell, проклятый Microsoft и проклятый Билл Гейтс!», или даже просто: «Компьютеры такие глупые! Их так тяжело использовать!».

Windows 2000: перенаправление DLL

Раньше приходилось принимать решение о том, какая программа «победила», а какая — «проиграла». Начиная с Windows 2000 появились средства, помогающие разрешить такие конфликты. Тем не менее эти средства представляют собой лишь временные решения, позволяя вернуть систему в рабочее состояние, пока вы будете заниматься поиском более постоянного решения конфликта.

В Windows 2000 реализована минимальная версия технологии, поставляемой сейчас под модным названием Dynamic-Link Library Redirection (перенаправление библиотек динамической компоновки). Чтобы включить перенаправление библиотеки DLL, создайте файл с тем же именем, что и файл программы, для библиотек DLL которой требуется перенаправление, но добавив .local к имени файла. Например, чтобы использовать перенаправление для программы C:\Program Files\Litware Inc\Invoice.exe следует создать файл C:\Program Files\Litware Inc\Invoice.exe.local . Содержимое файла не имеет значения; важен сам факт существования этого файла.

После включения перенаправления для программы все попытки этой программы загрузить библиотеку DLL сначала приведут к поиску в той папке, где расположен файл программы, и лишь затем — в обычных местах. Поэтому в случае конфликта между различными файлами MSVCRT.DLL можно включить перенаправление для каждой из программ и поместить копии файлов MSVCRT.DLL для частного использования в папку установки каждой программы. После этого каждая программа будет использовать свою собственную версию библиотеки MSVCRT.DLL , а именно ту версию, с которой выполнялось тестирование программы.

Волшебство этого метода заключается ещё и в том, что он работает даже тогда, когда программа использует полный путь для загрузки библиотеки DLL. Например, представим себе, что программа пытается загрузить библиотеку C:\Program Files\Common Files\Proseware Inc\taxplugin.dll . После обновления до версии Proseware 2.0 вы обнаруживаете, что подключаемые модули расчета налогов несовместимы с программой подготовки счетов. Вы можете скопировать старую версию подключаемого модуля расчета налогов в C:\Program Files\Litware Inc\taxplugin.dll . Даже несмотря на то, что при загрузке подключаемого модуля расчета налогов используется полный путь, перенаправление библиотек DLL сначала выполнит поиск в текущей папке и будет использовать локальную копию вместо копии в папке «Proseware Inc».

В операционных системах Windows XP и выше правила перенаправления библиотек DLL немного отличаются, но общий принцип остается тем же. Кроме создания файла с расширением « local » можно создать и папку с таким расширением. В этом случае поиск будет выполняться в папке с расширением « local », а не в папке установки программы. Это позволяет использовать перенаправление для нескольких программ в одной папке, не создавая конфликтов. К примеру, если у программы из примера выше существует папка C:\Program Files\Litware Inc\Invoice.exe.local , то будет загружена DLL C:\Program Files\Litware Inc\Invoice.exe.local\taxplugin.dll

Осталось только заметить что .local файлы и папки игнорируются, если приложение использует манифесты для управления зависимостями (см. ниже).

Перенаправление библиотек DLL не позволит полностью избежать кошмара библиотек DLL, но, по крайней мере, оно предоставляет средства первой помощи для контроля над ситуацией на время решения проблемы. По этой же причине, если раньше для установщиков были рекомендации: пишите свои DLL в системные папки, ведь тогда их смогут использовать и другие программы. И вы сэкономите на ресурсах! То начиная с Windows 2000 рекомендации меняются на противоположные: ребята, диск сегодня уже не ограничитель, так что установщикам следует располагать DLL в папке с программой. Да, место не сэкономите, но зато программа будет работать надёжно, ведь её не коснётся DLL Hell.

Windows XP: изолированные приложения и side-by-side сборки

Начиная с Windows XP в вашем распоряжении появляется новый механизм, позволяющий избавиться от проблемы DLL Hell: Isolated Applications и Side-by-side Assemblies. Это решение Microsoft Windows для уменьшения конфликтов версий в Windows приложениях. С его помощью разработчик может описывать требования своих приложений и DLL, так что они будут защищены от влияния других версий библиотек в системе. Конечные клиенты же получают выгоду от использования этого механизма тем, что приложения теперь будут работать надёжнее и будут устойчивы к обновлениям.

Эта технология поддерживаются начиная с Windows Server 2003 и Windows XP. На Windows 2000 вам нужно использовать Dynamic-Link Library Redirection. Кстати говоря, все из вас наверняка уже использовали технологию Isolated Applications, даже не осознавая этого. Так называемый «XP Manifest» включает в вашу программу специальное описание, что вашей программе требуется новая версия библиотеки Common Controls, так что при запуске вашей программы она получает особую версию comctl32.dll из папки WinSxS , а не обычную comctl32.dll из System32 . Это и есть Isolated Applications в действии. Впрочем, сама Windows XP использует эту технологию далеко не везде. А вот Vista и выше используют её на полную (это можно заметить по размеру папки WinSxS на обоих системах).

Side-by-side сборки и изолированные приложения

Side-by-side assemblies — это Win32 сборки (DLL или COM-сборки), описываемые манифестом, разработанные так, что несколько версий одной и той же DLL могут быть загружены в один процесс и работать в нём одновременно, без конфликтов друг с другом (вот откуда идёт название «side-by-side» — т.е. работающие одновременно, спина-к-спине). Когда программист пишет приложение с использованием side-by-side сборок, он создаёт для приложения манифест, указывающий какая версия сборки нужна для этого приложения, если в системе есть несколько версий одной сборки. Такое приложение с манифестом называется isolated application — изолированное приложение. Название, опять же, очевидно: ведь приложение изолируется от влияние других версий библиотек.

Приложение называется полностью изолированным, если все его компоненты являются side-by-side сборками. Если же ваше приложение использует один или более компонент, не являющихся side-by-side сборками (например: приложение использует обычную DLL без манифеста), то приложение называется частично изолированным. Заметьте, что частично изолированное приложение всё ещё уязвимо для DLL Hell. Учитывая, что мы уже сказали про «XP Manifest», многие (если не все) из ваших программ уже являются частично изолированными приложениями, хотя и в весьма малой степени.

Разработчикам программ рекомендуется разрабатывать полностью изолированные приложения и обновить свои старые приложения до полностью изолированных по следующим причинам:

  • Изолированные приложения более устойчивы и надёжны, потому что на них не влияют установки, обновления или удаления других программ в системе.
  • Изолированные приложения могут быть спроектированы так, что они будут запускаться ровно с теми версиями библиотек, с которыми они тестировались на машине разработчика.
  • Изолированные приложения могут использовать функциональность side-by-side сборок Microsoft.
  • Изолированные приложения не зависят от сроков поставки их side-by-side сборок, потому что приложения и администраторы могут обновлять конфигурацию после развёртывания приложения, не требуя переустановки приложения. Понятно, что это не применимо в случае, если у вас есть только одна версия сборки.
  • Полностью изолированное приложение может быть установлено с использованием команды xcopy . Windows Installer также может быть настроен для установки полностью изолированного приложения без влияния на реестр. (примечание: в этом пункте в основном имеется ввиду т.н. «registration free COM» и аналогичные вещи)

В некоторых случаях вы можете обновить существующее приложение до частично или полностью изолированного без изменения исходного кода и иногда даже без перекомпиляции. Вы можете создать для приложения манифест, который описывает зависимости приложения от side-by-side сборок. Если приложение использует компоненты, которые не являются side-by-side сборками, то их можно распространять как частные сборки (см. ниже).

Переделать приложение в полностью изолированное не всегда возможно. К примеру, некоторые компоненты, защищаемые Windows File Protection (WFP), не доступны в виде side-by-side сборок и не могут быть установлены вместе с приложением как частные сборки.

Управление сборками с помощью манифестов

Как уже было сказано, side-by-side сборки Windows описывается манифестами. Манифесты содержат мета-данные, которые описывают side-by-side сборки и зависимости этих сборок. Сборка может содержать набор DLL, классов Windows, COM серверов, библиотек типов или интерфейсов, которые представляются приложению как единое целое. Все они описываются в манифесте сборки. Обычно же, типичная side-by-side сборка — это одна DLL с одним манифестом в ней. К примеру, сборка COMCTL32 от Microsoft является DLL библиотекой comctl32.dll с одним манифестом. А вот сборка run-time от Microsoft Visual C++ содержит несколько файлов. В некоторых случаях версии сборки, указанные в манифесте, могут быть изменены глобально или для одного приложения — авторами сборок, разработчиками приложений или системными администраторами. Разработчики также могут использовать side-by-side сборки, разработанные Microsoft, или side-by-side сборки других разработчиков. Мы уже не раз упоминали пример с подключением новой версии (6.0) библиотеки Common Controls с поддержкой тем в ваших приложениях.

Процесс приложения может использовать более одной версии side-by-side сборки. К примеру, приложение загружает две библиотеки, одна из которых использует версию 1 side-by-side сборки, а вторая загружаемая библиотека требует версии 2 той же сборки. Для различения сборок друг от друга используются манифесты и номера версий сборок. Используя эту информацию, загрузчик DLL может определить правильную версию DLL для загрузки. Это показано на следующем рисунке:

В этом примере, обе версии comctl32.dll (6.0 и 5.0) находятся в кэше side-by-side сборок и доступны для приложений. Когда приложение запускается и инициирует загрузку DLL, то менеджер side-by-side сборок определяет, какая версия библиотеки нужна для приложения (что описано в манифесте этого приложения). Если такового требования нет, то менеджер загрузит вариант по-умолчанию. Для Windows XP это будет версия 5.0 comctl32.dll . Если менеджер находит информацию о зависимости от версии 6.0 (указано в манифесте), то именно эта версия и будет загружена для приложения.

Манифесты

Итак, с понятиями изолированного приложения и side-by-side сборок мы разобрались. А что такое манифест, о котором мы постоянно говорим? Манифест представляет собой XML файл, который привязывается к side-by-side сборке или изолированному приложению. Он может внедряться в исполняемый файл или быть отдельным файлом. Манифесты и файлы конфигураций не локализуются. Манифесты идентифицируют саму сборку (указывая её имя и версию) — через элемент assemblyIdentity . Они также могут содержать информацию о привязках и активации — вроде COM-классов, интерфейсов и библиотек типов. Ранее эта информации хранилась в реестре. В манифестах также указываются файлы, входящие в сборку. Side-by-side сборки не регистрируются в системе, но они доступны для приложений (и других сборок), которые указывают свою зависимость от них в своих манифестах.

Манифесты в виде отдельных файлов позволяют администраторам и приложениям управлять версиями side-by-side сборок после развёртывания приложения. Каждая side-by-side сборка должна иметь манифест, ассоциированный с ней. При установке Windows XP устанавливаются side-by-side сборки от Microsoft вместе с их манифестами. Если вы собираетесь разрабатывать ваши собственные side-by-side сборки, то вы также должны устанавливать их манифесты.

Как вы уже догадались, манифесты сборок и манифесты изолированных приложений — это немного разные вещи. Существуют такие типы манифестов:

  • Манифесты сборок (assembly manifests) описывают side-by-side сборки. Они используются для управления именами, версиями, ресурсами и зависимостями side-by-side сборок. Манифесты общих сборок хранятся в папке WinSxS (из System32 ). Манифесты частных сборок хранятся либо в ресурсах DLL, либо в папке приложения.
  • Манифесты приложений (application manifests) описывают изолированные приложения. Они используются для управления именами и версиями сборок, с которыми должно связываться приложение при выполнении. Манифесты приложений хранятся в папке с исполняемым файлом приложения, либо же внедряются в ресурсы приложения.
  • Файлы конфигурации приложений (Application Configuration Files) — это манифесты, используемые для перенаправления версий зависимых сборок.
  • Файлы конфигурации поставщика (Publisher Configuration Files) — это манифесты, используемые для перенаправляения side-by-side сборки на совместимую с ней версию.

В этой статье не рассматриваются вопросы перенаправления сборок.

Чтобы создать манифест для приложения или сборки, вы создаёте пустой текстовый файл с расширением .manifest. К примеру, манифест приложения или сборки, который ссылается на приложение или сборку myassembly должен иметь следующий формат: Вы можете пропустить часть [.resource-ID] , если resource-ID (идентификатор ресурса — см. чуть ниже) равен 1. Например, Project1.exe.manifest , эквивалентный ему Project1.exe.1.manifest или Project1.exe.2.manifest .

Внимание: если вы применяете манифест в виде отдельного файла и меняете сам манифест без изменения двоичного модуля, то вы должны обновить дату изменения исполняемого модуля, чтобы манифест вступил в действие. Происходит это по той простой причине, что Windows кэширует данные и не проверяет наличие/отсутствие/изменение манифеста, если файл программы не поменялся. Это типичная оптимизация частого случая (файл не меняется).

Если вам не нравится манифест в виде отдельного файла, а также для случаев, когда это неприменимо — вы можете внедрить манифест в исполняемый файл в виде ресурса. Для этого используются такие константы: Значение идентификатора ресурса определяет, как зависимости сборок, описанные в манифесте, будут использоваться загрузчиком ОС.

К примеру, если вы установите идентификатор ресурса в 1, то загрузчик ОС будет использовать зависимости сборок, указанные в манифесте, как умалчиваемые для всего процесса. Все загружаемые плагины также будут использовать эти же зависимости.

Таблица ниже показывает, как загрузчик ОС использует манифест с различными значениями идентификатора ресурса. Заметьте, что разработчик может управлять этим процессом вручную, используя функции активации контекста (Activation Context API), которые не рассматриваются в этой статье.

Идентификатор По умолчанию для процесса? Используется при статическом импорте? Используется для EXE? Используется для DLL?
1 Да Да Да Нет
2 Нет Да Да Да
3 Нет Нет Да Да

CREATEPROCESS_MANIFEST_RESOURCE_ID должен использоваться приложениями, которые не работают с плагинами.

ISOLATIONAWARE_MANIFEST_RESOURCE_ID используется приложениями, которые загружают сторонние библиотеки (плагины).

Подробнее об этом процессе — см. ниже в разделе практики.

Частные и разделяемые сборки

Разделяемая (shared) сборка — это сборка, доступная для использования несколькими приложениями на машине. В Windows 7, Windows Vista и Windows XP side-by-side сборки могут быть установлены как разделяемые. Разделяемые side-by-side сборки не регистрируются глобально в системе, вместо этого они доступны приложениям, которые указывают зависимость от этой сборки в своих манифестах. Несколько разных версий side-by-side сборок могут разделяться одновременно несколькими приложениями, работающими одновременно.

Разделяемые side-by-side сборки устанавливаются в папку WinSxS. Разделяемые side-by-side сборки могут быть установлены при установке обновления операционной системы или пакетом Windows Installer, который устанавливает или обновляет ваше приложение.

До Windows XP общие сборки (называемые просто DLL) регистрировались глобально и устанавливались в папку System. В этом случае приложению была доступна только последняя установленная версия сборки. Side-by-side сборка могла быть установлена как частная сборка для эксклюзивного использования приложением.

Как видите, здесь обычные и привычные вещи называются новыми именами.

Частная (private) сборка — это сборка, которая распространяется с конкретным приложением и используется только этим приложением. Иными словами, другие приложения не используют эту частную сборку (сборка не является разделяемой). Частные сборки являются одним из способом создавать изолированные приложения. Частные сборки должны проектироваться для работы side-by-side с другими версиями этой же сборки в системе.

Частные сборки должны иметь манифест сборки. Заметьте, что при распространении DLL как сборки к ней применяются ограничения на имя, чтобы соответствовать способу поиска частных сборок в Windows. При этом рекомендуется включать манифест сборки в саму DLL. В этом случае идентификатор ресурса должен быть равен 1 и имя частной сборки должно быть таким же, как и имя DLL. Например, если имя DLL — MICROSOFT.WINDOWS.MYSAMPLE.DLL , то значение атрибута name , используемого в элементе assemblyIdentity манифеста, также должно быть Microsoft.Windows.mysample . Альтернативный метод поиска частных сборок — предоставить манифест сборки в отдельном файле. В этом случае имя сборки и имя манифеста должны быть отличны от имени DLL. К примеру, Microsoft.Windows.mysampleAsm , Microsoft.Windows.mysampleAsm.manifest или Microsoft.Windows.mysample.dll . Как правило, это применяется для сборок, состоящих более чем из одной DLL.

Частные сборки устанавливаются в папку приложения. Обычно это сама папка приложения с исполняемым файлом. Частные сборки также могут располагаться в подпапке с именем сборки, или в подпапке с именем языка (тема локализации сборок не рассматривается в этой статье). Например, вы можете использовать следующую структуру папок для размещения частной сборки Microsoft.tools.pop без указания языка:

Структура Описание
AppDir\MICROSOFT.TOOLS.POP.DLL Манифест внедрён как ресурс в саму DLL.
AppDir\Microsoft.Tools.Pop.MANIFEST Манифест сделан в отдельном файле.
AppDir\MICROSOFT.TOOLS.POP\MICROSOFT.TOOLS.POP.DLL Манифест внедрён как ресурс в DLL, которая расположена в подпапке с именем сборки.
AppDir\Microsoft.Tools.Pop\Microsoft.Tools.Pop.MANIFEST Манифест расположен в отдельном файла в подпапке с именем сборки.

Частные сборки могут быть установлены любым способом установки, который может копировать файлы сборки в папку — к примеру, простая команда xcopy .

Частные сборки могут быть также установлены на операционную систему ниже Windows XP. В этом случае сборка должна быть зарегистрирована в системе обычным способом, а манифест сборки использоваться не будет. Копия частной сборки может быть скопирована в папку приложения для эксклюзивного использования этим приложением. Другая версия сборки может быть глобально зарегистрирована в системе и быть доступной любому приложению. Глобальная версия сборки может быть той версией, что установило ваше приложение, или любой другой — как старше, так и младше. Мы обсуждали эту тему в разделе выше, где мы говорили про перенаправление DLL в Windows 2000.

Заметьте, что шаги для создания частной сборки идентичны созданию разделяемой сборки (рассмотрено в разделе практики ниже), за исключением следующих:

  • Частную сборку можно не подписывать, а элемент publickeyToken является необязательной частью блока assemblyIdentity манифеста сборки.
  • Частные сборки могут быть установлены с использованием любой технологии установки — простым копированием. Частные сборки не обязаны устанавливаться с помощью Windows Installer.

Практический пример: включение визуальных стилей

Общие элементы управления (common controls), которые включены в состав Windows XP, Windows Vista и Windows 7, имеют новую функциональность, которая называется «визуальными стилями» (visual styles). Внешний вид элементов управления может быть изменён, основываясь на настройках внешнего вида системы, изменяемых пользователем.

Примечание: визуальные стили не работают в режиме 256-цветов.

На рисунке ниже показано окно с панелью задач на Windows Vista. Приложение было скомпилировано со стандартной библиотекой общих элементов управления.

Для сравнения — на рисунке ниже показано то же окно, но в этот раз приложение было привязано к новой версии общих элементов управления и, поэтому, использует визуальные стили. Обратите внимание на разницу в отображении кнопок в клиентской области.

Новые библиотеки (ComCtl32.dll версии 6 и UxTheme.dll) доступны в по умолчанию в Windows XP и выше. Они позволяют задействовать в вашем приложении визуальные стили. UxTheme.dll используется ComCtl32.dll для реализации визуальных стилей. ComCtl32.dll запрашивает у UxTheme.dll размеры и другую информацию об элементах управления и вызывает UxTheme.dll для прорисовки различных частей элементов управления.

Чтобы использовать визуальные стили, приложение должно быть запущено на системе с наличием ComCtl32.dll версии 6. Windows XP и выше содержит ComCtl32.dll версии 5 и версии 6. Предыдущие версии операционной системы Windows содержат только ComCtl32.dll версии 5. По умолчанию, приложения везде используют ComCtl32.dll версии 5 по соображениям обратной совместимости. Если вы хотите, чтобы ваше приложение использовало ComCtl32.dll версии 6, вам нужно добавить манифест к своей программе. Тогда ваш код будет использовать ComCtl32.dll версии 5 на старых системах, а где возможно — ComCtl32.dll версии 6. Версия 6 также включает в себя несколько новых элементов управления и некоторые новые возможности старых элементов управления, но самое большое изменение — это, конечно же, поддержка визуальных стилей.

Если вы используете только стандартные элементы управления, то вам не нужно делать никаких других действий для включения визуальных стилей. Если же вы используете элементы управления с custom-прорисовкой, то вам нужно использовать предоставляемое API для получения информации о текущем визуальном стиле и рисовать свои элементы управления в этом стиле. См. Using Visual Styles with Owner-Drawn Controls.

Автоматическое использование для чайников

В Delphi есть два способа для подключения манифеста — автоматический и вручную. Для автоматического способа вам нужно зайти в настройки проекта ( Project / Options ), перейти на вкладку Application и установить галочку Enable runtime themes :

Обратите внимание, что эта опция называется неверно: темы (themes) были ещё в Windows 95, а визуальные стили (visual styles) появились только в Windows XP. Поэтому эта опция должна называться как минимум Enable visual styles . Кроме того, эта же опция подключает в программу и «манифест Vista» — указание требуемого уровня привилегий для работы программы. О чём, вообще говоря, в названии опции нет даже и намёка. Поэтому, правильное название опции должно было бы быть Add default manifests (enable visual styles and set execution level) .

В старых версиях Delphi такой опции нет, а вместо неё используется компонент TXPManifest . Вам достаточно бросить его на форму (одну, любую) в вашем приложении:

Для отключения визуальных стилей вы снимаете галочку Enable themes (а в случае использования старых версий Delphi — удаляете с формы компонент TXPManifest , а также удаляете модуль XPMan из списка uses ).

Автоматический способ прост, но не лишён недостатков. Во-первых, при его использовании в программу включается манифест по умолчанию. Если вас не устраивают эти настройки, то вы не можете их изменить. Во-вторых, он работает не для всех сценариев использования. В-третьих, использование этого способа означает подключение в программу манифеста. Если вам нужно использовать манифест для указания дополнительной информации (см. примеры ниже), то вы не можете это сделать — ведь манифест может быть только один. В этом случае вам нужно отказаться от манифеста по умолчанию и добавить в программу свой манифест, включив в него как вашу дополнительную информацию, так и информацию, добавляемую автоматическим способом.

Поэтому, когда вы не можете использовать автоматический способ, то можно сделать всё руками.

Использование манифестов для включения визуальных стилей в приложениях

Манифест приложения позволяет последнему указать, какую версию библиотеки ComCtl32.dll оно требует. Манифесты представляют собой XML файлы. Имя файла манифеста приложения представляет собой имя файла приложения с добавленным к нему «.manifest». Например, Project1.exe.manifest . Следующий пример манифеста показывает, что первая секция манифеста относится к нему самому. В таблице ниже показаны атрибуты, которые необходимо установить для элемента assemblyIdentity :

Атрибут Описание
version Версия манифеста. Версия представляется в форме major.minor.revision.build (т.е., n.n.n.n, где n assemblyIdentity в блоке зависимостей:
Атрибут Описание
type Тип компонента-зависимости. Например: Win32.
name Имя компонента.
version Версия компонента.
processorArchitecture Процессор, для которого предназначен компонент.
publicKeyToken Токен публичного ключа компонента.
language Язык компонента.

Ну а теперь — и сам пример манифеста.

Важно: если вы пишете приложение для платформы Windows x86-64, то вы должны изменить запись processorArchitecture на processorArchitecture=»amd64″ . Вы также можете указать «*» для указания любой платформы. Части до блока dependency (т.е. первый блок assemblyIdentity и тэг description ) должны быть модифицированы для вашего приложения вписыванием в него ваших значений. Обратите внимание, как атрибут name в первом блоке assemblyIdentity похож на атрибут name во втором блоке assemblyIdentity .

Если вам не нравится манифест в виде отдельного файла, то вы можете внедрить манифест в исполняемый файл в виде ресурса. Для этого используются такие константы: Вот как это делается. Вы создаёте пустой текстовый файл с расширением .rc , например Project1_manifest.rc . Затем вы добавляете в него строчку: Где 1 и 24 — константы выше, а Project1.exe.manifest — уже созданный и существующий файл, содержащий манифест (XML файл с текстом из примера выше).

После чего вы добавляете .rc файл в проект, используя команду Project / Add to project . Добавленный файл будет виден в менеджере проектов (слева — Delphi XE, справа — Delphi 7):

Примечание 1: в Delphi XE и выше намного проще воспользоваться менеджером ресурсов, вызываемым из меню Project / Resources . Вы просто щёлкаете по кнопке «Add», выбираете свой .manifest файл и указываете его имя (1) и тип ресурса (24). Всё, не нужен никакой .rc файл.

Примечание 2: возможно, что в некоторых случаях вам также может потребоваться вручную добавить эту строчку в файл проекта (например, Project1.dpr): Сделать это можно в любое место — к примеру, сразу после строки с program и до uses : Каждый раз, когда вы будете делать компиляцию проекта, файл Project1_manifest.rc будет скомпилирован в Project1_manifest.res (вот почему мы назвали его Project1_manifest.rc , а не Project1.rc — чтобы не перезаписать стандартный Project1.res ), а файл Project1_manifest.res будет подключен в готовый .exe файл.

Если по какой-то причине вам не удаётся скомпилировать .rc файл таким образом, то вам нужно будет сделать это вручную вызвав компилятор ресурсов brcc32 из папки Bin Delphi, например (запускать надо из папки с .rc файлом): Эта команда создаст файл Project1_manifest.res по Project1_manifest.rc , после чего файлы .rc и .manifest можно удалить, а в .dpr файл вставить: Файл Project1_manifest.res , разумеется, удалять не нужно.

В следующих пунктах описаны шаги для применения визуальных стилей в приложениях разных типов. Обратите внимание на отличия манифестов в каждом случае.

Использование ComCtl32.dll версии 6 в приложениях, которые используют только стандартные расширения

Примеры приложений, которые не используют расширения сторонних производителей:

  • Калькулятор
  • Косынка
  • Сапёр
  • Блокнот
  • Солитер

Для приложений этого типа используется такой манифест: И в RC-файле подключается он так: Либо же вы можете просто оставить .manifest файл в папке с программой. ОС сначала загрузит манифест из файла, а лишь затем будет проверять секцию в exe-файле. Версия манифеста в отдельном файле имеет приоритет.

Использование ComCtl32 версии 6 в приложениях, которые используют расширения, плагины или DLL от других производителей

Вот примеры приложений, использующих расширения от других людей:

  • Microsoft Management Console (MMC)
  • Оболочка Windows (Windows Shell)
  • Delphi
  • Total Commander

ComCtl32.dll версии 6 не является обратно совместимой с предыдущими версиями библиотеки. Использование ComCtl32.dll версии 6 требует изменения кода. Поэтому, если ваше приложение использует компоненты, разработанные другими людьми, вы не можете изменить их так, чтобы они работали с ComCtl32.dll версии 6. Иными словами, такое приложение применяет ComCtl32.dll версии 6 только для себя, но не для загружаемых компонентов. А каждый компонент отдельно декларирует, какая версия ComCtl32.dll ему необходима.

Для приложений этого типа используется такой манифест: И в RC-файле подключается он так:

Использование ComCtl32 версии 6 в Панели управления или DLL, которая запускается RunDll32.exe

Использование ComCtl32 версии 6 в оснастке MMC

Практический пример: использование частных сборок

Настало время поговорить и о создании своих собственных сборок. Быть может вам кажется, что это что-то страшное — ведь сколько всего было сказано в этой теме. Но на самом деле это очень просто.

Одна DLL — одна сборка

Для начала возьмите или создайте любое .exe приложение, которое загружает или статически ссылается на DLL. Вы можете создать пустое приложение и пустую DLL для этого эксперимента. Запустите приложение. Оно запустилось? Запустилось. И приложение загрузило DLL. Что же нам сделать, чтобы превратить DLL в сборку? А всего ничего: создать манифест сборки и подключить его в DLL.

Вот пример файла манифеста сборки: Подключается он как: Здесь мы говорим, что наша DLL — это частная сборка с именем Alex.Demo.Assembly версии 1.0.0.0. Заметьте, что архитектура процессора здесь указана явно. Кроме того, здесь отсутствуют атрибут publickeyToken , необходимый для разделяемых сборок.

Ну. вот, собственно и всё. Компилируйте DLL (разумеется, её имя должно быть Alex.Demo.Assembly.dll и приложение должно загружать или импортировать функцию именно из Alex.Demo.Assembly.dll ) и теперь вы получите уже не просто DLL, а полноценную частную сборку.

Запустите приложение теперь. Ну, вроде бы ничего не изменилось, да? Да. Всё потому, что в самом приложении мы не указали зависимость от этой сборки. Поэтому приложение загружает эту сборку как обычную DLL.

Как у нас указываются зависимости от сборки? Правильно, подключением манифеста приложения. Вот пример такого манифеста: Подключается манифест как обычно: Заметьте, что, по сути, это «стандартный манифест XP» (если так можно выразиться) с добавленным к нему одним блоком dependency , описывающий зависимость приложения от сборки Alex.Demo.Assembly версии 1.0.0.0.

Что будет, если запустить приложение теперь? Ну, вроде бы, снова ничего не изменится. Однако, под капотом произошло важное изменение: теперь DLL грузится как сборка. Что означает, что в силу вступают проверки версионной зависимости.

Как это можно увидеть? Попробуйте поменять версию (атрибут version ) либо в манифесте приложения, либо в манифесте сборки (конечно же, речь идёт об атрибуте version для блока assemblyIdentity с name = Alex.Demo.Assembly ). Скажем, пусть мы поменяем номер самой сборки с 1.0.0.0 до 2.0.0.0. Пересоберём сборку и запустим приложение.

Опа. Теперь мы получаем сообщение о том, что приложение не может найти нужную DLL:

Как же так, ведь DLL никуда не пропала и вообще мы её не двигали и ничего не меняли? А вот это и есть действие механизма сборок. Ведь приложению нужна сборка Alex.Demo.Assembly версии 1.0.0.0, но в папке лежит только версия 2.0.0.0. Это не та, что нам надо. А версии 1.0.0.0 нигде нет — вот поэтому приложение не может её загрузить и отказывается запускаться.

Это справедливо как для статического связывания, так и для загрузки через LoadLibrary .

Одна сборка — несколько DLL

Итак, мы реализовали сборку в виде единственной DLL и нам это практически ничего не стоило. Всего делов-то, добавить манифест (кстати, было бы неплохо в опции проекта Delphi добавить галочку «Enable assembly manifest» по аналогии с «Enable visual themes»).

Что касается ситуации с несколькими файлами в одной сборке, то я не буду подробно её описывать — вы сможете разобраться с ней по аналогии. Замечу только, что для этого манифест приложения должен ссылаться на сборку, манифест сборки должен быть отдельным файлом ( имя-сборки.manifest ), компоненты сборки должны называться отлично от имени самой сборки, а приложение при импорте функций из DLL должно ссылаться на компонент (конкретную DLL), а не имя сборки (потому что сборка — это описание зависимостей и файлов, а не библиотека функций). Иными словами, в коде не меняется ничего — меняются только манифесты. И вот простой пример манифеста сборки с двумя файлами:

Side-by-Side в частных сборках

Хорошо, а как же тогда нам разместить в папке две версии одной частной сборки? Чтобы приложение зависимое от сборки 2.0.0.0 грузило бы её, а плагин приложения, зависимый от 1.0.0.0 — грузил бы именно 1.0.0.0. Ну, в автоматическом режиме и только на частных сборках — никак. Ведь частная сборка должна лежать в папке с программой или подпапке с именем сборки. Что означает, что любые две частные сборки с одним именем, но разными версиями перезапишут друг друга.

Получается, что частные сборки очень похожи (в плане ограничений) на обычное перенаправление DLL. В чём же преимущества частных сборок по сравнению с обычными DLL? (кстати, если указан манифест, то файл .local или папка local игнорируются)

  • К сборкам автоматически применяется механизм версионности. Мы только что видели, как приложение отказалось грузить частную сборку, только потому, что она была другой версии.
  • Сборки более защищены. Ведь DLL ищутся во многих путях. Особенно в PATH. А сборки — только в хранилище WinSxS (общие) и папке приложения (частные).
  • Сборки могут реализовать registration free COM. Это значит, что их можно установить простым копированием без регистрации и элевации.

Но настоящая сила частных сборок получается, когда вы осознаете, что вы вообще-то можете реализовать side-by-side на частных сборках — использованием ручной их загрузки с применением Activation Context API. С его помощью вы можете указать альтернативные пути поиска сборок для загрузки, выделив, таким образом, отдельное место для хранения разных версий одной частной сборки. Впрочем, этот механизм в этой статье не рассматривается. Ведь намного проще в этом случае использовать разделяемые сборки.

Практический пример: использование разделяемых сборок

Хорошая новость — глобальные разделяемые сборки почти ничем не отличаются от частных сборок. Единственное отличие — их надо подписать и установить в хранилище.

Чтобы подписать сборку, вам потребуется сертификат, пригодный для цифровой подписи кода. Кроме того, длина его ключей должна быть не менее 2048 бит. Итак, чтобы подписать сборку, вам нужно:

  1. Использовать какую-нибудь утилиту для извлечения токена публичного (открытого) ключа сертификата (public key token). В состав Visual Studio/PSDK входят утилиты pktextract.exe и sn.exe — они пригодны для этой цели. В Delphi ничего такого нет, но вы можете взять их в MSDN/PSDK.
  2. Вписать полученное значение в атрибут publicKeyToken элемента assemblyIdentity манифеста сборки.
  3. Использовать утилиту MT.exe для создания хэшей файлов сборки и создать каталог-описание (.cdf файл).
  4. Использовать утилиту Makecat.exe над созданным .cdf-файлом для создания защищённого каталога сборки.
  5. Наконец, подписать созданный каталог вашим сертификатом, используя утилиту SignTool.exe . Файл .cdf может быть удалён.

Заметьте, что изменение файлов сборки или содержимого манифеста после подписи приведёт к блокировке сборки. Если вы меняли эти файлы после простановки подписи, то вам необходимо подписать сборку заново.

Как это выглядит на практике.

Начните с подготовки файлов сборки, манифеста сборки и сертификата, которым вы будете подписывать сборку. Ключ сертификата должен иметь длину не менее 2048 бит. Вам не обязательно использовать сертификат, подписанный доверенным центром сертификации (trusted certificate). Сертификат необходим только для проверки того, что сборка не была изменена. Поэтому для подписи сборок обычно используются само-подписанные сертификаты. Вероятно, будет хорошей идеей делать отдельный сертификат для каждого вашего продукта.

Вот как вы можете создать само-подписанный сертификат с использованием Windows SDK: Вы можете использовать любое имя в параметре CN= , так что лучше всего там написать что-то понятное. Команда в примере выше создаст само-подписанный сертификат и автоматически добавит его в ваше персональное хранилище сертификатов, которое вы можете посмотреть в соответствующем апплете Панели управления: Сгенерированный сертификат будет показан Windows с красным значком, что означает, что доверия к сертификату нет, потому что он не был выпущен доверенным центром, а является само-подписанным. Это может раздражать, но эта ситуация штатная и её можно игнорировать.

Запустите утилиту Pktextract.exe из Windows SDK, чтобы извлечь токен открытого ключа сертификата. Чтобы Pktextract.exe работала правильно, надо чтобы сертификат был в той же папке, что и утилита. Используйте полученное значение токена в атрибуте publicKeyToken .

Вот пример файла манифеста, названного MySampleAssembly.manifest . Сборка MySampleAssembly содержит только один файл: MYFILE.DLL . Заметьте, что значение атрибута publicKeyToken элемента assemblyIdentity должно быть изменено на значение, полученное от работы Pktextract.exe : Теперь надо запустить Mt.exe из Windows SDK. Файлы сборки должны лежать в той же папке, что и манифест. В этом примере все файлы лежат в каталоге MySampleAssembly . Запустите Mt.exe так: Вот как будет выглядеть наш манифест после работы Mt.exe : Опция -hashupdate создала нам атрибуты hash и hashalg , а опция -makecdfs создала файл MySampleAssembly.manifest.cdf .

Далее, мы запускаем Makecat.exe для этого .cdf-файла: И последний шаг — запуск SignTool.exe для простановки цифровой подписи. Сертификат для подписи должен быть тем же самым, из которого вы извлекали токен открытого ключа в самом начале: Это стандартная команда подписи файла MySampleAssembly.cat вашим сертификатом mycompany.pfx .

Готово. Теперь остаётся только установить её.

Windows требует, чтобы разделяемые сборки устанавливались с помощью Windows Installer (MSI). Это гарантирует, что Windows сможет починить сборку, если она будет повреждена.

Устанавливаемая сборка сохраняется в подкаталоге папки %systemroot%\WinSxS . Манифест и .CAT файлы переименовываются Windows и копируются в папку %systemroot%\WinSxS\Manifests , а другие файлы сборки идут в отдельные каталоги с именем, сгенерированным на основе манифеста. К примеру, имя сборки Microsoft Windows Common Controls версии 6.0.10 — это:
Для дальнейшей информации — см. установка сборки с помощью Windows Installer. Кроме того, начиная с Windows Vista, вы можете вручную установить сборку, используя API Side-by-Side сборок (см. метод IAssemblyCache.InstallAssembly ).

Рекомендации по использованию Side-by-Side

Практический пример: другие типы стандартных манифестов

Кратко рассмотрим ещё три примера использования стандартных манифестов, а также суммирующий пример. Только, пожалуйста, не надо бездумно включать эти манифесты в свою программу. Прочитайте сначала статьи по теме, чтобы ознакомиться с темой и понимать, что делают эти манифесты, когда их нужно использовать, а когда — не нужно.

Примечание: обратите внимание, что примеры использования манифестов в этом разделе уже не имеют отношения к side-by-side сборкам и изолированным приложениям — это уже расширения возможностей манифестов, появившиеся в Windows Vista и выше.

High DPI awareness: объявление, что ваше приложение в курсе про режимы экрана с высоким DPI

Когда приложение объявляет себя как DPI-aware («я в курсе, что бывают высокие DPI»), то это эквивалентно утверждению, что приложение будет хорошо работать на высоких DPI (включая DPI с 200%, равный 150). Эта настройка не имеет силы на Windows XP и ниже. Начиная с Windows Vista и выше когда включается DPI виртуализация, приложения, которые не помечены на DPI-aware, автоматически масштабируются системой, а также они получают подстановочные эмулирующие данные (с учётом масштабирования) от системных API функций вроде GetSystemMetric .

Примечание: по умолчанию виртуализация DPI включается только на DPI выше 120 (125%).

Хотя в Win32 API есть функция для объявления приложения как DPI-aware ( SetProcessDPIAware ), её использование не поощряется, кроме специальных сценариев. В общем случае рекомендуется использовать манифест для объявления приложения DPI-aware.

Для этого вы должны добавить в манифест элемент . Например: Примечание: если элемент появляется в манифесте сборки DLL компонента, то этот элемент игнорируется. Только манифест приложения может указывать на «осведомлённость о DPI».

UAC: указание требуемого уровня привилегий для приложения

В выпуске Windows Vista есть положения, позволяющие коду без манифеста или неподписанному коду работать с полным административным маркером доступа.

Примечание: в будущих версиях системы единственным способом для приложения запуститься с полными административными привилегиями будет указание подписанного манифеста.

В Windows Vista и выше используется такой формат в манифесте для указания требуемого уровня привилегий: Возможные значения и их трактовка:

Значение Описание Комментарий
asInvoker Приложение запускается с тем же токеном, что и вызывающий процесс. Рекомендуется для обычных приложений пользователя. Примеры программ: Блокнот, Калькулятор, Microsoft Word, Delphi, Total Commander.
highestAvailable Приложение запустится с максимальными привилегиями, которые могут быть доступны пользователю. Рекомендуется для приложений смешанного режима. Примеры программ: Консоль MMC, Редактор реестра.
requireAdministrator Приложение всегда запускается с полным токеном администратора. Рекомендуется только для приложений администраторов. Примеры программ: установщики программ.

Смысл значений uiAccess :

Значение Описание
False Приложению не требуется управлять вводом в пользовательский интерфейс другого окна на рабочем столе. Приложения, которые не предоставляют возможности accessibility, должны устанавливать этот флаг в False. Приложения, которым требуется управлять вводом в другие окна на рабочем столе (к примеру, экранные клавиатуры) должны устанавливать это значение в True.
True Приложению разрешается обходить уровни контроля интерфейса пользователя, чтобы получать доступ к окнам с высокими привилегиями на рабочем столе. Эта настройка должна применяться только приложениями, реализующими Assistive Technology.

Примечание: приложения с uiAccess равным True должны иметь корректную цифровую подпись. Кроме того, приложение должно располагаться в защищённом месте системы. Сегодня такими местами являются папки \Program Files\ и \windows\system32\.

Указание на совместимость с конкретной ОС

Поведение операционной системы может меняться в каждой новой версии системы. Поэтому приложение, написанное для старой версии системы, может работать не совсем верно (или вообще не работать) в новой версии системы. Мы только что разобрали пример с UAC. К примеру, в Windows 7 было немного изменено поведение системы. По умолчанию приложения получают поведение системы как в Windows XP (если в манифесте нет информации о требуемом уровне привилегий или совместимости с ОС) или как в Windows Vista (если в манифесте указана информация о требуемом уровне привилегий или задекларирована совместимость с Windows Vista). Чтобы получить поведение как в Windows 7 (без эмуляции), приложению нужно указать это явно.

Общий сценарий при этом:

  1. Указать, что приложение поддерживает Windows N (где N — это Vista, 7 или иная более поздняя версия системы).
  2. Проверить, что приложение нормально работает в Windows N.
  3. Устранить все найденные проблемы при работе приложения в Windows N:
    • Если это сделать удалось, то оставить отметку о совместимости приложения с Windows N.
    • Если это сделать не удалось, то убрать отметку о совместимости приложения с Windows N.

Приложениям, которые поддерживают функциональность и Windows Vista, и Windows 7, не требуются отдельные манифесты. В этом случае они должны задекларировать свою совместимость с операционной системой добавлением секции supportedOS в блок application . Например: Допустимыми значениями Id на сегодня являются:

  • для Windows Vista: это значение по умолчанию, если иного не указано явно.
  • <35138b9a-5d96-4fbd-8e2d-a2440225f93a>для Windows 7: необходимо указывать явно, если приложению требуется поведение Windows 7.
  • <4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38>для Windows 8: необходимо указывать явно, если приложению требуется поведение Windows 8.
  • <1f676c76-80e1-4239-95bb-83d0f6d0da78>для Windows 8.1: необходимо указывать явно, если приложению требуется поведение Windows 8.1.
  • <8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a>для Windows 10: необходимо указывать явно, если приложению требуется поведение Windows 10.

Microsoft будет создавать новые GUID по мере выхода новых версий Windows при необходимости.

Список изменений в поведении для Windows 7 по сравнению с Windows Vista можно увидеть в статье MSDN Windows 7 / Application Manifests. Список для Windows 8/8.1 можно посмотреть в Windows Compatibility Cookbook.

Собираем всё вместе

Заключение

Хотелось бы только отметить не упомянутое здесь расширение манифестов: технология ClickOnce, предназначенная для создания само-обновляемых приложений, работающих с минимальным взаимодействием с пользователем (название технологии происходит от «установка в один щелчок»). Ещё одним примером, с которым, правда, вы не встретитесь в Delphi, является подключение сборки C++ run-time — аналогично тому, как мы подключали сборку ComCtl32 версии 6. Например: Кроме того, за кадром статьи остались также многие темы работы с разделяемыми сборками, включая управление конфигурацией, registration free COM, перенаправление сборок, использование ресурсных сборок и т.п., а также ручное управление контекстами. Тем не менее, я надеюсь, что эта статья помогла вам ознакомится с темой зависимостей в DLL и манифестов. Пусть она служит вам отправной точкой в этой теме.

Кстати говоря, если вы столкнётесь с проблемами при поиске/загрузке сборок в своих программах, то утилита командной строки sxstrace поможет вам их решить.


Манифест программ Windows XP в Delphi

Здесь рассказывается о том, как сделать любой проект похожим на Windows XP программы. В Windows XP присутствует менеджер тем (theme manager), который может изменить вид многих стандартных объектов Windows.

Здесь рассказывается о том, как сделать любой проект Delphi похожим на Windows XP программы. В Windows XP присутствует менеджер тем (theme manager), который может изменить вид многих стандартных объектов Windows. Сам Misrosoft утверждает, что библиотеки comctl32.dll старой версии содержат код для поддержки платформ разного вида. У Microsoft возникла хорошая мысль о чистке содержимого comctl32.dll, чтобы улучшить работу тем в Windows XP. После этого получилось, что библиотек есть две версии: старая — 5.8 и новая – 6, последняя из которых совместима только с XP и со всеми последующими версиями Windows.

По умолчанию любая программа Delphi, разработанная под Windows XP, работает с версией 5.8, что позволяет получить такой же вид, что и ранее разработанные приложения Windows. Поэтому для использования библиотеки 6 версии, необходимо подключить к нужному приложению Manifest, который Windows будет воспринимать для отрисовки компонентов из новой библиотеки.

Манифест является XML документом, который необходимо подлинковать в ресурсы необходимого приложения Delphi (источник — форум программистов). Наиболее часто ресурсы применяются для хранения различных вещей, таких как: курсоры мыши, иконки и картинки. XML документ, подключаясь к ресурсной секции, позволяет выбрать Windows XP необходимую версию comctl32.dll для использования.

arada_s

arada_s

1. Создание манифеста

Манифест — это xml-файл, который декларирует, что ваше приложение может использовать новые стили. Его можно создать блокнотом, сохранив текст в кодировке utf-8. Текст манифеста можно посмотреть на MSDN, изменив только версию и название вашей программы (Microsoft рекомендует формат яПриложения>). Впрочем, даже если вы оставите всё как есть, на работоспособности это не отразится.

Получившийся файл можно сохранить рядом с запускаемым файлом, дав ему имя .manifest. Например, если запускаемый файл называется HelloWorld.exe, файл манифеста надо назвать HelloWorld.exe.manifest и сохранить в той же папке, что и HelloWorld.exe. Вместо этого файл манифеста можно добавить в ресурсы, указав тип ресурса как RT_MANIFEST.

2. Модификация приложения

Нужно внести небольшие изменения в ваше приложение, а именно вызвать функцию InitCommonControls из библиотеки ComCtl32.dll.

Ниже находятся подробные инструкции для некоторых IDE, в которых вы можете столкнуться с этой проблемой.

В новых RAD (RAD XE, RAD XE2 и т.д.) от вас не потребуется никаких действий. Сказанное ниже относится именно к шестому билдеру. Думаю, в Delphi 5 всё то же самое, хотя не проверял.

1. Создаём в папке проекта файл XPStyle.manifest следующего содержания:

  1. version = «1.0» encoding = «UTF-8» standalone = «yes» ?>
  2. xmlns = «urn:schemas-microsoft-com:asm.v1»
  3. manifestVersion = «1.0» >
  4. name = «НАЗВАНИЕ ВАШЕЙ ПРОГРАММЫ»
  5. processorArchitecture = «x86»
  6. version = «1.0.0.0»
  7. type = «win32» />
  8. Executable
  9. type = «win32»
  10. name = «Microsoft.Windows.Common-Controls»
  11. version = «6.0.0.0»
  12. processorArchitecture = «x86»
  13. publicKeyToken = «6595b64144ccf1df»
  14. language = «*»
  15. />

2. Создаём рядом файл XPStyle.rc следующего содержания:

  1. 1 RT_MANIFEST «XPStyle.manifest»

Файл .rc — файл ресурсов. Здесь единица указывает номер ресурса (то есть можно поставить любую другую цифру). RT_MANIFEST — макрос из winuser.h, указывающий тип ресурса. Если компилятор вдруг начнёт ругаться, что не знает RT_MANIFEST, можно напрямую указать вместо него MAKEINTRESOURCE(24).

3. Добавляем оба файла в проект.

4. Пересобираем проект. Радуемся.

Будьте готовы к тому, что перерисованы будут только стандартные (для WinAPI) элементы. В частности, кнопки TSpeedButton и TBitBtn так и останутся прямоугольными. Можно сделать их flat, будет смотреться не так жутко.

b) WinAPI, Code::Blocks

Здесь всё просто. Все нужные файлы будут созданы плагином.

1. Plugins > WindowsXP Look’n’feel

От вас требуется только инициализировать библиотеку элементов управления:

2. В опциях линкера добавляем библиотеку libcomctl32.a

3. Добавляем в WinMain инициализацию библиотеки:

  1. int WINAPI WinMain ( HINSTANCE hThisInstance,
  2. HINSTANCE hPrevInstance,
  3. LPSTR lpszArgument,
  4. int nCmdShow)
  5. <
  6. /* . */
  7. InitCommonControls();

Если вдруг после этого не заработает, можно попробовать тёмное шаманство, — открыть манифест блокнотом и удалить все переносы, так, чтобы весь манифест был записан в одну строчку.

c) Microsoft Visual C++

Project > Properties > Linker > Manifest File
Additional Manifest Dependencies:

Windows XP манифест в Delphi

Данная статья рассказывает о том как сделать чтобы ваши проекты выглядели как Windows XP программы.

В Windows XP есть менеджер тем (theme manager) который изменяет вид большинства стандартных объектов Windows. Misrosoft утверждает что старые версии библиотеки comctl32.dll содержат код для поддержки различных платформ семейства Windows. Microsoft разумно решила почистить содержимое comctl32.dll для улучшения работы тем в Windows XP. Теперь получается что существует две версии библиотеки: старая (версия 5.8) которая имеет обратную совместимость всех предыдущих версий Windows (в том числе и XP) и новую версию (версия 6) которая совместима только с XP (ну и следующими версиями Windows).

По умолчанию все программы разработанные под Windows XO используют версию 5.8, получая тот же вид что и предыдущие приложения Windows. Для того чтобы использовать компоненты из библиотеки 6 версии в вашем приложении вы должны подключить к вашему приложению Manifest который Windows будет читать для того чтобы отрисовка компонентов производилось через новую библиотеку.

Что такое манифест?

Что такое манифест, и какую роль он играет в выборе версии 6.0 библиотеки comctl32.dll для моего приложения? Манифест — XML документ который должен быть подлинкован в ресурсы вашего приложения. Обычно ресурсы используются для хранения таких вещей как картинки, иконки и курсоры мыши. (С тем как использовать ресурсы вы можете прочитать в моей статье. Прим. Переводчика) XML документ, когда подключается в ресурсную секцию позволяет решить Windows XP какую версию comctl32.dll использовать.

Как это сделать?

Чтобы подключить этот XML манифест в ваше приложение Вы для начала должны знать константы предоставленные Microsoft. Когда вы добавляете ресурс в ваше приложение, есть номер группы и порядковый номер, связанный с ресурсом. Номер группы обычно называется понятным именем. Если вы посмотрите проводник ресурсов (resource explorer), поставляемый с Delphi в виде демонстрационного проекта (распологается <$delphiDemos>) вы увидите группы называемые «Strings» (Строки), «Bitmaps» (Картинки), «Icons» (Иконки) или «Cursos» (Курсоры мыши) — это просто представления номер группы. Номер группы для «Manifest» (манифеста) — 24, в соответствии с заголовками C распространяемыми Microsoft. Номер манифеста для определения версии библиотеки comctl32.dll — 1 (Также в соответствии с заголовками C распространяемыми Microsoft). Эта информация будет необходима когда мы будем создавать наш новый ресурс (.RES файл) для подключения к нашему приложению. Для создания необходимого .RES файла нам нужно создать файл .RC в котором будет содержаться наш XML манифест, принадлежащий к соответствующей группе и номеру ресурса. В zip-архиве включенном в этот документ вы увидите два файла:

* 1. WindowsXP.RC
* 2. WindowsXP.Manifest

Файл WindowsXP.RC содержит инструции для подключения WindowsXP.Manifest (XML-документа), а именно:

* 1 24 «WindowsXP.Manifest»

Сам манифест — XML документ содержащий информацию о вашем приложении которую вы добавляете как и информацию содержащую версию библиотеки comctl32.dll для использования. Его содержание должно быть немного заточено под ваше приложение, но будет выглядеть примерно так:

Теперь когда у нас есть эти два файла нам необходимо использовать компилятор ресурсов Delphi чтобы скомпилировать .RC файл. В результате чего у нас получится файл WindowsXP.RES который мы можем подключить в наше приложение. Для компиляции ресурса введите в командной строке:

C:project1> brcc32 windowsxp.rx

Конечно, я думаю что вы вставили в переменную окружения PATH директорию BIN Delphi.

После компиляции вы увидите Файл WindowsXP.RES в тойже директории. Последний шаг для того чтобы ваше приложение стало WindowsXP-совместимым, это подключение ресурсного файла в ваше приложение. Самый простой способ сделать это добавить нижеприведенную директиву в ваш файл проекта или главную форму:

Скорее всего вам прийдется поместить эту строчку сразу за директивой <$R *.dfm>которая уже имеется в вашем приложении, сразу за приедложением implementation. Как только вы подключили WindowsXP.RES в ваше приложение откомпилируйте ваше приложение и запустите его. Менеджер тем Windows приведет ваше приложение к виду остальных приложений написанных для Windows XP.

Microsoft предупреждает всех разработчиков что они убрали большое количество кода из библиотеки comctl32.dll, и что необходимо тщательно проверять все стороны работы компонентов перед тем как распространять новую версию. По моему опыту могу сказать что могут быть проблемы совместимости с Delphi. С другой стороны я нашел только одну проблему — с компонентом TListView. Если вы используете TListView в режиме показа (View Style) vsReport, у вас возникнут проблемы с использованием свойства TColumns. Во время запуска при попытку использования заголовков колонок с указанием вида показа у вас возникнет ошибка ядра (Kernel Error).

Исправление проблемы с TListView (спасибо Евгению Иванову)

Стал искать как исправить это упущение, так как и Delphi 6 с Update 1 не помогает справиться с этой проблемой. Решение заключается в следующем:

1. Открыть «ComCtrls.pas» и найти «TCustomListView.UpdateColumn»
2. Найдем следующую строку.

if FImageIndex <> -1 then
fmt := fmt or LVCFMT_IMAGE or LVCFMT_COL_HAS_IMAGES;

3. Заменяем её на:

if FImageIndex <> -1 then
fmt := fmt or LVCFMT_IMAGE or LVCFMT_COL_HAS_IMAGES
else
mask := mask and not (LVCF_IMAGE);

4. Сохраняем Comctrls.pas. Теперь TListView не вызывает ошибку в режиме vsReport под Windows XP.

Автор поправки Matteo Riso.

Исправление проблемы с TPageControl

Решение проблемы с установкой цвета фона clBtnFace для TTabSheet.
Как вы знаете TPageControl является контейнером TTabSheet: TPageControl нормально воспринимается Windows XP манифестом, но это остается правильным пока вы не добавите TTabSheet.

Решение заключается в следующем:

1. Откройте модуль «ComCtrls.pas» и найдите строчку «TTabSheet.UpdateTabShowing»
2. Вы увидите следующий текст:

procedure TTabSheet.UpdateTabShowing;
begin
SetTabShowing((FPageControl <> nil) and FTabVisible);
end;

3. Добавьте следующую строчку в эту процедуру:

SetWindowLong(handle,GWL_EXSTYLE,WS_EX_TRANSPARENT);

4. Если в вашем TPageControl создано более одного TTabSheet, возможно при запуске вашего приложения вы увидите все компоненты отрисованные на первом листе (TTabSheet). Не надо впадать в панику. Найдите метод «TPageControl.Loaded» и измените его чтобы он был похож на следующий код:

procedure TPageControl.Loaded;
var
I: integer;
begin
inherited Loaded;
UpdateTabHighlights;
for I:=self.PageCount-1 downto 0 do
self.ActivePage:=self.Pages[I];
end;

Добавленый код заставляет TPageControl пройтись по всем страницам перед показом. Это конечно немного некрасиво, но работает. Если у вас есть другие методы решения этой проблемы сообщите мне.
Автор поправки Matteo Riso.
Исправление проблемы с TTrackBar

TTrackBar — извините, а какая текущая позиция?

Подсказка, показывающая текущее значение TTrackBar при перемещении ползунка удобна, то есть вам не будет необходимо добавлять TLabel для этого.

1. Откройте «ComCtrls.pas» и найдите «TTrackBar.CreateParams».
2. Вы увидите следующий код:

procedure TTrackBar.CreateParams(var Params: TCreateParams);
const
OrientationStyle: array[TTrackbarOrientation] of DWORD = (TBS_HORZ, TBS_VERT);
TickStyles: array[TTickStyle] of DWORD = (TBS_NOTICKS, TBS_AUTOTICKS, 0);
ATickMarks: array[TTickMark] of DWORD = (TBS_BOTTOM, TBS_TOP, TBS_BOTH);
begin
[. ]
with Params do
begin
Style := Style or OrientationStyle[FOrientation] or
TickStyles[FTickStyle] or ATickMarks[FTickMarks] or TBS_FIXEDLENGTH or
TBS_ENABLESELRANGE;
[. ]
end;
end;

3. Добавьте условие «or TBS_TOOLTIPS» в линию «Style:=». В конечном итоге должно получиться:

Style := Style or OrientationStyle[FOrientation] or
TickStyles[FTickStyle] or ATickMarks[FTickMarks] or TBS_FIXEDLENGTH or
TBS_ENABLESELRANGE or TBS_TOOLTIPS;

4. Сохраните ComCtrls.pas и наслаждайтесь подсказкой.

Автор поправки Matteo Riso.

Добавил: LedWorm Дата публикации: 2005-07-04 10:23:09
Рейтинг статьи: 5.00 [Голосов 1] Кол-во просмотров: 12759

Комментарии читателей
Всего комментариев: 83

2020-06-15 02:29:49
CharlesDiunc

2020-06-15 00:20:40
PerryskymN

2020-06-14 03:57:56
CharlesDiunc

2020-06-13 20:22:20
Semenzod

Регистрация в каталоге dmoz

http://bit.ly/2aKk97Z — раскрутить сайты магазин
http://bit.ly/2aKk97Z — каталог продвижение сайта
http://bit.ly/2aKk97Z — Регистрация В Трастовых Сайтах
http://bit.ly/2aKk97Z — каталог интернет магазинов регистрация
http://bit.ly/2aKk97Z — прогон сайта закладкам

СЕРВИС ДЛЯ ПРИВЛЕЧЕНИЯ КЛИЕНТОВ ИЗ ИНТЕРНЕТА.
КОНТЕНТ МАРКЕТИНГ И ДРУГИЕ ИНСТРУМЕНТЫ ДЛЯ БИЗНЕСА
ПОИСКОВОЕ ПРОДВИЖЕНИЕ
КОНТЕКСТНАЯ РЕКЛАМА
ПРОГОНЫ ПО ПРОФИЛЯМ
РЕГИСТРАЦИИ ПРОФИЛЕЙ
СТАТЕЙНОЕ ПРОДВИЖЕНИЕ

http://bit.ly/2aKk97Z — регистрация каталогах 2020
http://bit.ly/2aKk97Z — статейный прогон сайта
http://bit.ly/2aKk97Z — как раскрутить сайт на досках объявлений
http://bit.ly/2aKk97Z — трастовая площадка
http://bit.ly/2aKk97Z — прогон сайта закладкам

яндекс каталог продвижение сайтов
Продвижение Сайта В Каталогах

http://bit.ly/2oI4psW — ВЫДАВАЙ МИКРОЗАЙМЫ С ГАРАНТИРОВАННОЙ ДОХОДНОСТЬЮ ОТ 192% ДО 265% ГОДОВЫХ И ЗАБУДЬ О ФИНАНСОВЫХ ПРОБЛЕМАХ

2020-06-13 17:03:58
Willienacag

Только эти три дня распродажа Спортивных часов со скидкой!

2013-07-30 23:56:27
decko7549

Самый большой сборник популярных онлайн игр со всего рунета играть бесплатно.

2013-04-06 14:38:45
654dxfbfd5

VKeditor скачать бесплатно можно здесь http://soft7x.ru/vkeditor.html это новейшая программа для взлома аккаунтов vkontakte.ru. Если вы давно искали способ взломать страничку вконтакте, то VKeditor именно та программа, которая поможет вам сделать это легко и просто. Скачать

2012-12-04 11:12:54
fgdjb5d5

Программы, игры, музыка, фильмы, драйвера бесплатно Скачать вы можете на сайте http://varim-sami.ru Скачать Универсальный взломщик программа для восстановления забытого пароля от почтового ящика. Взлом вконтакте, взлом программ, взлом платных архивов и многое другое

2012-11-28 21:55:11
fgdjb5d5

Скачать программу вы можете на сайте http://varim-sami.ru Скачать Универсальный взломщик программа для восстановления забытого пароля от почтового ящика. Взлом вконтакте, взлом программ, взлом платных архивов и многое другое

2012-10-01 21:35:13
fgdjbgft

Как то листая просторы интернета, наткнулась на очень интересную программу Xfenez, Это чудо программа по описаниям умеет многое. Это по сути универсальный взломщик всего что только можно придумать,- читайте ниже:подробней
Описание:
Xfenez — программа для восстановления забытого пароля от почтового ящика! Очень часто в интернете можно встретить рыдающих юзеров с просьбой помочь с восстановлением пароля к почтовому ящику, стандартные сервисы почтовых служб которые помогают вспомнить пароль не всегда выручают, пользователи забывают ответы на секретные вопросы, дополнительные e-mail адреса, контактную информацию которую указывали при регистрации и другие тонкости которые требуют почтовые службы для восстановления пароля. Программа Xfenez поможет вам максимально быстро восстановить пароль к своему почтовому ящику. Достаточно ввести в поле e-mail и нажать кнопочку «Взлом» и забыть о ней на некоторое время, в это время вы можете заниматься своими любимыми делами в интернете, по окончанию работы программа проинформирует вас об этом звуковым сигналом.

Добавление манифеста для запроса прав администратора

У меня есть приложение, которое записывает параметры программы в реестр Windows, что абсолютно необходимо, так что поиск файла не является вариантом.

Чтобы упростить это, я хотел бы дать экран nag для «admin privileges» вместо того, чтобы пытаться объяснить, как щелкнуть правой кнопкой мыши по файлу программы/короткому замыканию.

Я нашел достаточно хорошую статью, но получаю дублируемую ошибку ресурса после добавления моего собственного файла ресурсов для манифеста.

Предполагается, что это связано с конфликтом с внутренним манифестом и для решения проблемы я вижу, что многие комментарии, предлагающие «включить темы времени исполнения», отключить в параметрах проекта. Я прошел через каждое меню, но не могу его найти, и теперь мне сказали, что он может быть недоступен в Delphi 7 и был представлен в более поздних версиях.

Как я могу добавить свой собственный манифест?

Я уже прокомментировал, что «Написание параметров программы в реестр не является надлежащей причиной для предоставления привилегий администратора приложения». Однако в любом случае рекомендуется включать манифест UAC. общий requestedExecutionLevel должен быть level=»asInvoker» . см. документы

Создайте ниже 4 файла (2 набора):

uac.manifest

uac.rc

Добавьте в проект желаемый rc файл ( uac.rc или uac_xp.rc ) через пункт меню «Проект > Добавить в проект». Это создаст директиву <$R>в файле проекта:

Обратите внимание на <$R 'uac_xp.res' 'uac_xp.rc'>. Delphi автоматически скомпилирует файл rc в res .

В качестве альтернативы вы можете скомпилировать файл rc через brcc32 uac.rc вне Delphi IDE. а затем добавьте <$R 'uac_xp.res'>вручную в свой проект.

Убедитесь, что вы не используете какой-либо другой манифест XP.

Windows xp манифест в delphi

Итак, начнем с манифеста. Он представляет собой документ в формате XML, содержащий всю информацию, необходимую для взаимодействия приложения и библиотеки ComCtl32.dll версии 6.

Следует отметить, что манифесты широко используются во многих продуктах и технологиях, работающих в операционных системах Microsoft. С полной схемой XML манифеста вы можете ознакомиться в документации Microsoft MSDN.

Пример манифеста представлен в листинге 6.1.

Листинг 6.1. Манифест Windows XP

Your application description here.

Обратите внимание, что в элементе

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

При загрузке приложения операционная система Windows XP считывает манифест (если он есть) и получает информацию о том, что для выполнения приложения потребуется библиотека ComCtl32.dll версии 6.

Помимо этой информации манифест может содержать и другие необходимые сведения о приложении и условиях его работы. Например, общая информация о приложении и его версии представлены элементом

Вы можете добавить манифест в ваше приложение двумя способами:

  • использовать компонент TxpManifest;
  • добавить манифест в ресурсы приложения вручную. Рассмотрим их.

Delphi 7 для профессионалов Электронный учебник

Манифест Windows XP

Итак, начнем с манифеста. Он представляет собой документ в формате XML, содержащий всю информацию, необходимую для взаимодействия приложения и библиотеки ComCtl32.dll версии 6.

Следует отметить, что манифесты широко используются во многих продуктах и технологиях, работающих в операционных системах Microsoft. С полной схемой XML манифеста вы можете ознакомиться в документации Microsoft MSDN.

Пример манифеста представлен в листинге 6.1.

Листинг 6.1. Манифест Windows XP

Your application description here.

Обратите внимание, что в элементе

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

При загрузке приложения операционная система Windows XP считывает манифест (если он есть) и получает информацию о том, что для выполнения приложения потребуется библиотека ComCtl32.dll версии 6.

Помимо этой информации манифест может содержать и другие необходимые сведения о приложении и условиях его работы. Например, общая информация о приложении и его версии представлены элементом

Вы можете добавить манифест в ваше приложение двумя способами:

  • использовать компонент TxpManifest;
  • добавить манифест в ресурсы приложения вручную. Рассмотрим их.

В оформлении пользовательского интерфейса операционной системы Windows ХР появилось новшество — визуальные стили, которые позволяют настраивать не только внешний вид элементов управления, но и их поведение, и даже управлять отрисовкой отдельных частей элементов управления. Это стало возможным благодаря системной библиотеке ComCtl32.dll версии 6.

Любое приложение может использовать возможности этой библиотеки по созданию «продвинутых» пользовательских интерфейсов. Для этого оно должно содержать манифест — документ XML, описывающий, какую версию ComCtl32.dll используют его элементы управления.

Для отрисовки частей элементов управления приложение может использовать функции Theme API, разработанные Microsoft. Кроме этого, данный программный интерфейс позволяет управлять менеджером тем, который сменяет текущие темы для визуального стиля. Темы хорошо известны пользователям, начиная с Windows 95.

Разработчики могут создавать в Delphi 7 собственные визуальные стили, разрабатывая их на основе класса TActionBarStyleEx .

Windows xp манифест в delphi

Столкнулся с одной интересной проблемой в Windows XP.

При подключении к проекту манифеста (как через Res файл, так и через внешний), не работает конструктор окна:

Т.е. :

hMainWnd := CreateDialog(hInstance, «MAIN_DIALOG», 0, Nil)

Выдает всегда 0 Handle !

Если создавать окно не из ресурса, а напрямую через API все нормально для главного окна, а вот последующие контролы снова возврашают 0 Handle.

Если убрать манифест, или запускать программу в режиме совместимости с Windows 9X — работает нормально.

Вся заковырка была в следующем:

необходимо в событие WM_CREATE окна включать :

WM_CREATE:
begin
InitCommonControls;
.
end;

Процедура InitCommonControls находится в модуле CommCtrl.

Может кто прокомментирует, что делает процедура InitCommonControls ?


> Может кто прокомментирует, что делает процедура InitCommonControls
> ?

Регистрирует оконные классы Common Controls

А ещё не работает TListBox в режиме отчёта!

Xerx © (11.05.04 20:28) [2]

Работает, но его надо править.

И не TListBox, а TListView.

Кстати, что интересно — в WinXP Rus без SP, Delphi 6 Personal все прекрасно работает :)


> OlegGashev © (11.05.04 21:13)
> Работает, но его надо править.

А что именно в нем надо править, Вы в курсе?
У меня та же проблема, а как устранить — не знаю.

Забыл добавить: d5.

Где, что изменял, уже не помню. У кого есть оригинальная версия файла, выложите разницу в файлах. Там всего пара добавленных строк.

ListView в XP содержит много других ошибок (недочетов?) в реализации. Некоторые легко обнаружить:
В XP выключите пункт «отображать содержимое окна при перетаскивании» и перетащите значок на Рабочем столе. Надпись смещена вправо. Иногда она вообще пропадает. То же будет и с любым другим ListView — неправильно генерируется образ перетаскиваемого итема.
Может кто знает как победить?

Написать баг-репорт в Майкрософт? ;-)
Я, по крайней мере, пишу баг-репорты тем компаниям, у которых обнаруживал баги (или веб-мастерам).

Делаем Delphi программу Vista-совместимой (исходники)

Как сделать Вашу программу более дружелюбной в Vista (32 бит)? Тот кто уже использует Висту успел заметить работу нового User Access Control (UAC). Как Вы знаете, это «улучшение» модели безопасности довольно быстро начинает раздражать. Поговорим о том как Вашу программу научить работать с UAC.

это если вам нужны привилегии админа

если устраивают обычные привилегии текущего пользователя

Стоит заметить, что в обоих случаях возможно появление окна UAC из-за недостатка привилегий. Допустим, вы запустили приложение с манифестом админа под обычным юзером — появится UAC окошко. Такие манифесты будут работать ТОЛЬКО с Виста. Для работы с XP поменяйте

Это позволит запускать программу и в XP и в Виста.

Для тех, кто не знал или забыл как создать свой ресурс манифеста в Дельфи 6-7-2007:

  1. Во первый если вы добавили компонент типа XPManifest — уберите его, закройте дельфи, удалите файл <имя проекта>.res,откройте проект в дельфи, перекомпилируйте проект. Это позволит обновить ресурсы .res.
  2. Вручную создайте файл с содержимым описаным выше (это XML кто не в курсе) и назовите его vista.manifest. Попробуйте отрыть его в Internet Explorer — должно открываться без проблем. Если нет — ищите ошибки в тексте.
  3. Создаем файл vista.rc в notepad вида 1 24 vista.manifest
  4. Компилируем файл ресурсов: brcc32 vista.rc
  5. Должен получится файл vista.res который вы прицепляете к программе директивой <$R vista.res>где нибудь в главной форме сразу под uses.
  6. Да. Не забудьте перекомпилировать программу. ;)

В кратце это все — но для тех кому подобные выкрутасы нужны в COM сервере — почитать тут

Илон Маск рекомендует:  Как программно определить, что приложение работает под windows nt
Понравилась статья? Поделиться с друзьями:
Кодинг, CSS и SQL