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

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

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

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

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

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

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

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

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

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

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

Я склоняюсь к Windows Presentation Foundation. Я полагаю, что это ответ Microsoft на Cocoa в 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?

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