Какой Windows API выбрать для приложения с расширенными возможностями?

Question

Я разрабатываю многофункциональное клиентское программное обеспечение для Mac OS X и Linux. Я хочу портировать приложение на Windows и, не будучи пользователем продуктов Microsoft, я не очень знаком с Windows в целом.

С чем я знаком:

В Mac OS X у меня есть опция Какао и Objective C или Carbon и C / C ++. В Linux у меня есть опция GTK + и C / C ++ или Qt и C ++. Я предпочитаю Какао на Mac OS X и GTK + на Linux. Конструктор интерфейсов для Cocoa и Glade для GTK + облегчит мою жизнь. интересно создавать в этих операционных системах богатых клиентов.

Мои базовые классы, или «модель» в MVC, написаны на кроссплатформенном C ++. Классы пользовательского интерфейса, или «представление и контроллер» в MVC, написаны на «предпочтительном» языке и GUI API для каждой соответствующей платформы.

C ++ - язык, с которым я наиболее знаком. Я широко использую библиотеки Boost. Особенно умные указатели, потоки и сетевые библиотеки asio. Для Unicode, локализации и т. Д. Я использую международные компоненты для Unicode (ICU).

Вопрос 1. Какой «предпочтительный» язык и графический интерфейс API для платформы Windows совместим с моими классами межплатформенных моделей?

Вопрос 2. Как получить доступ к моим кроссплатформенным модельным классам?

Например, в Mac OS X я получаю доступ к своим модельным классам через классы контроллера. Классы контроллера реализованы в Objective-C ++. Objective-C ++ представляет собой смесь C ++ и Objective-C. Просмотр объектов «общаются» с объектами контроллера в Objective-C, в то время как объекты контроллера «общаются» с объектами модели в C ++.

В Linux все классы реализованы на C ++.

Answer 1

Qt отлично работает с windows. Более того, он не зависит от платформы.

Answer 2

На самом деле в Windows нет «предпочтительного» языка и API, больше похоже на множество вариантов. Очевидными являются необработанные вызовы Win32, направленные непосредственно в операционную систему (так на самом деле просто вызовы C), или тонкая абстракция поверх этого (например, WTL, библиотека шаблонов Windows, которая является C ++), или более толстая абстракция (например, MFC, также C ++).

В наши дни Microsoft активно продвигает WPF, но это часть управляемого мира .NET. Вы можете написать C ++ таким образом, чтобы вы могли портировать свое приложение, но я ожидаю, что это потребует значительных усилий.

Учитывая, что вы используете GTK + или QT в Linux, очевидной вещью было бы изучить использование обоих в Windows, так как оба они существуют - таким образом, вы могли бы сохранить версии Linux и Windows почти идентичными. Они не являются естественным выбором для приложений только для Windows, так как они не из мира Windows, но, учитывая ваш опыт, они имеют большой смысл. Возможно, вам придется потратить некоторое время на их настройку, чтобы приложение Windows выглядело правильно, но это должно быть более чем компенсировано отсутствием необходимости писать целый новый уровень представления.

Answer 3

Если вы можете заставить ваш C ++ компилироваться с помощью набора инструментов Visual Studio (а не gcc или mingw), я очень рекомендую вам создать .lib и затем связать его в сборку C ++ / CLI, где вы предоставляете управляемый API для вашей библиотеки.

Тогда вы можете использовать C # и WinForms API или WPF и иметь чрезвычайно богатое и родное приложение для Windows. Эта работа довольно проста, и если вы захотите переписать графический интерфейс, она будет иметь лучший результат и ее будет легче развернуть.

Одно предостережение: если вам нужно, чтобы оно работало на машинах, на которых может отсутствовать .NET, - если это так, я бы придерживался .NET 2.0 (и WinForms). Вам также нужно, чтобы ваш установщик обнаружил и установил его. Если вы готовы установить .NET 3.5, если ее нет, перейдите на WPF.

Answer 4

Windows Presentation Foundation (WPF) - это новый стандарт приложений Microsoft для Windows. Ваш C ++ будет портировать на него, но большинство людей развивают C # против него.

Answer 5

GTK + отлично работает на Windows. Если вы уже знакомы с этим, это то, что я бы использовал. Хотя производительность, вероятно, не совпадает с производительностью собственных библиотек пользовательского интерфейса Windows, таких как MFC, она достаточно хороша, если только ваше приложение не зависит от производительности пользовательского интерфейса. Один большой пример использования GTK + для всех платформ - Pidgin .

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

Answer 6

Я склоняюсь к Windows Presentation Foundation. Я полагаю, что это ответ Microsoft на Какао на Mac OS X, поскольку «он нацелен на объединение ряда сервисов приложений: пользовательский интерфейс, 2D и 3D рисование, фиксированные и адаптивные документы, расширенная типография, векторная графика, растровая графика, анимация, привязка данных , аудио и видео. " Для меня это звучит как Какао: -)

Полагаю, реализация будет аналогична моей реализации в Mac OS X:

• Модель: кроссплатформенные классы C ++
• Просмотр: WPF и C #
• Контроллер: C ++ / CLI или что-то еще

Принимая во внимание, что в Mac OS X классы представлений реализованы в Objective-C, а классы контроллеров реализованы в Objective-C ++. Просмотр объектов «общаются» с объектами контроллера в Objective-C, в то время как объекты контроллера «общаются» с объектами модели в C ++.

Является ли C ++ / CLI в Windows похожим на Objective-C ++ в Mac OS X или классы C # Я определяю , недоступный в C ++ / CLI?

Каков «правильный» или «предпочтительный» способ доступа к классам C ++ из управляемого языка .Net?