LINUX.ORG.RU

wine: перенаправить вызов с dll на нативный so

 , , ,


3

3

Нужно перехватить вызовы к определенной dll и перенаправить на вызовы нативного в системе so. Набор API (названия функций и т.д.) полностью совпадают.

Как такое реализовать?

★★★★★

В общем нужно либо смотреть в сорцы вайновского загрузчика, либо использовать rpc и виндовую dll которая релизует ipc. Как-то сходу в доке описания подобного механизма нет, хотя он 100% реализуем где-то на уровне загрузчика, а значит, есть даже шанс, что если ты реализуешь это не по-уродски, то оно и в апстрим уехать могёт.

pon4ik ★★★★★ ()

Нужно перехватить вызовы к определенной dll и перенаправить на вызовы нативного в системе so.

Чего уж там «мелочиться».
Почему бы не - «Как из unix API использовать API wine?».
Microsoft разработала WSL.
Может быть есть смысл в разработке LWA /выполнение в нативном Linux API Windows/?

PS: Просьба сильно «не пинать».

Владимир

anonymous ()

Нужно перехватить вызовы к определенной dll и перенаправить на вызовы нативного в системе so. Набор API (названия функций и т.д.) полностью совпадают.

Но ты ведь в курсе, что у винды и линукса отличается calling convention?

Как такое реализовать?

А насколько сильно тебе это нужно именно в таком виде, без пересборки твоего подменного кода под винду?

im-0 ()
Ответ на: комментарий от im-0

Но ты ведь в курсе, что у винды и линукса отличается calling convention?

Каким образом работают builtin-библиотеки wine?

А насколько сильно тебе это нужно именно в таком виде, без пересборки твоего подменного кода под винду?

Библиотека проприетарная, кроссплатформенная. Есть только заголовки из SDK.

xDShot ★★★★★ ()
Ответ на: комментарий от xDShot

Каким образом работают builtin-библиотеки wine?

Неким образом конвертируют одно в другое. Подробностей не знаю, но скорее всего код для этого как-то генерируется автоматически*.

upd. * Имею ввиду случаи, когда API и там и там одинаковое, OpenGL какой-нибудь, например. В либах, которые «конвертируют» именно API, а не calling convention/ABI, скорее всего просто в объявлениях функций указано нужное соглашение и остальное делает компилятор.

im-0 ()
Последнее исправление: im-0 (всего исправлений: 1)
Ответ на: комментарий от xDShot

Библиотека проприетарная, кроссплатформенная. Есть только заголовки из SDK.

По идее можно написать «генератор DLLок для вайна» под такие случаи. Возможно даже такое уже есть и надо только составить правильный запрос гуглу.

im-0 ()
Последнее исправление: im-0 (всего исправлений: 1)
Ответ на: комментарий от xDShot

Каким образом работают builtin-библиотеки wine?

Собраны с вендовой calling convention.

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

Stanson ★★★★★ ()
Ответ на: комментарий от xDShot

А сразу чо, типа чтобы протестировать лоровскую libastral надо было скрывать чо за dll и чо за софт?

Если это оно - https://github.com/rll/sixense/blob/master/include/sixense.h то и в винде и в линуксе calling convention одинаковый - cdecl. Так что линуксячья либа не отличается от вендовой. Всё что требуется - загрузить её. Смотри в сторону fakedll насчёт placeholder.

Stanson ★★★★★ ()

Тут https://github.com/jazzkutya/sdrplay-wine-fakedll/tree/master/mir_sdr_api приведён простой пример как заменить Win32 DLL. В NOTES описана буквально пара шагов:

  • взять Win32 DLL (например, foo.dll)
  • winedump для генерации foo_dll.h, foo_main.c, foo.spec
  • winemake для создания Makefile’ов.

Нужно будет раскомментировать все требующиеся вызовы и дёргать в них такие же из нативного .so.

gag ★★★★★ ()

Всем спасибо. Особенно за наводку товарища gag и автору предложенного репозитория. Удалось сделать «прослойку», теперь вызовы дергаются с нативной библиотеки.

xDShot ★★★★★ ()