Друзья! Прямо сейчас помочь проекту очень просто: нужно найти админов freepascal.ru и попросить их активировать мою учётку на форуме.

При возможности консультироваться с людьми, которые знают и понимают fp, дело будет двигаться куда быстрее. Сами эти люди, в свою очередь, выиграют от пополнения экосистемы ещё одним интересным продуктом.

Верю в лор-эффект и теорию всяких рукопожатий :)

Я вот сейчас специально скачал на поизучать эти самые 6 и 7 турбо паскали. Вот там, скажем, есть VIEWS.INT (интерфейсная часть views из Turbo Vision), но нет его реализации в исходниках.

ЧЯДНТ? И где можно посмотреть на полные версии, чтобы убедится, что Ritlabs оттуда код не тырили?

ну то есть было:

unit Test;
interface

procedure something; inline; begin end;

implementation

end.

а чтобы fpc собирать начал, из этого надо сделать

unit Test;

interface

procedure something;

implementation

procedure something; begin end;

end.

Строго говоря, современный FPC отлично умеет inline, причем указание директивы допустимо и в обоих разделах, и только в одном из ;-) Но реализация должна быть, сюрприз-сюрприз, в разделе реализации ;-)

Если попробовать сохранить inline, под это нужно заводить отдельную ветку, ибо для VP пригоден только вариант с inline-кодом в интерфейс-разделе. Дублировать фрагмент кода и там и там — так себе идея.
Можно обойти при помощи {$i FileName}:

unit Test;
interface

procedure someshit;
{$IFDEF VIRTUALPASCAL}
  inline;
  {$i someshit.pi}
{$ENDIF}

implementation

procedure someshit;
{$IFNDEF VIRTUALPASCAL}
  inline;
  {$i someshit.pi}
{$ENDIF}

end.

unit Test;
interface

procedure someshit;

implementation

procedure someshit; 
{$IFNDEF VIRTUALPASCAL}inline;{$ENDIF}
begin
end;

end.

где можно посмотреть на полные версии, чтобы убедится, что Ritlabs оттуда код не тырили?

В BP7 на 13-й дискете RTLTV.ZIP, если правильно путаю.
Глянуть можно, например, на pascal.sources.ru/museum/bp7.htm или tpdn.ru/files/turbo-pascal-download/

вот да, я не очень верю во фрипаскалевский турбо вижн, перетащенный с сей (ведь борланд исходники только сишного публиковали).

Точно? По-моему, Борланд поставлял исходники TV с TP (мы тогда даже смотрели и отметили обилие ассемблерных вставок).

Проанализировал, спасибо! Вот вы реально очень помогли сейчас.

Да, Ritlabs действительно просто взяли и использовали Borland’овские исходники, переделав под себя. То есть, тупо наплевали на копирайт, такие дела.

Беда.

Что тут можно сделать? Для начала, не паниковать :)

Оно всё ещё пролезает в fair use, т.к. коммерческой выгоды я не извлекаю, угрозу бизнесу embarcadero моя деятельность не несёт, используются только минимально необходимые части, а не весь продукт, и оно таки полезно в образовательных целях.

Но это такая себе основа для дальнейшего развития, конечно. Надо на free vision всё-таки переходить будет, значит.

Сейчас допишем в ридми про это.

Я проверил. Поставляли, да. Только права на использование и распространение производных работ приложить забыли. Придется поверить в порт турбо вижн с сей, штош :)

Друзья! Прямо сейчас помочь проекту очень просто: нужно найти админов freepascal.ru и попросить их активировать мою учётку на форуме.

Проверяйте.

Включив на максимум режим юриста и вспомнив всё, что я знаю об американских законах об авторском праве, написал вот такое дополнение в ридми. Это должно защитить от случайных напрыгов, по крайней мере. В суде такое не 100% что устояло бы (хотя это ж Америка, от судьи и адвоката всё сильно зависело б), но, по-моему, мы раньше этот код на FV пересадим, чем кто-нибудь по его поводу судиться надумает.

