Все это конечно здорово, но хотелось бы что бы автор поделился информацией о каких либо неприятных

глюках в Сибил и о способах их обхода....

Я бы оценил Sibyl на уровне Delphi2 с частичным шагом в сторону Delphi3.

Из терминологии. IDE в Sibyl носит название SVDE.

Исходники модулей Sibyl Portable Component Classes (SPCC( действительно лежит в Sibyl\Source\Spcc, но это не относится к остальным модулям.

Хороше практикой является давать имена классам, а не оставлять малозначащие Form1, Labe13.

А вообще - welcome to OpenSibyl project ;)

Не знаю, как в третьем фиксе, а

в 2.0, например, with неюзабелен - глюки внутри with xx do begin ... end; забодают. Нет stdcall, невозможно описать указатель на функцию с типом вызова, отличного от pascal. Ну и пр.

Хотя, вменяемо. И даже формы дельфовые почти внятно импортит.

Замечательная среда разработки! Работает не впример лучше чуда под названием Kylix!

Не знаю что там за проблемы с STDCALL. Не замечал, хотя функции вызываю из множества сторонних DLL.

И о глюках with мне не известно ничего. Применяю его повсеместно.

Что касается глюков - то они есть в результирующем коде ТОЛЬКО при включеной оптимизации!

Все остальные глюки - в коде библиотечных модулей и легко могут быть ликвидированы т.к. исходники данных модулей имеются.

С уважением, Алексей.

Хорошо бы ещё чтобы начинающим был бурблхэлп по вызываемым методам/функциям, как это стало в дельфе. У меня сестрёнка учится (хехе) на программера, пока что копается в дельфе, может, его бы в сибиле и написала, да документация не шибко удобная и подобного хелпа нет. Я так понимаю, кранты спидсофту настали?

2 A.Smitnov

Ты вызываешь cdecl ;) А ежли dll написана с stdcall не судьба ;) Не знает сибил такого слова.

А глюки в with у меня были, когда их несколько и вложенных - у меня такой стиль ;)

О! Еще вспомнил - word в double 2.0 не конвертила - получался ноль всегда ;))) Не знаю как FP3.

Alexey Smirnov

А не мог бы ты сделать список

самых вопиющих глюков?

Тем более ты у нас самый главный

СибилоВед.....;-)

Друзья, вот вас столько всего откликнулось - почему бы всем вам и не пойти в команду написания OpenSibyl ?

Вот это действительно было бы дело и всем радость..

И прошу, не надо говорить что сибил идеален. Если не считать самой главной и большой его проблемы, о которой мы тактично умолчим, то и без оной в нем багов и просто недостатков которые максимально не дают жить навалом..

В Сайбиле действительно много глюков, но большинство из них я бы назвал скорее недоработками и проблеммами совместимости, да и живут они в основном в SPCC. Ведь, по-сути, Сайбил - это два в одном. Даже Борланд споткнулась на этом в Kylixе.

Я сейчас собираю материал о tips'n'tricks в Сайбиле, так-что если вы знаете какие-то "фичи" - киньте на мыло.

With вот сейчас проверил с третим уровнем вложения - нормально работает с оптимизацией и без оной.

Преобразование Word to Double? Проверил, вполне нормально неявно конвертит.

Про паскалевский тип вызова что-то не понял - как тогда вызываются ф-ции из С-шных OS/2 API DLLей :-|

Наcчет "бурблхелпа" (в Делфях он называется "code insight" - предсказание кода), то это довольно сложный в технической реализации вопрос. В Делфи это реализуется компилятором, а в M$ ВБасике - весь хелп сидит в библиотеках типов (что довольно ограничивает его).

В качестве довольно сносного источника могу порекомендовать хелп от Virtual Pascal - там есть OS/2 SDK, хоть и английский. Кстати, кто знает, где можно взять русский OS/2 SDK?

Кстати, Юрий Прокушев забыл упомянуть, наверное от скромности :-), что именно он заведует OpenSibyl а сам проект живет на [url]

Главная проблемма Сайбила, IMHO, конечно, но по-моему - это то, что даже после своего развала СпидСофт не хочет поделится полной версией. Того гляди - закопает, а карту сожжет ;-)

С моей точки зрения главная проблема всех Delphi-like продуктов - это использование библиотек совместимых с VCL. VCL, с моей точки зрения, неудачна. Для того же PM я бы предпочел что-то аналогичное OCL для C++. Просто и не скрывает PM.. Кстати, значительно легче и шустрее той же SPCC.

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

