Application migration

Is it possible to migrate an existing MFC application to Dolphin in
piecemeal fashion? I am guessing a complete re-write would require a couple
of man-years which are not available. Is it possible to use Dolphin for
little pieces here and there that grow over time and eventually become the
entire product?

John

I'd certainly try very hard to do what you describe. Although the total
effort will arguably be greater (since you need to support intermediate
coordination that is not needed at the beginning or the end), I believe that
a case could be made that the overall cost/benefit would be better. Projects
that follow the "big bang" model (deliver everything at the end of a long
development process) are more likely to be wasteful (and/or cancelled) than
projects that deliver immediate value.



Probably the biggest question is how flexible your customers/users are about
the stability of the user interface during the transition. If they are quite
flexible and the application can be divided into different modules, then the
easiest approach would be to have two applications, one with some features
and the other with other features. For example, an accounting program could
be divided into GL, AR, AP, etc.



The next level of complexity would be to incorporate one application into
the other using OLE/COM/ActiveX. Perhaps you could modify the MFC
application to call the Dolphin application for certain features. For
example, when the user picks a menu item that would ordinarily open a new
window with lots of MFC widgets and logic, instead have it open an MFC
window in which a Dolphin component is displayed. Over time the MFC
application could become nothing more than a wrapper for Dolphin, and then
could be finally retired.



An alternative would be to have Dolphin start out as the outer shell and for
every menu item it would cause various MFC windows to open.



James Foster





"John Keenan" <[hidden email]> wrote in message
news:616Wf.723$[hidden email]...

John,

> Is it possible to migrate an existing MFC application to Dolphin in
> piecemeal fashion? I am guessing a complete re-write would require a couple
> of man-years which are not available. Is it possible to use Dolphin for
> little pieces here and there that grow over time and eventually become the
> entire product?

The last thing I want to do is to discourage a new Smalltalk project,
but IMHO, you will _probably_ be headed for trouble.  I would hate to
see you get clobbered and end up blaming Smalltalk for the problems
associated with component software, which IMHO is much harder to create
than conventional wisdom suggests.

With that said, there are ways it could work.  What does the software
do?  Is your two man-year estimate based on C++ experience?

Have a good one,

Bill


--
Wilhelm K. Schwab, Ph.D.
[hidden email]

> using OLE/COM/ActiveX.... instead have it open an MFC window in which a
Dolphin component is displayed.

This sort of migration would be acceptable (splitting the application into
separate modules would not).  Is there a specific example of this available?

John

"James Foster" <[hidden email]> wrote in message
news:[hidden email]...
> I'd certainly try very hard to do what you describe. Although the total
> effort will arguably be greater (since you need to support intermediate
> coordination that is not needed at the beginning or the end), I believe
that
> a case could be made that the overall cost/benefit would be better.
Projects
> that follow the "big bang" model (deliver everything at the end of a long
> development process) are more likely to be wasteful (and/or cancelled)
than
> projects that deliver immediate value.
>
>
>
> Probably the biggest question is how flexible your customers/users are
about
> the stability of the user interface during the transition. If they are
quite
> flexible and the application can be divided into different modules, then
the
> easiest approach would be to have two applications, one with some features
> and the other with other features. For example, an accounting program
could for the
> > entire product?
> >
> > John
> >
> >
>
>

> > An alternative would be to have Dolphin start out as the outer shell and
for every menu item it would cause various MFC windows to open.

Opps. I answered previous reply before reading to the end.

This also would be acceptable. However, I am not sure how to do this without
modifying the original application extensively. I would prefer a solution
that would allow minimal changes to the original application so the majority
of the development was done in Dolphin. Are there any canned examples of
this available?

John

"James Foster" <[hidden email]> wrote in message
news:[hidden email]...
> I'd certainly try very hard to do what you describe. Although the total
> effort will arguably be greater (since you need to support intermediate
> coordination that is not needed at the beginning or the end), I believe
that
> a case could be made that the overall cost/benefit would be better.
Projects
> that follow the "big bang" model (deliver everything at the end of a long
> development process) are more likely to be wasteful (and/or cancelled)
than
> projects that deliver immediate value.
>
>
>
> Probably the biggest question is how flexible your customers/users are
about
> the stability of the user interface during the transition. If they are
quite
> flexible and the application can be divided into different modules, then
the
> easiest approach would be to have two applications, one with some features
> and the other with other features. For example, an accounting program
could for the
> > entire product?
> >
> > John
> >
> >
>
>

Bill,

> What does the software do?  Is your two man-year estimate based on C++
experience?