It turned out that some of the source code files originally published by Ritlabs and therefore inherited by dn2l were based on the source code of Turbo Vision for Turbo Pascal, never published by Borland under any permissive license. As long as we have no reason to doubt the good faith of Ritlabs, we can assume that they had the right to use this code in their open source product. We also still can consider usage of that code in dn2l as fair use, since no profit is being made from dn2l, dn2l does not pose any threat to the business of Embarcadero Technologies, dn2l is using only the minimum necessary parts from original Turbo Vision sources, and the entire dn2l project has historical and educational value. Yet it’s better to confider use of this code in dn2l only a temporary solution: we should gradually replace such code with Free Vision from the Free Pascal project, this should be a first priority task as solid legal base is requred to secure any further development of dn2l. Here is a full list of such files: collect.pas, colorsel.pas, decoder.pas, dialogs.pas, drivers2.pas, drivers.pas, histlist.pas, memory.pas, menus.pas, tvhc.pas, validate.pas and views.pas.

https://github.com/unxed/dn2l#28-10-2020-update

При этом теперь однозначно ясно, что надо таки переходить на FV, а не свой серый форк TV развивать. Ну что ж, одним сложным решением меньше :)

Большое спасибо, вы настоящий волшебник!

А подскажите, пожалуйста, в какой теме вопросики по портированию DN на fpc позадавать корректнее всего будет?

Я пока пришел сюда: http://freepascal.ru/forum/viewtopic.php?p=160527#p160527

но это не выглядит прям вот идеальным местом

Возможно, стоит завести основную тему в разделе «Разработки на нашем сайте». А те или иные отдельные технические вопросы обсуждать в своих темах сообразно разделам, в основной теме фиксировать принятые решения по результатам обсуждений и прочие новости и пульс публиковать.
Это как делал бы я. Как делать вам, решать не мне ;-)

у меня ощущение, что некоторым людям забыли рассказать, как переводится «fun» из «just for fun». если уж хочется попахивая недержанием рассказывать внучкам как-оно-там-раньше-было – не обязательно воспроизводить унылый двухпанельник

Спасибо за ваше мнение! А что бы вы воспроизвели, чтоб было о чём рассказать внучкам, попахивая недержанием?

Спасибо! Разумеется, я и хотел послушать, как делали бы вы - у вас же на этом форуме есть опыт, а я пришел только.

Вот, http://freepascal.ru/forum/viewtopic.php?f=10&t=43132

И спасибо, что помогли прояснить вопрос с turbo vision и лицензионной чистотой кода!

Плохая новость: во фривижне экранный буфер всё ещё построен на концепции «1 символ = 1 байт», ну как так-то :)

Хорошая новость: пример перевода на utf-8 сишной турбо вижн в природе существует (я скачивал и собирал), значит, и паскалевую можно.

Ещё хорошая новость: фривижн хотя бы не написан на асме)) так что поменять его должно быть сильно проще.

Это мощная инициатива с реинкарнацией DN! С тех времен когда он активно развивался, я так и не нашел менеждера файлов который был нестолько же удобен. Сложно описать в чем магия, но она есть :)

По поводу utf-8, кстати, в последних версиях DN просмоторщик файлов вроде-как умел читать и показывать двухбайтные кодировки. Может будет полезным покопать - как оно там реализовано на паскале (если конечно сохранилось в текущей версии исходников).

ссать в уши внукам надо по-крупному, я бы ваял форк Периметра, WOPR из книжки Бишофа или отой херни, которая комок фольги с людьми на Луну запустила.

Та херня, которая кусок фольги с людьми на Луну запустила, называется «Холодная война», и ваять её сейчас точно не надо (:

Если подскажете точную версию, в которой оно работало — это сильно упростит задачу)

В процессе экспериментов с free vision (а он местами даже милый!) нашёл баг в far2l вот :))

https://github.com/elfmz/far2l/issues/830

К - кумулятивный эффект, с - синергия!

Посмотрел тут пристально в отладочные символы NDNа (они открыто публикуются вместе с бинарниками). Судя по всему, он собран FreePascal’ем, но на базе модифицированной Virtual Pascal RTL.

Потому что в ndn.dbg встречаются и строчка «Free Pascal 3.2.0 2020/10/18», и строчка «VPSYSLOW.PP», а модуль VPSYSLOW как раз из комплекта VP (в DN есть его модифицированная версия).

А ещё в ndn.dbg встречается строчка «COLLECT.PAS», что говорит о продолжении использования DNовской версии Turbo Vision (во Free Pascal RTL аналогичные штуки живут в другом файле, objects.pp), а она, как мы теперь знаем, основана на коде Borland, право на использование которого в FOSS проекте остается под вопросом.