Другой особенностью является то, что большинство компиляторов инициализирует VMT _после_ вызова консруктора. Sibyl делает это перед вызовом. Как результат - доступ в конструкторе к любым полям и методам.

Про stdcall не интересолвался, бо никогда небыло надо.

code insight, как и многое другое - не сложно. Но требует ряд извращений.

SpeedSoft более ничем делиться не будет. Компилятор с отладчиком они отдавать не намерены. А вот все остальное - пожалуйста. Правда, все остальное-то сильно не используешь. Слишком уж завязано на "особенности" Sibyl.

По поводу OpenSibyl. Видимо данный проект никому не интересен. Помощи - ноль (если не считать консультации по конкретным вопросам на канале).

Кстати, сейчас вот опять проблемка выросла. Свежеприкрученная поддержка нативной компиляции в FPC дает Access violation на конструкции типа MOV EDI,[address].

to Yuri Prokushev: в чем конкретно проблема/ непонятность? непонятно почему трап или что? Пиши на емайл - разберемся.

FPC - глюкало, был им и будет во веки веков ;) Именно поэтому OpenSibyl вызвал у меня сильное разочарование.

Относительно вызовов: stdcall<>cdecl

И: положим мы хотим получить указатель на функцию с cdecl и загнать его в процедругную переменную. А потом вызвать. Фиг там. Нет возможности указать тип вызова в описании процедурного типа.

В VP хоть есть {&StdCall+} или {&Cdecl+}.

Лично мне в проекте OpenSibyl не понравился именно выбор компилятора. Отказ от нативных средств в пользу Unix портированных по моему не верно. Да и ошибок в нем тоже хватает.

По поводу ошибок компилятора Sibyl. Сколько ни писал, не встречался с явными ошибками. Может быть, конечно, я пишу аккуратно?...

По поводу вызова DLL - ни разу проблем не встречал. И из базовых OS/2 DLL все вызывается нормально и из своих на Virtual Pascal написанных.

В любом случае проблема StdCall обходится через вызов функции в ассемблерной вставке.

2Igor Vaskov FPC не есть портированный компилятор. Он такой же нативный, как и VPC, TMT или SPC. А ошибок хватает везде. Но лучше компилятора я не знаю. Все остальные устарели или авторы не хотят их расширять. Так что выбора, по большому счету, и нет.

2dixie А есть варианты? Компиляторов больше нет.

Достаточно начать делать что-то б.м. объемное на сибиле, чтобы сразу словить массу глюков. При этом их настолько много и разного размера, что как-то в сознании они сливаются в один большой ;), а записывать их как-то не входит в мои привычки. При этом, на самом деле я довольно регулярно закидывал (в том числе и на ecs.ru) наиболее "мощные" перлы.

Копаться (особенно в пятницу после работы =) в своих же заметках мне лень, поэтому просто сразу на вскидку:

1) pchar и array[0..x] of char не являются "одинм и тем же" с точки зрения компилятора. Нельзя сделать pchar:=array. (Ладно, согласен, чепуха но напрягает)

2) string,ansistring,cstring жестко лимитированы в 255 символов. При этом если у нас есть textfile, содержащий строки>255 длины, то readln(textfile,pchar) и writeln(textfile,pchar) выполняются с ошибками. например, врайтлн дает мусор произвольного размера (меняется в зависимости от длины строки) в начале строки в файле. Спрашивается, как тогда работать с текстовыми файлами, содержащие длинные строки? (логи, да хоть config.sys осный =). К сожалению только через file of char с последующей разбивкой _вручную_ полученных блоков символов на строки. И запись через тот-же изврат. Кстати, попробуйте записать да хотя бы в stringgrid трочку>255 - ексцепшн гарантирован. Кстати, с ексцепшнами тоже странноватая работа.. Впрочем, я увлекся =))

Блин, да я понял что час писать про глюки его могу - пока пишу, вспоминаю.

НО!

Я пишу вообще не за этим =))

