Future of COM Architecture :: COM
-
Hi. I am studying COM from Inside COM by Dale Rogerson. Thus far, this is the first and only COM book I read on COM. COM concept and implementation using C++ are simple enough. One reason is probably because I have read and is familiar with concepts in Modern C++ Design by Andre Alexandrescu. I plan to work on some simple COM designs in the coming months. I would like to know what is the future of COM? How does .NET affect COM present and future? Is it possible to use COM components written in C++ in C#? I am a hardcore C++ programmer, but I may develop COM components for other languages if possible in the future. Thanks, Kuphryn
-
Hi. I am studying COM from Inside COM by Dale Rogerson. Thus far, this is the first and only COM book I read on COM. COM concept and implementation using C++ are simple enough. One reason is probably because I have read and is familiar with concepts in Modern C++ Design by Andre Alexandrescu. I plan to work on some simple COM designs in the coming months. I would like to know what is the future of COM? How does .NET affect COM present and future? Is it possible to use COM components written in C++ in C#? I am a hardcore C++ programmer, but I may develop COM components for other languages if possible in the future. Thanks, Kuphryn
COM will never die. That's what Windows is based on. It is possible to use COM components from within C# or any other .NET language via COM Interop. .NET doesn't seek to kill COM, it just runs alongside it. I predict that as .NET becomes more and more prevalent in the programming community that we'll see more and more .NET components, but I don't think that means that we'll ever see the end of COM components.
any idiot can write haiku you just stop at seventeenth syl -ThinkGeek Fortunes
-
COM will never die. That's what Windows is based on. It is possible to use COM components from within C# or any other .NET language via COM Interop. .NET doesn't seek to kill COM, it just runs alongside it. I predict that as .NET becomes more and more prevalent in the programming community that we'll see more and more .NET components, but I don't think that means that we'll ever see the end of COM components.
any idiot can write haiku you just stop at seventeenth syl -ThinkGeek Fortunes
Don't be too sure mate, the next versions of Windows after 2003 will have CLR built into the OS, so COM won't be needed for internal purposes, my guess is another 5 yrs and COM will be like straight C dll's. May the Source be with you Sonork ID 100.9997 sijinjoseph
-
Don't be too sure mate, the next versions of Windows after 2003 will have CLR built into the OS, so COM won't be needed for internal purposes, my guess is another 5 yrs and COM will be like straight C dll's. May the Source be with you Sonork ID 100.9997 sijinjoseph
Sijin wrote: the next versions of Windows after 2003 will have CLR built into the OS, so COM won't be needed for internal purposes, my guess is another 5 yrs and COM will be like straight C dll's. True, but do you think Microsoft is going to totally abandon the unmanaged scene? There are still reasons for staying unmanaged (speed being one of them) and I know a couple diehards (Mr. Losinger for one) who swear they'll never convert.
any idiot can write haiku you just stop at seventeenth syl -ThinkGeek Fortunes
-
Hi. I am studying COM from Inside COM by Dale Rogerson. Thus far, this is the first and only COM book I read on COM. COM concept and implementation using C++ are simple enough. One reason is probably because I have read and is familiar with concepts in Modern C++ Design by Andre Alexandrescu. I plan to work on some simple COM designs in the coming months. I would like to know what is the future of COM? How does .NET affect COM present and future? Is it possible to use COM components written in C++ in C#? I am a hardcore C++ programmer, but I may develop COM components for other languages if possible in the future. Thanks, Kuphryn
COM seems like a pretty cool concept when you first start reading about it. Inside COM by Dale Rogerson was the first COM I read, and I thought COM was coolest thing since sliced bread after reading that book. But I think you'll soon come to realize that COM is the devil in disguise. First, there is good amount of overhead just to use COM. Initialize the COM runtime, create the class factory, look up guids/iids in registry, create the real object, etc... Second, the COM datatypes suck. Variants are useless blobs of garbage simply created for communicating with languages like VBScript/JScript. There's a whole slew of API's to get data into and out of of variants. BSTR's aren't bad. But again, you have to use API calls(SysAllocString, etc..) to use them. I think .NET is very much the future for Microsoft. I've read reports that thier re-writing everything from the ground up(not wrappers around existing API's) with .NET. This includes the Win32 API and Office. You can use COM Components written in C++ from C#, but you pay a performance penalty. Windows is currently based on the Win32 API, not COM. There is much Win32 functionality exposed via COM wrappers. But as I said before, according to Microsoft, those API's(Win32, COM) will be gone in future. Personally, I think writing C/C++ directly against the Win32 API is the best way to go right now. In the future, it'll be .NET. Unfortunently, there are still some areas where you don't have a choice. For instance, IE. If you want to communicate with IE, you have to use COM. Either directly or through .NET/COM interop. Anyway, these are just my opions. Take'em or leave'em....:-D
-
Hi. I am studying COM from Inside COM by Dale Rogerson. Thus far, this is the first and only COM book I read on COM. COM concept and implementation using C++ are simple enough. One reason is probably because I have read and is familiar with concepts in Modern C++ Design by Andre Alexandrescu. I plan to work on some simple COM designs in the coming months. I would like to know what is the future of COM? How does .NET affect COM present and future? Is it possible to use COM components written in C++ in C#? I am a hardcore C++ programmer, but I may develop COM components for other languages if possible in the future. Thanks, Kuphryn
kuphryn wrote: Inside COM by Dale Rogerson I love that book. I think COM as we know it will die. Sorry. Regardz Colin J Davies
Sonork ID 100.9197:Colin
I'm guessing the concept of a 2 hour movie showing two guys eating a meal and talking struck them as 'foreign' Rob Manderson wrote:
-
Sijin wrote: the next versions of Windows after 2003 will have CLR built into the OS, so COM won't be needed for internal purposes, my guess is another 5 yrs and COM will be like straight C dll's. True, but do you think Microsoft is going to totally abandon the unmanaged scene? There are still reasons for staying unmanaged (speed being one of them) and I know a couple diehards (Mr. Losinger for one) who swear they'll never convert.
any idiot can write haiku you just stop at seventeenth syl -ThinkGeek Fortunes
Are you saying that if you write unmanaged code in .NET then you are producing COM? (I doubt those words) Or are you saying that when Microsoft write certain code they won't even use the unmanged bits of .NET? (Forgive me if I am asking stupid questions. I do C# and used to do VB, and apart from CP+ have never touched C++, MC++ or any of those things.)
Paul Watson
Bluegrass
Cape Town, South AfricaMacbeth muttered: I am in blood / Stepped in so far, that should I wade no more, / Returning were as tedious as go o'er DavidW wrote: You are totally mad. Nice.
-
Hi. I am studying COM from Inside COM by Dale Rogerson. Thus far, this is the first and only COM book I read on COM. COM concept and implementation using C++ are simple enough. One reason is probably because I have read and is familiar with concepts in Modern C++ Design by Andre Alexandrescu. I plan to work on some simple COM designs in the coming months. I would like to know what is the future of COM? How does .NET affect COM present and future? Is it possible to use COM components written in C++ in C#? I am a hardcore C++ programmer, but I may develop COM components for other languages if possible in the future. Thanks, Kuphryn
I've read "Inside COM", "Essential COM" and many other books - in Russian and English. COM's a beautiful thing - when you first meet it. And than - tons o' problems. As an example - I'm working now on some application. I decided to build it upon COM - but now I use simple MFC with extension libraries. But I'm not a novice in COM! The reason is that COM data transfer and types are really sick. I can't say anything 'bout .NET - I don't know this thing (yet). P.S. But IMHO COM's quite helpfull when one needs Drag&Drop, COM+ and MTS features. Sepultura in my heart, can`t take it away... (Max Cavalera)
-
COM seems like a pretty cool concept when you first start reading about it. Inside COM by Dale Rogerson was the first COM I read, and I thought COM was coolest thing since sliced bread after reading that book. But I think you'll soon come to realize that COM is the devil in disguise. First, there is good amount of overhead just to use COM. Initialize the COM runtime, create the class factory, look up guids/iids in registry, create the real object, etc... Second, the COM datatypes suck. Variants are useless blobs of garbage simply created for communicating with languages like VBScript/JScript. There's a whole slew of API's to get data into and out of of variants. BSTR's aren't bad. But again, you have to use API calls(SysAllocString, etc..) to use them. I think .NET is very much the future for Microsoft. I've read reports that thier re-writing everything from the ground up(not wrappers around existing API's) with .NET. This includes the Win32 API and Office. You can use COM Components written in C++ from C#, but you pay a performance penalty. Windows is currently based on the Win32 API, not COM. There is much Win32 functionality exposed via COM wrappers. But as I said before, according to Microsoft, those API's(Win32, COM) will be gone in future. Personally, I think writing C/C++ directly against the Win32 API is the best way to go right now. In the future, it'll be .NET. Unfortunently, there are still some areas where you don't have a choice. For instance, IE. If you want to communicate with IE, you have to use COM. Either directly or through .NET/COM interop. Anyway, these are just my opions. Take'em or leave'em....:-D
Gerald Schwab wrote: Windows is currently based on the Win32 API, not COM. There is much Win32 functionality exposed via COM wrappers. But as I said before, according to Microsoft, those API's(Win32, COM) will be gone in future. Where did you read this? Have you the link? I can't see the whole of the Operating system being accessed thru the .net framework. :~
-
Gerald Schwab wrote: Windows is currently based on the Win32 API, not COM. There is much Win32 functionality exposed via COM wrappers. But as I said before, according to Microsoft, those API's(Win32, COM) will be gone in future. Where did you read this? Have you the link? I can't see the whole of the Operating system being accessed thru the .net framework. :~
http://www.theinquirer.net/?article=5238[^] http://www.codeproject.com/interview/interview_msdn_0103.asp[^] The long-term future is going to start with Longhorn and the inclusion of the framework in the operating system’s core http://msdn.microsoft.com/chats/vstudio/vstudio_121802.asp[^] The "Windows Forms" API is essentially a set of interfaces that expose the existing Win32 functionality via managed code. In the future, you will see the API for developing applications on Windows will evolve into a fully managed API. http://www.eweek.com/article2/0,3959,642737,00.asp[^] The newly posted screens also highlight Longhorn's inclusion of Avalon, the .Net-based successor to the Win32 subsystem, as well as the Yukon file system, which the screens label as "WFS," or Windows file system.
-
http://www.theinquirer.net/?article=5238[^] http://www.codeproject.com/interview/interview_msdn_0103.asp[^] The long-term future is going to start with Longhorn and the inclusion of the framework in the operating system’s core http://msdn.microsoft.com/chats/vstudio/vstudio_121802.asp[^] The "Windows Forms" API is essentially a set of interfaces that expose the existing Win32 functionality via managed code. In the future, you will see the API for developing applications on Windows will evolve into a fully managed API. http://www.eweek.com/article2/0,3959,642737,00.asp[^] The newly posted screens also highlight Longhorn's inclusion of Avalon, the .Net-based successor to the Win32 subsystem, as well as the Yukon file system, which the screens label as "WFS," or Windows file system.
I have now got the message - move to .Net or your future will become obsolete. :| OK. I've done a few .Net window form projects, compared to straight Win32 or MFC and WFC it has lots of limitations, I supposed this will be ironed in later versions of .net. But it the future of Windows development has be planned, and I think a few our hardcore Windows developers should take note - esp Chris L/John S, as Darth Vader said to Luke Skywalker, "Join us or you will die" and on that note this will become my new sig.