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

Question

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

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

наш первый шаг в нашем плане состоял в том, чтобы выбрать среду компилятора / dev.

кажется, что наши варианты - MS Visual Studio, Cygwin, mingw / gcc и Windows Services for UNIX (SFU).

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

, поэтому мы решиликомпилятор.

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

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

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

Mingw действительно имеет возможность создавать собственные exe-файлы, ноне хватает поддержки POSIX.

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

Answer 1

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

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

Мы портировали программы UNIX для командной строки и X на Windows, используя CygWin с минимальными трудностями.

Answer 2

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

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

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

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

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

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

Answer 3

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

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