Я готов выкатить 5л. пива тому, кто ПОЧИНИТ НАКОНЕЦ РЭНДОМНОЕ ПОЯВЛЕНИЕ МУСОРА ПО onDisconnect ПОЯВЛЯЮЩЕЕСЯ ВМЕСТО IP АДРЕСА ОТКОННЕКТИВШЕГОСЯ ОТ СОКЕТА И УБЕРЕТ НАКОНЕЦ РЭНДОМНУЮ НЕВОЗМОЖНОСТЬ ЗАКРЫТИЯ СОКЕТА ServerSocket.Connections[x].Disconnect!!!

Извиняюсь за крик, но _достало_ просто... =((

p.s.

Блин, какой же классный VP после этого! Какой код делает - просто сказка =))

Ы! =)

Имелось ввиду ServerSocket.Connections[x].Close

pchar и array[0..x] of char никак не могут быть тем же самым. В лучшем случае pchar может быть равен ^array[0..x] of char..

Кстати, а чем VP не катит для OpenSibyl? Можно на автора понаезжать в принципе ... ;)

2dixie Он отказался поддерживать проект. А ждать когда он соизволит внести какие-либо изменения - не катит. Да и отстал VP уже прилично.

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

Ну почему ;)

Мне б хорошее описание дерева, по которому генерит код OpenWatcom - я б свой компилер сделал ;) Морда, т.е., парсер и вполне внятный ( на уровне VP/Delphi) уже есть ;) Несколько лет валяется - ломы генератор кода писать ;)

Хотя на inline асме получается в нем маленькие exe уровня "Hello OS/2" компилить ;))

2dixie Парсер на уровне какого Delphi? С классами, интерфейсами и все прочим? Все равно, ИМХО, использовать готовый компилятор лучше, чем писать свой с нуля.

Объекты есть, классы не дописаны, но это не так сложно, как кажется, когда все остальное отработано ;) На неделю работы максимум. Рантайм можно взять от VP ;) Отладочную инфу писать в ваткомовском формате ;))

А вот оптимизация - это да. Почему и хотелось бы прикрутить оное к ваткому. Тогда можно было бы и все его фичи в #pragma (включая указание регистров для параметров и пр.) задействовать. Да и оптимизация - и FPC и VP рядом не валялись.

Но самому разбирать как и что там в генератор подсовывается ... :((

Угу. А интерфейсы?

Кстати, runtime брать от VP нельзя. Из-за лицензии.

2EG Для меня итог простой. Я работаю с FPC, бо другого компилятора нет и в ближайшее время не предвидится.

А что такое интерфейсы внутри ты в курсе? ;)) Это просто VMT класса ;)

А итог в общем понятен. И ожидаем. ;)

А почему бы вам просто не перейти а c/c++ ? Пора уже исправлять ошибки детства ;)

Калечить мозги? Нет уж. Звиняйте. Идти на поводу всеобщей истерии по поводу плюсов я не желаю.

Ну почему ;)

У меня есть и "дельфа" и на плюсах - пишу помаленьку ;) Есть скришнот на os2.in.ru ;)

Просто полюсы действительно, не настолько хороши, как это внушено общественным мнением ;) А единственный серьезный недостаток паскаля - плохая оптимизация.

"плюсы", пардон ;)

И, кстати, ещё один прикол: в принципе, в паскалевском юните (в отличие от

плюсового объектника) совершенно необязательно хранить компилированный код.

Код можно генерерить на этапе линковки, при этом программа на паскале,

состоящая из нескольких файлов, будет гарантированно быстрее аналогичной на

плюсах (при том же оптимизаторе) - по той простой причине, что междуфайловая

оптимизация в плюсах почти невозможна. А паскалевская программа будет

выглядеть для оптимизатора как один файл ;).

Эх, мне б описание ваткомовского генератора кода ;)~~

2theDick: Я готов выкатить 5л. пива тому, кто ПОЧИНИТ НАКОНЕЦ РЭНДОМНОЕ ПОЯВЛЕНИЕ МУСОРА ПО onDisconnect ПОЯВЛЯЮЩЕЕСЯ ВМЕСТО IP АДРЕСА ОТКОННЕКТИВШЕГОСЯ ОТ СОКЕТА И УБЕРЕТ НАКОНЕЦ РЭНДОМНУЮ НЕВОЗМОЖНОСТЬ ЗАКРЫТИЯ СОКЕТА ServerSocket.Connections[x].Disconnect!!!

С первым не всречался - ибо не надо было, но можно посмотреть на досуге.

Второе IMHO (если я верно понял проблему) я уже правил и выкладывал патчи на Sockets.

В любом случае Welcom to mail.

