我在Mac OS X和Linux上开发了丰富的客户端软件。 我希望将应用程序移植到Windows，而不是微软产品的用户，我对Windows一般不太了解。
我所熟悉的是：
在Mac OS X上，我可以selectCocoa和Objective C或Carbon和C / C ++。 在Linux上，我可以selectGTK +和C / C ++或者Qt和C ++。 我更喜欢Mac OS X上的Cocoa和Linux上的GTK +。 Cocoa和GTK +的Glade界面生成器让我的生活变得简单。 在这些操作系统中创build富客户端很有趣 。
我的核心类，或MVC中的“模型”，是用跨平台的C ++编写的。 MVC中的用户界面类（即“视图和控制器”）是用每种平台的“首选”语言和GUI API编写的。
C ++是我最熟悉的语言。 我广泛使用Boost库。 尤其是智能指针，线程和asionetworking库。 对于Unicode，本地化等，我使用Unicode的国际组件（ICU）。
问题1：与我的跨平台模型类兼容的Windows平台的“首选”语言和GUI API是什么？
问题2：如何访问我的跨平台模型类？
例如，在Mac OS X上，我通过控制器类访问我的模型类。 控制器类在Objective-C ++中实现。 Objective-C ++是C ++和Objective-C的混合体。 在控制器在C ++中对象“对话”模型对象时，查看对象与Objective-C中的控制器对象进行对话。
在Linux上，所有类都以C ++实现。
Windows上并没有真正的“首选”语言和API，更像是很多选择。 显而易见的是原始的Win32调用直接到操作系统（所以真的只是C调用），或者是一个简单的抽象（例如WTL，Windows模板库，它是C ++），或者是一个更厚的抽象C ++）。
微软这些天正在推动WPF，但这是托管的.NET世界的一部分。 你可以在那里编写C ++，所以你可能能够移植你的应用程序，但我认为这将是很大的努力。
考虑到你在Linux上使用GTK +或QT，最明显的就是考虑在Windows上使用这两者，因为两者都可以保持Linux和Windows版本几乎相同。 对于Windows应用程序来说，它们不是自然选择，因为它们不是来自Windows世界，但是考虑到你的背景，它们会很有意义。 您可能需要花一些时间来调整它们以使Windows应用程序的外观和感觉恰到好处，但是由于不需要编写全新的表示层，这应该得到更多的补偿。
Qt可以和windows一起工作。 而且它是平台独立的。
如果你可以用Visual Studio工具链（而不是gcc或mingw）来编译你的C ++，那么我建议你制作一个.lib文件，然后把它连接到一个C /图书馆。
然后，您可以使用C＃和WinForms API或WPF，并有一个非常丰富和本机的Windows应用程序。 这个工作非常简单，如果你愿意重写GUI，它将会有最好的结果，并且是最容易部署的。
一个警告是如果你需要它在.NET可能不存在的机器上工作 – 如果是的话，我会坚持.NET 2.0（和WinForms）。 您还应该让安装程序检测并安装它。 如果你愿意安装.NET 3.5，如果不存在，那么去WPF。
Windows Presentation Foundation（WPF）是适用于Windows的新的Microsoft富可视化应用程序标准。 你的C ++将移植到它，但大多数人开发C＃反对它。
GTK +在Windows上工作得很好。 如果你已经熟悉它，那就是我所用的。 尽管性能可能与本机Windows UI库（如MFC）不相匹配，但除非您的应用程序真正依赖于性能，否则这足够好了。 在所有平台上使用GTK +的一个很好的例子就是Pidgin 。
如果没有看到一些代码，不能真正回答你的第二个问题，但是我不明白为什么它和其他平台上的模型 – 视图 – 控制器方法不同。
我倾向于Windows Presentation Foundation。 我想这是微软在Mac OS X上对Cocoa的回答，“它旨在统一一些应用服务：用户界面，二维和三维绘图，固定和自适应文档，高级版式，矢量图形，光栅图形，动画，数据绑定，音频和视频“。 这听起来像可可对我:-)
我想这个实现和我的Mac OS X实现类似：
而在Mac OS X上，视图类是在Objective-C中实现的，而控制器类是在Objective-C ++中实现的。 在控制器在C ++中对象“对话”模型对象时，查看对象与Objective-C中的控制器对象进行对话。
Windows上的C ++ / CLI与Mac OS X上的Objective-C ++类似，还是我在C ++ / CLI中定义的 C＃类？
什么是从托管的.Net语言访问C ++类的“正确”或“首选”方法？