Saturday, August 23, 2008

Простенький броузер

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

Так как в то время я решил поробовать основаный на исходных кодах дистрибутив Lunar в нем firefox не коппилился под 64 разрядную архитектуру. А пользоваться инетом скартинками хотелось:-)

Маленькое отступление:
  1. Выбор был основан на том что дистрибутивы основаные на пакетах я уже пробовал - не понравилось: так как все равно сам все пытался перекомпилить и установить не стандартные версии :-)
  2. И перешел на LFS все сам руками установил:-) Поставил нужные мне версии приложений - создал подобие системы установки используя как основу скрипты из установщика Gnome - Garnome.
  3. Он у меня простоял полгода:-) И тут мне захотелось купить ноутбук. Вот он как раз AMD64 и не него я решил перенести результаты своих трудов - и появились проблемы на 64 битной платформе все было не так гладко: не мог подобрать нужные драйвера под контролер жеских дисков -- нашел нужны а он у меня после компиляции отказывался работать.
  4. И я вернулся на Ubuntu:-) но долго терпеть не мог. Так Gentoo стояла у моего друга на компьютере, я решил найти что - то подобное, но не Gentoo - в ней был старый гном, а Lunar более новый(мне тогда это казалось достаточно важным - теперь я не особо замечаю различия между версиями или они действительно стали очень мелкими).
  5. И выбор был сделан с тех пор я пользуюсь им:-) Не все конечно так отлажено как в Gentoo, но очень даже не плохо:-)
И после этой короткой(а может и не очень) исторической справки маленькое описание броузера:
  1. он может нормально обрабатывать кодировки пришедших страниц(gtkhtml понимает только utf8) ;
  2. он может отобразить html стриницу с картинками:-);
И имеет несколько мелких ошибок:
  1. Он оправляет запросы в независимости от исходной кодировки страницы utf;
  2. Очень часто ошибаеться в относительных путях если часть стриниц имеет разный путь откуда отсчитываеться относительный путь (причина очень проста - в gtkhtml не храниться кодировка страницы и путь с которого она загружена - сейчас не могу говорить точно может уже и исправили);
  3. И ужасный интерфейс без кнопочек назад и указание на какую страницу только в логах на терминал.

Вот и весь проект...

Wednesday, August 20, 2008

SilverLight WPF

Продолжая предыдущее сообщение:

Удалось создать простейшие тестовые приложения с использованием SilverLight. При создании приложения автоматически системой сборки генерируется тестовая страница и сразу можно проверить его работоспособность. Благодаря этому не нужно дополнительный проектов чтобы проверить результат, в результате отдельный сервер для тестирования не нужен( проектов под ASP создавать не нужно).

Ручками создавать проект под SilverLight из пустого проекта нельзя нужно немного подредактировать в текстовом редакторе проект, чтобы он компилировался в xap(обычный zip архив с библиотекой и ресурсными файлами) иначе получается тоже самое, но без упаковки в архив и тестовой страницы.

Изменения достаточно тривиальны: добавить список импортируемых библиотек и исправить тип результирующего файла. Затем можно это все экспортировать как шаблон и сохранить его себе и не проделывать это снова.

Единственное есть пара недостатков: нельзя проект запустить в режиме отладки и присоединять отдельно отлажены проекты под WPF - как следствие создать скачала обёртку как обычное десктопное приложение, а затем над основной его логикой(окошки и графические элементы) добавить обёртку для запуска под SilverLight.

В результате хоть доступны одинаковые элменты в обоих приложениях, но они расположены в разных библиотеках с одинаковыми именами и свойствами. Как следствие: выход один создание логики преобразования внутренего состояния непосредственно в элементы в обертках- но код можно просто копировать, что тоже не плохо;-).

Sunday, August 17, 2008

SilverLight и Visual Studio Express 2008

