Unicorn is a lightweight, multi-platform, multi-architecture CPU emulator framework based on QEMU.

Unicorn offers some unparalleled features:

Multi-architecture: ARM, ARM64 (ARMv8), M68K, MIPS, SPARC, and X86 (16, 32, 64-bit)
Clean/simple/lightweight/intuitive architecture-neutral API
Implemented in pure C language, with bindings for Crystal, Clojure, Visual Basic, Perl, Rust, Ruby, Python, Java, .NET, Go, Delphi/Free Pascal, Haskell and Pharo.
Native support for Windows & *nix (with Mac OSX, Linux, *BSD & Solaris confirmed)
High performance via Just-In-Time compilation
Support for fine-grained instrumentation at various levels
Thread-safety by design
Distributed under free software license GPLv2


Последний мастер - --> Link <--
Последний релиз Version 1.0.2-rc4 (30.06.2020) - --> Link <--



Сборка - следуем указанию в --> Link <--


*Если MINGW64 Портабельный то здесь нужно указать полный путь с названием диска $ cd c:/msys64/unicorn

-----
RE In Progress [!] Coding Hazard [!] Stay Clear of this Cube

| Сообщение посчитали полезным: plutos, Isaev

hors пишет:
Очевидно затем, чтобы выявлять на этом форуме психически психически неурaвновешанных людей, которые свои личные комплексы сублимируют в агрессивное навязывание своего мнения. Например в теме про Unicorn рассказывают про trace32.
Я психопат нарциссического типа, вполне себе уравновешенный. На форуме по кракингу (именно кракингу, не программированию) меня заинтересовала тема об идельном-эмуляторе-процессоров, тема мне близкая и можно сказать выстраданная. Беглый осмотр предмета вызвал легкую фрустрацию, я просто не знаю, что бы я стал с этим иструментом делать. Может кому-то, кто настолько же неуравновешен и закомплексован, как я, именно мой совет покажется полезным. А быть может кто-то, к кому этот пост был адресован, придет и объяснит мне дураку чем эта штука может быть полезна.

ЗЫ: может все дело в плагинах, интересно есть ли они там?

-----
2 оттенка серого

| Сообщение посчитали полезным:

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

Бро, я даже не удивлюсь если у тебя самая быстрая рука в Гомеле, но тема совсем о другом.
Задающий вопрос может хоть перфокартами пользоваться и если задаёт вопрос по перфокартам, постарайся для разнообразия давать ответы в контексте вопроса, а не убеждать всех, какой ты Д'Артаньян, а вопрошающий мудак, нужно брать X и тренировать руки, когда будет вопрос в духе X или Y, тогда твой выход, а пока даже не можешь понять о чём тема.

| Сообщение посчитали полезным:

shellstorm

Да ладно, это наверно не вам было адресовано, а Bronco(какую то чушь писать начал, впрочем я забыл уже), не важно впрочем, мб я под синь на солнышке нагрелся

Интересно про тормоза такие, конечно не всегда профайл важен, для целей отладки это в общем то и не важно. Но всё равно такие просадки не есть гуд, если будет отлаживаться какое то тяжёлое апп, браузер или к примеру тот же вмп с огромными циклами, то эти трассы/графы/етц будут строится сутками, что в принципе можно сделать за минуты.

Думаю даже что это лично я зациклился на профайлах по большей части, потому что такая задача давно у меня поставлена

hors

> Ставим хук на всё адресное пространство, останавливаемся на каждой инструкции и сравниваем адреса.

Вы изобретаете велосипед с квадратными колёсами. Отследить потоки данных(cfg/dfg) можно не только эмулируя код. Эмуляция для прикладных задач не подходит - эмулятор огромного размера всегда и не без косяков, причём есчо и медленный. Оптимальный выбор это динамическая эмуляция - прямое выполнение кода в буферах и эмуляция ветвлений. При этом профайл садится примерно на 10% от реалтайма. И вероятность ошибок в таком случае весьма мала, есть есчо куча положительных моментов, как например возможность пакетной обработки, что невозможно сделать под эмулятором.

Добавлено спустя 4 минуты
А есчо нужно не забыть важный момент - системная обработка. Тоесть эмулятор лишь поток инструкций эмулирует, но как быть с ядерными вызовами(сервисами) ?

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

-----
vx

| Сообщение посчитали полезным:

difexacaw пишет: Да ладно, это наверно не вам было адресовано, а Bronco

