Здравствуйте, _NN_, Вы писали:
_NN>Какая итоговая цель ?
Ну, чисто технически, получить портер для MFC-приложений было бы неплохо. Есть куча легаси, которая вроде еще и хочет жить, но с наступлением суверенного астралинукса может попроситься на выход. И вот какое-то предприятие, которое пользует MFC-приложение, вдруг, решает выделить кучу денег на написание "такого же, но суверенного". А тут мы такие, раз-два, и портировали старое. Все довольны. Другое дело, что задача эта ох как нетривиальна. Особенно по части ресурсов приложения и всяких MS-специфик хаков, которыми полон MFC.

Здравствуйте, Went, Вы писали:

W>Ну, чисто технически, получить портер для MFC-приложений было бы неплохо. Есть куча легаси, которая вроде еще и хочет жить, но с наступлением суверенного астралинукса может попроситься на выход. И вот какое-то предприятие, которое пользует MFC-приложение, вдруг, решает выделить кучу денег на написание "такого же, но суверенного". А тут мы такие, раз-два, и портировали старое. Все довольны. Другое дело, что задача эта ох как нетривиальна. Особенно по части ресурсов приложения и всяких MS-специфик хаков, которыми полон MFC.

Запускайте через Wine.

А вообще, простые приложения быстрее на Qt переписать, чем сделать порт MFC под Linux.

Здравствуйте, SаNNy, Вы писали:

SNN>Запускайте через Wine.
На Wine денег не заработаешь

SNN>А вообще, простые приложения быстрее на Qt переписать, чем сделать порт MFC под Linux.
Ну, тут зависит от размера плеча. А 100 приложений? А непростых? Другое дело, что практически любое MFC-приложение имеет "WinAPI-вставки". Что бы не говорили выше, а MFC — действительно "тонкая" прослойка над WinAPI, и работать с ним серьезно без прямых обращений к оному просто нереально. Отсюда, выходит, что для реализации реально работающего порта, нужно будет не сколько MFC портировать, сколько весь WinAPI, а MFC потом просто поверх из исходников сам соберётся

Здравствуйте, Went, Вы писали:

W>Ну, тут зависит от размера плеча. А 100 приложений? А непростых? Другое дело, что практически любое MFC-приложение имеет "WinAPI-вставки". Что бы не говорили выше, а MFC — действительно "тонкая" прослойка над WinAPI, и работать с ним серьезно без прямых обращений к оному просто нереально. Отсюда, выходит, что для реализации реально работающего порта, нужно будет не сколько MFC портировать, сколько весь WinAPI, а MFC потом просто поверх из исходников сам соберётся

Делать аналог Wine? Боюсь спонсоров на это не найдешь...

Здравствуйте, qaz77, Вы писали:

Q>Здравствуйте, Александр, Вы писали:

А>>Имелось ввиду, такие примитивы, как CArray, CString, СMap, COleVariant etc.

Q>Строки и контейнеры в MFC — шаблонные классы.
Q>Можно просто взять соответствующие заголовки и с ними компилировать зависимый код.
Q>Зачем заменять реализацию этих контейнеров на реализацию через STL?

Q>С вариантом посложнее будет, т.к. COleVariant — обертка над виндовым VARIANT и пачкой функций API.

Q>Или я не правильно понял задачу?
Q>Может, наоборот, существующий код хочется переписать на контейнеры и строки STL?
Q>Тогда сложность зависит от объема и навороченности кода.

Q>Например, у CString и std::basic_string весьма отличается интерфейс, как и у контейнеров.
Q>Такая переделка может вылиться в полное переписывание кода.

Коллеги, всем спасибо, особенно, qaz77
Задача была в том, что есть много текста на MFC, который надо переписать на Linux.

Здравствуйте, Went, Вы писали:

W>Здравствуйте, SаNNy, Вы писали:

SNN>>Запускайте через Wine.
W>На Wine денег не заработаешь

SNN>>А вообще, простые приложения быстрее на Qt переписать, чем сделать порт MFC под Linux.
W>Ну, тут зависит от размера плеча. А 100 приложений? А непростых? Другое дело, что практически любое MFC-приложение имеет "WinAPI-вставки". Что бы не говорили выше, а MFC — действительно "тонкая" прослойка над WinAPI, и работать с ним серьезно без прямых обращений к оному просто нереально. Отсюда, выходит, что для реализации реально работающего порта, нужно будет не сколько MFC портировать, сколько весь WinAPI, а MFC потом просто поверх из исходников сам соберётся

Раз на раз не приходится.
Простые приложения в Wine вполне себе хорошо работают.
Тут надо запускать и смотреть, что будет дешевле.

Здравствуйте, Went, Вы писали:

W>Что бы не говорили выше, а MFC — действительно "тонкая" прослойка над WinAPI, и работать с ним серьезно без прямых обращений к оному просто нереально.

Не надо путать тяжёлую форму зависимости и обёртку. Без WinAPI про MFC лучше забыть — это правда. Из чего совершенно не следует, что она прослойка. Реализация MVC на документах, какой бы простой она не была, это нечто принципиально новое. Было бы нечто подобное сделано в дотнете — он бы выстрелил в мире офисных приложений гораздо сильнее. И сами приложения были бы лучше и проще.