AsmGuru - вопрос нескромный - а начем оно писано будет?
как минимум требуется удобный интерфейс плагинов + скриптинг ( лучше всего так же со своим интерфейсом - чтоб можно было и perl и python подрубить )
подсветка синтаксиса само собой.
code completion
code templates
project explorer - как минимум как в VC
block collapsing - чтоб можно было свернуть к примеру те же циклы и условные блоки (VS.NET) .
так же были бы не плохи фишки, которые есть в Visual Assist
подключение дебаггера - чтоб в идеале я мог подключить любой дебаггер - это хорошая практика в юнихе - я могу подключить любой дебаггер к debug frontend
подключение компиллеров.
интерфейс удаленной отладки.
все фичи должны быть кастомизируемы через интерфейс плагинов - так и тебе проще писать будет и армия разработчиков выростет.
для начала я думаю этого хватит чтоб озадачить годика на пол.

VC++ 6.0 (no MFC).

Не знаю что такое PERL и PYTHON.
Не знаю что такое 'интерфейс удаленной отладки'.

Plug-In's это простые Win32 DLLs.

Можно подробнее про скриптинг?
Зачем он нужен в IDE?

по поводу скриптинга - да хотя бы для того, чтобы можно было сделать сркипт, который мне выровняет текст как мне нравится - а-ля ident в unix.
по поводу плагинов - эээ тут ты не прав - плагины правильно делать в виде COM объектов а не win32 dll - это общепринятая практика - раз, если я захочу плагин написать на VisualBasic - он не может дллки создавать к примеру.
по поводу удаленной отладки - а это нужно, чтоб я к примеру через используя windbg мог подключиться к машине где запущен remote debugger.
perl,python-языки программирования такие.

Про удаленную отладку буду думать позже.
Не хочется усложнять проект более чем надо.
COM-технология 'потащит' за собой несовместимости для
разных систем Windows.
===
Опять же, зачем нужны языки PERL/PYTHON?
Как они вписываются в архитектуру IDE?

AsmGuru62
На сколько я мог понять Вы хотите написать прогу которая будет иметь БД в, которых соответствующим специфическим инструкциям (например .IF в MASM), не имеющим прямого аналога в Ассемблере, будут сопоставленны инструкции Ассемблера, таким образом можно реализовать компилятор с любого языка простым подключением соответствующей БД, этакий универсальный компилятор, соответсвенно реализовать БД для тех же PERL/PYTHON вполне реально если кто то возьмёт на себя труд написать соответствующую БД.
Я правильно понял Ваш замысел?

это интересно... база примитивов языка...
===
однако, мои мысли были немного не здесь.
Наоборот, .IF, .ELSE и другое будет встречаться
в коде функций, которые мне не хотелось бы трогать.
Наверняка, это ограничит свободу программиста.
===
В БД, я думаю, надо хранить структуры более высокого
уровня: классы, структуры, устройство API.
===
Пример: функция, как монолит, содержит следующее:

1. Имя
2. Список параметров
3. Локальные переменные
4. Возвращаемое значение
5. Код тела функции
6. ... пока не придумал...
===
Таким же способом, можно представить любой елемент проекта.
===
Параметер/переменная:

1. Имя
2. Тип
3. Флаги (Простой тип или класс... <- Intelli-Sense!)
4. Комментарий (Удобство вызова/документирования...)
===
и тому подобное...

COM-технология 'потащит' за собой несовместимости для
разных систем Windows.
какие несовместимости?!?!? несовместимости только в winnt 4.0 without servicepacks - по той причине , что там atl.dll и ole32.dll кривые.
а если ты будешь менять GUIDы интерфейсов - дык это твоя беда. А перед тем, как что-то утверждать насчет COM - могу посоветовать Трельсена почитать.
===
Опять же, зачем нужны языки PERL/PYTHON?
Как они вписываются в архитектуру IDE?
Да скриптинг нужен, а не PERL/PYTHON! Если не понимаешь зачем - очень жаль. Кстати тот же MSVC поддерживает скриптинг на базе VBScript. Я уже не говорю насчет vim и emacs и прочих.


Про удаленную отладку буду думать позже.
Не хочется усложнять проект более чем надо.

да высунь наружу интерфейс и забудь о ней. за тебя все напишут.

Кстати по поводу BD прочего - это уже задача компилятора а не IDE. а насчет компилятора - это уже реализовано - gcc оно называется - там тебе и forth и java и c и c++ . остальное можешь сам дописать -)

>Например, в последнее время стали стандартом меню со значками
...
>Работу Кетила (RadASM) нужно, как минимум уважать - такой проект на асме тянуть не каждый сможет.

Я уважаю, но без "розовых очков". Скажите пользователю MS Word, что интерфейс - это блаж и фигня, и вообще можно работать с командной строки.
О красивом интерфейсе (вообще программ) - пока возишься со значками в меню, стилями контролов, забываешь, зачем пишешь программу, хотя это имеет стандартный функционал и ничего нового здесь не придумаешь - кодовая "шелуха" ;) Здесь IDE должна думать за нас!

rst
Понятно, через скрипт можно добраться до елементов
проекта и начать ими управлять... подумаю... Просто
не хочется убить уйму времени на что-то такое, что
не будет жизненно важным. Мне еще встроенный редактор
ресурсов надо делать - потому что с ним связан 'event handling'
в Win32 и мне хотелось бы упростить такие вещи.

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

Понятно, через скрипт можно добраться до елементов
проекта и начать ими управлять... подумаю... Просто
не хочется убить уйму времени на что-то такое, что
не будет жизненно важным.
Ага. ты это скажи программерам того же vim emacs и т.д. хотя это просто текстовые редакторы.А так же комманде разрабатывающей MSDEV. А так же всем остальным :) Хотя вначале могу посоветовать все-таки набраться немного опыта и изучить хорошо предметную область.

но без "розовых очков"

А где, простите, вы увидели розовые очки? Я, кстати, не пользуюсь и не призываю пользоваться как RadASM, так и чем-либо.

Скажите пользователю MS Word

Вы - пользователь MS Word? А я вообще-то иногда на ассемблере программы пописываю. Почитайте внимательно мой пост, пожалуйста.

AsmGuru62
Редактор ресурсов действительно не нужен. Лучше на другом сосредоточиться. Поддержка плагинов нужна, но на базе dll. Раз уж IDE для ассемблера, нужно учитывать интересы пишущих на ассемблере, а не VB. Скриптинг, кто зачет, с помощью плагина прикрутит.

Раз уж IDE для ассемблера, нужно учитывать интересы пишущих на ассемблере, а не VB. Скриптинг, кто зачет, с помощью плагина прикрутит..
Ну блин. Не согласен ни разу. Мне допустим плагины писать проще на С++ и именно COM плагины а не dll. К тому же сама IDE пишется для асма, но на С. И не факт, что плагины будут писаться на асме - асм используется для другого, а не для написания плагинов.

И не факт, что плагины будут писаться на асме

Если мне по быстрому нужно будет что-то написать - я на асме и напишу. И насчет "общепринятой практики" - к тому же Photoshop-у все плагины идут в виде dll, т.е. за всех расписываться не нужно.

rst
И не факт, что плагины будут писаться на асме - асм используется для другого, а не для написания плагинов.
Данное высказывание не совсем верно. Ассемблер используется для чего угодно: написания плагинов, отладчиков, трекеров, редакторов и т.п. Впрочем, это тема уже обсуждалась многократно.