OberonCore

Как-то BlackBox больше приучил к POINTER TO ARRAY [untagged], но почему бы и не просто ARRAY [untagged]?

Посмотрите в сторону ключика GCC -Wl,-e_WinMain@16 (для Win32) или -Wl,-eWinMain (для Win64). И возьмите обновлённый crt1.c

Обратите внимание, что это не единственный способ привязаться к внешней библиотеке. Модификатор PROCEDURE - (я предпочитаю писать PROCEDURE- , т.к. минус относится к типу процедуры, а не к имени) сгенерирует макрос #define Module_Proc Proc. Также Вам потребуется #include <библиотека.h>, который Вы подключаете через файл .h0, и фактически Вы просто макросом переадресовываете вызов на прототип, описанный в .h-файле библиотеки. Если в этом прототипе функции будут свои типы, характерные для Си, но несовместимые с оберонскими, то придётся делать преобразования. Иначе будут предупреждения при компиляции.

В Ofront'е+ в дополнение к этому есть и другой способ (смотрите модуль WinApi):

Здесь уже сгенерируется прототип __EXTERN MyExternLib_Proc (Typ parameter);
И #include <библиотека.h> не нужно, точки входа подставит сам линкер.

То есть, в случае способа 1 Вы используете готовые сишные хидеры библиотек, а при способе 2 Ofront+ генерит свой собственный хидер.

Теперь по поводу этой проблемы:



Вы объявляете PROCEDURE -GetModuleHandleA, а такая процедура разворачивается в макрос, имеющий имя Module_GetModuleHandleA, а не просто GetModuleHandleA. В Ofront'е+ есть более удобный механизм определения прототипа внешней процедуры. Про это читайте постом выше. А макрос немного для других, менее тривиальных применений.

И раз Вы описываете процедуру так, как описываете, то у Вас генерится такой Си-код:

Здесь у меня нет никаких идей, кроме такой: GetModuleHandleA считается необъявленной функцией. А в Си такая необъявленная функция работает по умолчанию с параметрами типа int. И наверное с результатом типа int. Вот поэтому Вы и имеете сравнение результата неявного типа int с явным NIL, который описан в SYSTEM.oh как ((void*)0)

Получилось слинковать и запустить программу. Надо было, как вы и советовали, использовать и crt1.c, и ключ линкеру gcc.

Необходимость включать в проект ваш crt1.c вызывает вопрос - зачем, собственно, так сделано? Ведь наверное не все компиляторы си содержат по умолчанию ваш crt1.c (например моя версия gcc ? Если это необходимо, то, наверное, имеет смысл включить этот файл в oFront+?

Поправка. По своей рассеянности я раньше не замечал, что crt1.c уже включён в oFront+. По этому мои предыдущие замечания снимаются. В старых версиях oFront+'а я успешно компилировал свой проект без этого файла. В последней версии oFront+'а файл crt1.c необходимо сключать в проект. При этом, если использовать crt1.c из oFront+'а, то программа не завершается. А если использовать обновлённый crt1.cб то - завершается.

Издавна ещё со времён ретро-платформ у меня есть привычка добиваться компактности. Создайте в GCC пустой исполняемый файл и посмотрите зависимости. Он потянет из msvcrt.dll целую кучу функций, в т.ч. нужных для поддержки C++ (которая нам не нужна). И посмотрите размер. Он будет > 20-30 Кб в зависимости от версии GCC.

В сети есть советы как уменьшить размер исполняемого файла путём вырезания из него этих зависимостей. Так мы можем получить .exe размером 1-1,5 Кб для пустой программы.

Но если есть желание избавиться от crt1.c, просто уберите опции, заданные в StripExe:

Обновите Ofront+, уже добавлен новый crt1.c, всё протестировано и работает. Просто я изменил механизм работы с командной строкой под Windows, отсюда побочкой возникла эти проблема.

Следующая ошибка.

Этот модуль транслируется в си, но при дальнейшей компиляции вылаёт ошибку.

Это унаследованная проблема, она есть также в Ofront, voc и CPfront. И в МультиОбероне.

Пока думаю.

Выкатил исправление.

GameHunter, благодарю! Судя по всему, Вы кодите что-то нетривиальное на Обероне, раз вскрываете такие редкие ошибки, которые не возникли даже при трансляции в Си модулей BlackBox.

Следующая ошибка.

Этот модуль успешно транстируется в си, но потом выдаёт ошибку компиляции gcc:

Есть исправление.

Кстати, ошибка унаследованная — присутствует в Ofront и CPfront. И, видимо, в Мульти-Обероне тоже.

Следующее замечание. Данный модуль успешно транслируется в си и затем успещно компилируется, но с какими-то подозрительными предупреждениями. Посмотрите пожалуйста, всё ли в порядке.

Следующая ошибка. Этот модкль успешно транслируется в си, но при дальнейшей клмпиляции происходит ошибка.

Похоже, что я предыдущим фиксом сломал вообще работу индексов.

Новое исправление. Протестируйте, пожалуйста, его хорошенько с многомерными массивами. Я прогнал некоторые тесты для двухмерных массивов, вроде всё работает.

К моему большому сожалению, Йозеф Темпл совсем забросил Ofront, а он понимает его многие тонкости куда лучше меня.

Так, с фиксом не получилось, на этот раз сломалась работа со статическими массивами. Я всё откатил, думаю дальше.

В офронте можно объявлять строковые константы в каком-нибудь юникоде? Нидеприведённый модуль, если использовать utf-8, компилируется, но выводит на экран кракозябрв вместо русских и немецких букв.

Можно. Ключик -w (wide) включает перекодировку исходника из UTF-8 в UCS-2 (двухбайтовую кодировку широких символов в Windows).

Насчёт проблемы - обдумываем с Йозефом. Вернее, Йозеф думает, я жду

Ну что ж, Йозеф совсем зашился, придётся самим.

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

Следующя ошибка. Данный модуль транстируется в си, но в дальнейшем имеем ошибки компиляции.

Эта проблема связана с тем, что на момент определения массива Arr0 тип записи Rec0 ещё недоопределён. Если поменять порядок определений, будет та же самая проблема:


Эта ошибка также присутствует в CPfront и в Мульти-Обероне. В Ofront и voc её нет, там такой код просто вызовет ошибку рекурсивного определения.

Я прошу помощи у Дмитрия Викторовича Дагаева, если ему ещё интересна доработка Мульти-Оберона. Тем более, что он уже патчил код, связанный с рекурсивным определением типов.