Few days back I started reading COM. Then one of my team member told that it is an old technology, now a days no one is using this.
My question is:
1) If it is an old technology then what is the alternative for that.
2) Why should not I need to use COM. Ie what is the drawback of the COM.
We use COM most commonly at work today to do IPC across native C++ applications and managed . NET applications written in C#.
The Microsoft Component Object Model (COM) is a platform-independent, distributed, object-oriented system for creating binary software components that can interact. COM is the foundation technology for Microsoft's OLE (compound documents), ActiveX (Internet-enabled components), as well as others.
Component Object Model (COM) is a binary-interface standard for software components introduced by Microsoft in 1993. It is used to enable inter-process communication object creation in a large range of programming languages.
DCOM is a programming construct that allows a computer to run programs over the network on a different computer as if the program was running locally. DCOM is an acronym that stands for Distributed Component Object Model.
COM is an 'old technology' in the same way C++ is. Just because it's old doesn't mean it's out-of-date. The reason Microsoft keeps coming back to it (Windows 8 makes big use of it) is because it's a relatively low-overhead object based technology. There's no big run-time to initialize before using COM (although a component could initialize a run-time if it needed to, e.g..NET CCW).
The interface/implementation boundary is kept strictly separate so it is useful for exposing Windows functionality in an object orientated way (as well as DirectX the Windows Shell is based around COM).
COM suffers from a general misunderstanding of what's COM and what's built on top of COM. ActiveX, DCOM, OLE, COM+, etc. are built on COM but do not define what COM is. COM itself as a core technology has been kept relatively simple.
I say relatively because COM is not perfect. The apartment model can cause significant problems, such as cross-apartment marshalling requiring an application to pump a message queue. Back in the late nineties people were going COM mad and making everything out of COM components and it caused unnecessary complexity in applications. However, it's a well tested technology and when used properly it works well, especially for exposing or consuming functionality for 3rd parties. If you want to really understand the Windows API you need to know how COM works.
1) If it is an old technology then what is the alternative for that.
COM is certainly old. Microsoft's "alternative" to it was/is .NET, but means you need to play along with the CLR (so native C++ doesn't get to play along, you would need C++/CLI for this). The latest alternative is now called WinRT (Windows Runtime). WinRT is currently only available for Windows 8 and Windows Server 2012. At the lowest level, WinRT is actually COM, but Microsoft has rethought a lot of its pitfalls. Platform/language agnostic alternatives include Google Protocol Buffers, Apache Thrift, and SOAP.
2) Why should not I need to use COM. Ie what is the drawback of the COM.
COM's primary purpose is inter-process communication (IPC). If, for example, you have two applications written in two programming languages and wish for them to communicate, COM is a (windows-specific) solution. COM was used extensively in the 90's to communicate between C++ and VB6 applications. If you don't have a need for IPC, then your prospects for COM are pretty low. We use COM most commonly at work today to do IPC across native C++ applications and managed .NET applications written in C#.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With