Добавление поддержки Windows в проект POSIX ... Как больно? Стоит ли усилий?

Question

Я пытаюсь / думаю сделать CppCMS - проект C ++ Web Framework немного более кроссплатформенным.

Сегодня я могу легко поддерживать Linux, OpenSolaris, FreeBSD и даже Cygwin. Но когда дело доходит до Native Windows, становится очень больно:

Обзор ситуации:

1. Я являюсь разработчиком POSIX / Linux и почти не знаком с инструментами разработки для Windows, такими как Visual Studio и Win32 API. Однако я работаю над этой платформой, чтобы понять ограничения и тот факт, что Windows - это совершенно другой мир.

2. Это веб-проект, использующий API, популярные в мире Unix, такие как: CGI, FastCGI и SCGI, которые реализованы на большинстве веб-серверов UNIX; но я понимаю, что не смогу использовать его с IIS, поскольку он не поддерживает FastCGI через TCP / IP (только каналы Windows).

   Так что, даже когда он будет работать, он, вероятно, будет работать только с портом Windows Apache.

3. Я активно использую POSIX API:

   • Предварительная разветвленность позволяет поддерживать высокую живучесть в случае сбоя (не поддерживается под Windows), поэтому эта функция будет отсутствовать.
   • Я использую некоторые средства блокировки файлов (но, вероятно, могу отказаться от них, не разветвляясь)
   • Я интенсивно использую нативные потоки, даже могу заменить их на Boost.Thread
4. Я, вероятно, никогда не смогу поддерживать Visual Studio (возможно, 2010 с поддержкой C ++ 0x), потому что я использую функцию decltype / auto в C ++ 0x или расширение typeof / __ typeof__, которое поддерживается большинством компиляторов, с которыми я работал : gcc, intel, sun studio. (Если честно: я могу работать без них, но это значительно облегчает жизнь пользователю фреймворка.
5. Я активно работаю с автоинструментами и не могу заменить их на CMake, bjam или друзей, потому что когда дело доходит до поддержки интернационализации, кросс-копирования, управления пакетами, они просто не дают мне решение.
6. Есть много раздражающих моментов, таких как отсутствие gmtime_r или localtime_r под окнами и многие другие, которые просто требуют от меня переписать их или заменить на библиотеки 3-й части.
7. По-прежнему существует множество библиотек типа UNIX, которые портированы на Win32, таких как: iconv, gcrypt и некоторые другие, которые едва портированы, как libdbi, которые имеют много ограничений для окон.

Итог:

Есть много нетривиальной работы, и даже когда она будет завершена, она, вероятно, будет работать только с инструментами MingW, а не с инструментами " native ", которые используются программистами Windows. знакомы с.

Итак, мои вопросы:

• Стоит ли использовать такой порт MingW? Поможет ли это построить большее сообщество?
• Кто-нибудь знает, насколько болезненно переносить большие проекты из среды POSIX в Win32 API есть?
• Будет ли это вообще полезно для разработчиков Windows?

Edit:

Мне также важно понять, сколько разработчиков Windows предпочитают использовать Средства разработки с открытым исходным кодом, MingW над решениями Microsoft для разработки, такими как VS.

Редактировать # 2: Разъяснение "родных" решений Windows и IIS.

На самом деле, запуск фреймворка с IIS - действительно сложная проблема. Я объясняю:

• Проект относится к стандартному API веб-сервера как FastCGI или SCGI , что позволяет принимать множество запросов через сокет sinlge. Таким образом, на стороне приложения, я принимаю новый запрос, продолжаю его и возвращает ответ. Иногда несколько потоков обрабатывают несколько запросов.

  Таким образом, реализуя один или два стандартных протокола , я открываю связь с любым существующим сервером: Apache, lighttpd, nginx, cherokee ... или любыми другими серверами; за небольшим исключением IIS

• В IIS есть реализация FastCGI, но ... Он поддерживает только 1 соединение на локальный процесс только то, что контролируется веб-сервером ...

Итак ... нет абсолютно никакого стандартного способа подключения моего приложения к IIS.

Обратите внимание, я реализую стандартный API веб-сервера, я не реализую ни проприетарный ISAPI IIS, ни проприетарный API Apache, даже второй более важен для ориентации на мир UNIX.

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

Answer 1

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

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

Answer 2

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

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

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

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

Answer 3

• Стоит ли использовать такой порт MingW? Поможет ли это построить большее сообщество?

Я все еще работаю над этой проблемой с моим собственным большим проектом POSIX, и я пришел к выводу, что если вам потребуется позднее взаимодействовать с продуктами Microsoft, то это того стоит, однако тогда я буду использовать MingW только в том случае, если проект среднего размера, если он очень большой, то я бы прошел весь путь с инструментами разработки MSDN Microsoft - там будет доступно огромное количество помощи - однако это будет стоить

• Кто-нибудь знает, насколько болезненным является перенос больших проектов из среды POSIX в Win32 API?

мягко говоря, мое собственное преобразование моего проекта POSIX постоянно откладывалось, потому что количество времени, которое занимает каждая проблема, огромно - еще не закончено преобразование - если я когда-либо буду

• Будет ли это вообще полезно для разработчиков Windows?

Конечно, работа в Microsoft IDE с использованием инструментов из MSDN определенно сократит время разработки, однако увеличит вашу зависимость от библиотек Microsoft - то, что вам нужно с самого начала решить, если это проблема

** На самом деле вы можете просто добавить необходимые библиотеки cygwin в ваши проекты, а затем вы сможете запустить его в Windows

Мне удалось запустить мой проект POSIX, когда я добавил следующие библиотеки

cygboost_filesystem.dll
cygboost_system-mt-1_53.dll
cygboost_thread.dll
cyggcc_s-1.dll
cygstdc++-6.dll
cygwin1.dll

Возможно, ваш проект будет иметь разные зависимости, однако, если вы считаете, что преобразование не стоит, то, возможно, это решение для вас

Вы также можете добавить свои библиотеки как статические, тогда вам придётся только предоставить последний cygwin1.dll

Answer 4

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

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

Answer 5

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