Пока опыт не очень удачен, но удалось заставить компилироваться примеры. Осталось заставить их работать:-) Проблемы с asp - часть примеров с ошибкой нет доступа к подчиненным папкам. Но часть проектов нормально запускается при открытии с локальной папки. Пробовал не все примеры и не очень подробно разбирался почему недоступны файлы через стандартный тестовый сервер.

Надеюсь это кому-то поможет...

Основа опыта здесь. Но получилось это сделать немного правильнее по моему мнению.

Отличия от описанного я файлы требуемые для компиляции получил из стандартного пакета разработки под SilverLight 2.0(Silverlight Tools Beta 2 for Visual Studio 2008 silverlight_chainer.exe). Этот пакет требует для своей установки полной версии VS, но это можно обойти распаковав это пакет и запустив непосредственно версию SilverLight 2.0(Silverlight.2.0_Developer.exe) и библиотеки для разработки silverlight_sdk.msi.

После этого можно приступать непосредственно к открытию файлов примеров. Так как все примеры расчитаны на полную версию при открытии их появиться сообщение, что не все проекты удалось открыть. Для того чтобы их открыть нужно немного подправить файл описания проектов, которые не удалось открыть, удалив строки productversion и projecttypeguids.

Более подробно можно посмотреть по указанной выше ссылке.

Скачать установочный пакет SilverLight можно с официального сайта.

Удачи всем:-)

Wednesday, August 6, 2008

Портирование приложений СSharp на mono

Начальные действия.

Написано на основе опыта полученного при портировании толстого клиента, так как портирование еще не завершено(приостановлено), то опыт не полный.

Первое и самое важное что нужно сделать это определить какой именно функционал требуется в результате портирования. Так как скорее всего в результате портирования получается несколько урезанная версия в связи с ограничениями реализации mono и возможным использованием недокументированные функций из .NET в результате чего приложения будет работать некорректно.

Определить, где хранятся основные файлы приложения и важность именно такого расположения файлов и конфигураций. Хранение данных в реестре и использование установочных пакетов удобно в Wiondows, при запуске под Linux второе не используется, а для первого нужно самому внести все данные в реестр. В моем случае это было не критично так как в реестре храниться только версия установленного приложения в системе. И как следствие приложение не сможет себя автоматически обновить.

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

  1. Environment.SpecialFolder.ApplicationData===домашний каталог/.config
  2. Environment.SpecialFolder.CommonApplicationData===/usr/share
  3. Environment.SpecialFolder.CommonProgramFiles===пустое значение
  4. Environment.SpecialFolder.Cookies===пустое значение
  5. Environment.SpecialFolder.Desktop===домашний каталог/Desktop
  6. Environment.SpecialFolder.DesktopDirectory===домашний каталог/Desktop
  7. Environment.SpecialFolder.Favorites===пустое значение
  8. Environment.SpecialFolder.History===пустое значение
  9. Environment.SpecialFolder.InternetCache===пустое значение
  10. Environment.SpecialFolder.LocalApplicationData===домашний каталог/.local/share
  11. Environment.SpecialFolder.MyComputer===пустое значение
  12. Environment.SpecialFolder.MyDocuments===домашний каталог
  13. Environment.SpecialFolder.MyMusic===домашний каталог/Music
  14. Environment.SpecialFolder.MyPictures===домашний каталог/Pictures
  15. Environment.SpecialFolder.Personal===домашний каталог
  16. Environment.SpecialFolder.ProgramFiles===пустое значение
  17. Environment.SpecialFolder.Programs===пустое значение
  18. Environment.SpecialFolder.Recent===пустое значение
  19. Environment.SpecialFolder.SendTo===пустое значение
  20. Environment.SpecialFolder.StartMenu===пустое значение
  21. Environment.SpecialFolder.Startup===пустое значение
  22. Environment.SpecialFolder.System===пустое значение
  23. Environment.SpecialFolder.Templates===пустое значение
Все не установленные пути лучше не использовать так как результат будет зависеть от текущей папки(обычно это папка где запустили) и возможны неприятные неожиданности.

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