2 ...За Справедливость, All:

Где-то я уже это цитировал, ну да ладно -

[url]

2All Давайте без вечных спорах о языках, а?

Языки все одинаковы. Просто в некоторых можно делать нечитаемый программный код. И программисты его делают. И если человек в Си пишет "*a++ = *b--;" или в Пердле наворачивает в одной строке два десятка рег.выражений - его к компьютерам подпускать вообще нельзя. Но все остается безнаказанным...

Т.е. если кто-то кому-то на даче сортир построил и он рухнул вместе с владельцем - за это рыло набьют. А кривую и падающую программу - скорее всего перепишут заново. Или сменят внешний вид, присвоят ей имя 2000/Me/Xp/Rg - и все равно продадут как "новинку".

И это не значит, что есть "плохие" и "хорошие" языки программирования, верно?

to Sergey Posokhov: верно. лично я пишу одинаково замечательно на асм, паскале и си.

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

Что из этого получается я думаю мне не нужно комментировать ;)

Плохо работает с базами данных.

По крайней мере мне не удалось вставлять новые записи и редактировать старые.

Если кто работал с базами DB@ выше 2.0, напишите,как решали проблемммы и какие драйверы ODBC использовали. ПЛЗ

DB2 использовали в проекте [url] Драйверы ODBC самые обычные. Стандартные объекты работы с базой данных переписаны. В свое время я их раздавал, но никому не надо было ;) Также как и исправленные объекты работы с сокетами.

У меня прекрасно работает в промышленное эксплуатации с _непрерывным_ циклом работы несколько систем, написанных на Sibyl и очень хорошо работают.

To Y.Prokushev:

Возвращаясь к теме проблемм VCL-like библиотек (SPCC) хотел-бы заметить, что OCL менее универсальна, чем VCL. И проблемма тут старая: за универсальность платишь скоростью работы. Возможно разработчикам VDE, стоило-бы создавать несколько визуальных библиотек по профилям: СУБД, графика, общие контролы, т.д.

А насчет скрытия PM ты неправ. Разве SPCC мешает напрямую создавать окна и другую бижутерию.

To Igor Vaskov:

Не смог-бы подсказать, где можно почитать про ODBC в OS/2, желательно с примерами? И вообще меня интересует вопрос работы Client/Server СУБД в оси. Заранее благодарю.

2stVova: Подсказать, где почитать - не могу. Я проектом руководил и в технические тонкости не лез. Помню, что для обхода некоторых багов и для ускорения работы была написана небольшая DLL на Сях.

2stVova Я просто не вижу никакой универсальности. Все то же самое, но "по-своему". Использование функций PM/GDI в библиотеках типа VCL затруднено, но никто не говорит о том, что невозможно. Я все же считаю подход OCL более правильным, чем VCL. Новые классы должны формироваться не в программе, а в отдельных DLL. Как пример - MMOS/2 (всякие volume control и т.п.), EPM (EMLE). Это ИМХО, более правильный подход, чем формирование всяких Toolbar-ов каждый раз вместо одного раза. Это, кстати, служит еще одним плюсов в сторону развития поддержи SOM в FPC.

2stVova. Читать по поводу ODBC можно о os2ezine. Был там цикл статей. С примерами.

Вообще надо сделать SybilRTL.dll и чтобы все программы ее использовали. Как в Watcom VX-REXX, например.

Кстати, обнаружил забавную вещь. По отладочной инфе Sybil совместим с VAC. Т.е., егойные программы можно отлаживать idebug из VAC 3.6 ;)

To Yuri Prokushev:

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

Там действительно довольно толково все описано в 12 статьях об ODBC.

Кстати, никто не сталкивался с такой проблеммой: когда DIVE криво конвертит RGB в 256.

С мусором в поле RemoteAddress в момент закрытия сокета проблему решил ;) А что вы хотели? Если соединение разорвано удаленной стороной вызов стандартной функции определения IP клиента не работает, потому как и соединения то нет.

Фиксы готов выложить. Но только для _последнего_ фикса Сивильи (его почему-то многие не любят).

2 Igor Vaskov Ух ты! Здорово! =) Выкладывай! =)))

А что там теперь, вместо мусора? 8) И как узнать, кто же все-таки отвалился?

А последний фикс не любят, наверное, потому, что там дебаггер совсем окривел =). Но зато там ошибок тож много исправлено..