Он умеет листать выхлоп дасма. Зачем ему для проверки каких то идей брать инструменты на которые нужно тратить уйму времени, софтварная реализация BP эмулятором не отличается от реализации в рекомпиляторе, поэтому при желании этот опыт можно перенести на другие инструменты из этого же класса, при этом не тратя время на написание обвязок. Сам код это не просто "какой то криптор", а вполне себе по типу llvm-based обфускатора (разрыв графа, калькуляция ссылок, защита данных), там нет декрипта, там нужен ребилд трассы, а перед этим неплохо сначала получить более-менее читабельную трассу, желательно таким способом, который совместим с остальными компонентами, иначе всё оборачивается написанием большого объема кода, когда это работа, это нормально, а когда хобби и которое не подразумевает за собой каких-то больших выгод, сомнительная трата времени, не все живут за компом, в этом дело, а вовсе не в знании или незнании альтернативных решений. Вот x64dbg реально медленный и не факт, что дождёшься трассы, а не рухнет всё в процессе работы, windbg несравнимо быстрее, но толку если у него нет сопутствующей инфраструктуры, можно конечно заворачивать трассу в сторонний движок, но это опять же, оборачивается написанием кода. Время и целесообразность траты, вся причина.

| Сообщение посчитали полезным:

shellstorm

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

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

Добавлено спустя 17 минут
shellstorm

> indbg несравнимо быстрее, но толку если у него нет сопутствующей инфраструктуры

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

> вовсе не в знании или незнании альтернативных решений.

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

-----
vx

| Сообщение посчитали полезным:

difexacaw, ты как то реже пости, а то тебя много, и всё ни о чём. таргета не видел, сабж не юзал, его возможости_недостатки не знаешь, текст в постах читаешь выборочно, как девица реагируешь только на ключевые для тебя слова, но в дырку лезешь, хотя вухи то не пролазят.
нужен будет твой совет, я тебе в личку напишу, но опыту знаю, что и от этого толку нет.
f13nd пишет:
интересно есть ли они там?
угу... есть... купился в своё время на сдк x64dbg, осталось только отладочный двиг обойти.

-----
Чтобы юзер в нэте не делал,его всё равно жалко..

| Сообщение посчитали полезным:

Bronco

Так это вы во всех темах со своими понтами, мне же тех детали интересны. Вот и сейчас я спросил - вы не можите ответить по сабжу. Мне он не особо интересен, это нужно прогружать, отлаживать - куча гемора. Тем более что вроде бы как это уже было сделано ранее, может даже и на данном ресурсе, проще спросить чем искать. Да и статус у вас - местный троль, вы ниочём в каждой теме. Мне хотелось бы услышать что то по делу, техническую инфу. А как сделать лучше - давно уже визор механизмы проработаны, вы не ищите лучшее решение, только колхозите тем что есть. Без обид только, может вы и умный чел, но пока это под сомнением и не точно

-----
vx

| Сообщение посчитали полезным:

difexacaw пишет: Пусть напишет тот кто в теме как происходит системная обработка.

Может напишешь трейсер на базе dbi для x64, просто трейсер с доступом set\get к регистрам и доступом к памяти set\get, с возможностью завернуть буфер в движок дасма, это конструктивней тысячи слов и думаю проект будет оценен общественностью.

| Сообщение посчитали полезным:

shellstorm

У меня засада уже больше года с алго по визору, тут рядом тема вы в ней отвечали. Какую то примитивную трассировку может любой собрать, оно хоть и будет работать, но невероятно медленно. Мне же хочется реализовать визор реалтаймом не отличимый от прямого исполнения. Это во первых решит кучу викс задач, апп будет взято под полный контроль, это не сможет обнаружить юзер, какой то инструмент даже на основе статистики и позволит реализовать полноценную софтверную защиту от OP, это моя задача. Я приводил пример dye, тут всё обосрали, вместо того что бы почерпнуть от туда наработанные техники.

-----
vx

| Сообщение посчитали полезным:

difexacaw пишет: Какую то примитивную трассировку может любой собрать

