Оберон-клуб «ВЄДАsoft»

Твердыня модульных языков
Текущее время: 08 дек 2019, 23:21

Часовой пояс: UTC + 2 часа




Начать новую тему Ответить на тему  [ Сообщений: 5 ] 
Автор Сообщение
 Заголовок сообщения: WinApi vs libc
СообщениеДобавлено: 21 ноя 2013, 05:45 
Не в сети

Сообщения: 53
Откуда: Россия, Самара
Олег, не лучше ли сделать привязку к libc? В windows это mscrt, в linux это libc или glibc. То есть нужно менять только внутреннюю реализацию биндинга при переходе на другую ос.

Привязка к win api, бессмысленна, так как есть переносимые библиотеки. Сделать биндинги к самым нужным библиотекам, некий минимум.


Вернуться к началу
 Профиль  
Ответить с цитатой  
 Заголовок сообщения: Re: WinApi vs libc
СообщениеДобавлено: 21 ноя 2013, 05:50 
Не в сети
Аватара пользователя

Сообщения: 985
Откуда: Днепропетровская обл.
Jordan писал(а):
Олег, не лучше ли сделать привязку к libc? В windows это mscrt, в linux это libc или glibc. То есть нужно менять только внутреннюю реализацию биндинга при переходе на другую ос.

Привязка к win api, бессмысленна, так как есть переносимые библиотеки. Сделать биндинги к самым нужным библиотекам, некий минимум.
libc даёт возможность делать GUI-программы?

А в Linux'е можно пользоваться Wine. Всё это относительно.

Впрочем, делайте. :) Если хотите.


Вернуться к началу
 Профиль  
Ответить с цитатой  
 Заголовок сообщения: Re: WinApi vs libc
СообщениеДобавлено: 21 ноя 2013, 06:12 
Не в сети

Сообщения: 53
Откуда: Россия, Самара
Zorko писал(а):
А в Linux'е можно пользоваться Wine. Всё это относительно.


Так много писалось, о минимальной программе на КП. Но для её запуска нужно ставить wine мегобайт на 20. :)


Вернуться к началу
 Профиль  
Ответить с цитатой  
 Заголовок сообщения: Re: WinApi vs libc
СообщениеДобавлено: 21 ноя 2013, 06:37 
Не в сети
Аватара пользователя

Сообщения: 985
Откуда: Днепропетровская обл.
Jordan писал(а):
Zorko писал(а):
А в Linux'е можно пользоваться Wine. Всё это относительно.

Костыль, хоть и работающий. Мне больше импонирует ваш компилятор, чем целая среда ББ. Так как компилятор перенести легче. Внешних редакторов кода куча, бери и пиши.
Ну, на самом деле это громко сказано "мой". :) Если Вы имете в виду OPCL, то он ETH'овский. А если XDev, то это и не компилятор вовсе, а нахальная попытка по быстрому собрать в кучу транслятор в Си (Ofront) и компиляторы Си для разных платформ. И попытка всё это скрутить в одну среду и заточить для своих нужд. А вот библиотеки к нему да, в основном мои. Только очень уж применимость их, опять же, узкая. Специфическая. Под мои цели. Но я не считаю нужным скрывать свою работу, хотя раньше так делал. И хотя без ажиотажа, но ведь ещё даже нет первой версии! (и не знаю когда будет).

Перед тем как опускать винапи, неплохо бы поинтересоваться какие именно задачи решать на нём подразумевается. Потому что задачи действительно есть чисто виндовские. А компов с виндами (по крайней мере у нас в стране) 99,99%. И винапи вовсе и не думает помирать. Вон в винде 8 реализован полный набор, да и ещё с лишком. А у винды 7 срок поддержки заявлен до 2020 года. Это для IT немало.

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

