Да, проблема действительно в софте (см. habrahabr.ru/qa/48284/#comment_227330)
Спасибо за совет (отметил ваш ответ, как решение, за рекомендацию поэкспериментировать).
Путем перебора запущенного софта с удивлением для себя обнаружил, что с буфером обмена так «игрался» VNC-клиент (что, как ни парадоксально, имеет смысл). Буду искать ему альтернативы или нормально настраивать. Спасибо всем ответившим.
Компьютер рабочий + я его сетапал с нуля. Соответственно, левых программ быть не должно.
Из того, что, например, запущено на конкретно данный момент (все процессы, включая различные сервисы), нет ничего, что вызывает подозрения или могло бы явно вызвать подобные проблемы.
Не исключено, правда, что я могу что-то не знать про установленные мною программы, но тогда надо проверять лично каждую, т.к. подозреваемых пока вообще нет.
Недавно поставил Ditto (дополнение для буфера обмена, которое хранит историю буфера и позволяет вставлять некогда скопированные тексты), но проблема проявлялась и до него.
В нем, кстати, видно, что в буфер русский текст сначала копируется в нормальной кодировке, а потом он перезаписывается «кракозябрами».
Вы берет слишком узкое понятие слова «производительность», потому что кроме метрики «операции в секунду» существуют как минимум интегральное и пиковое потребление памяти.
Тем более, что необходимо учитывать различные внешние факторы и знать, как минимизировать их влияние.
Можете считать, что сложность всей затеи экспоненциальна: на тривиальных задачах все просто. Но уже в момент, когда потребуется динамически выделить память, прочитать/записать файл, узнать время, то возникает туча проблем. Тогда даже эмуляцию нельзя будет упростить, не переписав кучу системных библиотек (или эмулировать и их, но каждая из них тянет и другие… все сведется к эмуляции ядра ОС).
И опять же, если библиотека тривиальна, то в любом случае проще ее написать с нуля.
Реализация эмулятора (как общего, так и какого-то частного назначения) конечно возможна. Вопрос трудозатратности и эффективности:
1) эмулятор реализовать с нуля скорее всего сложнее, чем с нуля написать новую мат. библиотеку.
2) выполнение библиотеки на эмуляторе заведомо будет медленее
3) высоки шансы, что исполнение библиотеки на эмуляторе будет отличаться от исполнения на исходной системе вплоть до ошибок исполнения.
Проблемы уже начинаются с момента, когда вам хочется вызвать этот синус. Т.к. эмулируемая мат. библиотека находится в своем собственном адресном пространстве, то вызвать ее из приложения невозможно, только через обращение к эмулятору. Но эмулятор, в свою очередь, не знает по какому адресу находится нужная функция. Для этого ему нужно знать адрес загрузки библиотеки и прочитать экспортную секцию dll-ки. Фактически, эмулятор должен иметь все способности обычного системного загрузчика.
Абсолютно нет. Эмулятор — это программа, которая просто исполняет другую программу как есть. То есть, у эмулятора, грубо говоря, есть несколько объектов, представляющих регистры, память и стек. Далее ему дается программа и эмулятор ее начинает выполнять: надо сложить два регистра -> эмулятор начинает исполнять кучу кода, которые складывают два виртуальных регистра. Причем для выполнения этой простой операции эмулятор должен:
1) Прочитать машинную инструкцию.
2) Найти объекты, соответствующие нужным регистрам
3) Взять их значения
4) Сложить и записать в соответствующую структуру данных
(Конечно, с учетом оптимизаций самого эмулятора это все делается гораздо быстрее и проще)
Эмуляторы занимаются иным процессом: в рамках эмулятора воссоздается исходная архитектура (этакая песочница) в рамках которой работает приложение. Грубо говоря, можно сказать, что софтварными средствами создается сам процессор и эмулируется его работа (то есть взаимодействие регистров, чтения-записи в память и все остальное). Кроме этого, нативное приложение не может в рамках своего процесса использовать (напрямую звать ее функции и использовать результаты вычислений) эмулируемую библиотеку, т.к. они будут находится в разных адресных пространствах, да и вообще в разных средах исполнения.
Ну, во-первых, стоит отметить, что вопрос стоит не только в «пересборке» приложения под другую процессорную архитектуру, но и под другую ОС тоже.
Соответственно, первая же возникающая проблема — это API операционной системы. Практически все, начиная от операций чтения-записи до межпотоковой синхронизации, будет требовать вызовов различных функций ОС.
Понятное дело, что на различных системах API отличается не только интерфейсом, но и функционалом в принципе. Например, в Windows для синхронизации есть критические секции, а в линуксе — мьютексы.
Таким образом, имеем два варианта:
1) Либо вызов подобной системной функции (или даже процедуру, в которой есть такие вызовы) придется переписывать заново, чтобы использовать API целевой системы
2) Либо необходимо написать библиотеку, которая будет обладать исходным API и реализовывать требуемый функционал на целевой системе.
Первый вариант — это, собственно, то, как пишутся мультиплатформенные приложения: platform-dependent код прячется в отдельные модули, разные для каждой платформы, и закрывается уже общим API. Однако, в случае дизассемблированного кода можно представить насколько это сложнее (если разум вообще может представлять такие масштабы).
Второй вариант — это что-то типа Wine'а. В этом случае исходный код, в принципе, не трогается (нет нужды), но нужно писать множество библиотек и реализовывать загрузчик для всего этого.
Если же меняется только архитектура, то здесь тоже не легче. Во-первых, ОС тоже, фактически, меняется (например, с 32-битной на 64-битную, хотя тут есть односторонняя совместимость, которая позволяет запускать x86 приложения на amd64, но, тем не менее, нельзя совмещать бинарники разных архитектур). Меняются соглашения о вызовах для всех функций (на каких регистрах передаются параметры функций, на каких возвращаются, кто чистит стек итд). Кроме этого, меняются константы в коде (имеется в виду, например, что для инструкции jmp смещение для прыжка вычисляется по-разному), то есть требуется много чего пересчитывать. Кроме этого, если есть совсем разные архитектуры (RISC и CISC, например), то однозначно отобразить одно множество инструкций в другое в принципе невозможно. Тут уже нужно отображать множество последовательностей инструкций в лучшем случае. Кроме этого даже регистры невозможно однозначно друг в друга отобразить («нужен ли этот регистр или его уже можно перезатереть?», «если я положу значение на стек и сэкономлю регистр, то не поедут ли захардкоженные константы?», «переживает ли этот регистр вызов функции или нет?»).
И вообще, перенос чисто ассемблерного кода с одной архитектуры на другую можно сравнить с трансляцией кода с одного языка на другой. При трансляции же обычно строится внутренее представления отдельно взятых процедур и это внутренее представление уже переводят на целевой язык. Однако, для ассемблерного кода (тем более оптимизированного), несмотря на элементарный синтаксис, подобное внутренее представление построить невозможно из-за неструктуированности кода. Таким образом машинный анализ впадает в полный ступор. А человеческому тоже ничуть не легче.
PS. возможно слегка сумбурно описал, но я вижу проблему как-то так.
Надо только уточнить, что эти виртуальные машины работают не с машинным кодом, а со специальным байткодом (такой, который, например, используется в Java или C#), который да, можно динамически компилировать под конкретную платформу (JIT — Just-In-Time compilation).
Байткод Java-приложений и архитектура JVM на порядок проще реальных процессорных архитектур и наборов машинных команд, и возможность декомпиляции (абсолютно однозначной) Java-приложений была заложена by-design.
В то же время, для native-приложений и исполняемых файлов декомпиляция возможна в совершенно мизерных случаях, при условии, что: 1. некоторый абстрактный компилятор компилировал приложение с учетом того, что потребуется ее декомпиляция, т.е. сохраняя дополнительную мета-информацию, ненужную для работы программы. 2. отсутствую platform-specific оптимизации, которые могут превратить ассемблерный код в такую лапшу, что невозможно будет разобраться даже с отдельной дизассемблированной функцией.
В общем случае декомпиляция (тем более однозначная), можно считать, что невозможна.
Сортировка так или иначе происходит по одному определенному параметру, относительно которого обработчик выдает результат при сравнении. В данном же случае имеется набор аттрибутов, по которым невозможно создать один единственный универсальный параметр для сравнения.
@ivsedm, можно сказать и так. В случае с булевскими параметрами это получается естественным образом — множество комбинаций бинарных значений легко отображается в целые числа.
VNCviewer от RealVNC версии 3.3.7
Для справедливости стоит отметить, что последняя версия (5.0.5) этого клиента работает нормально.