Выводы: код там, похоже, без заботы о лицензионной чистоте, есть и у Borland’а взятые вещи, и у Virtual’а. Такое в любом случае в публичном проекте пришлось бы всё вырезать и переводить на лицензионно чистые исходники, а это уже почти эквивалентно по трудозатратам переделке с нуля от исходников DN OSP.

Так что, может, и не стоит сильно приставать к Некромансеру с предложением открыть код: скорее всего, dn2l не сможет так уж много пользы извлечь из этого кода. Я-то к 100% лицензионной чистоте стремлюсь.

Какие-то компоненты, может, и можно было бы переиспользовать, но не надо ждать, что вот Некромансер откроет код, мы его смёржим, и будет у нас искаропки лицензионно чистый и полностью открытый DN.

Целесообразность перевода FV внутри на utf8, а не на utf32, вызывает у меня сильные сомнения... Возможно, необоснованные, поди знай ;)
Хранить/передавать ресурсы можно и в utf8, но постоянно оперировать в памяти буферами с переменной длиной символа — так себе затея, по крайней мере непонятно, ради чего...
С другой стороны, utf32 не избавляет от ситуации «несколько кодпоинтов -> одно знакоместо», и тперь минусы уже перевешивают плюсы...

А вот необходимость нового FV-utfX может саму работу над dn2l задвинуть в долгий ящик.

Плюс, нужно иметь в виду, что TV изначально был ориентирован на дешёвый вывод на экран больших областей в формате {символ, цвет} — пиши себе в видеопамять напрямую и горя не знай, после CGA даже обратного хода луча не надо ждать. А вот *nix терминалы в тупом варианте такого счастья лишены напрочь, под удалённую работу имело смысл минимизировать передачу, для вывода областей отдельные команды, вывода цвета отдельно нет и т.п.
Вот над этой разницей при порте FV тоже стоит немного подумать.

пример перевода на utf-8 сишной турбо вижн в природе существует (я скачивал и собирал)

Можно ссылку или хотя бы где искать?

https://github.com/magiblot/tvision
Речь про него или про что-то другое?

Тут где-то видел в интернетах (на fp wiki?), что в fp нет UTF32. А UTF16 мне честно кажется «худшим решением из возможных»: он не может считаться достаточно вычислительно простым, как ASCII, из-за суррогатных пар (модель «1 символ = 2 байта» тут на самом деле не работает), при этом и по памяти тоже не слишком-то экономичен (если вы не в Китае). Я, скорее, вот этих ребят сторонник http://utf8everywhere.org/

Но это, безусловно, обсуждаемая история. Вообще тут видится форк Free Vision из FP и доработка его под современные нужды, так что отчего ж не обсудить? :)

А вот необходимость нового FV-utfX может саму работу над dn2l задвинуть в долгий ящик.

Я тоже читал эту статью :) https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/

Разумеется, эксперименты пойдут в отдельной ветке, улучшения текущей (уже работающей) сборки dn2l блокироваться ими никак не будут.

Вот над этой разницей при порте FV тоже стоит немного подумать.

То есть, откажемся от кроссплатформенности, заточив форк FV исключительно под *nix терминалы? Ой ну чёт не уверен пока :)

PS: Дописал в readme свое видение перспектив «просто попросить исходники NDN»:

https://github.com/unxed/dn2l/blob/main/README.md#ndn-already-works-on-linux-shouldnt-we-just-ask-its-devs-to-open-the-code

Конечно!

Сама юникодная Turbo Vision, но на сях https://github.com/magiblot/tvision

Пример классного проекта на ней https://github.com/magiblot/turbo

простая модель «1 символ = 2 байта» тут на самом деле не работает

1 символ = 4 байта и в utf32 не работает из-за альтернативных представлений составных (precomposed) символов, а памяти жрёт ещё больше, чем utf16 ;)
С другой стороны, если в наличии способы получить «длину на экране», то вопрос с отображением почти закрывается (привет символам двойной ширины, right-to-left и смешанным направлениям письма ;) )

Зато есть 11 бит свободных, куда так и просится цвет ;)

вопрос с отображением почти закрывается

Ну вот разработчик этого юникодного форка TV выбрал именно UTF8 и обосновал это тем, что как раз именно его приделать проще всего туда. Я в код глубоко не глядел там, но, раз всё работает, подход можно считать перспективным :)

