Комментарии 33
А хром, например, нельзя использовать? Или он не запустится на калибри?
KolibriOS — любительская операционная система для x86-совместимых компьютеров, ядро которой полностью написано на языке ассемблер… использует собственные стандарты и не является POSIX или UNIX совместимой
архив всех программ, написанных под эту ОСь, весит меньше хрома раза в 2 :)
архив всех программ, написанных под эту ОСь, весит меньше хрома раза в 2 :)
Замечу, что портирование Chromium теоретически возможно, но ресурсов для этого у проекта нет — в частности, человеческих.
Зато возможно практически портирование другого браузера, поменьше.
Зато возможно практически портирование другого браузера, поменьше.
Netsurf сейчас дорабатывается.
А когда (если) портируют/выйдет NetSurf для KolibriOS, разработка WebView будет приостановлена?
Вряд ли. Хотя в WebView много архитектурных проблем, NetSurf значительно массивней. Размер бинарника Netsurf раз в 70 больше, и он использует очень много чужеродных для Колибри библиотек — freetype, libjpeg и так далее.
И вообще, разве Chrome/Firefox «убили» разработку текстовых браузеров?
И вообще, разве Chrome/Firefox «убили» разработку текстовых браузеров?
разве Chrome/Firefox «убили» разработку текстовых браузеров?
Если честно, то похоже на то, ибо я не могу вот сейчас навскидку назвать более одного (теперь — двух) текстовых браузеров.
Это lynx/Links и теперь WebView. Да и Links тоже умеет картинки выводить на самом деле.
И вообще, разве Chrome/Firefox «убили» разработку текстовых браузеров?А разве нет? Вы тут перечислили целую кучку браузеров, но когда у них что-то новое выходило? w3m — три года назад, netrik — пять, debris — десять, zen прямо на своей старнице пишет «Please note that this project is no longer in development»… Разработка lynx'а/links'а вроде теплится — но тоже едва-едва: на то, чтобы вышла предыдущая минорная версия lynx'а ушло три года, на версию 2.8.8, похоже, лет 10 понадобится. Links, правда держится (последней версии всего полгода!), но он уже и не совсем текстовый.
Также замечу, что возможно создание имплементации Linux ABI и эмуляции окружения POSIX, портирование иксов и запуск хромиума ^_^
короче, возможно всё :)
Конечно, возможно. Я вот этими своими кривыми руками *смотрит на руки* добавлял обработчик int 0x80 в ядро, писал два десятка основных POSIX-функций, и запускал несложные elf-бинарники из Колибри. Аналогичный проект для PE/WinApi позволяет даже запускать TASM.
Кстати, вот тема PELoad, если кому-нибудь интересно.
А как-же JavaScript? Или только HTML разметка?
Можно попросить скриншот Хабра или Википедии для примера?
Wikipedia i.imgur.com/WEKgpGl.png
Habrahabr i.imgur.com/nfz0IZl.png
(извиняюсь, не на тот уровень ответил)
Habrahabr i.imgur.com/nfz0IZl.png
(извиняюсь, не на тот уровень ответил)
Мне кажется, что с целью еще большей минимизации используемого места, стоило бы все же допилить Downloader, т.к. нечто умеещее работать с HTTP уже есть. В общем по-моему unix-подход «1 программа для 1 задачи» в вашем случае оптимален.
Интересное мнение.
К сожалению, в downloader можно передавать только адрес, но нельзя передавать заголовки. Плюс IPC было через файл /rd/1/.download (на рамдрайве, размер которого ограничен).
Одно из возможных решений: действительно расширить функционал downloader. Чтобы он понимал заголовки и тип запроса в качестве параметров; чтобы обмен данными вёлся через именнованную общую память.
Другое решение, которое и было использовано: программа downloader была разделена на библиотеку libhttp и интерфейс к ней. API библиотеки прост и понятен, а сам механизм взаимодействия проще, чем в случае с shared memory. Сам downloader стало проще расширять, улучшать и модфицировать.
О преимуществах разных подходов можно спорить вечность. Если бы Колибри была ОС с UNIX-корнями, то, я думаю, предпочтение отдавалось бы первому решению. Однако, Колибри действительно далека от *NIX; можно сказать, что какие-то несколько лет назад она была почти полной противоположностью. До появления в относительно недавнем прошлом shared memory и локальных сокетов взаимодействие между процессами было возможно только через файлы или очень-очень медленную функцию обмена сообщениями через ядро, которая носит гордое имя «IPC». Каналов в Колибри нет до сих пор (что очень мешает переносу консольных POSIX-совместимых приложений). Однако, Колибри интересна, на мой взгляд, именно своей самобытностью. Позволяет иначе взглянуть на «привычные» вещи.
К сожалению, в downloader можно передавать только адрес, но нельзя передавать заголовки. Плюс IPC было через файл /rd/1/.download (на рамдрайве, размер которого ограничен).
Одно из возможных решений: действительно расширить функционал downloader. Чтобы он понимал заголовки и тип запроса в качестве параметров; чтобы обмен данными вёлся через именнованную общую память.
Другое решение, которое и было использовано: программа downloader была разделена на библиотеку libhttp и интерфейс к ней. API библиотеки прост и понятен, а сам механизм взаимодействия проще, чем в случае с shared memory. Сам downloader стало проще расширять, улучшать и модфицировать.
О преимуществах разных подходов можно спорить вечность. Если бы Колибри была ОС с UNIX-корнями, то, я думаю, предпочтение отдавалось бы первому решению. Однако, Колибри действительно далека от *NIX; можно сказать, что какие-то несколько лет назад она была почти полной противоположностью. До появления в относительно недавнем прошлом shared memory и локальных сокетов взаимодействие между процессами было возможно только через файлы или очень-очень медленную функцию обмена сообщениями через ядро, которая носит гордое имя «IPC». Каналов в Колибри нет до сих пор (что очень мешает переносу консольных POSIX-совместимых приложений). Однако, Колибри интересна, на мой взгляд, именно своей самобытностью. Позволяет иначе взглянуть на «привычные» вещи.
НЛО прилетело и опубликовало эту надпись здесь
Насколько мне известно, есть. Колибри может быть интересным суповым набором, если требуется очень быстрый доступ к «железу» и графика. Порты линуксовых драйверов ATI/AMD и Intel этому способствуют. Приятные «бонусы» — BSD-совместимые sockets, стек USB OHCI/EHCI/UHCI (мышки-клавы-флешки) и звуковая подсистема с поддержкой Intel HDA.
Я имел в виду, что unix-подход вам бы подошел по той причине, которая ведет в некоторых случаях (например как этот) к уменьшению количества кода — а значит и размеров бинарников. Думаю в ОС которая влезает на дискету это очень важный момент.
Я не говорю что, мол, «давайте делайте все как в никсах», я говорю что это же логично — если какой-то функционал используется не только в одном месте, то можно его отделить и немного сэкономить :)
Если сам downloader уже тоже использует общую библиотеку, то все ок. Просто из статьи я лично этого не понял.
Я не говорю что, мол, «давайте делайте все как в никсах», я говорю что это же логично — если какой-то функционал используется не только в одном месте, то можно его отделить и немного сэкономить :)
Если сам downloader уже тоже использует общую библиотеку, то все ок. Просто из статьи я лично этого не понял.
«New Downloader» использует libhttp практически с рождения. И вот почему.
В Колибри за последние два-три года изменилось очень многое. Так, была выброшена на обочину истории сетевая подсистема MenuetOS. Героическими усилиями разработчика hidnplayr в Колибри появилась новая сетевая подсистема, с BSD Sockets и поддержкой одновременной работы нескольких сетевых интерфейсов. Все сетевые приложения превратились в тыкву. Многие были написаны практически «с нуля», включая downloader/libhttp. И жить стало лучше, жить стало веселее.
В Колибри за последние два-три года изменилось очень многое. Так, была выброшена на обочину истории сетевая подсистема MenuetOS. Героическими усилиями разработчика hidnplayr в Колибри появилась новая сетевая подсистема, с BSD Sockets и поддержкой одновременной работы нескольких сетевых интерфейсов. Все сетевые приложения превратились в тыкву. Многие были написаны практически «с нуля», включая downloader/libhttp. И жить стало лучше, жить стало веселее.
Чувствую меня уже не раз поминали дурным словом, за то что проект начинался на C--. Да и честно говоря он не планировался как полноценный браузер. Чисто документацию к системе в html чтоб можно было смотреть.
Там же еще проблема в том, что не строится DOM-дерево, а сразу рисуется, из-за чего полноценный css и js невозможен.
Но надо отдать должное Leency (Кириллу) и всем кто дальше поддерживал этот проект, получилось весьма неплохо
Там же еще проблема в том, что не строится DOM-дерево, а сразу рисуется, из-за чего полноценный css и js невозможен.
Но надо отдать должное Leency (Кириллу) и всем кто дальше поддерживал этот проект, получилось весьма неплохо
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
WebView или история о том, как в KolibriOS браузер писался