nedoPC.org

Ну скажем прямо - у очень многих она есть. ДОС - юзают разве что любители экстрима.
А ...никсоиды - это такой отдельный клан или многочисленная секта.

а про маководов что скажешь? их тоже последнее время развелось немерянно...

Да ничего не скажу... не собирался всяких-водов за глаза обсуждать..

Я, собственно, конструктивно интересуюсь - есть в этих системах общий
подход к отрисовке графики средствами API?
Ведь авторы ОСей воровали друг у друга беззастенчиво!...

Должны же быть идентичные функции или обёртки какие?

Ну поточечно отрисовывать в нашем веке прямо претит...

Может какой DIRECT.... общий есть для платформ?

OpenGL есть, но там нету виджетов - только графические примитивы...

Угу.


Так точно. Только с показом локальных переменных иногда проблемы. Даже если отключить всю оптимизацию у SDCC, всё равно отладочная информация иногда не соответствует бинарнику.


Нету у меня фотошопа, приходится реальные вещи делать
Если заинтересовало (хотя оно вряд ли в wine будет работать), скачай emuide.rar с моего сайта (раздел файлы). Только там не всё так очевидно, всё-таки первая попытка. Надо запустить PN и открыть тестовый проект, тогда должно получиться.
F5 - запуск
F9 - поставить бряк
F10 - шаг, не заходя внутрь
F11 - шаг, заходя внутрь (можно использовать для запуска по шагам в главном файле)
После того, как программа отработала, эмулятор надо закрыть.

Я думаю в wine оно не пойдёт...

Кажись, я ещё и рантайм девятой версии забыл приложить. PN с десятой идёт, она в архиве есть. Вобщем - фигня.

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

Планируется MDI или каждое окно отдельно на экране?

Я считаю что удобнее иметь всё внутри большого окна, чтобы не путать окна с другими окнами в системе...

Хочется MDI, но с возможностью прицеплять любое окно как док-панель, с закладками.

А у меня такой вопрос: рассматривался ли вариант с gdb remote target как вариант? На этом пути, конечно, просматриваются достаточно неприятные проблемы, например мне совершенно неизвестно, насколько сложно (и возможно ли) связать gdb фронтенд с эмулятором процессора, с которым незнаком gdb. И вероятно это непросто, по-моему, gdb не имеет собственного декодера машкода, использует для этого libbfd, а libbfd -- это какая-то абстракция над абстрактной платформой. Точнее я не могу описать -- на libbfd любовался лишь мельком и давно.

Но, проблемы проблемами, а ведь наряду с ними просматриваются и блестящие перспективы, типа цепляния в качестве gdb фронтенда какой-нибудь штуки типа той же IDA Pro. Да если и штуку попроще (и подешевле) брать, то как минимум не надо никакой возни с созданием IDE, поскольку симулятор будет вполне совместим с любым IDE, который умеет отлаживать gdb'шный remote target. В конечном итоге, можно и свой gdb-фронтенд написать: я разглядывал как это делается, там ничего особо сложного нету. При таком подходе, с одной стороны получится, вроде как, что всё равно всё писать придётся самостоятельно (особенно если ещё потребуется в libbfd загонять определение процессора), но зато выйдет модульная структура программулины: вместо единой и монолитной софтины, получится набор отдельных и заменяемых кубиков, из которых складывается программа.

В общем это я к тому распинаюсь, что мне кажется вопрос я придумал весьма здравый. =)
И прежде чем изобретать велосипеды, стоит обрести хотя бы примерное понимание того, почему gdb remote target -- это не вариант.

Shaos сказал же - легче написать всё сначала, чем разбираться в чужом коде.

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

А почему этот автор напортачил вот так? Хмммм... Блин, да он - лох! Он не знал
вот этого и вот этого... Мы так делать не будем!

Но это больше - эмоции...

Как-то странно выглядит юзать gdb чтобы отлаживать виртуальную машину на этом же компе...


Ну я сказал не совсем так



т.е. лучше писать своё, чем лазить дебаггером по чужому коду БЕЗ исходников (что очень любит практиковать Lavr), а ежели существует опенсорцная хорошая программка в тему, то можно и поизучать

Но и тем не менее такие штуки как bochs и qemu так умеют. И по-моему никак иначе они и не умеют. А dosbox так не умеет и имеет свой собственный встроенный дебуггер, и честно говоря я до сих пор не могу до конца понять как им пользоваться. Всё не собраться найти мануал и почитать его последовательно, от начала к концу, а не от содержания к нужному абзацу.

Моё понимание ситуации с удалённой отладкой таково. Есть некий удалённый процесс, слушающий сокет. К процессу коннектится фронтенд и переводит движения мышки пользователя в команды gdb-шного протокола. При этом возможна более сложная конфигурация: фронтенд запускает локальный gdb, который уже коннектится к удалённому gdb (или к процессу изображающему из себя удалённый gdb). Такое полезно тем, что этот "локальный" gdb может ещё заниматься всякой отладочной инфой: переводить адреса в имена и в номера строк и обратно. То есть фронтенду не надо даже примерно представлять себе в каких-таких разных форматах может хранится отладочная информация к бинарю.

IDA Pro, допустим, не использует "локального" gdb, IDA коннектится непосредственно к удалённой цели -- но это и понятно, IDA, в некотором смысле -- это генератор отсутствующей в исполняемом файле отладочной информации, и ей не нужена помощь какого-то-там gdb. emacs же напротив, каким бы образом я не отлаживал, требует локального процесса gdb форкнутого из emacs'а -- и это опять же понятно: emacs ни в зуб ногой не понимает что такое исполняемый файл, формат ELF, отладочная информация и тп. emacs работает лишь с сорцами и номерами строк в них.