1 (изменено: Freeman, 26.06.2023 в 17:02)

Тема: Delphi SDK для KolibriOS (2020-2022)

Я думаю над возобновлением разработки, в связи с чем стоит вопрос в расстановке приоритетов. После такого долгого перерыва приступить к разработке Кантора напрямую не получится, сначала неплохо бы вспомнить код, работая над более обозримой задачей, обеспечивающей быстрый результат. Такой задачей, как обычно, выступит PE Tool. В рамках 6-й версии я могу добавить некоторые опции и доработать существующие, делающие PE Tool более пригодной для разработки под KolibriOS, пока не добавляя поддержку форматов KolibriOS напрямую.

В связи с этим хотелось бы увидеть Delphi в качестве штатного инструмента разработки под KolibriOS. В статье Leency о компиляторах, которую я считаю официальным описанием разработки на языках высокого уровня под KolibriOS, Delphi перечислен в списке экзотических или неактуальных инструментов, что видеть неприятно.

Для успешного развития PE Tool в сторону KolibriOS требуется описать стек разработки на Delphi понятным для программиста Delphi языком, чтобы Leency смог включить его в свою статью. В настоящий момент, как понимаю, наиболее проработанный способ разработки включает в себя следующий набор инструментов (toolchain) и модулей:

  • Компилятор Delphi в составе IDE или командной строки

  • Утилиту omf2d

  • Открытый компоновщик ld (возможно, какой-то особой версии, не из стандартного набора GNU)

  • Скрипт сборки для ld

  • Облегченные версии модулей SysInit и System для Delphi

  • Модуль или набор модулей Delphi, разработанные 0CodErr, содержащие поименованные функции API KolibriOS.

Всё это предлагается описать в виде статьи с краткими примерами и образцами вывода программ, как было сделано для PE Tool. Возможно, даже стоит подготовить дистрибутив открытых программ для этого стека, чтобы их не приходилось выцарапывать с форума. Всё это повысит мою заинтересованность в развитии поддержки KolibriOS в своих инструментах, включая Кантор.

Если целью команды KolibriOS является привлечение разработчиков на Delphi (в числе прочих), поддержку KolibriOS лучше сделать в стиле Delphi, аналогично поддержке других операционных систем. Стиль Delphi подразумевает наличие одного большого модуля, соответствующего названию платформы: Windows, libc. Соответственно, поддержка KolibriOS также должна состоять из одного модуля KolibriOS или Kolibri, содержащего все именованные функции API. Функции, не относящиеся к прикладной разработке, можно выделить в отдельный модуль. К примеру, сетевые функции вполне допустимо вынести в модуль KolibriNet. В этом случае подключение библиотек для сетевой программы на Delphi будет предельно простым:

uses
  KolibriOS, KolibriNet;

Всё это придаст серьезности стеку Delphi. Перестал следить за форумом, но когда смотрел его последний раз, всё выглядело сделанным на коленке, лишь в некоторых аспектах стремящимся к развитию.

В Канторе

В Канторе нет модулей, только вложенные классы, в контексте импорта системных функций называемые пространствами. Поддержка существующих ОС будет разнесена по пространствам, а внутри каждого пространства — по именам системных библиотек. К примеру, набор для разработки под Windows будет включать пространства Legacy:Windows:Kernel32, Legacy:Windows:User32, Legacy:Windows:Shell32 и так далее.

Единый модуль Delphi удобен в контексте его компиляции Халва-Паскалем — первым компилятором переднего плана платформы Кантора. Синтаксис Халва-Паскаля предельно близок Delphi, что означает возможное появление поддержки KolibriOS уже в ранних версиях.

Если в PE Tool будет реализована прямая поддержка форматов исполнимых файлов KolibriOS, появится второй стек, состоящий из Delphi и PE Tool.

По всей видимости, я забыл про стек на основе exe2kos, pe2kos и подобных утилитах. PE Tool заменит как раз его. Наверное, его тоже надо как-то описать, если это штатный способ разработки программ для KolibriOS.

2

Re: Delphi SDK для KolibriOS (2020-2022)

В статье Leency о компиляторах

Вряд ли можно этого человека считать компетентным в этом вопросе.
Вот в 2018 году список выглядел иначе http://archive.li/9bUOX
Стоит заметить, что и там тоже отсутствуют, например, такие как GCC и MSVC.
А уж экзотическим впору называть c--, который по факту вообще никто не поддерживает.
Тот список — просто "с потолка".

Вот тут список другой habr.com/ru/post/338602/
Но по поводу KolibriOS.lib написано не точно

библиотека системных вызовов Колибри из D7 и различных ассемблеров (ниже)

