Я уже приступил. Небольшая вводная выдержка из документации.

> -- Цитата:
> Библиотека KOL может быть полезна для думающего Windows-разработчика, которому не чуждо эстетическое удовлетворение от красивых решений. Она предоставляет удобные абстракции на контролы и маскирует сложность многих WinApi-вызовов, но назвать её только обёрткой вокруг WinApi нельзя — в ней много самобытных решений, воплощённых опытным автором при поддержке русскоязычного сообщества. Замечательна она и тем, что позволяет создавать на языке Object Pascal программы очень компактные по размеру, делая процесс создания намного более простым, чем на чистом WinApi, а с привлечением технологии MCK сохраняется возможность визуальной разработки. Целевые приложения не только малы по размеру, но и более экономичны к потреблению памяти. Многое в KOL для оптимальности переписано на ассемблер.	KOL успешно портирована под Windows CE (этот проект известен как KolCE и его ведёт Юрий Сидоров — ) так что некоторый задел для кроссплатформенной разработки уже есть. Также Владимир Кладов планирует портировать KOL под GTK и Qt, но когда это будет и будет ли вообще — неизвестно.	Разумеется, KOL пока нельзя считать универсальным и, главное, кроссплатформенным средством построения интерфейсов с пользователем, но всё может измениться.	Проект по портированию KOL задуман для упрощения и повышения безопасности и скорости разработки целевых Windows-приложений на языке Component Pascal (надмножество языка Oberon-2) в системе BlackBox Component Builder от Oberon microsystems Inc. (), когда, по мере освоения Оберон-систем и написания на них приложений под Windows, я понял, что мне не хватает аналога KOL для Оберона и приступил к адаптации нужных мне возможностей KOL под BlackBox.	Владимир Кладов отнёсся к идее портирования KOL на Компонентный Паскаль с пониманием и согласился поместить порт на сайт , за что ему отдельная благодарность.	В процессе портирования, безусловно, придётся изменить многое в KOL, и, наверное, самая для этого веская причина — отсутствие в BlackBox условной компиляции (это вызовет дикий ступор у Объект Паскаль-программиста, которого лишили любимой игрушки, но для меня условная компиляция это пройденный этап и средство засорения исходников, и я вполне научился обходиться без неё; плюсы, поверьте, в её отсутствии тоже есть, и самый веский, как ни странно, стимул к повышению аккуратности при проектировании). Решено завести по 2 варианта модулей: Kol[Module] (для UNICODE) и Kol[Module]A для ANSI. Можно было бы впихнуть всё в один большой модуль Kol, как у Владимира, я, может быть, так позже и сделаю, но пока для большей структуризации — пусть будет в разных.	На данный момент подсистема Kol состоит из следующих модулей:KolTypes KolObjects KolStrings KolRegistry KolIniFiles KolFiles KolIOKolTypesA KolStringsA KolRegistryA KolIniFilesA	При наименовании типов и переменных, а также отступов при объявлении и вызове процедур я применил некоторые соглашения, рекомендуемые Oberon microsystems.	Работа ведётся не целенаправленно, а по мере необходимости параллельно с другими проектами. Не весь портированный код тщательно тестировался. Любая Ваша помощь (в т.ч. и по созданию тестовых модулей и переписыванию отдельных процедур) будет принята с благодарностью. Отчёты об ошибках и предложения по улучшению направляйте по адресу allot (at) bk.ru	Естественно это не путь классических Оберон-решений, традиционно кроссплатформенных и минималистичных, но Оберон-подобные языки, безусловно, имеют право на жизнь и на платформе Microsoft Windows.	Реализован модуль KolIniFiles для работы с Ini-файлами (UNICODE и ANSI), кроме функций GetSectionNames и SectionData (по той же причине). Начаты модули KolObjects (объекты), KolStrings (строки), KolTypes (типы KOL и преобразования между ними), KolFiles (файлы), IO (консольный ввод-вывод). Вместо функций Int2Str, Str2Int, Double2Str и Str2Double пока сделаны заглушки, но рабочие.	Запустилась первая тестовая консольная программа на KolBB. Занимает после упаковки UPX-ом 25,5 Кб. С учётом того, что туда запихнут практически весь готовый код KOL (кроме KolRegistry) и плюс ядро со сборкой мусора и поддержкой динамической модульности с разбором формата .OCF, который легковеснее DLL, выглядит неплохо. Крайне необходимо смартлинкование. С ним код будет в разы компактнее.Практически полностью реализованы модули KolRegistry для работы с реестром (UNICODE и ANSI), за исключением функций RegKeyGetSubKeys и RegKeyGetValueNames, которые требуют ещё неготовой работы со списками типа KOLStrList. Код компилируется без ошибок, но не тестировался.