Перенос большого проекта C из Unix в Windows

Перенос большого проекта C из Unix в Windows

23.09.2010 12:28:11 Просмотров 27 Источник

Итак, у меня есть большой проект C, который был полностью построен на Unix (SPARC Solaris). я и еще несколько человек начали его пересматривать, потому что у них был некоторый интерес к сборке windows.

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

первым шагом в нашем плане было решение о компиляторе / среде разработки.

похоже, что наши варианты-это MS Visual Studio, Cygwin, mingw/gcc и Службы Windows для UNIX (SFU).

у нас довольно короткий график, поэтому мы хотим переписать как можно меньше кода.

Итак, выбор компилятора.

Другая проблема заключается в том, что код использует команды потока POSIX (pthread и т. д)

мы бы предпочли компилировать изначально, а не использовать какой-то слой между исполняемым файлом и ОС. к сожалению, с вызовами pthread в нашем коде это может быть невозможно.

Я считаю, что и Cygwin, и SFU делают именно это. В Cygwin есть .dll, которая должна быть включена в скомпилированный код для работы. Я не уверен насчет СФУ, любая информация об этом была бы очень признательна. Похоже, что это был бы хороший вариант, но он был разработан, чтобы позволить компилируемому программному обеспечению UNIX работать на машине windows с SFU, а не на какой-либо старой коробке windows.

у mingw есть возможность создавать собственные exes, но отсутствует поддержка POSIX.

Итак, может ли кто-нибудь дать мне дополнительную информацию, предложения, знания по любому из этих компиляторов в этом контексте. или любой опыт, который они имеют с такого рода вещами, это очень ценится.

У вопроса есть решение - Посмотреть?

https://stackoverflow.com/questions/3773354/porting-a-large-c-project-from-unix-to-windows#comment3994508_3773354
Является ли ваше программное обеспечение GPL-совместимым? Если нет, то Cygwin не является вариантом, потому что если вы используете cygwin1.dll, то вы должны GPL ваш код.
https://stackoverflow.com/questions/3773354/porting-a-large-c-project-from-unix-to-windows#comment3994643_3773354
@Adam, есть отдельная лицензия, которую вы можете получить за это. Вам не нужно идти с открытым исходным кодом (но это будет стоить, конечно).
https://stackoverflow.com/questions/3773354/porting-a-large-c-project-from-unix-to-windows#comment3994676_3773354
@paxdiablo: верно, хорошая мысль.
https://stackoverflow.com/questions/3773354/porting-a-large-c-project-from-unix-to-windows#comment3996095_3773354
С концептуальной точки зрения, чем использование библиотеки типа cygwin отличается от использования библиотеки типа C runtime?
https://stackoverflow.com/questions/3773354/porting-a-large-c-project-from-unix-to-windows#comment3996142_3773354
@caf, это не так уж и отличается, но среда выполнения cygwin требует определенной конфигурации, чтобы она выполняла разумное сопоставление букв дисков с путями POSIX. Это вносит больше трений при перераспределении его, что-то вроде времени выполнения C, которое в случае MinGW можно предположить, что уже установлено правильно.

Ответы - Перенос большого проекта C из Unix в Windows / Porting a large C project from Unix to Windows

paxdiablo

23.09.2010 12:35:26

Короткие сроки? CygWin, просто и ясно.

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

Мы портировали как программы командной строки, так и X-based UNIX на Windows с помощью CygWin с минимальными хлопотами.

Jerry Coffin

23.09.2010 12:45:52

Если код (по крайней мере, в основном) переносим и единственная серьезная проблема заключается в использовании pthreads, вы можете использовать библиотеку Win32 Pthreads. Несмотря на то, что он неполный, он достаточно полный и точный, чтобы иметь дело с большинством кодов pthreads, с которыми я его пробовал. В то время как обычно строится как DLL, он также может быть построен как статическая библиотека, чтобы избежать создания дополнительных зависимостей в исполняемом файле.

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

RBerteig

23.09.2010 12:47:44

Cygwin, вероятно, самый быстрый путь к рабочему исполняемому файлу. Однако это оставит вас с некоторыми интересными вариантами распределения. Скорее всего, сайгвин.dll становится зависимостью. Его лицензируют GPL, если только вы не платите деньги за покупку прав на коммерческое использование.

Cygwin не особенно дружелюбен к обычному пользователю Windows. Его цель состоит в том, чтобы обеспечить полный опыт POSIX на Windows, поставляя оболочку, все знакомые утилиты *nix и даже порт X. Однако он также преобразует имя диска Windows в файловую систему POSIX-подобного типа. Я никогда не пытался распространять приложение, созданное для Cygwin, на машинах, которые еще не имеют полной установки Cygwin. Отмечу, что, насколько мне известно, ни одно из крупных известных приложений с открытым исходным кодом с портами Windows не основано на Cygwin.

Если единственная жесткая зависимость POSIX у вас есть pthreads, то это разрешимо. Существует порт pthreads, построенный на собственных потоках Windows, который хорошо работает с MinGW. IIRC, он даже распространяется вместе с MinGW, или, по крайней мере, является одним из их основных поддерживаемых пакетов.

Если остальная часть вашей обработки имен файлов в основном является непрозрачными строками, вам, возможно, даже не нужно беспокоиться об изменении /на \. API Windows, как правило, с удовольствием рассматривает любой символ в качестве разделителя пути, даже смешанного с одним и тем же именем. Это командный пункт.EXE и раннее соглашение DOS об использовании /для параметров командной строки, которое предотвращает использование /для имен путей в командной строке, а не базового API Windows.

Для инструментов, которые могут облегчить перенос процесса сборки, ознакомьтесь с компонентом MSYS MinGW. Он обеспечивает легкий развилок от среды Cygwin, в которой доступно достаточно утилит *nix для общего запуска ./configureи аналогичные процессы.

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

https://stackoverflow.com/questions/3773354/porting-a-large-c-project-from-unix-to-windows/3773496#comment3996111_3773496
Другая серьезная проблема, с которой вы можете столкнуться при использовании собственного API Windows, заключается в том, что ваш код использует вызов select()для дескрипторов файлов, не являющихся сокетами.
Помочь в развитии проекта:
Закрыть X