помогите выбрать средство разработки проекта

[Zerg1]

Делается клиент-серверное приложение.
Серверная часть будет работать на выделенном сервере в интере (на постоянном ip) и просто через порты по UDP обменивается пакетами с клиентами через Интернет. Сервер представляется собой чистую консольную прогу на вижуал cpp 5.0 (ессно многопоточную, версия компилятора конечно старая, но меня вполне устраивает, работает - и зашибись). Серверная часть уже процентов на 70 написана. В программе довольно сложные алгоритмы и много сложных данных (в основном это большущие классы объектов). То что программа консольная и написана фактически на чистом cpp – позволяет надеяться на её переносимость и под какой-нибудь линуксойдный сервак, но пока не знаю, понадобится ли это.
С клиентом хуже. Как собственно программа он ещё не зачат, однако он должен использовать некоторое подмножество классов и функций из серверной части, плюс конечно собственная начинка. Некоторые оригинальные изолированные модули клиента уже написаны и отлажены на том же cpp (в командной строке, поскольку собссно пользовательский интерфейс ещё не программировался). Собссно пользователи будут скачивать в интере клиент и потом работать с сервером через интер. Интерфейс клиента будет не то чтобы очень сложным (никаких особых извращённых контролов, всё стандартное, приложение не мультидоковое, а обычное dialog based), однако достаточно объёмным. Десятки форм, некоторые очень большие, со вкладками и т.д. Графики никакой нет, кроме элементарного показа бмп в соответсвующих контролах.
Объём дистрибутива клиента не должен превышать 4 метров, а работать должен даже на 98х. Причём я не могу потребовать от пользователя скачивание всяких дополнительных 30 метровых рантаймов. Клиент должен работать на самой обычной (вплоть до 98й) голой стандартной винде.
ВОПРОС! На чём делать клиента?!
Пока я рассматриваю со своей, в силу чайниковости, конечно, невысокой колокольни, следующих кандидатов:
ВИЖУАЛ ВАСЯ.
Плюсы:
Потрясающая детскость в лабании интерфейса. Я просто влюблён в эту простоту и непосредственность. Такой простоты я нигде пока не видел.
Минусы:
Там где кончается интерфейс и начинаются алгоритмы, Вася сразу сдувается как проколотый шарик. Да и основная логика программы УЖЕ написана на cpp. Следовательно придётся выносить всё накопленное в длл и писать сложную кучу обёрток. Более того, это обёртывание осложняется тем, что на срр не просто изолированные функи (сложить два числа, извлечь корень : )), а работа со сложными данными. Как я понимаю, в длл данные жить не могут (поправьте, если я не прав), следовательно всё надо будет держать в Васе, и извращаться по поводу передачи всего в длл. Короче гимор, но как же прелестно делать интерфейсы на Васе! Кстати, я имел опыт по созданию 2х проектиков (правда там данные были ну очень несложной структуры), когда интерефейс писался на Васе, а основные расчёты делались на консольной плюсовой проге, запускавшейся в скрытом окне. Вася просто рубил потом процесс и всё. А данные в плюсы передавались через файл. Схема, хоть и чистой воды извращение, мне очень понравилась, но масштабируемость у неё, как мне кажется, никакая, а жаль.
MSVCPP.
Плюсы:
Наработанное «до» будет родным и не придётся его мучительно встраивать.
Минусы:
Ненавижу я мфси. А писать такую прогу на АПИ, легче повеситься. Как-то давно писал программу на мфси, обычное single document приложение, так опплевался весь. Ну невозможно локализоваться от всех этих мфсишных какашек. Ну не родная мне программа получилась, не чуйствовал я её до конца. Да и учить мфси серьёзно надо, а не наскоками, а на это нет ни времени, ни желания.
СИ ДИЕЗ.
Плюсы:
Из того что вскользь увидел думаю, что по примитивизму до Васи ему далеко.
Минусы:
Размер дистрибутива опять же, за счёт того, что рантайм тащить за прогой надо. Да и как там заработает уже написанный код, тоже вопрос. В общем на диезе ещё не писал, но покрутив в руках 10 минут, могут сказать – мне там особенно ничего не понравилось.

В общем я не прочь написать интерфейс клиента и на с++, но только не на мфси, подскажите что-нить простое и удобное.

Короче, помогите, а то сроки все уже к позавчера, а пока главное решение так и не принято.

[Amed]

Лично я бы советовал склониться к с++. Сам сейчас пишу (без MFC, с собственными классами) и плююсь местами, т.к. накручено очень плотно и много. Зато клиент и сервер на одном языке - будет меньше гемора со встраиванием.

Насчет дистрибутива < 4 мб. Тут к VB некоторый вопрос: для голой системы надо таскать с собой как минимум msvbvm60.dll (уже около 1,7 мб), а это еще не программа.

Дельфи вообще вне игры?

[Zerg1]

А как без мфси на микротовской студии писать интерфейс? На АПИ? Я слишком люблю себя для такой пытки.
А паскаль я с детства ненавижу, органически _не переношу_, так что сразу отметаем.
Чтобы мне склониться на сипп, надо чтобы среда и её библа были удобьны и просты как вася, а иначе кроме васи ничего нет. Вот и мучаюсь я.

[Zerg1]

Есть два доп вопроса.
1) Посоветуйте дополнительно такую среду/библиотеку, чтобы язык был си/++, а простота создания интерфейсов, как у Васи.
2) Кто имел опыт сопряжения васикововского интрефейса с большим объёмом подпрограмм на с++, как оно, стоит браться, или тухляк? Просьба на личных примерах/опыте.

