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.
(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'..)
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!
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.
Oh please Santa ! Let us adultrate WINE with C++, please.
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 ?
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 ?
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 !
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 ! 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.
Most of the time we are passing around multilevel pointers when a simple reference would have done:
For example a call like
Stream_LoadString( stm, unicode, &This->sString ); [To 'static HRESULT Stream_LoadString( IStream* stm, BOOL unicode,LPWSTR *pstr )']
can be made to a simple
Stream_LoadString(sString);
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..)
We have code like that all over the place whenever COM etc comes into play and "That's Not A Good Thing(TM)" !
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. 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 !
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++..)
For a expert discussion on C++ please see http://www.research.att.com/~bs/blast.html Microsoft themselves use C++ :
<quote> 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:
Windows XP Windows NT (NT4 and 2000) Windows 9x (95, 98,
"Subhobroto Sinha" subhobrotosinha@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...
Alexandre Julliard wrote:
"Subhobroto Sinha" subhobrotosinha@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.
We are meant to pick the best tool for the job. While I 100% agree with "no C++ in the core Windows DLLs" rule, I think some other areas make more sense to use C++ than C. I have not been able to find the prior discussions about this matter, though I know we had them.
Shachar
On Wed, Dec 10, 2003 at 09:24:26AM +0200, Shachar Shemesh wrote:
Alexandre Julliard wrote:
"Subhobroto Sinha" subhobrotosinha@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.
We are meant to pick the best tool for the job. While I 100% agree with "no C++ in the core Windows DLLs" rule, I think some other areas make more sense to use C++ than C. I have not been able to find the prior discussions about this matter, though I know we had them.
Read what Alexandre wrote. To paraphrase:
"Feel free to write it in C++ and submit it when you are done."
Ciao, Marcus
On Wed, 2003-12-10 at 08:06, Marcus Meissner wrote:
Read what Alexandre wrote. To paraphrase:
"Feel free to write it in C++ and submit it when you are done."
ie I guess there is no rule, it's just a matter of using it when appropriate (and of course Alexandre must agree that it is appropriate :)
Was it someone (from ROS) that said they had an "Internet explorer" replacement written in C++ ? Was that a shell-folder explorer or an iexplorer type of application. Can it be made to support "Internet Explorer" controls. (the "Shell.Explorer"/IWebBrowser2 one, that can be placed in user applications to display HTML files).
What is the situation with MinGW/cygwin on ROS/windows fronts is it able to build any kind of fully qualified ActiveX controls? Is there any free (beer is good to) compilers that can build fully qualified ActiveX controls? What is the situation on Wine. can widl or any other tool produce a proper .TLB structure? Can a ready made .TLB file (from VC++) be in any way associated (in registry) or linked to an ELF compiled dll(control) ?
any comments or pointers will be appreciated.
Free Life Boaz
Mike Hearn wrote:
On Wed, 2003-12-10 at 08:06, Marcus Meissner wrote:
Read what Alexandre wrote. To paraphrase:
"Feel free to write it in C++ and submit it when you are done."
ie I guess there is no rule, it's just a matter of using it when appropriate (and of course Alexandre must agree that it is appropriate :)
On Wed, 2003-12-10 at 19:25, Boaz Harrosh wrote:
What is the situation on Wine. can widl or any other tool produce a proper .TLB structure?
No, not as far as I know :( We really need this, for many years now Wine has been shipping OLE that is nearly non-functional for some important tasks because we lack stdole32.tlb
--- Mike Hearn mike@theoretic.com wrote:
On Wed, 2003-12-10 at 19:25, Boaz Harrosh wrote:
What is the situation on Wine. can widl or any other tool produce a
proper .TLB structure?
No, not as far as I know :( We really need this, for many years now Wine has been shipping OLE that is nearly non-functional for some important tasks because we lack stdole32.tlb
Someone submitted source/binarys for a repleacement stdole32.tlb a year or so ago but I think it required MS_VC to build.
Thanks Steven
__________________________________ Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing. http://photos.yahoo.com/
On Wed, 2003-12-10 at 21:07, Steven Edwards wrote:
Someone submitted source/binarys for a repleacement stdole32.tlb a year or so ago but I think it required MS_VC to build.
Yes, we have the IDL (mostly) but Alexandre won't accept binaries into CVS, we need to be able to translate the IDL into the TLB files ourselves as part of the build process.
I looked at the code (typelib.c/.h) it looks strait forward, read the file. (Microsoft invented yet another file format, this is when they where writing the book about OLE files. nu well ...)
I guess it should not be very hard to implement the ICreateTypeLib/2 (I hope). Than WIDL can use that Interface to (right?)
typelib.c is assigned to Rein KLazes (by copy-right). Did you experiment with also writing the TLB? do you have any code/documentation/URLs/pointers laying around that I should see before I start? (That is if you are not doing it?)
In the code you are checking for TLB signatures and for a PE. should that be checking for ELF and than load from resource Just as with PE? Is there a standard wine way to check for Executables PE or not?
Mean while I can use a pre-made .TLB and stick it in the RC file. Grate ! here comes ELF ActiveX controls.
About stdole32.tlb There must be a standard simple way to Translate it into HEX format (hence text mode for CVS) and than regenerate from HEX the actual file for installation. Should I submit an HEX file? Some one will have to change the Makefiles.
by the way a new bee question: what are the commands in Linux to make a binary file HEX and back.
Mike Hearn wrote:
On Wed, 2003-12-10 at 21:07, Steven Edwards wrote:
Someone submitted source/binarys for a repleacement stdole32.tlb a year or so ago but I think it required MS_VC to build.
Yes, we have the IDL (mostly) but Alexandre won't accept binaries into CVS, we need to be able to translate the IDL into the TLB files ourselves as part of the build process.
On Thu, 11 Dec 2003 12:20:46 +0200, you wrote:
typelib.c is assigned to Rein KLazes (by copy-right). Did you experiment with also writing the TLB? do you have any code/documentation/URLs/pointers laying around that I should see before I start? (That is if you are not doing it?)
I take those are questions to me. The copyright means no more then it was me that made the first contribution that allowed reading tlb's, some 4 years ago iirc. I haven't done much about it since and the most of the current code is probably added by others since. No, I did not write TLB's, except for modifying some with a hex editor and see what changed in the ole viewer. It should be relatively straightforward however, and no need to support two file format. All internal documentation is in the code and comments. External information on the file format is probably non-existent.
Rein.
ons, 10.12.2003 kl. 08.24 skrev Shachar Shemesh:
Alexandre Julliard wrote:
"Subhobroto Sinha" subhobrotosinha@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).
Ove Kaaven wrote:
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.
I don't think anyone was talking about MFC. MFC is written in some strange language MS made up using CPP macros and visual studio wizards. Calling it C++ is an insult to C++.
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)
I believe you meant winelib. I'm with you on that one.
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).
I'm sorry, it has been YEARS since I wrote anything OLE related (my very first Windows program was an OLE server, hand coded, that did a shell extension. That was my only interaction with OLE). As such, I will not presume to decide whether that statement is correct or not.
I do know, however, a thing or two about C++. I have coded quite a lot in C++, and I believe I am pretty much aware of the things the language does well, and the things it is poor at. It all boils down to this - C++ is a language (much much) more difficult to learn well than C, and OOP is something that is difficult to do right. Add to that the fact that there are (quite a few) jobs for which OOP is the wrong tool, and you get the origins of the common belief that C++ is evil.
Personally, I *love* C++. I don't use it for OOP much, because I spent the last 3/4 year trying to set up a business, and the preceding 2 1/4 years writing kernel level code for CheckPoint's FireWall-1. Not much C++ used there, for reasons purely technical. I do believe that, ABI interface problems aside (nothing unsolveable with extern "C"), C++ is a superior language to use to C for almost any task, provided you can master the art of not getting carried away with using features you don't need (with OOP being one of those). Granted, it's a difficult art to master.
When working with environments where most of those differences would amount to just more warnings for logic errors when using C++, I don't mind saying "everyone knows C, let's use only that". However, when really complicated stuff is involved (Boaz mentioned Direct something codecs), I believe there is room to use the best tool for the job.
To sum it all up - it may not be MFC (as I agree with Ove that MFC can be saftely left out of Wine proper), and it may not be OLE (as I don't know it well enough to judge), but I think C++ does have a place in certain parts of Wine. I do believe that most of the "less readable" claims are a result of either over-engineering the solution or people's expectance to "just read" the code. OOD will, occasionally, require you to read the docs before messing with the code.
Shachar
-
Alexandre Julliard -
Boaz Harrosh -
Marcus Meissner -
Mike Hearn -
Ove Kaaven -
Rein Klazes -
Shachar Shemesh -
Steven Edwards -
Subhobroto Sinha