Ну вот для некоторых это тёмный лес) Хотя тоже не вижу в этом ничего сложного. Со стороны форта тут просто надо написать обвязку на ассемблере.


Когда делал свой Нова-форт для винды столкнулся с небольшой проблемой – некоторые апи-фукции требовались объявить до появления обвязок. Я не стал заморачиваться и городить огород. Просто сделал требуемые апи статической линковкой.


Интересный вопрос, но насколько нужный и актуальный? В любом случае придётся лезть в документацию к dll

А чего же там? LoadLibrary и GetProcaddress. Другое дело, что если форт-систему плотненько запаковали и активно отбиваются разными ANSами, то это не получится, несмотря на то, что технически несложно. А так тема интересная. Линковать статически или подключать? Тут вопрос, можно ли к dll спроектировать удобный API.

Помню, когда-то кто-то на хабре поднял вопрос – как в форте вызываются функции из DLL.
Как думаете, стоит писать про это статью? Причём форта по определённым причинам там будет мало

ну....в целом ответ на вопрос темы - "да"

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

Совместное проведение исследований и разработок - это в целом "высший пилотаж", наподобие ремонта работающего мотора. В целом же имеет смысл разделять эти процессы, отдельно создавая программы. демонстрирующие принципиальную работоспособность каких-то подходов, и отдельно - создавая программы для непосредственного применения. В этих программах стоит использовать только уже проверенные архитектурные подходы - например, не пытаться внедрять на ходу непроверенные оптимизации кода, динамическое переключение модели ШК или хэширование словарей.

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