I made a wish, wrote a letter to Santa...

Ove Kaaven ovek at arcticnet.no
Wed Dec 10 11:23:42 CST 2003


ons, 10.12.2003 kl. 08.24 skrev Shachar Shemesh:
> Alexandre Julliard wrote:
> 
> >"Subhobroto  Sinha" <subhobrotosinha at rediffmail.com> writes:
> >
> >>However, soon many of his elves found out that technologies like
> >>MFC, WTL, ATL, COM, DCOM, COM+ and other MS bloops were getting too
> >>complex to be implemented using plain C, and thus developments in
> >>those areas were soon in limbo.
> >>
> >>But that could be solved using yet another language called C++ - if
> >>only Santa would let it be.
> >
> >You don't need Santa's permission for that, just go ahead and
> >implement DCOM in C++ and show us how easy it is. I suspect you will
> >quickly realize that the complexity of the problem does not come from
> >having to explicitly pass the this pointer around...
> >
> While You are, no doubt, right about the complexity problem, I fail to 
> understand the "no C++ in the wine source tree" rule.

Consider that the reason could be that C++ has too many interoperability
problems to solve any within an interoperability project like Wine. Just
try to compile something like MFC with g++ and see how well the result
would run MSVC++-compiled programs.

Okay, perhaps I should say right away that it won't run, because g++
won't generate VC++-compatible code. In any case, I don't see why MFC
should be part of Wine, it's not a core Windows component. There's
nothing wrong with having a separate FreeMFC project outside Wine using
C++ (and compiling their FreeMFC libs with MSVC++ for the benefit of
Wine users)

As for COM/DCOM, having implemented big parts of it myself, I'm not so
sure C++ would have helped a whole lot in any case. It's a mess and the
only thing you'd achieve with C++ is a different style of mess (a more
unreadable one, for starters).





More information about the wine-devel mailing list