Упаковка exe + dll в один исполняемый файл (не.NET)
Возможный дубликат:
Как Windows Cll DLL может быть объединена в C# приложение exe?
Кто-нибудь знает о программе, которая может упаковать несколько DLL и.EXE в один исполняемый файл. Я не говорю о случае.NET здесь, я говорю об общих библиотеках DLL, некоторые из которых я генерирую в C++, некоторые другие являются внешними библиотеками DLL, которые я не контролирую.
Мой конкретный случай - это программа на python, упакованная с py2exe, где я хотел бы "спрятать" другие DLL, упаковав их. Вопрос достаточно общий, хотя.
Вещи, которые смотрели на:
- ILMerge: специфично для.NET
- NETZ: специфично для.NET
- UPX: выполняет сжатие DLL, но не несколько упаковок DLL + EXE
- FileJoiner:
Почти получил это. Он может упаковать исполняемый файл + что угодно в один exe, но при открытии он запустит средство открытия по умолчанию для каждого файла, который был упакован. Таким образом, если пользователь dlldepend установлен, он запустит его (потому что это средство открытия dll по умолчанию).
Может быть, это невозможно?
Резюме ответов:
Открытие DLL управляется ОС, поэтому упаковка DLL в исполняемый файл означает, что в какой-то момент их нужно извлечь в место, где ОС сможет их найти. Нет волшебной пули.
Итак, то, что я хочу, не возможно.
Если...
Мы что-то меняем в ОС. Спасибо Конраду за то, что он указал мне на ThinInstall, который виртуализирует приложение и механизм загрузки ОС. С ThinInstall можно упаковать все в один exe (DLL, настройки реестра, ...).
9 ответов
Попробуйте Powerpacker. Evalaze - еще одно бесплатное решение для виртуализации. БЕСПЛАТНОЕ издание Enigma Virtual Box
Если исполняемый файл статически связан с DLL, т.е. нет вызовов LoadLibrary, тогда я не думаю, что существуют какие-либо механизмы для упаковки DLL в исполняемый файл, поскольку загрузка DLL выполняется загрузчиком приложения ОС до вызова "основной" функции. Насколько я знаю, единственный способ обойти это - поместить exe и dlls в другой exe. Эта exe-оболочка распаковывает настоящий exe-файл и dll во временную папку и запускает exe-файл, удаляя файлы при выходе из exe-файла.
Если вы звоните LoadLibrary/Ex чтобы загрузить dll, извлеките dll из ресурсов exe в файл до вызова LoadLibrary/Ex,
Настоящая проблема в том, что LoadLibrary Функция выполняет много операций по исправлению адресов при загрузке библиотеки и работает только при загрузке из файла.
Вы можете добавить библиотеки DLL в виде двоичных ресурсов в ваш EXE. При запуске ваш EXE может извлечь ресурсы во временную папку, и LoadLibrary() результирующие DLL.
Вы смотрели на мой список дешевых утилит?
Предполагается, что есть несколько недорогих (то есть, довольно дешевых) инструментов, которые бы связывали вместе DLL(и) не-сетевого приложения, такие как:
1.) Molebox Pro (100 евро) 2.) BitArt's Fusion (160 долларов США) 3.) VB Wrap (100 долларов США) 4.) Пакет PE (30 долларов США)
Кроме того, на "www.oreans.com" вы можете найти пакет программ для eu 320, ориентированный на защиту, который, как они утверждают, может связывать вместе файлы Win32 или.Net; однако, когда я спросил их об определенном сценарии, где я использовал бы их "XBundler For Win32/.NET", чтобы упаковать ".Net" EXE, а затем попытался бы запустить его на Windos 98 (без фреймворка) Они сказали, что это не сработает.:-(
EXE Admirer
Вы можете использовать valgrid, thinstall или boxedapp.... Я предпочитаю последнее.
MoleBox Pro делает именно то, что вам нужно, но это условно-бесплатное программное обеспечение, и, если вы не купите полную версию, упакованные исполняемые файлы при запуске будут показывать диалоговое окно со словами: "Этот файл был упакован в пробную версию MoleBox. раздать
Вы можете скачать это здесь: ссылка
К сожалению, я не смог найти полностью удовлетворительное и бесплатное решение
Мне сказали, что можно попросить ссылку общего объекта на другой общий объект, таким образом, объединить их в один в Linux
Но это не будет работать для родных библиотек Windows, мне приходит на ум одна вещь - мы можем просто использовать компоновщик, чтобы связать все объекты вместе, независимо от того, к какому проекту они изначально принадлежали. Конечно, они должны иметь похожие варианты ссылок.