Технологии обмена данными между приложениями Windows
С первых дней существования компьютеров обозначились трудности, связанные с переносом данных между различными машинами. Непереносимость данных, вызванная разницей в платформах, сейчас практически преодолена за счет внедрения общих стандартов представления данных и наличия программ-перекодировщиков. До сих пор сохраняется проблема непереносимости данных внутри одного компьютера, между разными программами, создающими разные или даже одинаковые виды документов, но в различных форматах внутреннего представления.
Операционная система Windows изначально ориентирована на высокую степень интеграции ее компонентов, важнейшим элементом которой является возможность эффективного обмена данными между различными приложениями. Для этих целей реализовано несколько технологий, которые мы рассмотрим.
Буфер промежуточного хранения Clipboard
Уже в первых версиях Windows был реализован встроенный буфер промежуточного хранения данных Clipboard (буфер обмена), который постоянно активен и доступен всем Windows-приложениям. Обмен данными через буфер обмена осуществляется следующим образом.
1. Выделить в приложении-источнике фрагмент данных.
2. Скопировать (перенести) выделенный фрагмент в буфер обмена командой Правка►КопироватьилиПравка►Вырезать.
3. Перейти к приложению-приемнику, поместить курсор в то место, куда требуется вставить данные из буфера, и выполнить команду Правка►Вставить.
Аналогичный порядок действий обеспечивает обмен данными и в рамках одного приложения, поэтому отпадает необходимость включать в приложения внутренние средства копирования и перемещения объектов.
За счет использования обмена данными через буфер возможно включение в один документ объектов, созданных различными приложениями, – создание, так называемых, составных документов. Для всех Windows-приложений установлен ряд стандартных форматов представления данных, и при операциях с буфером обмена преобразования данных для этих форматов выполняются автоматически и совершенно незаметно для пользователя.
Для непосредственного просмотра данных в буфере обмена, изменения формата представления данных в нем, записи содержимого буфера в файл и его очистки используется утилита Clipboard Viewer (Clipbrd), которая является компонентой операционной системы и устанавливается при ее инсталляции.
Недостатками обмена с использованием буфера являются:
· некоторое ограничение объема передаваемой через буфер информации;
· данные, вставленные в документ-приемник через буфер обмена, не обновляются при их изменении в документе-источнике.
Для обмена данными между приложениями может использоваться технология DDE (Dynamic Data Exchange – динамический обмен данными). Суть технологии состоит в том, что вставляемый через буфер обмена объект сохраняет свою связь с оригиналом и при внесении в него изменений может автоматически обновляться. При этом 1) с одним оригиналом можно связать любое число документов; 2) возможно связывание по цепочке, когда источником является не оригинал, а ранее связанный объект; 3) установленная связь сохраняется и после закрытия приложений, т.е. внесенные в оригинал изменения автоматически вносятся во все документы, связанные с ним.
Для использования технологии DDE следует обычным путем скопировать объект из документа приложения-сервера в буфер обмена, перейти в приложение-клиент, а затем по команде Правка►Специальная вставка► переключательСвязьвставить его в документ.
Команда Правка►Связи позволяет, просмотреть все связи для данного документа, разорвать или переключить связь с одного объекта на другой или установить режим ручной активации связей, когда обновление информации в документе с изменением оригинала происходит не автоматически, а при выполнении соответствующей команды.
Однако, технология DDE не нашла широкого распространения, поскольку при всех достоинствах динамического обмена данными сложность его функционирования привела к тому, что пользователи предпочитали вставку объектов через буфер обмена из-за ее простоты и понятности.
При обмене данными по рассмотренным технологиям объектом является любой фрагмент, переносимый из одного приложения в другое. На самом же деле переносился не сам фрагмент, а лишь его «экранный образ»: приложение-источник преобразовывает данные из своего внутреннего формата в один из стандартов Windows, и в таком виде фрагмент вставляется в приложение-приемник. Вставленный объект является составным элементом документа, в котором он отображается, но внести в него изменения довольно трудно, т.к. для этого требуется приложение-источник.
Технология связывания и внедрения объектов (Object Linking and Embedding) имеет больше функциональных возможностей, причем, если приложение поддерживаетOLE, то оно само выполняет обмен данными по этой технологии.
Операции связывания (Linking) и внедрения (Embedding), реализованные в рамках OLE, внешне напоминают технологию DDE и обмен данными через буфер обмена. При работе по технологии OLE выполняется та же последовательность действий. Документ со встроенными OLE-объектами выглядит аналогично документу с фрагментами, вставленными через буфер обмена. Однако в этом случае при двойном щелчке мыши в поле объекта он активизируется и запускается приложение, в котором создавался этот объект, и в него передается объект для редактирования или выполнения других операций. После окончания работы с объектом программа-источник закрывается, а измененный объект автоматически передается обратно в документ приложения-клиента.
В рамках технологии OLE объект представляет собой сочетание данных какого-либо вида (текст, графика, видео, звук и др.) во внутреннем формате приложения-сервера, представленном в одном из стандартных форматов Windows, и информации о создавшей его программе, размере, времени создания и т.п. Таким образом, объект является законченной структурой, переносимой из одного документа в другой и сохраняющей отличительные особенности независимо от типа документа, в котором в данный момент находится.
· отсутствует необходимость создания второй копии объекта, что позволяет сократить требуемый объем дискового пространства;
· внесение изменений в связанный объект обеспечивает дублирование этих изменений во всех документах, с которыми объект был связан;
· запоминается путь к оригиналу, поэтому при переносе на другую машину необходимо переписать все файлы, содержащие объекты, включенные в данный документ.
· изменения вставленного объекта, не отражаются в оригинале;
· вся информация хранится в одном файле и никаких проблем при переносе на другой компьютер не возникает.
В рамках OLE реализован метод drag-and-drop (перетащить и бросить), который обеспечивает наглядность процесса обмена данными, и его можно применять вместо операции копирования через буфер обмена даже при межоконном перемещении объектов и их частей.
OLE обеспечивает возможность местной активизации объекта – при двойном щелчке мышью объект обводится широкой штриховой рамкой, обозначающей активность, и остается на месте. Заголовок окна меняется на заголовок вызываемого приложения, а меню представляет собой комбинацию из меню приложения-источника и приложения-приемника. После выполнения операций (чаще всего, редактирования) над объектом возврат в первоначальное состояние осуществляется по щелчку мышью за пределами объекта.
Приложение-сервер и приложение-клиент обмениваются данными по наиболее новой технологии, доступной им обоим, т.е., если приложение-источник поддерживает только DDE, при работе в OLE объект будет вставлен, но возможность его активации из документа-приемника теряется.
OLE-технология, разработанная корпорацией Microsoft, обеспечивает:
· привязку – возможность вызова одной программы из другой;
· встраивание – помещение объектов, созданных в одном приложении, в документ другого.
Источник
Межпроцессное взаимодействие (IPC)
в этом разделе объясняются различные способы выполнения межпроцессного взаимодействия (IPC) между приложениями универсальная платформа Windows (UWP) и приложениями Win32.
Услуги для приложений
Службы приложений позволяют приложениям предоставлять службы, которые принимают и возвращают контейнеры свойств примитивов (набор значений) в фоновом режиме. Объекты с широкими возможностями могут передаваться при сериализации.
Службы приложений могут выполнять как фоновые задачи , так и процессы в рамках приложения переднего плана.
Службы приложений лучше использовать для совместного использования небольших объемов данных, где задержка почти в реальном времени не требуется.
Com — это распределенная объектно-ориентированная система для создания двоичных программных компонентов, которые могут взаимодействовать и взаимодействовать. Как разработчик вы используете COM для создания многократно используемых программных компонентов и слоев автоматизации для приложения. COM-компоненты могут быть в процессе или вне процесса и могут взаимодействовать через клиентскую и серверную модель. Необработанные серверы COM долго использовались в качестве средства для обмена данными между объектами.
Упакованные приложения с возможностью рунфуллтруст могут регистрировать необработанные COM-серверы для IPC с помощью манифеста пакета. Это называется упакованным com.
Файловая система
BroadFileSystemAccess
Упакованные приложения могут выполнять IPC с помощью обширной файловой системы, объявляя ограниченную возможность broadFileSystemAccess . эта возможность предоставляет Windows. служба хранилища api и api-интерфейсы Win32 ксксксфромапп доступ к широкой файловой системе.
По умолчанию IPC через файловую систему для упакованных приложений ограничена другими механизмами, описанными в этом разделе.
PublisherCacheFolder
PublisherCacheFolder позволяет упакованным приложениям объявлять папки в своем манифесте, которые могут использоваться совместно с другими пакетами одним и тем же издателем.
Папка общего хранилища имеет следующие требования и ограничения.
- Данные в папке общего хранилища не архивируются и не перемещаются.
- Пользователь может очистить содержимое папки общего хранилища.
- Нельзя использовать папку общего хранилища для обмена данными между приложениями разных издателей.
- Нельзя использовать папку общего хранилища для обмена данными между разными пользователями.
- В папке общего хранилища нет управления версиями.
Если вы публикуете несколько приложений и ищете простой механизм обмена данными между ними, PublisherCacheFolder — подходящий простой вариант на основе файловой системы.
шаредакцесссторажеманажер
Шаредакцесссторажеманажер используется совместно со службами приложений, активацией протоколов (например, лаунчурифорресултсасинк) и т. д., чтобы совместно использовать сторажефилес через маркеры.
фуллтрустпроцесслаунчер
Благодаря возможности рунфуллтруст Упакованные приложения могут запускать процессы с полным доверием в одном пакете.
В сценариях, где ограничения пакета являются косвенными, или отсутствуют параметры IPC, приложение может использовать процесс полного доверия в качестве прокси-сервера для взаимодействия с системой, а затем IPC с полным уровнем доверия через службы приложений или другой хорошо поддерживаемый механизм IPC.
LaunchUriForResultsAsync
Лаунчурифорресултсасинк используется для простого обмена данными с другими упакованными приложениями, реализующими контракт активации протоколфорресултс . В отличие от служб приложений, которые обычно выполняются в фоновом режиме, целевое приложение запускается на переднем плане.
Для совместного использования файлов можно передавать маркеры шаредсторажеакцессманажер в приложение через его значение.
Замыкание на себя
Замыкание на себя — это процесс связи с сетевым сервером, который прослушивает localhost (адрес замыкания на себя).
Для обеспечения безопасности и сетевой изоляции подключения по обратной связи для IPC по умолчанию блокируются для упакованных приложений. Можно включить замыкание соединений между доверенным упакованным приложением с помощью возможностей и свойств манифеста.
- Все Упакованные приложения, участвующие в подключениях замыкания на себя, должны объявлять privateNetworkClientServer возможности в манифестах пакетов.
- Два упакованных приложения могут обмениваться данными через замыкание на себя, объявляя лупбаккакцессрулес в манифестах пакетов.
- Каждое приложение должно перечислить в лупбаккакцессрулес. Клиент объявляет правило «out» для сервера, а сервер объявляет правила «in» для поддерживаемых клиентов.
имя семейства пакетов, необходимое для распознавания приложения в этих правилах, можно найти с помощью редактора манифеста пакета во Visual Studio во время разработки, через центр партнеров для приложений, опубликованных с помощью Microsoft Store, или с помощью команды PowerShell Get-AppxPackage для уже установленных приложений.
Неупакованные приложения и службы не имеют удостоверения пакета, поэтому их нельзя объявлять в лупбаккакцессрулес. Вы можете настроить упакованное приложение для подключения через замыкание с помощью неупакованных приложений и служб с помощью CheckNetIsolation.exe, однако это возможно только в сценариях загружать неопубликованные или отладки, где у вас есть локальный доступ к компьютеру и у вас есть права администратора.
- Все Упакованные приложения, участвующие в подключениях замыкания на себя, должны объявлять privateNetworkClientServer возможности в манифестах пакетов.
- Если упакованное приложение подключается к неупакованному приложению или службе, выполните команду, CheckNetIsolation.exe LoopbackExempt -a -n=
чтобы добавить исключение замыкания на себя для упакованного приложения.
Если неупакованное приложение или служба подключается к упакованному приложению, выполните команду, CheckNetIsolation.exe LoopbackExempt -is -n=
чтобы позволить упакованному приложению принимать входящие подключения с замыканием на себя.
- CheckNetIsolation.exe должны выполняться постоянно, пока упакованное приложение прослушивает подключения.
- -is флаг был введен в Windows 10 версии 1607 (10,0; Сборка 14393).
имя семейства пакетов, необходимое для -n флага CheckNetIsolation.exe , можно найти в редакторе манифеста пакета в Visual Studio во время разработки, через центр партнеров для приложений, опубликованных с помощью Microsoft Store, или с помощью команды PowerShell Get-AppxPackage для уже установленных приложений.
Каналы
Каналы обеспечивают простое взаимодействие между сервером канала и одним или несколькими клиентами канала.
Анонимные каналы и именованные каналы поддерживают следующие ограничения:
- По умолчанию именованные каналы в упакованных приложениях поддерживаются только между процессами в одном пакете, если только процесс не имеет полного доверия.
- Именованные каналы можно совместно использовать в пакетах, следуя рекомендациям по предоставлению общего доступа к именованным объектам.
- Именованные каналы в упакованных приложениях должны использовать синтаксис \\.\pipe\LOCAL\ для имени канала.
Реестр
Использование реестра для IPC, как правило, не рекомендуется, но поддерживается для существующего кода. Упакованные приложения имеют доступ только к тем разделам реестра, для доступа к которым у них есть разрешение.
Классические приложения, Упакованные в MSIX, используют виртуализацию реестра , так что глобальные записи реестра содержатся в частном кусте в пакете MSIX. Это обеспечивает совместимость исходного кода при минимизации влияния на глобальные реестры и может использоваться для IPC между процессами в одном пакете. Если необходимо использовать реестр, то эта модель является предпочтительной, а управление глобальным реестром — с помощью.
RPC можно использовать для подключения упакованного приложения к КОНЕЧНОЙ точке RPC Win32 при условии, что Пакетное приложение имеет правильные возможности для сопоставления ACL в КОНЕЧНОЙ точке RPC.
Пользовательские возможности позволяют производителям оборудования и независимым поставщикам программно определять произвольные возможности, предоставлять им конечные точки RPC, а затем предоставить эти возможности полномочным клиентским приложениям. Полный пример приложения см. в примере кустомкапабилити .
Конечные точки RPC также могут быть доступен для конкретных упакованных приложений, чтобы ограничить доступ к конечной точке только этими приложениями без необходимости управления дополнительными возможностями. Вы можете использовать API деривеаппконтаинерсидфромаппконтаинернаме для получения идентификатора безопасности из имени семейства пакетов, а затем в списке ACL КОНЕЧНОЙ точки RPC с ИД безопасности, как показано в примере кустомкапабилити .
Общая память
Сопоставление файлов можно использовать для совместного использования файла или памяти между двумя или более процессами со следующими ограничениями:
- По умолчанию сопоставления файлов в упакованных приложениях поддерживаются только между процессами в одном пакете, если только процесс не имеет полного доверия.
- Сопоставления файлов можно совместно использовать в пакетах, следуя рекомендациям по предоставлению общего доступа к именованным объектам.
Для эффективного совместного использования больших объемов данных и управления ими рекомендуется использовать общую память.
Источник
