This question is the result of a lunch conversation with an employee ... I read questions like WPF vs. Winforms ... and I personally believe that long-term WPF is the way to go. The problem / question is what to do in the meantime.
Yes, WPF certainly has its advantages; not being built on GDI / USER, is one of them. But at the moment (that is, at the end of 2009, using VS2008, or perhaps even VS2005, Silverlight3, recently released and not yet widely adopted / deployed), WPF almost looks like it could be a “reworked” solution. Although I am sure that this will change over time, today it does not make it easier, nor for the immediate (say, 36 months) future.
And let it look, WinForms is actually simple and easy; especially for many employees who are still “happily” using MFC. Yes, it can be difficult to make smooth animations, 3D graphics, gradients, etc .; but this is a very utilitarian solution that many people (i.e. C ++ / MFC developers) easily understand today.
With this long introduction - anyone thought / tired / etc. about the idea of implementing (most) WinForms using WPF (i.e. WinForms sans GDI / USER)? I am sure that I was given something like Control.Handle, 100% re-implementation is impossible. But it looks like many WinForms controls can be reimplemented using WPF "under the hood." Or is it really a border impossible?
Under "reimplementation," I foresee deleting references to System.Windows.Forms assemblies , replacing them (say) with Microsoft.Wpf.WinForms , and then rebuilding my expression. After that, I would expect to fix some (relatively few) compilers and / or runtime errors (say P / Invokes for the Win32 API).
Something like this looks like a nice addition to various Microsoft WinForms / WPF strategies, such as WindowsFormsHost . For example, developers can start using / learning WPF in a much more incremental way.
Edit: So far, different "why?" the discussions are interesting, they do not answer the main technical question: "yes., .. as if ... or not, ... because ...".