Заменить в проекте все сообщения об ошибках на более информативные с указание стека выполнения. На пример: я добавил новый компонент которые отображает ошибку и в текстовом поле под ним отображает полный стек. Это очень важно так как исключения могут возникать по самым на первый взгляд безобидным причинам и приложение будет отказываться работать.

Установить последнюю версию mono и monodevelop - последнюю - так как скорее всего, именно в ней будет реализовано максимум возможностей из .Net. Если есть ограничение на дистрибутив максимально свежую из доступных в нем.

Сделать копию описания проекта и назвать его как нибудь на подобии проект_под_VS. После этого открыть проект под VS в monodevelop - при открытии, если был установочных проект, то среда сообщит, что он не передерживается. Это нормальная реакция системы после этого проект будет уже сохранен без не поддерживающихся частей и в результате для создания установочного пакета нужно будет использовать копию проекта сделанную ранее. В остальном проект можно использовать в на обоих платформах.

При компиляции возникает 2 типа ошибок(возможен и третий но очень редко.):

  1. Не корректно по мнению компилятора написанный код - возможно прийдеться раставить в местах ошибок дополнительные скобки чтобы исправить неоднозначности кода.
  2. Не корректная кодировка файла - самая подлая ошибка:-) Для избежания ее нужно все файлы используемые в проекте перевести из cp1251 в utf8. Ее симптомы компилятор ругается на нормальный на вид код и приложение работает неправильно , идет не по тем путям куда должно было. В моем случае некоторые элементы имели русское название и отображались не те формы или не те компоненты и не срабатывали нужные реакции.
  3. Не реализованы какие-то функции вообще никак, отсутствие некоторых свойств - очень редкое событие, но вполне возможно. Единственный метод решения этой проблемы не использовать этот код.
После выполнения всех этих шагов мы должны получить код который компилируется и запускается, но еше не работает.

Запускаем приложение

Основная проблема возникающая при работе: это отсутствие отладчика в monodevelop. И всю отладку скорее всего нужно проводить методом отладочных печатей и логов.

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

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

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

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


       /// 
/// Запущены под моно
///

/// нужно урезать объем отображения
public static bool IsRunningOnMono()
{
return Type.GetType("Mono.Runtime") != null;
}

///
/// Запущена не под XP(Считаем ее самой распространенной пользовательской системой)
///

///
public static bool IsTerminalServer()
{
return !(Environment.OSVersion.Version.Major == 5 && Environment.OSVersion.Version.Minor == 1);
}

///
/// Запущены под юникс
///

/// нужно запретить специфичные для виндоус операции
public static bool IsUnix()
{
return Environment.OSVersion.Platform == PlatformID.Unix;
}
После выполнения этих шагов мы получаем приложение(альфа версия), которое работает с урезанным функционалом, но выглядит очень странно:-)

Исправление внешнего вида

Эта стадия еще не завершено мной, в новой версии mono 2.0 все компоненты выглядят очень похожими на оригинальный , но лучше все таки проверить.

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

Как результат мы получим приложение которое можно тестировать(бета версия).

Исправление функционала

После того как мы получаем версию с нормальным отображение компонентов можно уже искать ошибки в приложении связанные с особенностями архитектур и платформ.

Зачем это все надо

При портировании и использование другого компилятора мы получаем ряд преимуществ:

  1. При компиляции мы можем обнаружит части кода которые по каким-то причинам были не завершены или сделаны не качественно - присутствуют не используемые переменные, не проверяются ответы от функций и параметры функций не проверяются на корректность.
  2. Приложение, когда это потребуется, можно будет портировать, и затратить на это меньше времени.
  3. И как следствие предыдущего факта при смене версии ос даже на одной платформе (XP -> Vista) с большей вероятностью будет работать.

Thursday, July 10, 2008

Эльбрус-3М