А вот libc это костыль, хоть и "есть во всех системах". Возьмите, к примеру, кривущую поддержку национальных символов путём работы с UTF-8, хоть и решающую поставленную задачу, но не добавляющую радости из-за символов разного размера (в байтах). Просто эта libc уже притёрлась всем на глаза, и это разучились замечать. Но эта прекрасная Linux-модель с UTF-8? Получается, libc тащит её даже под винду, где более традиционной является двухбайтовая кодировка, хотя и обладающая некоторыми недостатками (меньше символов, чем в UTF-8, всё те же локали (кодовые страницы)), но там хотя бы символы одинакового размера! Т.е. легче работать со строками, длину считать и т.д. Тут сказывается тот недостаток libc, что юникод был к нему прикручен потом. И шобы без потери совместимости. Ну по возможности.

Далее, тащит свою прекрасную работу с атрибутами файлов, специфичную только для линукса ну и т.п. Или возьмите функцию feof(). Что обозначает сие прекрасное и понятное для непосвящённых имя (без квалификатора)? Да просто это, оказывается, сокращение от File End Of File! Ну не рудимент ли? Разумеется, надо это тащить везде. А у меня эта функция вызывает желание поглубже её спрятать в модуле для более высокоуровневой работы с файлами, чтобы и не попадалась под руку. А то у неё есть фичи такие, что программер с двадцатилетним стажем кусает себе локти. К чести сказать, в винапи таких фич полно тоже. Поэтому разумным представляется использовать его тоже через прослойку, например, KOL (Key Object Library) Владимира Кладова.

Так что с точки зрения чистоты идеологии я всё-таки за собственную обероновскую библиотеку. Хотя и биндинги к другим на первое время могли бы поспособствовать, но смотрите что получается. Даже если находится человек, который делает биндинг, он сталкивается с пониманием, что сделать это на языке X гораздо проще, чем клепать биндинг для Оберона ручками, который устареет ровно с выходом новой версии библиотеки. А то сделал я биндинг к SDL 1.2. Ну написал народ пару программок, но особого ажиотажа вокруг Оберона + SDL не наблюдается. А в свете появления SDL 2.0 биндинг начинает помаленьку терять актуальность.

Эх, а хорошо бы научить Оберон-транслятор понимать напрямую сишные заголовки. Я уже предлагал эту идею и OMinc, и Джону Гофу (John Gough), может удастся пробить идею в сообщество Vishap Oberon Compiler (тоже маленькое, кстати).

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

Jordan, Вы могли заметить, что я, вобщем-то, уже приступил к созданию набора кроссплатформенных Оберон-библиотек (для XDev), которые опираются на libc (и SDL для графики). Просто делаю это помаленьку и в своём темпе, в рамках своих интересов. Идеи по расширению их применимости (или любая другая реальная помощь) весьма приветствуются. Но я не могу себе позволить делать и поддерживать совершенно не нужный мне набор биндингов в надежде, что вдруг он кому-то пригодится. Считаю, уже неплохо, что я сделал биндинг к SDL доступным для желающих. Так что внёс свой скромный вклад, как смог.

Но если говорить о биндинге к libc для BlackBox, то он уже имеется (модуль Lin/Mod/Libc.odc), правда, не знаю, насколько полный. Не пользовался. Но он включен в XDev.

Jordan писал(а):
Так много писалось, о минимальной программе на КП. Но для её запуска нужно ставить wine мегобайт на 20. :)
Угу, угу, уже лучше давайте не будем о подсистеме, которая моделирует поверх чуждой для этих целей ОС апи совсем другой (и немаленькой) системы, чтобы сделать линух немного побогаче на софт. А то давайте ещё вспомним .NET и JVM, которые тоже очень нехило памяти занимают?


Вернуться к началу
 Профиль  
Ответить с цитатой  
 Заголовок сообщения: Re: WinApi vs libc
СообщениеДобавлено: 08 мар 2015, 12:31 
Не в сети

Сообщения: 12
Zorko писал(а):
Эх, а хорошо бы научить Оберон-транслятор понимать напрямую сишные заголовки.


можно довольно быстро сделать приставную утилиту используя подсистему Coco - компилятор компиляторов, аналог yacc в си. На yacc есть читалки кода в си.


Вернуться к началу
 Профиль  
Ответить с цитатой  
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 5 ] 

Часовой пояс: UTC + 2 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
Создано на основе phpBB® Forum Software © phpBB Group
© VEDAsoft Oberon Club