У меня не получалось линковать, линкер ругается на отсутствие либы ...
более конткретно не занимался.
Но, как понимаю люди, которые пишут преимущественно на C редко заглядывают в получаемый выполняемый файл. ~500 байт погоду для них не делает......

Линкуйте wlink c ключами output raw op offset=0 op OBJALIGN=16 и будет вам счастье.
Если нет wlink - пишите.

> лишние ~500 байт, вызванные наличием MZ- и PE-заголовков
Твоя неправда. Все генерируются при создании секций и при их выравнивании (512, 4096 или еще сколько байт, Serge об этом упомянул - "OBJALIGN=16"). Причем еще pe2kos не все секции переносит и мои программы на FreePascal после него просто не работали, отчего я и написал свой конвертер. Кроме того существует понятие Image Base (или как там), Serge тоже об этом сказал - "offset=0", я, при компиляции, устанавливаю его в 0, думаю остальные поступают так же. В винде это смещение, как правило, устанавливается в 4Mb (0x400000). Не помню как оно обрабатывается в pe2kos, я, если оно указано, размещаю его нулями в выходном файле.

p.s. Это меньшая проблема KOS. Со мной можно поспорить, но минимализм системы я никогда не считал преимуществом. А компактный загрузочный формат и не дает большого выигрыша.

..bw

bw

А FreePascal сразу делает exe или компилирует в obj а потом собирает ?

Раньше обязательным этапом было формирование объектов, теперь, для pe, в этом необходимости нет так как имеется встроенный линковщик (для elf всё еще используется внешний), но они продолжают формироваться. Встроенный линковщик собирает приложения заметно компактнее чем внешний. Какие-то там свои алгоритмы, вроде SmartLink, используются. Поэтому для pe лучше использовать встроенный, а для elf, пока, без вариантов.

..bw

wlink с ключом "output raw" сразу собирает в родной формат Колибри. Без всяких заморочек с pe2kos. Ему только нужен объектник с заголовком колибри и описанием сегментов. Размер стека задаётся в командной строке. Довольно удобно.

SmartLink похоже на удаление неиспользуемого кода. Или они теперь крутые и генерируют код во время линковки как MSVC.

> SmartLink похоже на удаление неиспользуемого кода. Или они теперь крутые и генерируют код во время линковки как MSVC.
Почти уверен, что, просто неиспользуемый код не включается в целевой файл.

> wlink с ключом "output raw" сразу собирает в родной формат Колибри. Без всяких заморочек с pe2kos.
А откуда wlink нает заголовок kex'а? Что это вообще за линкер такой?
В любом случае, я вряд ли пойду на такое, сложности со сборкой появляются. Сейчас удобнее использовать конвертер.

Напомни, ты же предпологаешь использование EXE и DLL в ядре PE? Если так, то проблема конвертера со временем вообще отпадет. Если такой, качественный переход, произойдет не скоро (?), то я доберусь (со временем) до компилятора FP и добавлю в набор выходных форматов (платформ) KolibriOS. Это не такая уж и сложная задача.

..bw

Давайте не будем мешать всё в одну кучу.

Линкуйте wlink c ключами output raw op offset=0 op OBJALIGN=16 и будет вам счастье.
Если нет wlink - пишите.

Это дельный совет, но к конкретному моему вопросу не относится. В статье описывается компиляция штатными средствами Microsoft, а, похоже, статью все и используют.
Кстати, вроде бы ещё год назад было заявлено, что скоро появится руководство по компиляции OpenWatcom. И?

> лишние ~500 байт, вызванные наличием MZ- и PE-заголовков
Твоя неправда. Все генерируются при создании секций и при их выравнивании (512, 4096 или еще сколько байт, Serge об этом упомянул - "OBJALIGN=16").

При чём тут сами секции? Ну задаётся ImageBase=0 и align:16 при таком подходе, и где появляется секция? Примерно по адресу 0x200 (например, 0x1F0 - типичное значение). А почему? Потому что примерно столько занимают MZ- и PE-заголовки.

Кроме того существует понятие Image Base (или как там), Serge тоже об этом сказал - "offset=0", я, при компиляции, устанавливаю его в 0, думаю остальные поступают так же. В винде это смещение, как правило, устанавливается в 4Mb (0x400000). Не помню как оно обрабатывается в pe2kos, я, если оно указано, размещаю его нулями в выходном файле.

Serge не об этом говорил, он за watcom'овский линкер (если я правильно понял). pe2kos служит только для обработки файлов с ImageBase=0. При способе, разобранном в статье в разделе про VC, база устанавливается в 0, и с начала файла идут заголовки, а линковщик размещает секции после заголовка. Соответственно и pe2kos не может пересчитать все смещения, а вынужден оставить их как есть; при этом появляется неиспользуемое пространство на ~500 байт (в начало которого pe2kos вставляет MENUET01-заголовок).
Но при способе, разобранном в разделе про masm, используется другой подход, и там ImageBase = -0x10000, так что секции оказываются аккурат по адресу 0 и лишних нулей не появляется. Поэтому так делать лучше (хотя требует дополнительных телодвижений, не описанных в статье), и меня просто интересует: кто-нибудь пытался?

Чтобы не быть голословным, привожу два примера.
ac97snd: (распаковываем, не стесняемся) в начале файла заголовок, потом данные начинаются аж со смещения 0x1000 - итого 4060 неиспользуемых байт.
sqlite_kos-0.0: в начале файла заголовок, потом данные начинаются со смещения 0x1F0 - итого 460 неиспользуемых байт.

> Потому что примерно столько занимают MZ- и PE-заголовки.
А, ну да. Там же винда еще что-то в мозг пихает (по адресу ImageBase) и поэтому первая (с меньшим адресом) секция имеет большее чем 0 смещение. Запамятавал. В любом случае, при конвертировании в kex можно, насколько я понимаю, перегруппировать секции вообще как угодно и как угодно сместить их друг от друга. Главное не забыть пройтись по таблице Relocation.

..bw

Главное не забыть пройтись по таблице Relocation.

Это если такая есть... по умолчанию в exe-шниках её никто не создаёт. Но в любом случае для обработки релоков нужно писать какой-то код, а сейчас вроде бы никто такого не поддерживает - ни pe2kos, ни FreePascal'евский вариант.

> потом данные начинаются аж со смещения 0x1000 - итого 4060 неиспользуемых байт
А кто мешает их запользовать :-). Тут я не могу управлять своим линковщиком (встроенный в FP) и он всегда будет первую секцию на 4kb смещать. Надо будет заняться конвертером. Хотя потеря минимальнейшая. Она в редких случаях будет критичной. На 1000 запущенных приложений (а это еще нужно постараться) только 4 метра потерь (у меня оперативки 2Gb :-). Память сейчас не дорогая и это точно не проблема, просто досадная неприятность.

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

..bw

>А откуда wlink знает заголовок kex'а?

Он не знает. Заголовок прописан в сегменте BEGTEXT. wlink всегда ставит его первым. output raw генерирует бинарный файл без заголовков и заголовок Колибри получается первым.
Есть и ложка дёгтя. wlink понимает coff и omf и дружит с mingw, но некоторые либы сделанные в msvc его убивают.

Мда... попробовал реализовать - при компиляции из VC6 получается, а вот к VS2005/8 линкер поменяли и трюк с /base:-0x10000 не проходит из-за ругательства линковщика "fatal error LNK1249: image exceeds maximum extent with base address FFFF0000 and size 0x40000" (и даже нельзя сказать, что он совсем уж неправ). Жаль.