Только мне кажется не очень понятным как выполняется эмуляция x86 если брать преобразовывать по одной команде(наиболее универсальный метод) то при возможности выполнить 24 команды одновременно будет выполнять только одна и выполнение не более трёхсот миллионов операция - так не возможно обогнать 500 МГц PIII так как простейшие операции выполняются на нем на RISC ядре(1команда менее или равна 1 такт). Если динамически блоки бинарного кода преобразуются в код другой выполнимый на другой архитектуре - появляются проблемы разбора сложных ветвлений адрес перехода может быть вычислен косвенно и в новом коде распределение адресов сложно поддерживать(пример переход вычисляется по какой-то формуле и выполняется прибавлением результата к текущему адресу - решение удаление функции с заменой ее на таблицу переходов). Вторая проблема определения частей кода являющимися данными - они могут быть внутри исполнимого кода. В общем полиморфные вирусы могут не заработать:-).

Thursday, November 29, 2007

Kernel space: E-paper support for Linux

Моё мнение относительно статьи о E-paper.
В статье предлагается использовать для управления 2 варианта решения проблемы отсутствия как такового буфера кадров кадров.
  • Для определения что изменилось 2 буфера и сравнивать текущее значение с предыдущим и разницу использовать для управления экраном, что имеет недостатки так как требуется выполнять цикл прохода всех значений и требуется в 2 раза больше памяти. Что в существующей технике и так используется двойная(иногда тройная) буферизация кадров, но выполнять операции по прорисовке может в таком случае только процессор.
  • Отмечать буфер кадров как только для чтения и при на уровне обработки прерываний по обращению к этой памяти на запись формировать команды управление на для этой системы.
Но почему-то не рассмотрен вариант когда эти операции выполняются на уровне Xserver. И он свои команды преобразует в эту последовательность - что приведет к большой экономии процессорного времени и памяти, так как требуется только дополнительная память под хранение текстур и выполнении их наложения.

Thursday, November 16, 2006

Современные тенденции развития операционных систем(Мое выступление)

Мой доклад на конференции в XAИ в 2006 году.
Плакаты были потеряны - остались лишь их упоминания.

Особая благодарность моему научному руководителю Дужему В. И.
за помощь в подготовке к конференции.

Плакат 1.
На сегодняшний день существует довольно большое количество операционных систем. От долгожителей UNIX и его клонов до совсем новых и малоизвестных операционных систем созданных энтузиастами (иногда одним человеком). Все они используют различные концепции и идеи в своих работах. Но для всех операционных систем существуют некоторые базовые требования, которым должны удовлетворять все операционные системы вне зависимости от целей поставленных при их разработке. Такие как:
  • Скорость реакции на изменения в аппаратной архитектуре и концепциях.
  • Удобство использования ( администратора системы для сервера или конечного пользователя для офисного или домашнего компьютера).
На удовлетворение этих требований влияют в значительной степени архитектура операционной системы.
Плакат 2.
Вследствие этого основной задачей поставленной перед этим докладом это исследование существующих архитектур операционных систем, и на основе результатов определить (спрогнозировать) возможность быстрой разработки и дополнения поддержкой новых устройств и технологий в существующих операционных системах.
Плакат 3.
На данный момент существует 2 базовых архитектуры ядра и 3 вида архитектур, которые можно назвать дальнейшим расширением этих архитектур.

Базовые (классические):
  • Микроядро;
  • Монолитное ядро.
Потомки:
  • Экзоядро (похоже на микроядро) ;
  • Модульное (похоже на монолитное);
  • Гибридное ядро (монолитное плюс модульное).

Плакат 4.
Среди ядер можно выделить следующие проблемы:

  1. Неэффективное использование ресурсов из-за не эффективного и не оптимизированного под архитектуру кода, и как следствие невозможности добавления новых возможностей без полной переработки архитектуры системы;
  2. Сложность внесения исправлений и изменений вследствие сложной архитектуры системы;
  3. Отставание от развития аппаратуры вследствие большого объема изменений требуемых для добавления поддержки или нежелания разработчиков аппаратуры и операционной системы распространять информацию о разработанной или разрабатываемой системе;
  4. Для внесения новых возможностей требуется значительное изменение архитектуры системы вследствие того, что разработчики не заложили возможность расширения системы.
