Кроме того, можно за основу взять PocketPC пакет. Впринципе не пробовал, но нет никаких причин для того, чтобы он не скомпилировался под Windows без каких либо правок вообще.

Таки на свободном компиллере надо и CodeGen (и make_exe) на нем делать.

---

Доктор сказал в морг - значит в морг

У нас и FASM-то не особо двигается, а уж ещё один новый проект... Хотя кто знает, может заинтересованных больше будет...

tsdima, это я как бы забираю назад свое "на fasm-е тренируйся"
Еще есть на чем

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

Но лучше. Тем более, что это не проблематично. Должно быть, по-крайней мере

Кажется вы повторяетесь? господин АдМиН Вот Вас и подловили.

tsdima, тебе может нужна какая-нибудь помощь по fasm. Я не много умею и знаю, но свежая голова на плечах присутствует. Давай помогу чем.

Компоненты нужно писать. Как минимум, можно заняться невизуальными, так как с контролами пока не всё утряслось. И с типами данных и передачей их в потоке не всё ОК. Да и CodeGen ещё далёк от совершенства: трехэтажные макросы - это конечно круто, но вот с кольцеванием ничего не выйдет в таком случае. А копировать дизайн дельфового проекта с его динамическим установлением связей между компонентами - пока не охота.

НУ бу пробовать. Я сантехником работаю, щас отопление пошло. мне счас не до компа. через недельку буду готов. Попробуем, да и дельфя надо найти я так понял. Какой версией пользуешься?

Это кому вопрос?

tsdima, так как ты насчет проекта на GCC

Ну сам подумай...
String и Array - у нас динамические объекты одного типа. Будучи локальными, не требуют "ручного" перехвата исключений и вызова деструкторов (это делает паскаль безусловно, в т.ч. и перехват исключений).
Мы добавляем в свой TData поинтеры на "свои" динамические объекты - начинаем корячиться (причем не до конца чисто - исключений не перехватываем).
Вместо того, чтобы при введении MT честно завести счетчики ссылок, начинаем творить копии... Не вычистивши сохраненные в других элементах "хвосты" на уничтоженные данные
Криво все это
Фактически, нам нужен тип, аналогичный по функциональности встроенным string и array - ан дулю паскаль показывает.
Кладов попытался сделать чего-то похожее - TObj назвал. Так и там усё ручками делать надо...
А в результате, вместо того, чтобы просто увеличивать счетчики ссылок на Control, начинаем прилеплять к нему onDestroy ....

А, по теории, C++ как раз и сделан как инструмент для создания объектов пользователя
И как язык - довольно круто. Не знаю уж про реализации ...

Счетчики ссылок обычно реализуются через специальные классы-указатели, т.е. вместо обычного указателя, там где необходимо хранить (а не временно использовать) указатель на объект, мы используем этот класс. Простейший пример - string. Внутри это просто указатель, при копировании таких объектов увеличивается счётчик в том объекте, на который ссылается указатель. При уничножении - уменьшается, если дошло до нуля - уничножаем и то, куда ссылаемся. А в паскале есть аналоги конструкторов копирования и операторов присваивания? Конструктора копирования вроде нет, вместо него используется конструктор пустого объекта + оператор присваивания. А вот насчёт оператора присваивания я пока не знаю, но вроде можно его перегрузить.
Чтобы не писать для каждого класса свой класс-указатель в С++ есть шаблоны

tsdima,
Это все правильно и красиво. И даже известно
Для дипломатической беседы.
А для конкретной - можно обсуждать тот самый тип TData (в рамках нового проекта) будучи умудренными идеями MT, опытом проекта Дельфи, проблемами необходимости универсального интерфейса. Можно и идеологию разрешения типа ReadXXX функций на этапе компиляции попробовать внедрить.
И все это - не оглядываясь на совместимость с предыдущими кодами.

В общем - наливай, да пей

Если честно, я никогда не использовал GCC, и MinGW для меня тоже пока тёмный лес. В принципе, можно начать разбираться, но апологетом GCC я никогда не являлся Мелкософтовый компилятор теперь тоже свободный (но только лишь компилятор).

Причем тут использовал или нет? С++ компиляторы(в отличие от всех прочих) пишут по существующему стандарту плюс добавка некоторых своих фичей. Поэтому при написание кода на С++ в соответсвие с существующим стандартом он должен компилироваться на любом компиляторе не зависимо от фирмы производителя. Далее, апологетом GCC можно и не являться, но как я уже говорил лучше сразу делать решение наиболее универсальным в том плане, что пакет выполненый под GCC на 100% без изменений(синтаксиса конечно же) может быть перенесен на любую другую платформу, куда он портирован.