Enigma1/2 изнутри - С/С++ программируем !

    спасибо за ссылки, очень интересно, буду глядеть...


    а насчет энигмы - лично я собирался "hello world" компилить...
    (ну и еще пару прог, которые будут использовать энигму на уровне библиотек)

    Hочу замоунтить(Mounten)


    mtd5: 004e0000 00020000 "DreamBOX SquashedFS"


    делалю так не идёт,


    mount -t squashfs -o ro /dev/mtdblock/5 image


    как ббыть????

    Цитата

    По словам пользователя AlexXF ...
    а без наколок - просто кусочек кода?


    Я уже где можно это смотрел... проблема в том, как получить грамотный eServiceReference и понять - почему падает eServiceInterface::getInstance()->play


    вот и всего то!


    Копался, искал - нашел сам.
    Основной файл для поиска : sselect.cpp (enigma)


    В двух словах - искать канал и переключать на него можно в рамках активного букета. В любом случае, приходится делать вот что - тупой перебор всех каналов с помощью Callback функции до того момента пока не найдется нужный. Соответственно, когда требуется поиск ПО ВСЕМ каналам, устанавливается path как "все", выполняется поиск, возвращается обратно.


    ДА! ВСЕ ЭТО НАДО ДЕЛАТЬ ИМЕННО ЧЕРЕЗ ФУНКЦИИ ЭНИГМЫ!


    В таймере - другая история, туда загружена уже полностью подготовленая структура eServiceReference и Path, что в принципе уже достаточно.

    Что означает эта строка в configure.ac

    Исходный код
    CPPFLAGS="$CPPFLAGS -fno-exceptions -fno-rtti -D_REENTRANT -DDISABLE_LIRC -DENABLE_PPPOE -DENABLE_KEYBOARD -DDEBUG"


    вернее -DDISABLE_LIRC для чего оно нужно ?(

    Задача:


    Имеется WinXP, MS Virtual PC с установленным Debian


    Цель: загрузить Dream c PC, а не из флэшки.


    Причины: возможность отлаживать ядро энигмы не перепрошивая постоянно имидж во флэш


    Итак... как это сделать? Если можно, то по шагам.


    Если есть другое решение (скажем с помощью USB Stick), то тоже приветствуется.

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


    пост от NIL, крути страничку вниз, сразу после картинок с внутренностями дрима

    Насколько я знаю - такой способ канает только под линуксом, под виндой - фиг :(


    Но бум пробовать!

    Я пробовал загрузить под виндой, используя DBOX II boot manager. Официальный имидж пошел, ruDREAM - фик.
    Да и самый правильный способ - все-таки из под линукса. А то распакованный имидж на фате или нтфс - это ж слезы. Симлинки, права на запуск - куча нюансов.

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


    Итак... некоторые из них:


    1. delete без проверки на NULL - распространенная ошибка. Лучше сразу определить макрос


    #define SAFE_RELEASE(x) if (x != NULL){delete x; x=NULL;}


    2. чтение и запись в массив без проверки на его размерность... в частности меня убила функция в MV плагине, которая читает из ФИКСИРОВАНОГО массива по индексу, не проверяя индекс, который приходит в функцию на переполнение... мда...


    3. открытие файла на запись или чтение без указания флага бинарной записи/чтения


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


    5. непродуманость создания/удаления класса.


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


    btw, delete нулевого пойнтера является совершенно безобидной операцией в С++. Сбрасывать пойнтер в 0 после удаления или нет - спорный вопрос. Что касается флага бинарного чтения/записи - под юниксом фиолетово, там такой дискриминации нет :)


    А не пробовал вместо Virtual PC использовать VMware? AFAIK, там виртуальной машине можно дать IP адрес из подсети хардверного сетевого адаптера, т.е. можно использовать полноценные NFS/FTP/etc сервера.

    Цитата

    По словам пользователя Alexvrs ...
    ...
    для компиляции PLUGINS для имиджей ruDREAM, брать какое либо ядро не нужно (подходит то что есть на CVS), достаточно скомпилить их с заголовочными файлами от ruDREAM и причем это касается PLUGINS которые работают с интерфейсом enigma (точней используют ее классы), все PLUGINS типа игрушек - этого не требуют.


    P'S'
    для получения заголовочных файлов можно обратиться ко мне по ICQ


    А нет ли возможности положить все это куда-нть под CVS?

    Цитата

    По словам пользователя axstone ...


    btw, delete нулевого пойнтера является совершенно безобидной операцией в С++. Сбрасывать пойнтер в 0 после удаления или нет - спорный вопрос. Что касается флага бинарного чтения/записи - под юниксом фиолетово, там такой дискриминации нет :)


    1. Ага, вот то-то плагин падал как сумасшедший, когда он пытался "безобидный" пойнтер на несуществующую структуру удалить.


    2. Не знаю, фиолетово линуксу (тот который на дримбоксе) или нет, но чтение и запись конф.файла на MV было неверным, пока не поставил "rb". Так что....


    Да и вообще - я понимаю, что опенсорс есть опенсорс и на какие то шаги влево-вправо он не рассчитан. Чуть ситуация меняется нестандартно и все начинает разваливаться. Так что писать наверное стоит чисто, а не надеясь на то, что это не вылезет нигде боком.

    Цитата

    По словам пользователя axstone ...


    А не пробовал вместо Virtual PC использовать VMware? AFAIK, там виртуальной машине можно дать IP адрес из подсети хардверного сетевого адаптера, т.е. можно использовать полноценные NFS/FTP/etc сервера.



    Интересная мысль - попробую обязательно!

    Цитата

    По словам пользователя AlexXF ...
    1. Ага, вот то-то плагин падал как сумасшедший, когда он пытался "безобидный" пойнтер на несуществующую структуру удалить.


    2. Не знаю, фиолетово линуксу (тот который на дримбоксе) или нет, но чтение и запись конф.файла на MV было неверным, пока не поставил "rb". Так что....


    Все это смахивает на оффтопик, конечно, но... :)
    1.

    Исходный код
    int main()
{
    int* p = 0;
    delete p;
    return 0;
}


    Ничего не падает и не должно.


    2. man fopen
    По своему опыту знаю - в юниксе наличие "b" по барабану. Неужели в glibc для PPC учитываются 0x0D в концах строк? Сомнительно это. Видно где-то в другом месте собака порылась.

    Цитата

    По словам пользователя axstone ...

    Исходный код
    int main()
{
    int* p = 0;
    delete p;
    return 0;
}


    Ничего не падает и не должно.


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


    2. А когда делается так:


    somestruct* p;
    delete p;


    тогда все рушится на раз-два...


    Цитата


    2. man fopen
    По своему опыту знаю - в юниксе наличие "b" по барабану. Неужели в glibc для PPC учитываются 0x0D в концах строк? Сомнительно это. Видно где-то в другом месте собака порылась.


    Вряд ли... изучая исходник могу сказать - там было все очень просто - открыть файл, скинуть данные, закрыть... И наоборот. Так вот - читалась полная лажа в случае простого 'r'. Так что наверное все же отличаются. Но в любом случае - неужели сложно следовать простым правилам кроссплатформенности? Сказано, что для Binary использовать флаг b, значит НАДО ЕГО использовать.


    PS. Ладно, оффтоп... :)

    Цитата

    По словам пользователя AlexXF ...
    1. Вроде бы правильно, но так делать нельзя - указателю память не выделена, откуда он знает, чего ему надо удалять... В данном случае произойдет утеря 4х байт.


    По моему вы неправы. С чего это произойдет потеря 4х байт? Указателю память выделенна в стеке. Но ссылается указатель на 0. И я уверен на 99.9% что любой менеджер памяти перед удалением указателя проверит его на 0,так что в данном случае оператор delete сам проверит указатель на 0 и ничего страшного не будет.
    Скорее всего указанная вами ошибка в первоначальном посте связанна с тем что указатель не обнулялся и удалялся еще раз.
    Хотя я полностью согласен что лучше на 0 проверять самому и я сам всегда так делаю.

    Цитата


    2. А когда делается так:
    somestruct* p;
    delete p;


    Конечно он упадет, потому что p НЕ ИНИЦИАЛИЗИРОВАН и НЕ РАВЕН 0.
    Дмитрий

    открытие файла в режиме binary *ВЛИЯЕТ* поскольку помимо \r\n=>\n имеются также другие условности: конец файла (^D, ^Z). Еще я не совсем уверен, но, по-моему там еще возможна вертикальная табуляция, и могут быть какие-нибудь Esc-последовательности.


    А удаление незаведенного - это еще как повезет, может рухнуть, а может и нет, зависит от версии и вообще, каждый компилятор ведет себя как ему вздумается.
    IMHO может пойти прерывание, а может не пойти. Оно может быть фатальным, а может быть проигнорированным. То есть, чтобы сказать с уверенностью, надо узнать, с какими параметрами компилировался кросс-компилятор GCC.

    Цитата

    По словам пользователя vkonovalov ...
    А удаление незаведенного - это еще как повезет, может рухнуть, а может и нет, зависит от версии и вообще, каждый компилятор ведет себя как ему вздумается.
    IMHO может пойти прерывание, а может не пойти. Оно может быть фатальным, а может быть проигнорированным. То есть, чтобы сказать с уверенностью, надо узнать, с какими параметрами компилировался кросс-компилятор GCC.


    Еще раз повторяю...не надо путать НУЛЕВОЙ указатель и НЕИНИЦИАЛИЗИРОВАННЫЙ/СОДЕРЖАЩИЙ МУСОР...Это два СОВЕРШЕННО разные ситуации. В первом, случае это не критично т.к. это легко отсекает менеджер памяти, а вот как раз второй приводит к ошибкам. И я вообще не понимаю о чем мы спорим? Просто AlexXF сделав ПРАВИЛЬНЫЕ модификации в плагине (обнуление указателя при удалении), сделал ОШИБОЧНЫЕ выводы (необходимость проверки на 0). Вот и все.


    Дмитрий