Добавление поддержки Windows к проекту POSIX …, Как болезненный? Действительно ли это стоит усилия?

Вы должны основывать свое решение на спросе пользователей. Просили ли пользователи когда-нибудь использовать фреймворк в Windows? Если да, то объяснили ли они, почему они хотели использовать Windows (например, какие дополнительные ограничения у них были, какой веб-сервер они хотели использовать и т. Д.)?

Обычно пользователи Windows действительно ожидают, что все будет работать так же, как Windows. Это означает поддержку Visual Studio, поддержку IIS, установщик MSI и так далее. Если что-то по-прежнему похоже на Unix, я бы предпочел использовать собственно Unix, а не бороться с наполовину работающим портом.

Это означает поддержку Visual Studio, поддержку IIS, установщик MSI и так далее. Если что-то по-прежнему похоже на Unix, я бы предпочел использовать собственно Unix, а не бороться с наполовину работающим портом.

Это означает поддержку Visual Studio, поддержку IIS, установщик MSI и так далее. Если что-то по-прежнему похоже на Unix, я бы предпочел использовать собственно Unix, а не бороться с наполовину работающим портом.

Как разработчику клиентских приложений для Windows мне как-то больно, что в настоящее время разделение среды разработки по сути состоит из Win32 и всего остального , и что они в основном несовместимы. Вот почему я готовлюсь перейти на MinGW для моих личных проектов приложений Windows и попытаться сделать их кроссплатформенными.

Я бы предложил постепенно переходить к более кроссплатформенным библиотекам, например, как вы предложили, рефакторинг потоков pthread для повышения :: thread, или переход от fork () к многопроцессорности с IPC, возможно, также с использованием средств boost. Дата / время также могут быть обработаны с помощью Boost libs. Что касается поддержки баз данных, то есть

поддержка компилятора Microsoft, я думаю, не так уж и важна, поскольку MinGW обеспечивает достойную среду сборки со всеми поддерживающими ее IDE, Eclipse CDT и Dev-C ++ являются одними из самых популярных. Но если вы собираетесь сделать свой проект совместимым с msvc, убедитесь, что пользователи смогут использовать экспресс-выпуски Visual Studio 2010 (как только они выйдут) - так никому не придется раскошелиться на Visual Studio 2010. (обновите) просто для того, чтобы использовать свой проект, и вам не составит труда потребовать новейшие технологии Microsoft.

Скорее всего, вам не удастся избежать некоторого количества ifdef для кодовой базы размер вашего проекта, но, безусловно, усилия могут окупиться, если не только для получения ценного опыта и расширения сообщества несколькими новыми счастливыми и благодарными участниками.

Ваши слова о том, что вы можете поддерживать Cygwin, довольно легко напомнили мне, что я видел коммерческое программное обеспечение Windows, которое просто включалось в cygwin1.dll для поддержки некоторого исходного кода Unix. Если достаточно добавить cygwin1.dll в программу установки, попробуйте.

Я думаю, вам достаточно взглянуть на вопросы, заданные в SO, чтобы понять, что пользователи MinGW в Windows (к которым я отношусь) составляют меньшинство в сообществе разработчиков - подавляющее большинство разработчиков Windows используют инструменты MS. В любом случае, компилятор - это только половина (или меньше) проблемы - если ваша архитектура зависит от разветвления большого количества процессов, использование MinGW вам не поможет. Мой совет: если вы действительно хотите заниматься кроссплатформенной разработкой:

• посмотрите, как это делает Apache
• , подумайте об использовании библиотек Apache в качестве основы
• не используйте очень новые или специфичные для компилятора языковые функции
• используют многопоточность, а не многопроцессорность