The application performs numerical calculations (which will not be ported).
The ported software will handle the configuration UI, data management
(memory based double vectors), and other UI. My estimate, calculated after
20 seconds of hard squinting, is based on Smalltalk (5 years but now dated),
C++, and Smalltalk to external experience. The estimate really is one person
working for two years, actively porting BUT maintaining and enhancing the
application with an eye towards porting whenever possible, will have a
ported application in about two years.

John

I'm not aware of an example of a Dolphin COM component with UI (the
Education Centre has an example of a Random Stream, but that doesn't have a
UI). OA has provided a number of excellent UI demos (Notepad, Regedit,
etc.), but I haven't figured out how to make one into a COM component.
Perhaps someone else has had more success.

To give an informed opinion about the complexity of controlling a second
application from a Dolphin application, I'd need to know more about the
windows to be controlled. Depending on the MFC application, it might be
possible to modify it to be available as an OLE Automation object, then the
Dolphin application could control it, make requests, and get back results.
Based on what you've said so far, that is the approach I'd investigate
first.

James

"John Keenan" <[hidden email]> wrote in message
news:RDfWf.7954$%[hidden email]...

John,

>> What does the software do?  Is your two man-year estimate based on C++
> experience?
>
> The application performs numerical calculations (which will not be ported).

If that means what it means to me, keeping it in C++ can be a very good
idea.  I wrap such things in extern "C" functions that are marked for
export.  They end up with some truly ugly parameter lists, but it's just
a lot of [pointer][size][[size]] groups.


> The ported software will handle the configuration UI,

This kind of thing will generally be easily created in Dolphin.  IMHO,
it's easier to rewrite than to arrange for external call madness to
avoid same.


 > data management
> (memory based double vectors),

This is almost trivial in Dolphin.  Create your DOUBLEArray objects
(perhaps owned by some wrapper??), size them in Smalltalk, and then pass
them along with dimensions to your DLL functions.


 > and other UI.

This could get into work to port, depending on what you mean.  Can you
elaborate?  If it's heavy graphics, the porting could get ugly, but then
so could trying to expose it from C++.

Is it forms, or something out of Star Trek?  Even intense graphics
should be ok if you can pass an HDC and some other arrays/sizes to a
function and let it draw.  Mouse interaction should probably be ported,
perhaps with hit testing passed back to the DLL.  Keep in mind the
Squeak model of a GUI: it's a (frequently dynamic) image with a mouse
cursor flopping around on top of it.  More recently, Squeak is even
starting to respect input focus and keyboard control over same; those
things are easy to handle in Dolphin.


 > My estimate, calculated after
> 20 seconds of hard squinting, is based on Smalltalk (5 years but now dated),

That explains why I recognize your name but wasn't certain how much
experience you have.


> C++, and Smalltalk to external experience. The estimate really is one person
> working for two years, actively porting BUT maintaining and enhancing the
> application with an eye towards porting whenever possible, will have a
> ported application in about two years.

If you can fit the DLL model I describe, then you might surprise
yourself how easy it is to do, provided you throw away enough of the
boilerplate C++.  I'm not a fan of creating software components in the
name of making things easier - it almost never works.  Smalltalk calling
a DLL isn't much trouble and can work to advantage.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Bill Schwab wrote:
An important point: the parameter list must be C-friendly (no reference
arguments, etc.), but the body of the function can use all the C++
constructs you want, such as string classes, streams, templates, etc.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

Bill,

> Is it forms, or something out of Star Trek?

There is a lot of custom graphics. But this is not the problem. The point is
it MUST be a migration (because everytime I have stopped the world, the
world has stopped for everyone else as well).

I do not have the knowledge/resources/experience/etc. to put together an MFC
example to test the feasbility of a migration to Dolphin. But given a
working example I am capable of evaluating it and running with it if it
looks good.

I was really hoping this specific issue of migration (from various other
platforms) had been addressed through canned examples. Without a migration
path you have to be well funded or start with small applications that can
then grow into large applications.

John

John,

> The point
> is it MUST be a migration (because everytime I have stopped the world, the
> world has stopped for everyone else as well).

If I were in this position, I would start by putting an external interface
(either C+DLL or COM) onto my underlying C++ calculation engine.  That would
hardly impact the existing app at all[*] since the existing code would not use
the new interfaces[**].

([*] except in that you'd be taking time off from developing it further in
itself)

([**] unless you want it to, of course).

Then start bolting a Dolphin front-end onto the DLL/COM component.

Presumably, as in most things, the idea would be to start small.  Work out how
to build your app's calculation engine into a DLL, or COM component (possibly
you're app's structured that way already, or very nearly; if not then that
might turn out to be the most difficult step of the entire programme).  Expose
one small chunk of functionality via that API.  Bolt a small Dolphin app onto
that.  If that went well then continue the process, until it stops going well
or you run out of things to port.


