Skip to main content
gamedev.net
🔒 Locked

Should I port an old win32 tool to .NET?

Started by nukomod Jun 26, 2009 at 5:22 AM 7 replies 2.2k views
Original Post
nukomod
nukomod
We have an old tool that we use daily, but the programmer who originally wrote it has now left. Myself and a couple of others have worked in the tool for a long time. We have fixed bugs, added new features and generally gotten to know our way around. The problem though is the GUI. Think Lotus Notes but worse ;p The tool is generally renowned for having a bad interface and we'd like very much to give it an overhaul. Inside it's all raw win32 code (not sure if that's the right name for it!) and a whole load of macros the guy who wrote the tool has provided. He worked this way for years so he's a natural but I've only had minimal experience working with windows GUIs this way. I've used wxWidgets, didn't like that much, and now I write ALL of my new tools in c# and .NET. Basically I was thinking of moving the whole tool over to a managed c++ project so I could rework the GUI to use the .NET framework. I believe I could mark all the existing code as 'native' so I don't need to do any big rewrites of the internals. I was hoping to get some opinions from the experts on this! Does anyone have any alternative suggestions or tips?
feal87
feal87
I personally discourage to port a native project to .NET with Managed C++ reusing the same code. You will only get a big headache and get little or no profit from the managed approach.
It is way better to start anew if you have the time/resources.
nukomod
nukomod
The tool is very big and we have tight time constraints, which is why I was considering this approach. I would love to rewrite the tool but we just don't have the time :(

What are the big headaches you think I'm likely to encounter moving over to a .NET project?

Also my ultimate goal is really only to overhaul the GUI side of the tool. If anyone knows of an easier or better alternative than moving over to the .NET framework then please let me know.
feal87
feal87
Quote:
Original post by nukomod
The tool is very big and we have tight time constraints, which is why I was considering this approach. I would love to rewrite the tool but we just don't have the time :(

What are the big headaches you think I'm likely to encounter moving over to a .NET project?

Also my ultimate goal is really only to overhaul the GUI side of the tool. If anyone knows of an easier or better alternative than moving over to the .NET framework then please let me know.


The headache you will get are to handle trasformation between managed types and native types, all the new syntax you'll have to learn (Managed C++ added quite a lot keywords and functionality) etc...
If you want to reuse the same c++ code, the better idea is using something like wxWidgets or QT, they are pretty easy to use and you don't have to care learning new things or trying to patch up two different approach to programming.
But hey, if you want to use Managed C++ it is possible to use it, it is your call. :D
nukomod
nukomod
I definitely see your point. Hmmm... I don't suppose anyone has taken on the mammoth task of wrapping the .NET forms code in a native C++ lib?

Otherwise like you say wxWidgets or QT look to be the best alternatives.
feal87
feal87
Quote:
Original post by nukomod
I definitely see your point. Hmmm... I don't suppose anyone has taken on the mammoth task of wrapping the .NET forms code in a native C++ lib?

Otherwise like you say wxWidgets or QT look to be the best alternatives.


Maybe you taked me wrong, you can use Windows Forms in Managed C++, but if you (for example) need to transform a List to a std::vector to pass it to your native code, you have to do it manually. Same with ALL the managed type you will use. They all need to be transformed into a native type to use it with your existing code.

Anyway yes, IMHO the better idea is using wxWidgets or QT.
Nik02
Nik02
If the original code properly separates the GUI and core code (that is, follows the model-view-controller pattern), one good option would be leaving the core functionality in C++, add to it managed C++ interfaces for .net, and implement the user interface using WPF or Forms in C# or VB.

In an application that follows the MVC pattern, when the GUI (view) needs some data, it calls the business object's (controller) methods to get that data. The controller asks unprocessed data from the core of the program (model) and then returns the data to the view, filtered and processed by the business logic. This enables separation of concerns, as each tier is cleanly in their own modules and their functionality depend only minimally on each other.
Niko Suni
_the_phantom_
_the_phantom_
Just as a note: when talking about using C++ with .Net FORGET Managed C++.

What you are after is C++/CLI which is the greatly improved way of using C++ with .Net and other CLI languages.

It is no where near as bad as Managed C++ when it comes to keywords added, and while there will be somethings you have to learn, for the most part it is pretty straight forward.
NumberXaero
NumberXaero
Curious, what didnt you like about wxWidgets? I ask because I hated it myself, but now I build all my gui tools etc using widgets and wxFormBuilder and simply modifying the generated code, get things done pretty fast.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.