Тем более, значит времени много не займёт и инструмент полезный для общественности. По визору приводил пример очень качественной архитектуры, которая хорошо масштабируемый, выкинуть лишнее и практические готовая архитектура для dbi, которую очень сложно убить, но изобретать GC интересней. Сначала нужно продумать архитектуру связей, реализация именно трейсера вторична, поскольку во многом зависит от архитектуры и поставленных условий, возможно проседания из за реализации окажутся незначительной мелочью по сравнению с другими компонентами через который проходит поток, голой трейсер никому не интересен если в его работу нельзя вклиниться, вот этот момент может иметь существенную зависимость от архитектуры, тем самым экономя в одном месте, делаешь проседания в другом или невозможность адекватного внедрения какого то функционала. Контейнеры в гипервизоре давно изобрели, корпоративному сегменту не интересны костыли, а обывателям класть на OP, остается узкий круг задач связанный с ИБ, одна из которых контроль исполнения, ниша пока что не сильно занята. Не обосрали, а конструктивно раскритиковали, никому не нужен конструктор из сомнительного качества исходников, которые к тому же еще нужно дописывать и ко всему прочему x86, сделай нормальные интерфейсы, lib и сишный хидер, асм мертв, сугубо нишевой язык для очень узкого круга задач, пиши на сишке и получишь больше конструктивных комментариев, асм исходники будут читать только упоротые дети, которым заняться нечем, при нормальных исходниках на хабе мог бы получить адекватный фидбэк.

| Сообщение посчитали полезным: difexacaw

difexacaw пишет:
Мне же хочется реализовать визор реалтаймом не отличимый от прямого исполнения.
Этого нельзя сделать by design софтварно. В железе давно все эти визоры изобретены, оверхед небольшой.

| Сообщение посчитали полезным:

SegFault

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

Эта задача в разработке. Я отказался от повторного исполнения - модификация кода на лету, рядом тема. Как эффективно транслировать произвольный указатель на структуры не ясно. Но я найду решение

shellstorm

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

-----
vx

| Сообщение посчитали полезным:

difexacaw пишет:
статус у вас - местный троль, вы ниочём в каждой теме
плюсануть стрелочнику за ржач?
но ведь, сука, не отстанет, пока игнорить не начнёшь
difexacaw пишет:
это нужно прогружать, отлаживать - куча гемора
млять, пока ты лясы точишь, ни о чём или абстракциях, вот мне на это приходиться находить время.
и естественно то же есть вопросы, но ты своей шнягой, как обычно всё засрёшь на пару страниц, и мой вопрос в воздухе останеться. поэтому, лично меня, твоя персона давно уже плющит, отсюда и отвечать тебе, нет желания. находи время,собирай, кури и ковыряй.
shellstorm, за возню с тобой надо уже ранг подымать.
вот с ним, реально, очень интересно дискутировать, он оппонирует грамотно, местами даже генерит в оппоненте позитивное, мне во многом кругозор расширил.
/add
длины сабж пока определяет чётко, но капстон на avx512f уже попался, думается что тут те же грабли.
по рипу трассы в бинарь, кажется это предел, что можно выжать:
- Total Time: 00:00:00.062 - 1.Write instr->1069 | 2.Instr size->-0xfc6
если в текстовик как у пин, возможно будет немного быстрее.

-----
Чтобы юзер в нэте не делал,его всё равно жалко..

| Сообщение посчитали полезным:

Bronco

> вот мне на это приходиться находить время.

Это походу ваша работа, по этой причине вас и не интересуют никакие алго/абстракции, лишь тех задание, я прав ?

> Total Time: 00:00:00.062 - 1.Write instr->1069

часы-минуты-секунды-62мс на 1к итераций.. тоесть получается в секунду 17k итераций. Это куда медленее на порядки машинной трассировки. Тем более что 60мс - это планировочное время, на таких интервалах тайминг измерен быть не может, он должен статистически накапливаться. Те счётчики что вы используете - фейлят(tsc).

Кстате разрешение системных таймеров примерно соответствует вашей статистике, значит вы их и использовали. Они не пригодны для снятия профайла за одну итерацию - их нужны сотни/тысячи и деление на их число что бы получить результат. Иначе счётчик обнулится не в нужное время или задача прервётся, вы получите не корректные результаты.

-----
vx

| Сообщение посчитали полезным:

difexacaw пишет:
получается в секунду 17k итераций
тесты случайные, на самом деле ещё быстрей, где то до 30к в сек. по крайней мере 100к инстр за 4 сек в бинарь скинул. а может ещё быстрей, но тут гуй дбг начинает залипать и фризить,
приходиться гальмовать доуевентом и мультиками в статус бар. получается что рендер в кьюте медленней сишного кода.
всё бы хорошо, но есть косяк в связке логического сдвига влево и оператора флага, если первый операнд меньше. состояние рфлагс не меняется. в итоге уже в 2 случаях поведение разное. в одном случае перешли на метку, в другом перехода не было.
первый случай уменьшил для наглядности, на нём в роге попадаем в бесконечный цикл:

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

-----
Чтобы юзер в нэте не делал,его всё равно жалко..

| Сообщение посчитали полезным:

Bronco

