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 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...
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 snip 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. /snip snip, snip..
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...
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...
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: 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...
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...
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...
--- 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/
I made a wish, wrote a letter to Santa...
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,
I made a wish, wrote a letter to Santa...
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 M
I made a wish, wrote a letter to Santa...
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
I made a wish, wrote a letter to Santa...
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 makin
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/
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]
