<P>
With XMas nearing, I thought it was time I made my yearly wish to Santa - that he would let his elves use C++ in WINE.<BR>
<BR>
(Just in case, you did not know Santa's email address, it's 'julliard[at]winehq.org', and you can make your wishes at 'wine-devel[at]winehq.com'..)<BR>
<BR>
You see, Santa was always so good - he answered people's prayers and got together his obedient elves to run Win32 on Non-Windows platforms!<BR>
<BR>
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.<BR>
But that could be solved using yet another language called C++ - if only Santa would let it be.<BR>
<BR>
Oh please Santa ! Let us adultrate WINE with C++, please.<BR>
<BR>
It's not that we will rewrite everything in C++ once we get the green signal - things like the loader, scheduler, and most of the Win32 SDK does not need C++ at all, but what about MFC, COM, OLE ?<BR>
<BR>
Not that I expect to compile native MFC source using WineLib, but at least we can write the runtimes so that native MFC apps can atleast run under WINE ?<BR>
<BR>
DirectX oozes of classes,inheritance,abstaction and everything C++ as does OLE, COM and already our implementations have structure object pointers running wild, whereas encapsulation would have done away with it !<BR>
<BR>
As a simple explanation, we might take our 'This' hack wheras C++ would let have us use it as 'this' without even us worrying about it !<BR>
Also, there are many places in shell32, ole and shwlapi (I cannot comment on DirectX source as I do not have a graphics base at all ..) where initializing a few member variables from a constructor would have done away with some redundancy.<BR>
<BR>
Most of the time we are passing around multilevel pointers when a simple reference would have done:<BR>
<BR>
For example a call like<BR>
<BR>
Stream_LoadString( stm, unicode, &This->sString ); [To 'static HRESULT Stream_LoadString( IStream* stm, BOOL unicode,LPWSTR *pstr )']<BR>
<BR>
can be made to a simple<BR>
<BR>
Stream_LoadString(sString);<BR>
<BR>
using C++ if we had the prototype rewritten to 'static HRESULT Stream_LoadString(LPWSTR& pstr )' and making it a member function of IStream (and thus the 'IStream* stm' and 'BOOL unicode' would be member variables..)<BR>
<BR>
We have code like that all over the place whenever COM etc comes into play and "That's Not A Good Thing(TM)" !<BR>
<BR>
Please give us the green card - alternately, a new test branch may also be created just to see if C++ would work.All C++ based modfications would goto that tree.<BR>
If that test branch works and delivers, it maybe merged into the main WINE tree, otherwise if it fails to deliver just remove it after a stipulated period !<BR>
<BR>
If WINE stuck to C only because some platforms do not support C++, then will Win32 apps run on such OS at all ? Things like SPARC do not need MS Apps at all (though SPARC has C++..)<BR>
<BR>
For a expert discussion on C++ please see http://www.research.att.com/~bs/blast.html<BR>
Microsoft themselves use C++ :<BR>
<BR>
<quote><BR>
Microsoft: Literally everything at Microsoft is built using various flavors of Visual C++ - mostly 6.0 and 7.0 but we do have a few holdouts still using 5.0 :-( and some products like Windows XP use more recent builds of the compiler. The list would include major products like:<BR>
<BR>
Windows XP <BR>
Windows NT (NT4 and 2000) <BR>
Windows 9x (95, 98,
</P>
<br><br>
<A target="_blank" HREF="http://clients.rediff.com/signature/track_sig.asp"><IMG SRC="http://ads.rediff.com/RealMedia/ads/adstream_nx.cgi/www.rediffmail.com/inbox.htm@Bottom" BORDER=0 VSPACE=0 HSPACE=0 HEIGHT=74 WIDTH=496></a>