Пожелание: выложите все на сайт [e-mail]

Ха-ха... гостевуха в слове "netlAbs" нашла "[at]" и восприняла слово как адрес e-mail :)

По поводу конвертирования RGB в 256: а в чем бага проявляется?

2 theDick Там теперь, что и должно быть - IP клиента. Плюс при многократных попытках спрашивать IP клиента существенно возрастет производительность ;) Теперь IP удаленного узла сохраняется в переменной _объекта_ в момент onConnect. Все остальные вызовы не обращаются к API, а получают данные из поля объекта.

2Sergey Posokhov Я никогда там ничего не выкладывал и не знаю как там чего делается. Если успею до отпуска - положу на своем сайте, а здесь дам ссылку.

2 theDick

А узнать, кто отвалился по IP нельзя. А вдруг несколько коннектов с одного IP?

Вдруг на стороне клиента NAT?

Когда я писал подобные серверные прикладухи, я ориентировался на массив оъектов, для отслеживания клиентов.

2 Igor Vaskov

Если несколько коннектов с одного IP то они всеравно по разным портам будут.. То есть если клиент коннектится к фиксированному порту на сервере то двойки IP:Port будут уникальны для каждого соединения со стороны клиента. Nat всеравно работает через один внешний IP ...

Таким образом, по сочетанию IP:Port всегда можно точно сказать какое соединение завершено.

С массивом соединений я пробовал - всеравно не получается, так как для обработчика onDisconnect соединение какбы считается еще не закрытым и массив .Connections, не изменяется (то есть ActiveConnections уменьшается только после завершения работы обработчика onDisconnect)

2 Igor Vaskov

А как ты узнавал тогда какой из объектов уничтожать? =)

To LightElf:

Я юзаю однин юнит к VirtualPascal (os2dive.pas) от 2001, он автором DiveRace написан (имя забыл). Так там можно сделать только 256кол. DIVE окно (8 бит).

Другая прога переводит битмапы в array[x, y] (RGB), который я в DIVE-окно и вывожу.

В результате RGB-цвета переводятся не в ближайшие по таблице, а как-то криво: из красного -> синий (например).

Я уже начал подозревать, что DIVE воспринимает цвета как BGR (или подобное) и переводит их в 256.

2 theDick Все правильно. На onDiconnect чистим свою таблицу объектов (соединений). Считаем, что соединение развалилось. Объект сокета уничтожит сам серверный сокет. Об этом думать не надо.

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

Я в таблицу соединений записывал адрес объекта сокета. Если не nil - живы и работаем. Если диксоннект пишем в таблицу соединений - nil.

На коннекте ищем в таблице первый попавшийся nil и на его место пишем адрес объекта сокета.

Естественно в таблице соединений можно хранить много другой информации про открытый сокет, которая не хранится в объекте.

Полюс есть возможность взять объект из таблицы и сказать ему .Send :)

2 Igor Vaskov

А. Ну в общем-то, насколько я понимаю, мы говорим об одном и том же =). Я в общем тоже делаю примерно подобным образом, только объекты я не очень люблю ;) поэтому я просто делаю динамический массив записей, где запись=соединение. В каждой записи инфа, идентифицирующая соединение + доп. информация всякая.

Однако всеравно нужно знать кто отвалился, чтобы убить соотв. запись (в моем случае) или объект (в твоем случае). Для чего собсно и нужно знать ip _И_ порт отвалившегося. Потому что больше никакой другой инфы, по которой _однозначно_ можно идентифицировать соединение нету. В связи с чем вопрос: а порт соединения ты тоже в переменную объекта запихнул? А то там тож наверняка мусор будет.

---

Или я чего-то не понимаю? =)

2 theDick Не понимаешь ;) Массив соединений в моем примере - обычный array of record. Даже не динамический, как у тебя. Действительно, запись - соединение.

Теперь главное. Ты создаешь запись соединения на OnConnect? Ну и добавь в нее ссылку на объект. Ссылка на объект тебе передается в параметрах вызова события OnConnect, да и любого другого события OnRead, OnWrite и так далее.

Когда отваливаемся - OnClientDisconnet.

Берем из параметров ссылку на объект,

ищем ее в массиве записей соединения, удаляем эту запись.

Не надо удалять сам объект! Он прекрасно удаляется объектом серверного сокета.

Ух. Теперь понятно? ;)

2 Igor Vaskov

