Comments 15
Нагуглилась книжка, содержащая сводную информацию по передаче параметров в разных компиляторах.
Но если в стеке появляются структуры произвольного размера, «переворот» стека становится намного сложнее.
А разве большие структуры не передаются как указатель на стеке? Не уверен насчет 32 битов, но на 64 битах в Windows структуры передаются именно так.
Подозреваю, что работать с Raylib из Delphi 6 вообще невозможно.
Обычно в случае подобных проблем на Дельфи можно было выкрутиться при помощи ассемблерных вставок.
Можно, но это всегда некий намёк на ограниченность того высокоуровневого языка, который мы выбрали. Хотелось бы оставаться в рамках этого языка и иметь под рукой всё, что нужно.
Ну, практически все языки высокого уровня имеют свои ограничения, особенно в таких тонких вопросах, как недостаточно стандартизованные ABI. Если бы Raylib использовала более стандартный stdcall, как это делают, кажется, все DLL самой Windows, проблем бы не было.
Не помогло бы. stdcall отличается от cdecl только ответственностью за очистку стека. Оба соглашения вполне однозначны, пока речь идёт о простейших типах и указателях, и оба погружаются в одинаковый хаос, когда дело касается передачи и возвращения структур.
(Освежив память) Да, вы правы. Проблем с вызовом системных DLL нет не столько из-за stdcall как такового, сколько из-за того, что они практически не передают структуры через стек, только указатели.
Но, опять же, использование ассемблерных вставок для оборачивания таких нестандартизованных вызовов мне представляется приемлемым решением. Хотелось бы обойтись без таких костылей, но что делать.
Но, опять же, использование ассемблерных вставок для оборачивания таких нестандартизованных вызовов мне представляется приемлемым решением. Хотелось бы обойтись без таких костылей, но что делать.
Занимаясь чем то «похожим» пришёл к выводу, что бессмысленно пытаться оживить «Франкенштейна». Вот зачем все эти костыли и усилия, трата времени. Надо сделать заново всё, и как положено. Без оглядки на всякие там Си. Прошу прощения у автора за советы. Статья интересная, почитал с удовольствием.
Не совсем понял, что именно вы предлагаете сделать «без оглядки на всякие там Си». Сейчас любой новый язык программирования или компилятор должен уметь взаимодействовать с C, поскольку на C написаны миллиарды строк кода. Кто этого не сумеет — тот точно останется за бортом. Посмотрите, сколько усилий для налаживания взаимодействия приложили, например, разработчики Питона или Go.
Другое дело, что лично мне следовало бы сделать AST и впредь не «переворачивать» стек. Но это лишь одна частная проблема. Все остальные останутся как есть.
Другое дело, что лично мне следовало бы сделать AST и впредь не «переворачивать» стек. Но это лишь одна частная проблема. Все остальные останутся как есть.
Я согласен с вашими аргументами. Вопрос в другом, устраивает ли вас качество современного программного обеспечения? Меня категорически не устраивает. В пределе все эти миллионы строк ничего не стоят. Постоянно в новостях «обнаружена уязвимость ...». Программы глючат и падают. Если вас это устраивает, тогда вопросов нет.
Довольно наивно думать что, написав все с нуля, будет меньше ошибок, чем в уже оттестированном годами коде.
А так меня тоже не устраивает, см.мои публикации =)
А так меня тоже не устраивает, см.мои публикации =)
А, вы предлагаете создать с нуля всю индустрию IT! Благое пожелание. Но если вы пересчитаете эти миллиарды (не миллионы) строк кода в человеко-годы труда, вы, наверное, испугаетесь. Я думаю, выйдет задача лет на 50-60 — то есть именно столько, сколько на самом деле и развивается программирование. А главное, уязвимости всё равно останутся: во-первых, люди по-прежнему несовершенны и допускают ошибки, а во-вторых, есть среди них и те, кто намеренно весь свой талант бросает на поиск и эксплуатацию уязвимостей.
Sign up to leave a comment.
Самодельный компилятор и игровая библиотека Raylib. Опыт стыковки