Вообще-то нет жёстких ограничений "D7 и различных ассемблеров".

чтобы Leency смог включить его в свою статью

Я думаю, что статью можно написать и самостоятельно. Вообще есть планы о создании форума именно о программировании(не о разработке самой ОС) под KolibriOS.
Ну и там соответственно и будет статья с описанием. Думаю, что начать можно с Delphi, C, UASM.
Хотелось бы иметь возможность использовать и с FreePascal, пока непонятно как лучше, чтобы одну библиотеку можно было использовать с несколькими компиляторами, потому что есть ещё

стек на основе exe2kos, pe2kos

и это лучше, потому что omf2d не всё полностью поддерживает, да и возможно, что всё равно произойдёт переход на PE.

Ну и можно ещё развивать ту идею "Пример на Delphi7 под Windows и под KolibriOS" kolibriosandfasm.mybb.ru/viewtopic.php?id=24  (демки переносить вообще элементарно)
Было бы здорово найти единомышленников по этой теме.
Саму KolibriOS.lib я понемногу дополняю.

Соответственно, поддержка KolibriOS также должна состоять из одного модуля KolibriOS или Kolibri, содержащего все именованные функции API. Функции, не относящиеся к прикладной разработке, можно выделить в отдельный модуль.

Ну у меня идея, чтобы все системные функции, определения и константы находились в одном модуле, а служебные процедуры это уже что-то типа SysUtils или StdLib. Но в первую очередь именно обёртки для системных функций, а также множество примеров по их использованию, чем я и планирую заниматься.
Конечно, было бы не плохо скооперироватся с заинтересованными людьми.
Не знаю, где лучше искать: фурумы по электронике, общие форумы по программированию или же по разработке ОС?
На самом форуме KolibriOS данная тема не нашла единомышленников.

В связи с этим хотелось бы увидеть Delphi в качестве штатного инструмента разработки под KolibriOS.

Есть ли идеи насчёт XDS Modula-2/Oberon-2? Теперь ведь даже исходники открыты.

добавить некоторые опции и доработать существующие, делающие PE Tool более пригодной для разработки под KolibriOS, пока не добавляя поддержку форматов KolibriOS напрямую.

Может лучше не ограничиваться именно форматом KolibriOS, а сделать что-то наподобие линкер-скриптов для LD? тогда PET был бы востребован не только в KolibriOS.
Ещё есть, кстати, JLoc wiki.osdev.org/JLoc
Пример control-файла(аналог скрипта для GNU LD):

ALL:
   file1.obj
   file2.obj
   file3.obj
   last.obj
DATA:  0F0000 MAIN.after MAIN.i_after
   *,DGROUP
   ,,,FONT
FINAL:  0F0000 100000-FINAL.length FINAL.start-0F0000
   *,*,*,*,last.obj
MAIN: 0F0000 0F0000 0
   *

3

Re: Delphi SDK для KolibriOS (2020-2022)

0CodErr пишет:

Вряд ли можно этого человека считать компетентным в этом вопросе.
Вот в 2018 году список выглядел иначе http://archive.li/9bUOX
Стоит заметить, что и там тоже отсутствуют, например, такие как GCC и MSVC.
А уж экзотическим впору называть c--, который по факту вообще никто не поддерживает.

Я ценю вклад Leency в проект. Его иногда заносит, но сделанное нельзя не замечать. На данный момент его сборка — единственная сборка KolibriOS, причем хорошо доработанная.

Обсуждение личностей

Обсуждение личностей считается флудом. Прошу не продолжать тему.

Справедливости ради, MSVC и GCC в обоих списках есть.

C-- сейчас поддерживает команда KolibriOS, как понимаю. Видел на форуме тему с доработками. Язык C-- великолепен, с большим удовольствием прочитал его руководство. Благодаря своей незатейливости и простоте сборки программ он хорошо вписался в идеологию KolibriOS. Если бы я писал под KolibriOS, наверняка бы его попробовал.

0CodErr пишет:

Я думаю, что статью можно написать и самостоятельно. Вообще есть планы о создании форума именно о программировании(не о разработке самой ОС) под KolibriOS.

Самостоятельно — так самостоятельно. Главное, чтобы материал был хорошим. Готов предоставить этот форум в качестве площадки. Чтобы не флудить, лучше создать отдельную тему.

0CodErr пишет:

Ну у меня идея, чтобы все системные функции, определения и константы находились в одном модуле, а служебные процедуры это уже что-то типа SysUtils или StdLib.

