Comments on: Convert old Borland to new Visual Studio?

Question: Convert old Borland to new Visual Studio?

jozxyqk — Mon, 28 Apr 2008 07:35:17 -0800

CompilerFilter: I've got an old project that was written with Borland C++ 5.0 for Windows. I've been tasked with porting this project to Visual Studio 2005. Easy way to do this? It's a fairly simple old program, but we don't want to be dragging around old compilers anymore, and we're finally going to be working on improvements for it. Obviously, just trying to load the "workspace file" doesn't work, and I'm not that knowledgeable about the differences between Borland and Microsoft's C-plus-pluses.
If I could find a way to load the project into VS2005, even if it spits out a million compiler errors, that would be a start.
Is there any way to do it?

By: samj

samj — Mon, 28 Apr 2008 08:48:36 -0800

Wow that takes me back. Your only chance of this working really easily is if it is a plain Win32 project - just create a new win32 application in VS2005 (checking the option for an empty project), add all your source files, and compile. It's unlikely to be that easy, but you never know.

However, you may find it is based on C++ library called OWL that used to ship with Borland compilers (types like TWindow and TButton will Tfeature Theavily). There is a version of OWL called OWLNext that claims to work with modern compilers, so I guess you would have to make a decision about whether to try and use that or update the code to something more recent.

Good luck!

By: tomcooke

tomcooke — Mon, 28 Apr 2008 09:31:45 -0800

I would suggest starting off by creating a simple command-line test harness for the existing back end classes (hopefully they are well separated from the existing UI!), and then building a new UI in Visual Studio once you've managed to get that to work. If you're going to be responsible for this program, you'll need to understand the underlying data structures and algorithms anyway and getting the back end working first would be a good way to get going with that. Plus you'll have a basis for doing automated testing of any changes you make to the data handling classes later on.

Simple dialog-based UIs are really fast to produce and I think doing things the standard way for the development environment you're moving to would probably be a better option than jumping through hoops trying to get your old OWL code to work.