I understand that COM is really a way to program (i.e. like structured programming, or OO programming). However it is a little old. So I was just wondering what has really replaced this set of specifications? Will I find this in .NET documentation?
COM has not been replaced. The Component Object Model is a core part of Windows and will remain so for the foreseeable future.
COM provides you with one mechanism of inter process communication (communicating between applications on a machine), it is also used as a much simpler (for the consumer) system of sharing dlls. Its COM (or ActiveX, or OLE - all the same) that enables VBA to work so well in MS Office, it is the foundation of ActiveX controls.
COM is not a way to program (unlike OOP etc) it is a technology that works on windows to make access to other applications during runtime easier.
.NET can use COM object with wrappers, and if you want to allow any app to access your functionality, its still best to provide a COM wrapper.
Other methods of inter app coms now exist such as ZeroMQ.
The original specification for COM is old in age, but the specification as well as the concepts are still in use, and you can still create and consume COM objects.
For .NET, you can start by looking at the following links:
Com Interop Part 1: C# Client Tutorial (C#) # MSDN
Interoperating with unmanaged code # MSDN
In addition, there are other specs that are very similar to COM or have semantics that are the same. Most notably, XPCOM is in use in FireFox for their plugin spec and also used internally to FireFox to connectable objects.
XPCOM # MDN (Mozilla)
WinRT is an upcoming platform update for windows that is also heavy in COM concepts.
There are some useful here: Why is WinRT unmanaged # StackOverflow
For .NET developers, a lot of the declarative overhead is hidden as mentioned here: WinRT demystified - Miguel de Icaza
The head of the spec is here: The Windows Runtime # MSDN
And in the context of COM, developing WinRT components with C++ has similarities, although some syntax is borrowed from managed C++: Creating Windows Runtime Components in C++ # MSDN
Related
This question follows the previous one below:
Easy way to guarantee binary compatibility for C++ library, C linkage?
I wondered if making interface functions of C++ DLL or shared library with C linkage brings forward compatibility of Compiler and of standard library.
extern "C" someAPI();
The most voted answer was saying that I am wrong. The answer recommended making it open-source. And never mentioned about COM or CORBA. Making it open-source is not always possible.
But recently I am reading books about Windows COM. And I think COM maybe brings the compatibility I wanted. And there is another thing CORBA.
So I wonder if these things, COM and CORBA, really brings forward compatibity of compiler and standard library?
I think network library ACE uses CORBA. And that is only one I know about CORBA.
Isn't CORBA popular nowadays?
What about COM? ActiveX is maybe disappearing but WDF(Windows Driver Foundation) depends on COM.
Thank you very much!
Yes, COM was created, among other reasons, to overcome source code (and .obj, static lib, etc.) reuse issues, whether that source is C/C++ or anything else.
The essence of COM (v-table layout + IUnknown, forget about registration, OLE, Automation, marshaling, and other additional stuff) is very simple (in fact, it's hard to make it more simple). Since it only relies on binary contracts, you can write COM client and/or server code using any language (and any platform, but in reality, only Windows uses it). So you can have a 32-bit COM client written in python talk to a 64-bit COM server written in C++ for example (well, this example in fact requires some cross process marshaling, so it's not pure lightweight COM).
COM is very far from being dead or disappearing (because it's, again, quite simple). "ActiveX" was a marketing / tech mix name, but it's basically COM, and is massively used in Windows, by Windows and 3rd parties.
COM over the physical network (DCOM) is indeed disappearing (in favor of other technologies, like Web, sockets, HTTP, REST, or in general technologies more simple than COM), and what's still used today is basically in-process and out-process COM (out-process is somehow DCOM on the same machine).
I know that CORBA was once upon a time a strong COM competitor (especially because it was available on multiple platforms, including Windows), but it seems to be seriously declining, also in favor of the same more simple technologies (web, etc.).
Does LibreOffice/OpenOffice Support the COM Model (Component Object Model)?
Not directly. The creators of OpenOffice/LibreOffice invented their own component framework which is called UNO.
From the limited insights into this framework (quite crappy documentation, but the official COM documentation is also crap [save Don Box'es book, but that is Addison Wesley]), it seems to me as if UNO is quite a match to COM (no fixed ABI, so that components from the same environment can talk to each other without having to translate their calls into a common ABI).
I have to admit that I have not used it (only my co-workers) while I have used COM automation for MS Office a lot (Visual C++/ATL). I suppose that there is a bridging framework that creates COM to UNO glueing components.
But if you want to automate OpenOffice, you could as well start to use UNO (it is not as if you could write COM code that addresses both MS Office as well as LO/OO). Else have a look at this link: http://www.oooforum.org/forum/viewtopic.phtml?t=9815 (Googling for COM-related stuff is a PITA since com is also a top-level internet domain name. Guess what MS chose as name for the successor technology :-)
Regards,
Stuart
PS: Would you mind keeping us informed about your experience with UNO or UNO to COM bridging? Thx in advance
Visual C++. I have to implement some drawing and printing functionality that will be incorporated into (other developers') COM dll. Firstly I thought of doing everything using pure GDI and nothing more, but it seems that printing and print previewing is hell of a job to be done in GDI compared to the MFC implementation. So I decided to focus on MFC. Quick side question here: Is my choice right? I mean, are any easy ways of implementing printing (and print-preview) without MFC?
Now that I need MFC (assuming if you also agree with this), I have two questions about how to do it:
1) I believe the COM dll is the ATL project (it's not my code, some other developers independently develop it). Can I enable MFC support in that dll? What are the risks/limitations/drawbacks of having MFC runtime in the COM server? And if you advice doing this, how can I do it?
2) As much as I want to affect the third-party COM server's code as little as possible, I thought it might be the better approach to implement my code as a separate MFC-based DLL, and load and use that DLL from COM server. Do you advice doing this? What are the risks/limitations/drawbacks in this situation?
Shortly, I want to use MFC's drawing and especially printing capabilities in my code, which itself should be integrated in another developers' COM dll (which itself is utilized in a large corporate application). I'm no expert in COM technology so I'm a little bit confused. What are my best options?
You can use MFC in your own dll internally, and expose functionality to your users with non MFC intruded function: for example if you need to pass a point from/to ypur caller, use the GDI standard POINT structure, then convert it to a CPoint to use internally. In this case you don't need to enamble use of MFC in the ATL project ( that is possible anyway ) but of course you need to distribute or link with the MFC dll. If you want mantain the caller com dll as clean as possible, you can definitely create your own ATL+MFC dll and expose your functions via com interfaces too, but keep in mynd to avoid put MFC related objects in the interface.
Printing and print preview is a hell of a job unless you're using MFC Document/View Architecture. Will your COM expose such advanced UI?
If your COM must be independent of .NET then MFC is the way to go, otherwise I would use .NET. If you choose MFC, make sure you link to it statically. Otherwise you will most likely end up with runtime errors on machines where the necessary MFC version is missing.
Except for this, I wouldn't worry about compatibility since the idea of COM is to let the underlying magic do the marshaling of integers, strings and other objects.
I have some MFC code (custom CWnd controls and some classes to expose) that I need to make into an activex / COM object with interfaces. Is it easier to make an ATL project with MFC support and make my ActiveX that way or make an MFC ActiveX control?
When doing an activeX control, is doing dual interfaces (like that explained in ACDual from microsoft) good/bad/makes no difference?
MFC is an easier route if you're a newbie in COM stuff: The wizards are better and more helpful. But it's far less flexible than ATL, which is probably not an issue if you simply have a couple of simpole interfaces to implement.
Also, IIRC MFC doesn't support dual interfaces. Dual interfaces are interesting in 2 cases:
- Performance is an issue. Such as a call to a short method executed millions of times.
- The object users are programmed in C++. Calling a native interface is way easier in C++ than calling an automation interface.
In conclusion, dual interfaces are cool but they are really interesting only if you can have them for free. Which means you use a framework which supports them. If you plan on much COM-based work, it's interesting to investigate in ATL and deeper COM knowledge. If you just have to provide a couple of simple MFC-based objects, just stick to MFC.
It's a bit of pain to use MFC for COM - there is too much code to write, macros to copy -
however you have to know what you're doing if you are mixing MFC and ATL because they are deceptively similar yet different, especially if you create windows with ATL.
The main thing is, if you use MFC from an ATL, you will need to start every one of your ATL method with AFX_MANAGE_STATE(AfxGetStaticModuleState( )), otherwise you will get random problems. This is done for you automatically when you implement COM with MFC, which is why there are these ugly METHOD_MANAGE_STATE macros in every method.
Beyond this, it just works. MFC objects inside a ATL objects is what I do..
I've always used straight ATL with no MFC for development of COM components. MFC is useful as an application framework, which I generally didn't need for lightweight (non-UI) COM components. ATL provides lots of support for strings, collections, and various utility classes without the need to bring in all of MFC with the logistical complexities that arise from doing that (like setting context on every public API call, etc). It also includes some basic UI support via CWindow and its friends if you're building a UI component.
Is it possible to use an ActiveX/COM object from ColdFusion? If so, where's the documentation or samples for it?
(non ColdFusion programmer, asking on behalf of a ColdFusion programmer)
see: Integrating COM and CORBA Objects in CFML Applications
If you're worried about COM object performance, use .NET based CFML Engine like BlueDragon for the Microsoft .NET Framework
You can call both COM objects and .Net assemblies natively in ColdFusion both with excellent performance. Check out the following in the cf docs:
http://livedocs.adobe.com/coldfusion/8/htmldocs/cfobject_01.html
http://livedocs.adobe.com/coldfusion/8/htmldocs/help.html?content=dotNet_01.html
Examples are included in the docs.