[alibek]

Си-Билдер.
А что именно в VB не устраивает? На нем многое можно сделать при желании, и даже не прибегая к нестандартным извращениям.

[Andrey Fedorov]

Си-Билдер.
А что именно в VB не устраивает? На нем многое можно сделать при желании, и даже не прибегая к нестандартным извращениям.

IMHO человек просто не работал в этой области с ним...

Идеальным ответом была бы ссылка на какой-то пример, чтобы просто знать с чего начинать...

Я бы для начала сходил на http://planet-source-code.com/vb и поискал там все что касается udp...

[codemaster]

Там где кончается интерфейс и начинаются алгоритмы, Вася сразу сдувается как проколотый шарик. Да и основная логика программы УЖЕ написана на cpp. Следовательно придётся выносить всё накопленное в длл и писать сложную кучу обёрток. Более того, это обёртывание осложняется тем, что на срр не просто изолированные функи (сложить два числа, извлечь корень : )), а работа со сложными данными. Как я понимаю, в длл данные жить не могут (поправьте, если я не прав), .

Напиши User интерфейс на VB все накопленное "заверни" в COM
и будет тебе щастье! ( никакого MFC чистый ATL )

Данные очень неполхо живут в COM ......

[alibek]

Напиши User интерфейс на VB все накопленное "заверни" в COM
и будет тебе щастье! ( никакого MFC чистый ATL )

Кстати, так поступают очень многие фирмы, которые выпускают специфичные железки (hardware). Имеется библиотека, работающая с оборудованием, и прога, написанная на VB, которая с ней взаимодействует.

[Antonariy]

Напиши тонкого клиента, интерфейс и интерфейсную логику на html, и храни шаблоны там же на сервере. Клиент, если на тех же сях, и до мега не дотянет. Дополнительный бонус: никаких гемороев с обновлением клиента - логика в шаблонах на сервере.

[Zerg1]

Большое спасибо за участие и моральную поддержку, начал, всё-таки на VB. Пока просто визуально уточняю вид форм, кодить ещё не начинал. Не знаю правда что получится, но очень-очень надеюсь, что начинать гуй клиента второй раз не придётся, а если и придётся, то - мы идём к вам © одна реклама
Большое спасибо всем за участие и поддержку!
2Antonariy: Насчёт хтмл-варианта могу одно сказать, что вариант интересный, и более того, мной даже не рассматривавшийся вовсе (ввиду ограниченности кругозора )), но квалификации и опыта в этой области - 0, посему в разумные сроки ничего разумного нарОдить не смогу, а рОдить надо срочно и к позавчера. Бонус с обновлением очевиден и вкусен, но думаю, что в моём случае прокатит и традиционный вариант с полным перекачиванием дистрибов новых версий клиента. После отладки это будет не так часто, ну, во всяком случае я, как честный программист-любитель, верю в это .
2AndreyFedorov: В теоретическом плане проблем со связкой Вася+УДП нет, надеюсь, что и на практике это будет не самым трудным местом в клиенте.
2alibek: Насчёт сибилдера - там тоже не всё так просто, изучать его надо. Покрутил я его на днях минут 30 в руках - вобщем сходу его, как и мфси - не возьмёшь (такое уж у меня имхо сложилось).
2codemaster&alibek: А вот с заворачиванием в COM интересно. Спасибо что подвигли меня на расширение собственного кругозора, прочитал массу суровых статей в интере про ком. Но пока понял одно – штука интересная, опять же требующая тренировки на кошках, но в моём конкретном случае бонусов, видимо, не даст. Но обязательно буду иметь ввиду и попробую в других проектах, если там это будет выгодно.
2codemaster&alibek: Спасибо опять, что поддержали меня в моей решимости писать гуй всё же на VB! Но до сих пор пока страшно. Например, с сокетами-шмокетами проблем нет, но, есть такой аспект (один из нескольких, которых я боюсь). Пакет УДП, которыми обмен и идёт с сервером, есть в терминах сервера структура в сишнном понимании. В ней девять полей – отдельные переменные и массивы. При передаче она сжимается моим алгоритмом (у клиента он в длл, написанной на сипп). Так вот, принять в васиковском клиенте я пакет смогу, распаковать его с помощью длл тоже, думаю, сумею. Но вот если я создам в Васе структуру (по типам аналогичную сишному описанию на серверной части), и при вызове в длл процедуры распаковки передам этот адрес в качестве выхода для записи распакованных данных, то будет ли там, в этой васиковской структуре после распаковки то, что я ожидаю увидеть?! Вопрос до слёз простой. Собственно мои метания и есть страх того, что не потону ли я в таких мелочах? Это в си данные «прямо» в памяти хранятся, а как их куролесит Вася, только ему и известно. Ранее я опыта такого тесного взаимодействия Васи с плюснутыми длл не имел, поэтому в двух упомянутых мною ранее маленьких проектах обменивался данными через файлы.

[tyomitch]

то будет ли там, в этой васиковской структуре после распаковки то, что я ожидаю увидеть?! Вопрос до слёз простой. Собственно мои метания и есть страх того, что не потону ли я в таких мелочах? Это в си данные «прямо» в памяти хранятся, а как их куролесит Вася, только ему и известно.

Если в твоём UDT нет строк и объектов (нет?), то всё хранится точно так же, «прямо» в памяти, наиболее очевидным образом. Никаких проблем быть не должно.