> I do not have the knowledge/resources/experience/etc. to put together an
> MFC example to test the feasbility of a migration to Dolphin. But given a
> working example I am capable of evaluating it and running with it if it
> looks good.

Do you mean that you don't know how to write an MFC app at all ?  Or how to
build a DLL ?  Or that you don't know how to use Dolphin's external interfacing
?  If any of those things are the case then I suggest that you'll need to
acquire at least a little experience before you can sensibly plan this.  Having
a "migration path" doesn't make a lot of sense when you don't know what's
involved in each step.


> I was really hoping this specific issue of migration (from various other
> platforms) had been addressed through canned examples.

I don't know of any canned examples of a Dolphin front-end on an external DLL
or COM component.  /Except/ in the sense that the entire Dolphin environment
(IDE or runtime) is exactly that.  If you are looking for examples of something
specific, or for a really simple example, then maybe someone can suggest (or
even create) something.

I doubt if you'll find any examples at all of /migration/ as such.  We may be
able to find examples of the desired end-point, but planning the intervening
steps is up to you ;-)

    -- chris

Chris,

> I would start by putting an external interface (either C+DLL or COM) onto
my underlying C++ calculation engine.

That already exists and and will remain as it is.

> Presumably, as in most things, the idea would be to start small.

My terminology for this is migration.

> Do you mean that you don't know how to write an MFC app at all ?  Or how
to
> build a DLL ?  Or that you don't know how to use Dolphin's external
interfacing
> ?

I have obviously failed to communicate my concerns. Let me try again. On the
one hand I have an existing, mature, stable application. This application
has extensive MFC user interfaces, layered on top of well OO architected C++
classses (I call these the "domain" classes, non-MFC, generic C++), which in
turn utilizes some core functionality in a dll (which will remain as is). On
the other hand, I have Dolphin. The final objective being to replace the MFC
user interface and domain class with Dolphin.

Using Dolphin's external interfacing is not a problem, porting well OO
architected C++ classes to Smalltalk is not a problem, instanciating
Smalltalk instances from C++ instances is not a problem, creating the first
Dolphn user interface that duplicates the functionality of an existing MFC
user interface in not a problem...

The problem is how do I make that first Dolphin user interface appear and
co-exist with the rest of the existing application?

James Foster made the suggestion that the Dolphin user interface could be
written as a COM component that could be displayed in an MFC window.
However, he also indicated that Dolphin does not come with a canned COM
example including a UI. I have been through the drill enough times to know
that getting this first example working can be a daunting task.

James Foster also suggested that Dolphin could start out as the outer shell
with the menu items causing the existing MFC windows to open. But quite
honestly I do not see how to do this without extensive modifications to the
existing MFC application.

> I doubt if you'll find any examples at all of /migration/ as such.

I am quite surprised to hear this. Migration is such an important process.

John

John

IMHO, components make things possible.  If you use them as a short cut,
you are very likely in dangerous territory.  One exception is reusing C
(or even Fortran) numerical code.  Such things can be very nicely
wrapped in DLLs and called from Smalltalk.  The result is faster than
Smalltalk code would be, and avoids the translation of the code.  Your
code might fit that model.  If your goal is to use COM to give new life
to C++ objects, then you might have something.  If you are hoping to use
COM to make your MFC GUI appear in a Dolphin window, then my advice is
to not bother.  It will be a lot of work and will accomplish next to
nothing to move you in the direction you claim to want to go.  I do not
say that lightly.  Others are welcome to disagree.

Have a good one,

Bill


--
Wilhelm K. Schwab, Ph.D.
[hidden email]

John Keenan wrote:

> The problem is how do I make that first Dolphin user interface appear and
> co-exist with the rest of the existing application?

Why not make the Dolphin app run headless. Add some functions to the MFC
app to accept callback info which you send ExternalCallback blocks to.
Have the Dolphin app respond to callbacks which is trivial to implement.
This way you can replace the MFC app piece by piece.

Apologies if I'm misunderstanding your needs as well.

Take care,

John

John,

> The problem is how do I make that first Dolphin user interface appear and
> co-exist with the rest of the existing application?

Do you have a reason to think this /should/ be possible ?  Serious question.
You hadn't mentioned before that your app has a good internal structure (and
since you said it was an "MFC application" -- a code word for "big ball of
mud" -- I had rather assumed not), so maybe there is some other relevant
structure that you haven't yet mentioned.   For instance it might be structured
as multiple executables which launch each other.  Or it might be implemented
with ActiveX controls for each major element of the GUI. Or it might have been
designed with an eye towards turning it into a Web Service one day.  Or...

If so (or if you are willing to change your app to make it so) then there are
probably ways forward based on whatever that structure is.

