MFC?
-
COM was the only practical way to share modules between different applications, services. We write something in VC++ and share it with application clients that are made with VB, .net & even Web/JavaScript. It was doing a real good job on intranet applications from where you can control machines/hardwares. For any non technical folks, it was almost looking like a magic. Like, A web-page controlling hardwares? COM, ActiveX were all doing those magic. And still, COM is being used by Windows extensively. I guess WinRT does good use of COM underneath, if I'm right.
Starting to think people post kid pics in their profiles because that was the last time they were cute - Jeremy Falcon.
Vunic wrote:
COM was the only practical way to share modules between different applications, services.
dll's can also be shared. COM was designed to alleviate 'dll hell', where apps became dependant on a particular version of dll because later versions lost functions, or the interface to those functions changed, or the functions themselves changed behaviour. So instalers would often overwrite a newer dll with an older one. Of course if dlls are properly engineere this doesnt happen, and COM becomes irrelevant. Which is what has happened.
Vunic wrote:
We write something in VC++ and share it with application clients that are made with VB, .net & even Web/JavaScript
But it id still a dll written in C, even if it has a different set of functions to access it. A COM module is (unless it is an out of proc server) a dll.
-
Vunic wrote:
COM was the only practical way to share modules between different applications, services.
dll's can also be shared. COM was designed to alleviate 'dll hell', where apps became dependant on a particular version of dll because later versions lost functions, or the interface to those functions changed, or the functions themselves changed behaviour. So instalers would often overwrite a newer dll with an older one. Of course if dlls are properly engineere this doesnt happen, and COM becomes irrelevant. Which is what has happened.
Vunic wrote:
We write something in VC++ and share it with application clients that are made with VB, .net & even Web/JavaScript
But it id still a dll written in C, even if it has a different set of functions to access it. A COM module is (unless it is an out of proc server) a dll.
I think COM components fit naturally into the development environments of different tools. Application developers never have to worry about the importing stuff, datatypes mapping & even the physical location of the Dll. it was just piece of cake for the component consumer. obviously it was a lot of clutter for the component developer. And Active-X controls(UI+Com) were working beautifully on the web pages. it was doing real great stuff for the intranet. I know people hated it for the internet though.
Starting to think people post kid pics in their profiles because that was the last time they were cute - Jeremy Falcon.
-
I think COM components fit naturally into the development environments of different tools. Application developers never have to worry about the importing stuff, datatypes mapping & even the physical location of the Dll. it was just piece of cake for the component consumer. obviously it was a lot of clutter for the component developer. And Active-X controls(UI+Com) were working beautifully on the web pages. it was doing real great stuff for the intranet. I know people hated it for the internet though.
Starting to think people post kid pics in their profiles because that was the last time they were cute - Jeremy Falcon.
I only ever wrote in C / C++, so I guess it was no hassle to import a lib, either static or dynamic, it is just part of the life of a programmer.