Такой модуль уже есть — Types. Delphi — высокоуровневый многоплатформенный язык, и базовые модули в нем содержат типы и константы, разделяемые между всеми платформами. Поддержка KolibriOS — поддержка платформы, расположенная в одноименном модуле. Модуль Windows ведь тоже содержит типы и константы, а не только функции. Если есть боязнь за размер (модуль Windows действительно огромен), типы и константы лучше вынести во включаемый файл, используемый потом модулем KolibriOS.

SysUtils — уже другое. Он реализует исключения и кучу унаследованных (legacy) функций, использующих исключения. Нет никакого смысла их повторять. Лучше сразу ООП. Или ООП — это плохо? Было бы странно видеть такое заявление на форуме объектно-ориентированной ОС.

В CoreLite

В CoreLite принята несколько иная идеология, соответствующая концепциям платформы Кантора. Модуль CoreUtils содержит объявления констант и типов, зависящих только от архитектуры процессора, и функции, подменяющие собой системные в режиме {$DEFINE Tricks}. Всё остальное идет в ООП. Точка поддержки платформ — модуль CoreWrappers. Если портировать CoreLite на KolibriOS, придется дорабатывать именно его.

0CodErr пишет:

Не знаю, где лучше искать: фурумы по электронике, общие форумы по программированию или же по разработке ОС?

Неофициальный филиал «Канторовых систем» есть на OSDev.ru, тема с анонсами выпусков PE Tool — на ProgrammersForum.ru. Есть еще DelphiSources.ru, на котором я когда-то общался, но давно перестал. Не знаю, каков сейчас его уровень.

0CodErr пишет:

Есть ли идеи насчёт XDS Modula-2/Oberon-2? Теперь ведь даже исходники открыты.

Мой приоритет — Кантор. По всей видимости, компиляторами XDS должен заниматься другой Freeman. Можно подкинуть эту идею Антону Кротову, автору компилятора Oberon-07.

0CodErr пишет:

Может лучше не ограничиваться именно форматом KolibriOS, а сделать что-то наподобие линкер-скриптов для LD?

Разбор скриптов, то есть исходников, требует инфраструктуры компилятора. А сборка программ при помощи отдельных компоновщиков со своими скриптами противоречит понятиям Кантора. Это записано в концепциях. Все исходники для сборки программ на Канторе будут написаны на Канторе.

4 (изменено: Freeman, 04.05.2020 в 22:51)

Re: Delphi SDK для KolibriOS (2020-2022)

Модератор: обсуждение форума о KolibriOS перенесено.

Freeman пишет:

SysUtils — уже другое. Он реализует исключения и кучу унаследованных (legacy) функций, использующих исключения. Нет никакого смысла их повторять. Лучше сразу ООП. Или ООП — это плохо?

ООП - это не плохо.
Я вообще-то не хотел бы заниматься какой-либо отсебятиной.
У меня нет цели заниматься *Utils-ами, создавать какие-то аналоги и т.п.
Это и будет похоже по сути на модуль Windows, только это будет модуль KolibriOS.
И чем больше будет примеров, тем, думаю, больше будет заинтересованных в использовании.
Поэтому и выбираю форум с возможностью заливки файлов(исходников) и изображений(скриншотов).

5

Re: Delphi SDK для KolibriOS (2020-2022)

0CodErr пишет:

Я вообще-то не хотел бы заниматься какой-либо отсебятиной.

А придется. Если стоит задача полноценного программирования на Delphi, нужен если не полноценный модуль System, то хотя бы минимальный джентльменский набор. Помимо менеджера кучи и исключений нужны строки. Если модуль System выкладывать в открытый доступ, реализация библиотечных строк должна быть написана с нуля. Без строк не может быть и речи о программировании на Delphi без трюков.

По идее, на KolibriOS можно портировать CoreLite. Вероятно, этому может поспособствовать переход на Git. Но в CoreLite «компиляторные» строки, ориентированные на решение задач Кантора. При известной сноровке ими можно пользоваться, но сначала придется учиться. А мне придется закончить документацию по CoreLite... Мечты, мечты...

6

Re: Delphi SDK для KolibriOS (2020-2022)

0CodErr пишет:
{21.5}    Function  SetSystemLanguage(SystemLanguage: Dword): Integer; StdCall; External 'KolibriOS';

Почему в функциях для Delphi соглашение вызова stdcall, а не умолчательное register?

7

Re: Delphi SDK для KolibriOS (2020-2022)

Потому что библиотека KolibriOS.lib не только для Delphi

0CodErr пишет:

Просто так уж получилось, что KolibriOS.lib изначально делалась для Delphi, но файлы определений с прототипами функций планируется перевести на другие языки, в частности, С, UASM, возможно Modula\Oberon, возможно С--.
На форуме KolibriOS было уже выложено несколько примеров использования библиотеки, некоторые ссылки указаны раньше были на сайте kolibri-n http://archive.li/9bUOX но потом их оттуда убрали:

