Удивительное рядом. Как устроен буфер обмена в Windows и Linux

Опенсорсная утилита CopyQ показывает содержимое буфера обмена на всех ОС и сохраняет историю

Буфер обмена — один из основных элементов GUI, но он сложен в реализации. Подводных камней настолько много, что вы больше никогда не сможете произнести слово «копипаст» с презрительным выражением. Есть тысячи приложений и форматов данных. Невозможно обеспечить полную конвертацию всего во всё.

В некоторых случаях данные вообще нигде не сохраняются по нажатию Ctrl+C. И по нажатию Ctrl+V будет возвращён NULL. Shit happens, как говорится…

В одних программах возможен копипаст только текста, в других можно выделить графику, где-то поддерживается копирование/вставка файлов и т. д. Нюансов очень много. Попробуем выделить основные моменты для Windows и Linux.

Если идти от простого к сложному и в примерно хронологическом порядке, то лучше начать с X11.

▍ X11

Графический стек Linux состоит из множества разных элементов, которые объединены в монолитную архитектуру и каким-то чудом работают вместе без постоянных глюков.

Так или иначе, клипборд в X11 работает не так, как в других ОС. Здесь создаётся впечатление двух независимых буферов обмена. Один по горячим клавишам типа Ctrl+C/V (или Ctrl/Shift+Ins), а второй — по нажатию мыши. Если скопировать данные в буфер горячей клавишей с клавиатуры, то и вставить можно только с клавиатуры. А если скопировал мышью — то вставить средним колёсиком. Но иногда работают оба способа, то есть можно скопировать текст в буфер обмена мышью, а вставить — сочетанием клавиш.

Документация подтверждает, что в X11 действительно несколько независимых буферов обмена (здесь они называются selections). Их даже не два, а может быть сколько угодно много. По схеме эти selections представляют способ коммуникации между клиентами. Сами клиенты должны договориться между собой, какой буфер они будут использовать. Например, если вы пишете какой-то клиент под Linux, то как владелец буфера (SelectionOwner) можете ввести свой буфер обмена и надеяться, что остальные его поймут.

То есть работа с буфером обмена в общем виде выглядит так:

1. Клиент 1 заявляет X-серверу о владении определённым буфером как SelectionOwner (буфер 1).
   
2. В какой-то момент времени клиент 2 может попросить у сервера содержимое буфера 1 в определённом формате.
   
3. X Server получает запрос и перенаправляет его соответствующему владельцу.
   
4. Владелец буфера (клиент) напрямую отправляет запрошенные данные в указанном формате клиенту 2, когда (и если) сможет это сделать.
   
5. Клиент 2 возвращает клиенту 1 подтверждение получения.

Всё кажется просто и логично, при минимальном взаимодействии с системным ядром. Но в реальности тут возможны нестыковки и заминки. Самое главное, что нет абсолютно никакой гарантии, что клиент 1 когда-нибудь отправит запрошенные данные, а уж тем более в указанном формате.

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

• PRIMARY: буфер «средней кнопки мыши» (условно говоря);
• SECONDARY: практически не используется в наше время;
• CLIPBOARD: буфер Ctrl+C (условно говоря).

Часто работающие программы в X11 создают невидимые окна исключительно с целью владения (захвата) того или иного системного буфера. Теоретически, это можно сделать и с помощью видимого окна, но с помощью невидимого проще.

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

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

▍ Wayland

Как известно, на замену X11 разработан протокол Wayland, где всё организовано несколько иначе.


Работа буфера обмена в спецификациях Wayland описана с применением той же специфической терминологии (selection — буфер обмена, clipboard — один из буферов обмена, уникальный идентификатор atom и т. д.).

Но если разобраться, всё организовано довольно просто и логично, как в X11, даже с некоторыми усовершенствованиями.

Здесь примерно так же организовано владение буфером определённого типа. Когда вы нажимаете Ctrl+C, программа просто захватывает буфер обмена определённого типа и заявляет о наличии данных в определённом формате (например, image/png, text/x-moz-url1 или text/plain). На этом этапе никакие данные никуда не передаются и нигде не сохраняются. Так что в отсутствие специального менеджера для буфера обмена данные будут потеряны при закрытии окна или при их удалении в окне.

Захват буфера разрешён только основному окну. Когда новое окно захватывает буфер, оно получает сообщение от предыдущего владельца буфера о наличии данных и их формате. Затем наступает этап вставки данных «из буфера» (в кавычках, потому что мы уже поняли, что буфер — абстрактное понятие), то есть помеченных для копирования данных. Так вот, второй клиент делает запрос (создаёт дескриптор файла) с указанием формата, в котором хочет получить данные. Этот формат может не полностью совпадать с указанными выше, и тогда он получит лишь часть данных или вовсе ничего.

Несмотря на долгую эволюцию, API для буфера обмена в Wayland далеко не совершенен и этой подсистеме по-прежнему нужен внешний менеджер (библиотека) для нормальной работы.

▍ Как это работает в Windows

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

• Вызов Open­Clipboard(hwnd) отправляет информацию об окне, которое должно стать новым владельцем буфера.
• Вызов Empty­Clipboard() стирает из буфера предыдущее содержимое.
• Вызов Set­Clipboard­Data() для каждого фрагмента данных, которые вы хотите поместить в буфер (по историческим причинам этот вызов могут использовать даже программы, не владеющие буфером).
• Вызов Close­Clipboard() сообщает об окончании работы с данными.
• Поздравляем, вы новый владелец буфера.

При попытке стороннего окна получить доступ к буферу его владелец получает несколько сообщений. Среди них могут быть WM_RENDER­FORMAT (отложенный рендеринг данных для буфера до того момента, когда они будут непосредственно запрошены — о нём ниже), WM_RENDER­ALL­FORMATS (часть последовательности уничтожения окна, если он ещё является владельцем буфера обмена на момент его уничтожения) или WM_DESTROYCLIPBOARD (опустошение содержимого буфера).

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

• Вызов Open­Clipboard(hwnd) отправляет информацию об окне, которое читает из буфера.
• Вызов Get­Clipboard­Data() для получения данных из буфера.
• Вызов Close­Clipboard() для индикации окончания чтения данных.

По словам сотрудника Microsoft с 25-летним стажем Реймонда Чена, если бы все использовали рекомендуемую схему, то Windows бы работала как положено. К сожалению, сторонние программы постоянно норовят нарушить конвенцию, а API допускает запись в чужой буфер. Из-за этого возникают проблемы.

Примерно так же работает буфер в macOS (собственно, изобретателями самой концепции буфера обмена считаются создатели компьютера Mac/Lisa, под Mac есть отличные менеджеры с поиском по многомесячной истории типа ClipBuddy, Alfred и Raycast).

Кроме того, в Windows есть Linux-подобный способ работы с буфером, когда данные нигде не сохраняются, а просто помечаются как доступные (для экономии памяти). Это упомянутый выше отложенный рендеринг WM_RENDER­FORMAT. Поэтому если скопировать в буфер большой диапазон ячеек Excel, а потом попробовать их вставить в другой программе в текстовом формате, то операция может завершиться неудачно. В Windows действует ограничение 30 секунд на отложенный рендеринг (на июнь 2022 года). Если в течение этого времени данные не удалось переконвертировать в новый формат для вставки, то буфер вернёт NULL.

▍ Вывод

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

Недостаток тоже понятен — при закрытии исходного окна информация «из буфера» тоже будет потеряна и уже никуда не вставится (хотя эту проблему решают специальные менеджеры буфера).

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

Telegram-канал с розыгрышами призов, новостями IT и постами о ретроиграх ?️