Ага! Понятно!!! =)))))

Спасибо!!! А я-то парюсь... =)

2 stVova : DIVE понимает и RGB и BGR, если не изменяет мой склероз. Но переводить RGB в 256, а потом назад - изврат редкий. Могу только посоветовать выкинуть этот модуль и написать свой. Бо с дайвом работать не просто, а очень просто. К тому же сколько я видел разных либ/юнитов для дайва - нет ни одного правильного. У всех поголовно проблемы с scanlinesize - следовательно с хардварным дайвом будут проблемы. Каждый второй использует свои собственные буферы (с хардварным дайвом будут тормоза)

2 theDick Ты бы рассказал общественности, чего пишешь? Очень интересно, какой сервер на OS/2 платформе нужен в настоящее время?

2 Sergo

Эта страница к сожалению больше не развивается, и уже давно..

2 Igor Vaskov

Да ничего особенно интересного, просто текущая необходимость.. Сеть у нас, юзеры всякие, все в инет хотят =). Посему нужна система авторизации. Мы пошли путем создания клдиент-серверной проги, сервер авторизует, пускает (или не пускает =) в инет, еще кое чем занимается.. Клиент - мааленькое приложение с 2 кнопочками коннект и дисконнект. Удобно в том смысле, что если юзер, например, завис, выключил комп и т.п. доступ закрывается (по тайм-ауту на пинге). Ну, етстесно не дает воровать ип друг у друга.. И т.д. Все написано и работает уже пол-года, но глючит периодически в связи с вышеобсужденными проблемами =). Часть, отвечающую за коннект-дисконнект я переписываю щас согласно твоим рекомендациям =), а вот с неубиваемыми сокетами.. Но это всетаки значительно реже случается.

Помните, я писал, что в Сайбил нет автодополнения кода? Я ошибался, вчера видел скриншот Sibyl+CodeInsight.

Теперь вопрос: где можно взять такую версию Сайбила?

2dixie:

Почему бы не транслировать паскалевский сырец в голый Си и не скармливать потом прямо ваткому?

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

Копаюсь сейчас с выложенной версией OpenSibyl (пытаюсь переделать под FPC и VP, на счёт VP RTL не разделяю скепсиса: использовать её можно и нужно, а вот менять и распространять отдельно нельзя)

Так я вот о чём: в этом коде есть одна несообразность. Вот, берём FORMS.PAS и читаем вверху:

&#186; Sibyl Portable Component Classes (SPCC). &#186;

&#186; Object-oriented development library.

&#186; Copyright (C) 1995,99 SpeedSoft GbR, Germany &#186;

&#186;

&#186; This program is free software; you can redistribute it and/or modify it &#186;

&#186; under the terms of the GNU Library General Public License (LGPL)

и так далее и тому подобное. Думаю, всем понятно, что это значит.

В самом коде:

&#186; Sibyl Portable Component Classes (SPCC) &#186;

&#186;

&#186; This section: TClipBoard Class Implementation &#186;

&#186; &#186;

&#186; (C) 1995,97 SpeedSoft. All rights reserved. Disclosure probibited ! &#186;

И как это понимать? Если Disclosure уже произошло? Устарело что ли? Ладно, если что интересное сделаю, буду публиковать патчи.

Есть первые успехи (правда, пока под лицензионными "форточками", хорошей лицензии на полуось у меня нет, кроме eCS Demo CD и при существующей ценовой политике точно не будет: я не то что 3000, я и 300 рублей на неё не потрачу, прежде всего, по идеологическим соображениям, а потом - из-за недоработанности, хватит тех 2000, что я заплатил за форточки). Доделаю spcc под винду, потом попробую кросс-компиляцию под полуось, а потом в демо-версии запущу.

Пока даже не брался за сохранение/загрузку ресурсов. Думаю, этот блок надо будет переписать "с нуля", ориентируясь на Lazarus и другие (скажем, kcl)

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

Начать программировать лучше всего с языка PureBasic [url]

PureBasic - самый простой язык программирования, подходящий как новичку, так и професионалу!

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

Язык расчитан для написания консольных, оконных и игровых программ для Windows, Linux, MacOS, т. е. PureBasic - кроссплатворменный язык программирования. Предназанчен как для начинающих, так и для професионалов!

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

Он создаёт маленькие exe, от 2КБ и для их работы не нцжны никакие внешние файлы!