StdCall — это как общий знаменатель. Да, ещё подошло бы CDecl, но тогда будет нужен дополнительный код, корректирующий стек после возврата из функции

        push    p1
        push    p2
        call    [printf]  <---- вызов CDecl функции
        add     esp, 8    <---- корректировка стека(передано на стеке 2 параметра, размером 4 байта - Dword, итого 8 байтов)

Ну а Borland FastCall, насколько знаю, поддерживает ещё только UASM

http://www.terraspace.co.uk/uasm.html#p1 пишет:

Support for Borland Register Calling Convention.

8

Re: Delphi SDK для KolibriOS (2020-2022)

Для успешного сотрудничества весьма желательно завести хранилище Git, загрузить туда актуальные версии исходников и опубликовать на GitHub. Так можно будет обмениваться запросами на слияние (pull request). В хранилище обязательно должна быть лицензия.

Добавлено 05.05.2020 в 20:47

Напишу сразу, чтобы не было удивления. Я строго придерживаюсь оформления (форматирования) исходников в стиле Borland/Embarcadero. Не скажу, что это религия, но однозначно буду поминать маму автора, если исходники будут оформлены по-другому. В мире Паскаля законодатель мод один, поэтому есть два вида оформления — Borland/Embarcadero и неправильное. Неправильно оформляют исходники языковые иммигранты, пишущие на других языках, и лишь иногда на Паскале. Разработчики FPC — иммигранты.

Есть официальное руководство Embarcadero по оформлению исходников. Найду ссылку, кину.

Добавлено 12.05.2020 в 23:02

Object Pascal Style Guide — Embarcadero.

9

Re: Delphi SDK для KolibriOS (2020-2022)

Для лучшей поддержки разных версий Delphi разрабатываемой нами библиотекой (и PE Tool) нужен dcc32 от одной из последних версий Delphi, чтобы можно было проводить натурные тесты. Боюсь, на глючном мобильной интернете не получится скачать полный установочный пакет. Было бы неплохо, чтобы кто-то его скачал и отправил мне dcc32.exe почтой.

Насколько знаю, Embarcadero вернули редакцию Delphi Starter Edition, позволяющую использовать Delphi бесплатно, в обучающих целях или для некоммерческих проектов. У нас проект некоммерческий. Я его позиционирую также как учебный. Не для новичков, но именно учебный — для студентов профильных вузов, особенно кто изучает разработку компиляторов. Может быть, потом даже удастся продвинуть нашу разработку в какой-нибудь университет, вместе c KolibriOS.

10

Re: Delphi SDK для KolibriOS (2020-2022)

Freeman пишет:

Object Pascal Style Guide — Embarcadero.

Спасибо за ссылку.

Ну и немного своего мнения на этот счёт

8.2.3 if statement

Я вполне использую оба варианта 1 и 2:
1

      // INCORRECT
      if A < B then DoSomething; 

2

      
      // CORRECT
      if A < B then 
        DoSomething;

Немного странно, что 5 считается корректным, но 3 почему-то нет, а и там, и там на одной строке "end else"
Я использую вариант 3, просто 4 слишком много строк занимает
Тут, видимо, кому-то просто не нравится, что "begin" в конце строки
3

      // INCORRECT
      if A < B then begin
        DoSomething; 
        DoSomethingElse;
      end else begin
        DoThis;
        DoThat;
      end;

     
4

      // CORRECT
      if A < B then 
      begin
        DoSomething; 
        DoSomethingElse;
      end 
      else 
      begin
        DoThis;
        DoThat;
      end;

     
5

      // CORRECT
      if Condition then
      begin
        DoThis;
      end else
      begin
        DoThat;
      end;

номер 7 кажется лучше, чем 6
6

      // CORRECT
      if Condition then
      begin
        DoThis;
      end
      else
        DoSomething;

7

      // CORRECT
      if Condition then
      begin
        DoThis;
      end else
        DoSomething;

     
но я бы, наверное, сделал так

      if Condition then begin
        DoThis;
      end else
        DoSomething;

мне нравится, как сделано во всяких Basic-ах

      If Condition Then
        DoThis
      Else
        DoSomething
      EndIf

номер 8 я бы не стал использовать
8

      if Condition then
        DoThis
      else DoThat;

я бы сделал так(хотя и на одну строку больше стало)

      if Condition then
        DoThis
      else 
        DoThat;

     

Я его позиционирую также как учебный. Не для новичков, но именно учебный — для студентов профильных вузов, особенно кто изучает разработку компиляторов. Может быть, потом даже удастся продвинуть нашу разработку в какой-нибудь университет, вместе c KolibriOS.

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