> а лучше абстрагируйся от любых психоанализов.

Я просто поинтересовался, без каких то подвохов.

> тесты случайные, на самом деле ещё быстрей, где то до 30к в сек.

Странные тесты, так ведь не делается, ваша статистика плавает вместе с фазой луны, в неё столько факторов, что видимо можно лишь строить догадки про порядок значения(10-100к). Файловая система куда более непредсказуема, чем шедулер. Доступ к файлу может быть и более 4сек, аналогично и с отладчиком. 30к инструкций для декодера это очень мало. Хотя если не стоит задача профайла, то это не важно(если бы не название топика, эмуль ездящий как каток по асфальту ).

-----
vx

| Сообщение посчитали полезным:

difexacaw пишет:
непредсказуема, чем шедулер.
Хто??? Скежулэр или скежелер.
Что, бля, за шедулер?
По русски это называется: планировщик

ЗЫ: Это крайне распространенная ошибка почти всех. schedule говорить как шедуле. Вы school как говорите? Шул или Щул? )

| Сообщение посчитали полезным:

hypn0

Это общепринятый термин, ты вот его понял. Не нужно няпрягать терминами, каждый говорит как он хочет, лишь бы это было понятно. Все вопросы вашей училке в школе задайте, лол. Зачем же ты показываешь какой ты мудак.

-----
vx

| Сообщение посчитали полезным:

hypn0 пишет:
Что, бля, за шедулер?
hypn0 пишет:
Это крайне распространенная ошибка почти всех. schedule говорить как шедуле.

это не ошибка: так "ошибаются" все жители Британских островов.
это British вариант произношения этого слова.
Другой вариант - American English.

https://dictionary.cambridge.org/pronunciation/english/schedule

the modern British pronunciation ("shed-yul") is from French influence,
while the U.S. pronunciation ("sked-yul") is from the practice of Webster, and is based on the Greek original.


А вообще-то тема скатилась уже куда-то в помойную яму...


-----
Give me a HANDLE and I will move the Earth.

| Сообщение посчитали полезным:

difexacaw пишет:
Странные тесты, так ведь не делается, ваша статистика плавает вместе с фазой луны
нифуя не слушаешь советов - вот ещё внимательней читай посты
в трейсере 2 ошибки с одним оператором флага, на выходе рипнутая трасса в выделенную страницу и тайминг, поэтому 2 случайных теста. задача то дойти до ретурна. а скорость вполне терпима, лям инстр за минуту, это ого-го уже.
отладчик мистера по скрипту, с вкл видео потоком, хоть в браузере, хоть в медиа плеере, то же самое за боллее чем 7 часов лопатил. а без видяхи как то и дня не хватило. вот где полный ппц.
теперь задача понять причину такого поведения, в статик деобфускаторе такого нет, но и конечны фильтры, бряки и тп. меньше пишем, а треша дохрена, быстрее снимаем трассу.
ну тут от тебя тоже толку не будет.

-----
Чтобы юзер в нэте не делал,его всё равно жалко..

| Сообщение посчитали полезным:

Bronco

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

Добавлено спустя 30 минут
Bronco

Я вас туго воспринимаю, так как вы сливаете ваши мысли в кучу не разделяя их, получается трудно понимаемое месево, eg:

> на выходе рипнутая трасса в выделенную страницу и тайминг, поэтому 2 случайных теста.

Какую страницу и почему по этому тесты случайные" и как они могут быть случайными я хз

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

И что вообще у вас за трейсер" ?
Как это работает ?
Эмулятор потока инструкций ?

Добавлено спустя 51 минуту
А в общем же, для чего нужен эмуляторный цикл в юзер апп ??

Декодер возвращает всю нужную инфу для каждой инструкции. Но зачем её эмулировать ?
К примеру аверы это делают, но они это выполняют в виртуальной машине, где эмулируется не только каждая инструкция, но и окружение апп - память, функции етц.

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

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

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

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

-----
vx

| Сообщение посчитали полезным:

Bronco
difexacaw

Это не раздел "Оффтоп", а "Софт, инструменты". Свои личные волнения обсуждайте либо в оффтопе, либо в личке.

-----
EnJoy!

| Сообщение посчитали полезным: sefkrd

