Hello,

you could port your MFC layer/code using a product called Wind/U which allows you to port any windows application onto Unix & Linux without altering your source code.

We at S7 are adept at these technologies and this is what we excel at and we do similar services for many customers from US & Europe.

You can find all about this porting at our website

http://www.s7soltions.com

If you need any specific details, please do contact me at,

dilipm@bristolindia.com

Regards, Dilip.M

On Wed, 10 Dec 2003 15:34:10 +0530, Parul.Mathur Parul.Mathur@india.rsystems.com wrote:

Hi,

I am trying to port a large and complex application to Linux. I have identified two approaches by which this can be done. I was hoping to get advice on which is the best approach, as well as the pros and cons of each approach.

The application consists of 2 layers:

Layer 1

• Written in ANSI C
• Queries a proprietary database

Layer 2

• Consists of a GUI written entirely in MFC
• End user uses this layer to communicate what search and retrieval he

wants the Layer 1 to perform.

• Some part of business logic is also mixed up in the GUI. - Many times the result set returned by Layer 1 is modified by

Layer 2. - Occasionally the search string given by the end user is first modified in Layer 2 before being passed on to Layer 1. - Filters to queries are applied by Layer 2 code.

There are two approaches that I have identified to do the porting:

Option 1: Go the WINE way.

As expected, the ANSI C code of Layer 1 works perfectly within WINE. Not all parts of the GUI code of Layer 2 work in WINE. When a feature does not work, it does not mean that the problem is in its code. It could be in code which is some steps earlier. So I need to hunt and correct the errors by recoding the error producing code. The advantage is that perhaps this may be much lesser work than the second option.

Option 2: Go the Qtk way.

I have studied a white paper on Qtk. As far as I can see, almost all the components in MFC have been re-coded by Qtk people so that they can be complied to run on GNU/Linux. My task therefore involves a. examining all the code modules b. separating the code which deals with MFC from the business logic code. c. replacing the MFC code by Qtk code (The business logic code can be pasted directly in Qtk. Right?)

This is more work compared to Option 1 but there is one advantage. The same source code than can be recompiled for Mac and Unix versions also.

Does anybody on this group have practical experience of working with either of the two alternatives? What approach would you recommend I follow?

Thanks, Parul Mathur

-- http://mm.ilug-bom.org.in/mailman/listinfo/linuxers

On 10/12/03 15:34 +0530, Parul.Mathur wrote:

Hi,

Hiya.

I am trying to port a large and complex application to Linux. I have identified two approaches by which this can be done. I was hoping to get advice on which is the best approach, as well as the pros and cons of each approach.

I see you have still not learnt to wrap lines :).

<snip good analysis>

This is more work compared to Option 1 but there is one advantage. The same source code than can be recompiled for Mac and Unix versions also.

Does anybody on this group have practical experience of working with either of the two alternatives? What approach would you recommend I follow?

Option 3: Refactor the application, have it talk to a database via a wrapper module (or ODBC). Separate application logic, business logic and UI logic totally. The UI merely deals with the user interface part, formatting the data, and dealing with changes. The business logic part resides in a separate module which handles data validation and business rules. The database does application logic and data validation via stored procedures.

Once you can do this separation, then your business logic can be coded in whatever language you like, and the UI can be in the same or different languages. Logical choices for the UI are Delphi, QT, GTK+, Tk (if you are willing to release source). Delphi is a good tool when doing rapid application development (think of it as the VB of Linux when dealing with user interfaces, except that it doesn't have the bad featuritis of VB).

This isn't much more work than option 2, but it can give you a much more maintainable codebase, which can easily be scaled up later. The database wrappers ensure portability between various RDBMS systems, while separation of business and UI logic means that you can change backend rules *without* changing the UI.

Having a separate component for the business logic which is centralized also means that no user needs to talk directly to the database, enhancing security.

Devdas Bhagat