Which Windows API do I choose for a rich client application?

I develop rich client software for Mac OS X and Linux. I want to transfer the application to Windows and I am not a user of Microsoft products, I am not very familiar with Windows in general.

What I know:

On Mac OS X, I have the Cocoa and Objective-C option, or Carbon and C / C ++. On Linux, I have the option of GTK + and C / C ++ or Qt and C ++. I prefer Cocoa for Mac OS X and GTK + for Linux. The Builder interface for Cocoa and Glade for GTK + makes my life easy. It is fun to create wealthy clients on these operating systems.

My main classes, or “model” in MVC, are written in cross-platform C ++. The user interface classes or “view and controller” in MVC are written in the “preferred” language and GUI for each respective platform.

C ++ is the language I'm most familiar with. I use Boost libraries extensively. Especially smart pointers, streams, and asio network libraries. For Unicode, Localization, etc. I use International Components for Unicode (ICU).

Question 1. What is the “preferred” language and GUI for the Windows platform that is compatible with my cross-platform model classes?

Question 2: How do I access my cross-platform model classes?

For example, on Mac OS X, I access my model classes through controller classes. Controller classes are implemented in Objective-C ++. Objective-C ++ is a combination of C ++ and Objective-C. Viewing objects "talking to" controller objects in Objective-C, while a controller object "talking" to model objects in C ++.

On Linux, all classes are implemented in C ++.

+6
c ++ windows cross-platform visual-c ++
source share
6 answers

Windows doesn’t actually have a “preferred” language or API; it looks more like a lot of options. Obvious are raw Win32 calls directly to the operating system (it's just C-calls) or a subtle abstraction on top of this (like WTL, the Windows Template Library, which is C ++), or a thicker abstraction (like MFC, also C + +).

Nowadays, Microsoft is pushing pretty hard WPF, but that part of the managed .NET world. You can write C ++ in this so you can port your application, but I expect this to be a significant effort.

Given that you use GTK + or QT on Linux, it would be obvious to study the use of both of them on Windows, since both exist - so you could support almost identical versions of Linux and Windows. They are not a natural choice for a Windows-only application, since they do not come from the Windows world, but given your background, they will make a lot of sense. You may need a little time to customize them to look and feel in the Windows image, but this should be more than offset by the lack of the need to write a whole new level of presentation.

+4
source share

Qt works great with windows. In addition, it is platform independent.

+4
source share

If you can compile your C ++ using the Visual Studio toolchain (rather than gcc or mingw), I would highly recommend that you create .lib and then link it to the C ++ / CLI assembly, where you find the managed API in your the library.

You can then use the C # API and WinForms or WPF and have an extremely rich and native window viewer application. This work is quite simple, and if you want to rewrite the GUI, it will have the best result and will be the easiest to deploy.

One warning - if you want it to work on machines where .NET may be absent - if so, I would stick with .NET 2.0 (and WinForms). You must also install the installer and install it. If you want to install .NET 3.5, if not, go to WPF.

+2
source share

GTK + works great on Windows. If you are already familiar with this, then I would use. Although the performance probably does not match the performance of the embedded Windows UI files, such as MFC, it is good enough if your application is not really performance dependent. One great example of using GTK + for all platforms is Pidgin .

I can’t answer the second question without seeing some code, but I don’t understand why it will be different from your model-view-controller approach on other platforms.

+1
source share

Windows Presentation Foundation (WPF) is Microsoft's new standard for Windows applications. Your C ++ carries over to it, but most people develop C # against it.

+1
source share

I'm leaning towards the Windows Presentation Foundation. I believe Microsoft is responding to Cocoa on Mac OS X because "it aims to unify a number of applications: user interface, 2D and 3D drawing, fixed and responsive documents, advanced typography, vector graphics, bitmap graphics, animation, data binding, audio and video. " It sounds like Cocoa to me :-)

I assume that the implementation will be similar to my Mac OS X implementation:

  • Model: cross-platform C ++ classes
  • Browse: WPF and C #
  • Controller: C ++ / CLI or something else

While on Mac OS X, presentation classes are implemented in Objective-C, while controller classes are implemented in Objective-C ++. Viewing objects "talking to" controller objects in Objective-C, while a controller object "talking" to model objects in C ++.

Is C ++ / CLI on Windows as Objective-C ++ on Mac OS X or are C # classes that I define inaccessible in C ++ / CLI?

What is the “right” or “preferred” way to access C ++ classes from a managed .NET language?

0
source share

All Articles