Jupiter пишет:
Это не раздел "Оффтоп", а "Софт, инструменты".
упс., приехали всё в кучу.. ))
я поднял топ с конкретным вопросом о бряках в сабже, и выложил первый тайминг , используя сабж в первый раз, как трейсер, потому что у меня плагин к отладчику, а отладочное ядро при трассировке, невероятно медленное, завязаное на других компонентах инфраструктуры дбг, и в комплексе уже достало, всю эту хрень обходить, и выходить на прямую к сторонним движкам.
по БП пару ответов, феньк тыкнул, ну и так уже понятно, что если инициализирован хук калбека, само по себе понятие БП уже условное. других таймингов нет, и флудильня по ним это не мой треш,
промежуточные я и так выкладываю, а если кому то чешется знать подробности, переводя русло топа, в социалку и личное, провоцируя других участников топа на эмоции, то это не ко мне, а отмалчиваться, или постукивать типа куда надо, не в моей ментальности.
По багу с оператором флага то же пока тишина, но под капот лезть не буду, тыкну чего нить своё, для всех операторов флага, направляя поток , как он должен идти
в остальном, пока не предложено других готовых вариантов для сравнения качества и скорости, меня это решение устраивает. зная о багах, и что то о юм коде с текущей трассы, сабж можно юзать как трейсер.
Что не по теме? //лучше в личку

-----
Чтобы юзер в нэте не делал,его всё равно жалко..

| Сообщение посчитали полезным:

difexacaw отдохни 3 дня, за постоянную провокацию.
засрал рандомом все темы, ни одного поста по существу.

| Сообщение посчитали полезным: ajax, Bronco, plutos, sefkrd, DrVB_5_6

линковал либу, почти со всех доступных сорцов.
может студия как то не так собирает, но один хер, траблы с CF имеются.
1.при CF = 0, оператор "jb" переходит на метку.
2.арифметика, "adc" и "sbb", а состояние CF =0(под дбг 1), переход по чётности("jp" ), хотя данные в регистре не чётные.
3.при лог сдвиге, ситуация та же.
есть ещё парочка, но пока с ними не разобрался.
при трассировке, обороты набирает не торопясь, но уверено.
Current Timing: 00:01:04.469
1.Write instr->1 000 000 | 2.Skip instr->1 693 152
-------
Finish Timing: 00:29:17.407
1.Write instr->39 000 000 | 2.Skip instr->6 418 978
исузу тыкнул, но там фиксят, макси не больше 3-4 дней, после релиза.
лечить хз как, там такая матрёшка с кьюэму.

-----
Чтобы юзер в нэте не делал,его всё равно жалко..

| Сообщение посчитали полезным:

Bronco пишет:
может студия как то не так собирает
+1
после сборки в студии с мастер сорцов, без разницы статик либа или длл, но с флагами один и тот же баян.
комплект библиотек с релиза 1.01 работает стабильно. в релизе длл размером на порядок больше.
инструмент замечательный.

-----
Чтобы юзер в нэте не делал,его всё равно жалко..

| Сообщение посчитали полезным:

упс...раскочегарил этот двиг на запись трассы в бинарь, до 22 лямов инстр/мин.
т.е это уже лучше чем терпимо. но есть один большой недостаток, покрытие с ним не построишь.
синхронизация с рфлагс только на базовых блоках, при хуке на код, даже на блоках нет, синхронизирует где под капотом. т.е текущие значения регистров флагов, из контекста, не совпадают с реальными без синхрона с кьюэму.
полазил по исузам, флаги это больная тема, частый синхрон как бы влияет на скорость, есть там пару кустарных патчей, проверить пока не знаю как. минжв питона не видит, студия какого то фуя тупо всё ломает.
всё таки по студии вопрос, настройки проекта авторские, правда точилось под VS2013.
что может поломать VS2015 или VS2017?

-----
Чтобы юзер в нэте не делал,его всё равно жалко..

| Сообщение посчитали полезным:

В 15-ке впилено достаточно значительных изменений, чтобы не терять время на переписывание кода (или использование костылей совместимости), проще скомпилить в 13 студии имхо (если оно хоть там точно работает).

| Сообщение посчитали полезным:

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

| Сообщение посчитали полезным:

VOLKOFF пишет:
проще скомпилить в 13 студии имхо
у меня проект на 15-ке, даже если библа будет рабочая, как с релиза, то статик либа не подойдёт.
уточню, собирается в любой студии, только выхлоп лагает на операторах флага, если в релизе нет синхрона для юзера, то из под студии его нет нигде, запросто влетает в петлю. примеры на гите скидывал, и в топе чуть выше.
shellstorm пишет:
скорее всего проблема в дефайнах
какое то обсуждение, можно встретить только на фиглишь ресурсах, и его то же мало. саму проблему обсуждали только на гите.

-----
Чтобы юзер в нэте не делал,его всё равно жалко..

| Сообщение посчитали полезным: