Is it feasible to convert a desktop based MFC C++ application to a web app

Question

I have a very large app, 1.5 million lines of C++, which is currently MFC based using the Document/View architecture. The application includes a lot of 3d vector graphics, spreadsheets, and very many dialogs and Windows. Within the constraints of the DVA it is fairly well written, in that there is no significant program logic in the user interface, and anything that can be done using the user interface can also be carried out programmatically using a COM/OLE Automation interface.

At the request of a number of users, I have been toying with the idea of creating a browser interface to the program, where the program itself runs on a server. Thoughts so far are convert all the COM interfaces to DCOM and rewrite/port the UI to Java. Initial experimentation shows that this will be a huge amount of work.

Anyone else out there got any ideas for an easier implmentation? Anyone come across any refactoring or similar tools specifically to help this kind of a port?

Answer 1

It would be a significant amount of work, but you've already done the good design so you're halfway there already!

I would start by moving your MFC UI into a separate executable, and using it to drive the back-end code. Once you've done that (which should be relatively easy as you're just repackaging existing code) then you will get a much better idea of whether it'll be able to handle several users connecting to a single back-end server.

Once you've got that fixed up, you can see all the areas where you need to implement the connectivity to the back-end, and you can start to re-write the UI in any language or platform you like.

For a web interface, I would write webserver code that interacted with your back-end server. This way you get a much easier coupling, and you have much less security and connectivity issues to worry about. I always think the webserver+browser is the presentation layer in an n-tier app.

As for web technologies, you could use flex, activex, silverlight, or possible jquery/jsext to get the rich content into the browser.

Answer 2

The short answer is that it is feasible, don't use java, and that it will be a considerable amount of work.

A good few years ago (around the time of IE5) I was asked by a client to answer a similar question to this one. The application in question was a well structured three tier desktop application.

The upshot of the study was that it is possible. The options considered were Java, and CGI, using either CORBA or COM/DCOM. Building a Java applet was considered, but ruled out because it wouldn't have been too different to the C++ desktop version.

The approach taken was to take the backend tier and turn that into a server application sitting behind a cgi layer. The UI was largely re-written using what we now know as Ajax, i.e. Javascript and HTML. The UI was split between browser elements and server elements.

I did consider writing a tool to convert documents, views and dialogs and wrapping these into a compatible format, however after much analysis it became obvious that it wasn't really feasible to do this because the MFC is actually quite closely coupled to the Win32 API, and itself. Depending on the amount of dialogs it may be worth writing something to convert these.

I did find, that even in a well structured system that a fair bit of code that should have been in the backend had leaked into the front end.

If I were to do the same thing now, there are some excellent javascript libraries that would help, but I'd still take the same approach of doing as much as possible in the browser using Ajax, with possibly something like qooxdoo or YUI. I'd also probably move look at using XUL and moving at least most of the dialogs into the backend.

The only thing that concerns me from your list of requirements is the 3d vector graphics, although there maybe some mileage in this JS toy or JS3D.

This is only a brief summary, as I'm trying to avoid writing a dissertation.

Answer 3

Hi,

Before considering to convert the MFC application to a web application, I suggest you to read "Avoiding The Uncanny Valley of User Interface" from Jeff Atwood.

If you're considering or actively building Ajax/RIA applications, you should consider the Uncanny Valley of user interface design. When you build a "desktop in the web browser"-style application, you're violating users' unwritten expectations of how a web application should look and behave. This choice may have significant negative impact on learnability, pleasantness of use, and adoption.

I don't know what your application looks like and how well "web portable" it is, but maybe doing an exact copy of the application for the web isn't the best choice.

Answer 4

It has been a few years ago since I played around with this, but I did once try taking a small application and compiling it as an active X component which could then be easily used in a web page. (This app was based on a form created with Borland C++ Builder so it was fairly trivial to make it an active X component. I couldn't judge how difficult it would be to wrap your MFC D/V app up as an Active X component).

It was necessary to register the active X component on the user machine (also fairly trivial, but you had to reregister each new version of the component -- I felt like I was filling up the registry) and nowdays Internet Explorer throws up warnings with web pages using activeX so it would require the user lowering the security level in I.E. to keep it from complaining.

Answer 5

Yes, we have done this with a large (Borland) C++ application that could best described as having a 'big ball of mud' architecture.

You do have some interesting issues ahead, but we made a very 'webby' and attractive front-end (prototype is in ASP.NET but could be anything including Java) that largely just fires events in the desktop app running on the server, then displays the resulting graphics, tables and text. We are flexible on how something like graphs are displayed - as .PNG, flash objects or .SVG depending on the browser

Works surprisingly well and only took a few programmer months to implement once we had a model sorted out (design was an issue).

At the moment, we have only implemented a useful sub-set of the entire desktop application, but as we continue, the back-end will separate more cleanly from the front end (and reduce in size). If you have some good separation between GUI and back-end already then that is a big advantage.

We also looked at a largely automatic production of the web-interface from the application, but decided at design stage it was going to look too much like a Windows32 application running in a browser window....