Плакат 5.
На плакате 5 рассмотрены основные особенности существующих операционных систем.
Плакат 6.
Микроядро. Главная особенность вынесение некоторых функций из ядра в пространство пользователя, что позволило увеличить стабильность системы, но имеет несколько недостатков, так как компоненты находятся вне ядра нужны дополнительные затраты ресурсов при обмене сообщениями между различными компонентами системы, и дополнительные средства обеспечения безопасности системы. Хотя при этом можно создать систему, где каждый компонент работает в своем адресном пространстве. Существует абстракция от оборудования.
Плакат 7.
Монолитное ядро. Классика среди архитектур ядер. Все компоненты системы находятся в одном адресном пространстве и в одном программном коде. Ядро представляет собой единую и неделимую систему. Существует абстракция от оборудования. Вследствие этого нет возможности подгрузить и исполнить код в пространстве ядра. Но так все находиться в одном пространстве, и компилируется все вместе и размер кода достаточно большой и отладка очень затруднена.
Плакат 8.
Модульное ядро. Базируется на монолитном ядре с применением тех же принципов построения и работы ядра, но появляется возможность загрузки и выгрузки модулей ядра при необходимости. Что позволяет повысить безопасность работы системы (если какого-то компонента в системе нет он не может привести к проблемам) и уменьшить затраты памяти при работе системы. Но при появлении у злоумышленника сформировать и загрузить модуль это может привести к получению злоумышленником полного доступа к системе (хотя если злоумышленник смог получить доступ к загрузке модулей не полный ли это доступ?).
Плакат 9.
Экзоядро - самое молодое из архитектур ядер, близко по концепциям к микроядру. Все компоненты системы вынесены из ядра в пространство пользователя, и ядро выполняет роль арбитра при выполнении различных действий в системе. Минимальное количество функций выполняется на уровне ядра, оно только предоставляет доступ к ресурсам, осуществляет разграничение прав на уровне приложений и минимальное количество функций межпроцессного взаимодействия. Основная идея: ” никаких абстракций на уровне ядра программы могут себе сами создать абстракцию к чему-либо и только в необходимом им объеме, зачем лишние возможности?”
Плакат 10+11.
Гибридное ядро в отличие от предыдущего является расширением монолитного и модульного ядра с использованием абстракции от оборудования. Основная идея: если что-то можно перенести в пространство ядра для повышения скорости, почему бы не перенести? Что привело к новым недостаткам размер ядра большие затраты из-за абстракции от оборудования(хотя не все разработчики драйверов соблюдают эту идею). И из-за работы некоторых частей в ядре системы возникают проблемы безопасности в системе (некоторые частям не требуется такой большой приоритет, но они работают в ядре). Эти проблемы переносятся и в другие системы(LINUX и ATI+NVIDIA).
Плакат 12.
Более оптимальный вариант это объединение всех достоинств ранее рассмотренных систем. Основное единство интерфейсов на всех уровнях. В результате система разделена на две части у одной есть сквозной интерфейс для всех уровней, а у второй предназначен только для пользовательских программ, он аналогичен POSIX или подобному интерфейсу. В результате системные программы драйвера и другие программы могут запускаться на всех 3 уровнях (системный уровень, уровень ядра, уровень пользователя). И базовая часть ядра будет представлять экзоядро с поддержкой этого интерфейса. В результате появляется возможность в зависимости от задач переносить части с уровня на уровень.
Плакат 13.
Выводы:
  • Большинство современных операционных систем не поддерживает возможности расширения и увеличения надежности в зависимости от настроек системы и запуска приложений в изолированном пространстве.
  • В дальнейшее направление исследований изучить возможность модернизации существующих операционных систем в направлении изменения архитектуры ядра и улучшения его характеристик.
  • Наиболее подходящими для усовершенствования являются системы c открытыми кодами и лицензией подобной GPL(LINUX,*BSD).