привет символам двойной ширины, right-to-left и смешанным направлениям письма ;)

В far2l с этим тоже вопросики возникают, кстати :)

Зато есть 11 бит свободных, куда так и просится цвет ;)

А потом захотим 256 цветов, которым нужно уже два байта - по одному на цвет и фон, и ой

По поводу magiblot/tvision — спасибо, интересно, проект свежий (конец 1998-2000), раньше мне не попадался (TV/FV выпали из поля зрения значительно раньше), надо будет посмотреть внимательнее на код. Возможно, оценить трудоёмкость и подводные камни биндинга (ха, размечтался ;) ) либо реимплементации на fpc (так и подмывает заняться чем-то бесполезным и ненужным ;) ) ...

Во, это хороший заход — с биндингом/реимплементацией этой версии (у неё-то всё в порядке с лицензионной чистотой, она на коде, официально открытом под Public Domain, емнип, Борландом, основана). Автор, правда, предлагает в ответ DN на сях переписать)) https://github.com/magiblot/tvision/issues/24

Хотя, может, можно в FV просто те же приемы применить, посмотрев, как там у него сделано ¯\_(ツ)_/¯

фигасе

вот кому-то точно заняться нечем =)) как профит этой старой паскальной аппшки на gnu/linux в 2020х?)))

Я, кстати, знаю, почему DN OSP до сих пор ни на fp, ни на fv, ни на utf8 не пересадили.

Там адский dependency hell в модулях. Какой-нибудь lfnvp.pas, должный инкапсулировать логику работы с файловой системой, может тянуть в зависимостях интерфейсные модули, например.

И есть ещё штук 7 модулей с названиями «advance..advance7», куда запихнуто всё подряд, и которые зависят от всего на свете.

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

А пересадить весь DN на другую платформу «одним приемом» нереально, конечно. Вот и буксует.

Забавно, что в проекте, который мог бы служить демонстрацией силы ООП, напрочь забыто базовое понятие «инкапсуляция» :)

Поэтому что нужно сделать в первую очередь? Вооружиться хирургическим скальпелем и аккуратно отрефакторить всё это добро.

Чтоб представления жили отдельно, а IO - отдельно.

И тогда можно будет по частям на другой компилятор или UI фреймворк переходить: менять только небольшие кусочки кода, не ломая вообще всё. И можно будет работать инкрементально.

И всё получится.

Ответ уже был выше по треду :) На github опубликован Linux порт Dos Navigator с открытым кодом (комментарий)

Поправьте в README.md утверждение в части magiblot/tvision, проект на C++ (C++17), а не на C. Это сильно не одно и то же ;-)

Про CD хз, не натыкался в коде, а ещё остались CD-ROMы у кого-то?

Во-первых, таки да. И я с них, бывает, слушаю музыку. И пишу бэкапы на BD. Не говоря уже о copy-protected дисках, образы которых сделать не получается (напр., софт для OS/2).

Во-вторых, сейчас есть масса переносных устройств, поторые через USB можно воткнуть в любой ноутбук.

В-третьих, у меня в каждой виртуальной машине по виртуальному CD-ROM.

Спасибо, сделано!

С таким можно смело PRы слать, кстати)

Да и не только с таким. Я готов принимать всё, что что-нибудь улучшает, ничего при этом не ломая, и не препятствуя дальнейшему движению по roadmap.

Оки, убедили, мы обязательно подумаем об этом после того, как с переводом на FV разберемся и UTF-8 прикрутим :)

Порт в состоянии pre-alfa

alfa

Дениска, ты?

Спасибо =)

Вопрос: vp — это компилятор Virtual Pascal? Если не секрет, то какие части сейчас невозможно собрать fpc?

По поводу фрагментов Turbo Vision могу сказать, что, помимо кода, опубликованного Rit Labs, была полная версия кода библиотеки, опубликованная собственно Borland.

И после этого было два форка этого кода — кажется, один под LGPL, другой под BSD (я ранее приводил ссылки на форуме). Насколько я понимаю, можно было бы использовать наработки этих проектов.

Правда, это всё на C. Как у «Паскаля» обстоят дела с FFI, я не знаю.

Ещё бы Лексикон раскопали, палеонтологи. Кому оно нужно?

Вопрос: vp — это компилятор Virtual Pascal?

Ага.

