views:

387

answers:

6

I develop rich client software on Mac OS X and Linux. I wish to port an application to Windows and not being a user of Microsoft products, I'm not very familiar with Windows in general.

What I'm familiar with:

On Mac OS X, I have the option of Cocoa and Objective C or Carbon and C/C++. On Linux, I have the option of GTK+ and C/C++ or Qt and C++. I prefer Cocoa on Mac OS X and GTK+ on Linux. Interface Builder for Cocoa and Glade for GTK+ make my life easy. It's fun to create rich clients in these operating systems.

My core classes, or "model" in MVC, is written in cross-platform C++. The user interface classes, or "view and controller" in MVC, is written in the "preferred" language and GUI API for each respective platform.

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

Question 1: What is the "preferred" language and GUI API for the Windows platform that's 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. The controller classes are implemented in Objective-C++. Objective-C++ is a mix of C++ and Objective-C. View objects "talk to" controller objects in Objective-C while the controller objects "talk to" model objects in C++.

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

+1  A: 

GTK+ works just fine on Windows. If you're already familiar with it, that's what I'd use. Although the performance probably does not match that of native Windows UI libs, like MFC, it's good enough unless your application is really ui-performance-dependent. One big example of using GTK+ for all platforms is Pidgin.

Can't really answer your second question without seeing some code, but I don't see why it'd differ from your model-view-controller approach on other platforms.

psoul
right, there's no use in writing windows-only code when you can keep it crossplatform. of course, i'd prefer Qt over GTK+ (no performance overhead, or GUI mistmatch!), but the question mentioned already liking GTK+, so just keep it.
Javier
+1  A: 

Windows Presentation Foundation (WPF) is the new Microsoft rich app standard for Windows. Your C++ will port to it, but most folks develop C# against it.

John Dunagan
+1  A: 

If you can get your C++ to compile with the Visual Studio toolchain (rather than gcc or mingw), I would very much recommend that you make a .lib and then link it into a C++/CLI assembly where you expose a managed API to your library.

Then you can use C# and WinForms API or WPF and have an extremely rich and native windows looking app. This work is pretty straight-forward and if you are willing to rewrite the GUI, it will have the best result and be the easiest to deploy.

One caveat is if you need it to work on machines where .NET might not be present -- if so, I would stick to .NET 2.0 (and WinForms). You should also have your installer detect and install it. If you are willing to install .NET 3.5 if not present, then go for WPF.

Lou Franco
+3  A: 

There isn't really a "preferred" language and API on Windows, more like lots of choices. The obvious ones are raw Win32 calls direct to the operating system (so really just C calls), or a thin abstraction on top of that (e.g. WTL, Windows Template Library, which is C++), or a thicker abstraction (e.g. MFC, also C++).

Microsoft these days are pushing pretty hard WPF, but that's part of the managed .NET world. You can write C++ in that, so you might be able to port your application, but I would expect it would be significant effort.

Given that you're using GTK+ or QT on Linux, the obvious thing would be to look into using both of those on Windows, as both exist - that way you could keep the Linux and Windows versions nearly identical. They're not natual choices for a Windows-only application, as they're not originally from the Windows world, but given your background they would make lots of sense. You might need to put some time into tweaking them to get the Windows application look and feel just right, but that should be more than compensated for by the lack of a need to write a whole new presentation layer.

DavidK
+3  A: 

Qt works fine with windows. Moreover it is platform independent.

Vinay
A: 

I'm leaning towards the Windows Presentation Foundation. I suppose it's Microsoft's answer to Cocoa on Mac OS X insofar as "it aims to unify a number of application services: user interface, 2D and 3D drawing, fixed and adaptive documents, advanced typography, vector graphics, raster graphics, animation, data binding, audio and video." That sounds like Cocoa to me :-)

I suppose the implementation would be similar to my Mac OS X implementation:

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

Whereas, on Mac OS X, view classes are implemented in Objective-C while controller classes are implemented Objective-C++. View objects "talk to" controller objects in Objective-C while the controller objects "talk to" model objects in C++.

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

What is the "correct" or "preferred" way to access C++ classes from a managed .Net language?

GeorgiaRaised85
You'd build the C# view into one assembly and call out to another assembly built in C++/CLI. You could build your cross-platform C++ classes into the C++/CLI assembly in a number of ways, eg by linking the object files as a static native library, or by compiling the source into managed code.
tragomaskhalos