Да
Она компилирует .res

А что же за идею он предлогал?

Проблема с параметрами командной строки, выбирающими вариант вывода в случае ассемблирования, состоит в том, что данный код в любом случае, скорее всего, будет собираться и выполняться правильно только тогда, когда выбран тот же вывод, который имел в виду программист при написании этого кода. Также я вспомнил много случаев, когда у меня был источник для TASM, написанный кем-то другим, и чтобы правильно его скомпилировать, я должен был следовать указаниям, приведенным в комментарии в начале источника, и просто переписать все ключи командной строки, как описано там. И я подумал: почему бы просто не заставить ассемблер искать такие опции в исходном коде, чтобы никто не столкнулся с проблемой перекомпиляции? Так появился принцип SSSO - все настройки, которые могут повлиять на вывод ассемблера, выбираются только из источника, а источника всегда достаточно, чтобы сгенерировать именно тот файл, который был задуман программистом. Следствием идеи SSSO было также то, что независимо от того, какая версия fasm (учитывая порты для разных операционных систем), она всегда генерировала один и тот же выходной файл, поэтому, когда вы написали программу для DOS, версия fasm для Linux все равно сделает тот же DOS исполняемый файл из такого источника.

Некоторым людям, похоже, не нравятся последствия этого принципа, потому что все другие ассемблеры и компиляторы имеют параметры командной строки, которые влияют на вывод (или даже исходные константы), и этот другой подход должен немного изменить образ мышления в некоторых случаях ( это фактически происходит в еще большем количестве областей при программировании с использованием fasm, и цель этого текста - показать происхождение и причину этих различий). Правило SSSO стало одним из руководящих принципов проектирования fasm, и я не планирую его убирать.

Тем не менее, все еще возможно, что один и тот же исходный файл будет собран по-разному в другой среде, потому что он может включать в себя некоторые другие файлы, и их содержимое и доступность могут варьироваться от компьютера к компьютеру и от системы к системе. Пути к файлам должны соответствовать правилам для данной операционной системы, и то, какой файл загружается, может зависеть также от переменных среды, поскольку fasm позволяет им раскрываться в значениях пути. Чтобы избавиться от этой зависимости от среды, ассемблеру придется отказаться от функций включения файлов. Ну, я знаю одного ассемблера, который выбрал этот путь, но это не то, что я мог бы даже рассмотреть для моего ассемблера. Таким образом, мое обоснование заключается в том, что системные файловые пути определяют, какой источник (составленный из, возможно, множества разных файлов) ассемблер получит для окончательной обработки, но после этого начинает действовать принцип SSSO.

в двух словах, то что на масме/насме и тд мы пишем в ком. строке при компиляции, в фасме это пишется прям в коде (в исходнике). командная строка для фасма сведена к минимуму (входнойфайл, выходной, + несколько не сильно критичных управляющих опций)

format pe gui
entry start

в масме эти строки вынесены в командную строку например

Классная задумка

но там еще и линковщик нужен для масма, то же со своими параметрами дял сборки

Да, интересно и вот этот GoRc значит противоречит такому подходу

какому?

Смысле а фасму линкер не нужен?

как отдельный инструмент используя его родные фичи нет, не нужен

ну ты сказал инклюзивному так сказать?

Жесть

А на фасме статик либу написать тогда?

Кто её к бинарю прилинкует?

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

Жесть

Напоминает раст

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

я то подумал, что GoRk это программа для рисования интерфейсов а это целый комплекс со своим ассемблером :) Не правильно понял мысль значит