Re: I made a wish, wrote a letter to Santa...
> (2) A few things like DirectX and COM are so very closely tied with C++ > objects that implementing them in C seems an overkill to me. But after > knowing they are done, I have nothing against that Well, speaking for DirectX 1-7 , I do not see exactly what C++ would have gained us (except headaches when you would have needed to check the generated ASM to see if the compiler did the right thing behind your back to map 100 % with MS's COM API). Anyway, it could only have helped us a bit on the COM inftrastructure (which is about 2 % of the total work and was mostly auto-generated by a Python script :-) ). Lionel -- Lionel Ulmer - http://www.bbrox.org/
Re: I made a wish, wrote a letter to Santa...
Actually Shachar, I was thinking along these lines: (1) Programs in WINE are making direct calls to internal functions (which are not really Win32, but made by us using which we can use te Win32 functions as wrappers...) and that's just possible because C functions are globally callable (the only thing you really need to keep the compiler happy is the function prototype) And that's a bad thing, because while developing tools we should really forget that we are coding fo WINE, and just write using Win32 SDK APIs... Encapsulating internal WINE functions as private, and exposing them using the correct APIs would be better engineering... Just to force lazy people like us to write protable code (you see, calling internal WINE functions are a lot easier than calling the corresponding wrappers.. (2) A few things like DirectX and COM are so very closely tied with C++ objects that implementing them in C seems an overkill to me. But after knowing they are done, I have nothing against that (3) C++ is VERY reusable. WINE has a lot of potential for reusablity , but by doing C where it was not needed, we are unnecessarily having to spend time finding out pieces here and there in the huge code structure. WINE is recieving more interest than ever, and we can only encourage people to join us by giving something they too can reuse, and people who really work for WINE are those types who start writing their own code if they find that tracing down a function and it's references will take more time. For example, whatever I have gone through (which is VERY little BTW..), I still feel that implementing many tools like winemenubuilder or winefile would have been better in C++ Infact, I intent to do some experimentation after Xmas (I am having my semester exams now, so ..) Hope what I said reaches you all ;) Season's greetings Subhobroto On Thu, 11 Dec 2003 Shachar Shemesh wrote : >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.
Re: I made a wish, wrote a letter to Santa...
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. -- Rein Klazes [EMAIL PROTECTED]
Re: I made a wish, wrote a letter to Santa...
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.
Re: I made a wish, wrote a letter to Santa...
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.
Re: I made a wish, wrote a letter to Santa...
--- Mike Hearn <[EMAIL PROTECTED]> 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/
Re: I made a wish, wrote a letter to Santa...
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
Re: I made a wish, wrote a letter to Santa...
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 :)
Re: I made a wish, wrote a letter to Santa...
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 -- Shachar Shemesh Open Source integration & consulting Home page & resume - http://www.shemesh.biz/
Re: Re: I made a wish, wrote a letter to Santa...
To be honest, if you follow my previous posts, I DID write some C++. Albeit, that was not reallt necessary ... ;) Anyways, I will submit a pure C and a C++ version of future patches, sch that both work under the current WINE. After that, it will be upto Sir Julliard... Season's Greetings Subhobroto Sinha >On Wed, 10 Dec 2003 Sir Marcus Meissner wrote thus: >Read what Alexandre wrote. To paraphrase: > >"Feel free to write it in C++ and submit it when you are done." > >Ciao, Marcus >
Re: I made a wish, wrote a letter to Santa...
ons, 10.12.2003 kl. 08.24 skrev Shachar Shemesh: > Alexandre Julliard wrote: > > >"Subhobroto Sinha" <[EMAIL PROTECTED]> 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).
Re: I made a wish, wrote a letter to Santa...
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 :)
Re: I made a wish, wrote a letter to Santa...
On Wed, Dec 10, 2003 at 09:24:26AM +0200, Shachar Shemesh wrote: > Alexandre Julliard wrote: > > >"Subhobroto Sinha" <[EMAIL PROTECTED]> 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 pgp0.pgp Description: PGP signature
Re: I made a wish, wrote a letter to Santa...
Alexandre Julliard wrote: "Subhobroto Sinha" <[EMAIL PROTECTED]> 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 -- Shachar Shemesh Open Source integration & consulting Home page & resume - http://www.shemesh.biz/
Re: I made a wish, wrote a letter to Santa...
"Subhobroto Sinha" <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
Re: I made a wish, wrote a letter to Santa...
Being Jewish, and growing up in a Jewish majority environment, I don't connect much to the spirit of christmas. Sorry. However, I do have the vague recollection that Santa brings presents to boys who have been good. I don't see how sending the same message over and over and over again can be considered "Good". You may be shooting yourself in the foot here. Shachar Subhobroto Sinha wrote: 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 -- Shachar Shemesh Open Source integration & consulting Home page & resume - http://www.shemesh.biz/
