to post messages and comments.

← Все записи с тегом pe

@OCTAGRAM:

Самая проблемная (как сейчас представляется) часть совмещения библиотек для разных OS — это исключения и сигналы, которые конвертируются в исключения разных языков программирования. Виндоуз в этом плане очень продумана, по крайней мере, 32-разрядная и более поздние. Там общая для всех языков программирования система структурной обработки исключений (SEH), поэтому самое сложное, что там нужно делать — это брандмауэр исключений. Например, в ActiveX объектах такое есть. Исключение ловится, конвертируется в информацию IErrorInfo, передаётся в COM, а функция возвращает неуспешный HRESULT. Потом, по другую сторону можно обратно сконструировать исключение другого языка программирования.

Но нас интересуют операционные системы вроде Линукса и БиЭсДи, и там всё гораздо сложнее из-за того, что функционал структурной обработки исключений отдан на откуп компиляторам, а ядро вызывает сигналы. А компиляторы — кто в лес, кто по дрова. Они заточены под то, что вся программа написана на одном языке программирования, и код инициализации ставит обработчики сигналов для всей программы, и только так оно работает, а возможность комбинировать разные языки программирования не учтена.

@OCTAGRAM:

Почему-то сходу не находятся утилиты для слияния exe+dll. Нормального слияния, без выгрузки на жёсткий диск. Вот пытаться сконвертировать DLL в статическую библиотеку — это я согласен, не получится. При компоновке EXE и DLL теряется информация о внутренних связях между кодом и данными, и секции жёстко фиксируются друг относительно друга, а у статических библиотек нет такого формата. Там, наоборот, будь добр все связи предоставь, чтоб компоновщик потом мог как угодно код относительно данных подвигать. Но вот если слияние exe+dll делать на последнем этапе, после обычных компоновщиков, то можно себе представить такой метакомпоновщик, который делает бекон из секций входных PE-файлов, устраняет ставшие внутренними связи импорта/экспорта DLL и делает прочую рутинную работу, как то: сделать новую точку входа, повызывать оттуда DllMain, а потом WinMain. Если вложенные библиотеки не сильно злоупотребляют попытками обратиться к себе как к DLL, не пытаются узнать свой HMODULE и не суют его потом во все WinAPI, а просто служат хранилищем кода, должно сработать.

Жизнь бы упростилась, если делать только DLL, а для тех, кому ну очень нужно всё в одном файле, предоставить такой метакомпоновщик.

@OCTAGRAM:

Формат Portable Executable — чей?

При написании научных работ, да даже курсового проекта справедливо требуют ссылаться на документы. Выяснять авторство. По возможности, отдавать предпочтение публичным стандартам. W3C, IETF, ECMA, ISO — как минимум эти аббревиатуры нужно знать. А вот формат Portable Executable, который повсюду — он чей? Казалось бы, нестандартный от Microsoft, и со всеми свежими дополнениями документацию по этому формату действительно нужно скачивать с сайта Microsoft. Но, оказывается, что у истоков стоит комитет, в котором Microsoft — всего лишь соучредитель. Вместе с Borland, IBM, Lotus и MetaWare, глава Томас Пеннелло которого и возглавил комитет Tool Interface Standards (комитет по Стандартам Инструментальных Интерфейсов?) при основании в 1993м году. Свой сайт они как-то не удосужились создать, и сослаться с гиперссылкой не получится. Лучшее, что я нашёл. До 2004го года эти стандарты можно было скачать с сайта Интел. Сейчас их можно найти здесь. Там и OMF, и PE/COFF, и ELF.

Про Пеннелло я, кстати, узнал отсюда:
According to Thomas Pennello, chairman of the committee and vice president of MetaWare, many group members are wary of Microsoft's COM and related Object Linking and Embedding (OLE) technology because neither incorporates inheritance, and object property that allows developers to quickly give new objects the same characteristics as existing sets of objects.Вот, похоже, его профили в LinkedIn, Фейсбуке и Гугле

@OCTAGRAM:

Надо было по работе скомпилировать Wt, а он на C++. Причём, если говорят «беда не приходит одна», то это именно тот случай. Если C++, то ещё и boost, а если boost, то ещё и boost.spirit. Короче, на всю голову больные. Нет бы на C с классиками пописывать и не напрягать тех, кому это потом компилировать. Нет бы взять обычный внешний генератор парсеров. Настрадался я от этого boost.spirit. То там string table overflow at offset 10000004 в section .debug_frame случится, то
function_operator_10.hpp: In instantiation of 'const typename boost::phoenix::detail::expression::function_eval<F, A0, A1, A2, A3, A4>::type boost::phoenix::function<F>::operator()(const A0&…
Ну это манипуляциями с ключиками ещё как-то преодолел. Дальше проблемы, компоновщику тупо памяти не хватает. Вот тут посоветовали взять сборку отсюда. Не подошло:
c:/TDM/TDM-GCC-64-2017-01-07/bin/../lib/gcc/x86_64-w64-mingw32/5.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: c:/TDM/TDM-GCC-64-2017-01-07/bin/../libexec/gcc/x86_64-w64-mingw32/5.1.0/liblto_plugin-0.dll: error in plugin cleanup (ignored)
c:/TDM/TDM-GCC-64-2017-01-07/bin/../lib/gcc/x86_64-w64-mingw32/5.1.0/../../../../x86_64-w64-mingw32/bin/ld.exe: c:/TDM/TDM-GCC-64-2017-01-07/bin/../libexec/gcc/x86_64-w64-mingw32/5.1.0/liblto_plugin-0.dll: error loading plugin
И библиотеку указанную тоже пробовал заменять. Никак. Откатился на оригинальный ld.exe

Впрочем, оказалось, что снять у него ограничения по памяти не так сложно. Открыл HIEW, по смещению 0x96 пропатчил 0f 03 на 2f 03, что соответствует включению флага IMAGE_LARGE_ADDRESS_AWARE, и этим компоновщиком наконец смог собрать. Научить программы использовать больше памяти не так уж сложно, оказывается.