Если не секрет, то какие части сейчас невозможно собрать fpc?

Никакие, там всюду inline-функции до implementation, fpc в такое не может.

По поводу фрагментов Turbo Vision могу сказать, что, помимо кода, опубликованного Rit Labs, была полная версия кода библиотеки, опубликованная собственно Borland.

Было две версии: для C, выложенная Borland под открытой лицензией (кажется, Public Domain, но это не точно), и та, что шла с дистрибутивом Borland Pascal, и вот там ни о какой открытой лицензии речи не идёт. Именно поэтому разработчикам Free Pascal пришлось делать свой отдельный Free Vision, а не брать готовое.

Насколько я понимаю, можно было бы использовать наработки этих проектов.

Наработки сишной TV, возможно, будут использованы в виде переписывания на паскале или изготовления биндингов к этой вот юникодной версии. Выше по треду обсуждалось. https://github.com/magiblot/tvision

Зря не стали делать отдельную ветку (branch) под мероприятия переезда VP -> FPC.
Отсюда сразу вопрос: в текущих целях есть сохранение собираемости под VP (влитые в main модификации дают основания считать, что нет)?

PS. Переименовать COLLECT.PAS в OBJECTS.PAS, вероятно, было не самой лучшей идеей, ибо в составе RTL FPC одноименный модуль (unit) уже присутствует:
https://www.freepascal.org/docs-html/current/rtl/objects/index.html

PPS. Коллекции из стандартного Objects из FPC можно использовать.
В руководстве по языку указано

const MaxBytes = 16384;

const
{$IFDEF FPC}
  {$IFDEF CPU16}
   MaxBytes = 16384;
  {$ELSE CPU16}
   MaxBytes = 128*1024*128;
  {$ENDIF CPU16}
{$ELSE}
   MaxBytes = 16384;
{$ENDIF}
  MaxCollectionSize = MaxBytes div SizeOf(Pointer);
type
  PItemList = ^TItemList;
  TItemList = array [0..MaxCollectionSize-1] of Pointer;
  TCollection = object(TObject)
    Items: PItemList;
    ...

procedure TCollection.SetLimit(ALimit: LongInt);
...
  if ALimit > MaxCollectionSize then
    ALimit := MaxCollectionSize;

Зря не стали делать отдельную ветку (branch) под мероприятия переезда VP -> FPC.

Стали-стали. Те мероприятия, которые ушли в main, никак не влияют на собираемость под VP.

А настоящая вивисекция происходит здесь https://github.com/unxed/dn2l/tree/fp_experiments

PS. Переименовать COLLECT.PAS в OBJECTS.PAS, вероятно, было не самой лучшей идеей, ибо в составе RTL FPC одноименный модуль (unit) уже присутствует:

Так да, поэтому и переименовывал. Collect основан на Objects из TP TV, там прямо в каментах так и написано. Логично его поменять на соответствующий модуль из FP RTL, чтоб uses не менять в 50 местах потом.

PPS. Коллекции из стандартного Objects из FPC можно использовать.

Так и делаю, да.

TLineCollection только из DNовских сорцов утащил, но там всё чисто, кажется, с правами на код: в TP TV такого не было :)

Утащил грубовато, но о красоте рано думать пока, собралось бы))

Итого: собирается на данный момент 18 модулей из ~140 требуемых. Неплохо для начала :) До самого веселья (file io, которое в lfnvp живет) не добрался пока, впрочем. Ну да и там не должно быть так уж страшно, файлы они и в африке файлы))

Если не секрет, то какие части сейчас невозможно собрать fpc?

На данной стадии проще сказать, какие собрать можно :)

Сейчас в fpc-шной ветке собирабельны: Calculat.ppu commands.ppu country.ppu defines.ppu dnhelp.ppu dnini.ppu events.ppu files.ppu objects2.ppu scroller.ppu startupp.ppu streams.ppu ukeymap.ppu use32.ppu vpsyslo2.ppu vpsyslow.ppu vputils.ppu xtime.ppu

Не то чтобы очень много, но ещё вчера таких было 0 :)

UPD 29 штук собираются уже :)

Можно узнать, что за шрифт в консоле?

Многим интересно, да :)

Это Cascadia Code Semi-Light 13

btw, 34 юнита под fpc/fv собралось уже. Всё, перерывчик на какаушко. Иногда и работу поработать надо :)