If /not/ then you are in a position where you have an application with its GUI
tightly bound to the "meat" of the application (I mean tightly bound in the
sense of the implementation technology, not the code structure).  Sort of like
the shell around an egg.  And you want to replace the shell piecemeal without
breaking the egg.  I doubt whether it can be done.

Whatever you do will amount to building a new egg from scratch (re-using the
existing yolk).  Or, less metaphorically, you will always be in a position
where you have two programs, one written in C++, the other written in Dolphin,
where the Dolphin one provides a sub-set of what's available through the C++
one (until the port is complete).  I don't see what the benefit to your users
would be of "making" them use two programs, unless you can couple them together
so tightly that the seam is invisible.  And I don't know how to produce that
coupling -- at the very best it seems like a lot of extra work (over and above
the port itself) for no obvious gain.

    -- chris

> > The problem is how do I make that first Dolphin user interface appear
and
> > co-exist with the rest of the existing application?
>
> Why not make the Dolphin app run headless. Add some functions to the MFC
> app to accept callback info which you send ExternalCallback blocks to.
> Have the Dolphin app respond to callbacks which is trivial to implement.
> This way you can replace the MFC app piece by piece.

It is the user interface that I would like to replace piece by piece. I do
not see how your suggestion will help with the user interface. Please
clarify if I am missing something.

John

> > The problem is how do I make that first Dolphin user interface appear
and
> > co-exist with the rest of the existing application?
>
> Do you have a reason to think this /should/ be possible ?  Serious
question.

Absolutely. This would provide a migration path. Without a migration path,
*new* users must either be well funded (to support a complete port) or start
with small applications.

> You hadn't mentioned before that your app has a good internal structure
(and
> since you said it was an "MFC application" -- a code word for "big ball of
> mud" -- I had rather assumed not), so maybe there is some other relevant
> structure that you haven't yet mentioned.

My term for MFC is "house of cards"... you make a trivial change here and
something other there collapses. But that is mostly a result of
under-the-hood problems. I have found it is possible to keep the
*application* of MFC reasonably well architected from an OO point of view.

> For instance it might be structured
> as multiple executables which launch each other.  Or it might be
implemented
> with ActiveX controls for each major element of the GUI. Or it might have
been
> designed with an eye towards turning it into a Web Service one day.  Or...

Nope, nope, and nope. It is very possible I do not have the correct
definition of MFC. When I have been refering to MFC, I am refering to the
use of widgets such as CEdit, CStatic, CSpinButtonCtrl, CListBox, CButton,
CComboBox, CButton, CListBox, CProgressCtrl, CTreeCtrl, CTabCtrl,
CDateTimeCtrl, etc. in windows that are CDialog subclass (actually
subclasses a class I have developed that enables embedding within other
windows which in turn is a subclass of CDialog) with the message map such
as:
    BEGIN_MESSAGE_MAP( thisclass, superclass )
        ON_WM_SIZE()
        ON_WM_PAINT()
    END_MESSAGE_MAP()
which invokes methods such as:
    OnInitDialog()
    OnSize( const UINT nType, const int window_right, const int
window_bottom )
    OnPaint()
etc.

> If so (or if you are willing to change your app to make it so) then there
are
> probably ways forward based on whatever that structure is.

I would *prefer* to put the development effort into the new environment not
the old environment since the objective is to replace the old environment.
But, the reason I started this thread was to determine what options are
available.

> If /not/ then you are in a position where you have an application with its
GUI
> tightly bound to the "meat" of the application (I mean tightly bound in
the
> sense of the implementation technology, not the code structure).

BINGO. I am continually amazed how far the Microsoft tenticles reach into
your application when using their frameworks. It is an absolute brilliant
hook-em-and-keep-em strategy.

> Whatever you do will amount to building a new egg from scratch (re-using
the
> existing yolk).

In my terminology that is a code re-write... not a migration.

> Or, less metaphorically, you will always be in a position
> where you have two programs, one written in C++, the other written in
Dolphin,
> where the Dolphin one provides a sub-set of what's available through the
C++
> one (until the port is complete).  I don't see what the benefit to your
users
> would be of "making" them use two programs,

I do not want to burden my users with such a change. This is my problem...
not theirs. To them, the migration should be seamless.

> unless you can couple them together
> so tightly that the seam is invisible.  And I don't know how to produce
that
> coupling -- at the very best it seems like a lot of extra work (over and
above
> the port itself) for no obvious gain.

The obvious gain is to eliminate the MFC UI framework in favor of a more
flexible one. A big push port would require funding that is not available. A
slow port would require enhancing the old application while the port is in
progress thereby making double work. If a migration path were available, I
could make all enhancements in the new environment thereby eliminating the
double work.

John