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
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.).
I need to write a cascading shell extension à la 7Zip. It appears that only the .Net 4 framework supports this, but even in March 2012, MS still advises against using a managed language for this purpose.
So what unmanaged languages are available to write shell extensions for Windows (XP, Vista, 7)?
I read that writing a COM DLL is not easy even for seasoned C++ developpers, so it's probably a dead-end for non-pros. VB6 has been deadware for a decade. I looked at PureBasic and PowerBasic but they don't seem good candidates either.
So is there simply no reasonably easy language to write a cascading shell extension?
As a work-around, is there a library that I could call from VB.Net that would handle the hard part?
Thank you.
There is not a lot you can do if you're not willing to go into the unmanaged world. There is a series of articles on codeproject. This is the first of such articles. They helped me quite a bit. It is written in unmanaged c++ using visual studios ATL project which takes care of some other classes that you would otherwise have to deal with.
COM objects may not be the easiest thing to understand but once they're working they are fairly solid. If anything just treat it as a learning experience.
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
I have trouble understanding XPCOM. How is it different from COM? What makes it cross platform?
Is it a framework with a set of libraries that you can use to do some jobs?
Also, does Component Object Model means every functionality is implemented in component so we can use it without knowing the detail implementation?
Can you someone help me understand this please?
Thanks,
Chan.
I have trouble understanding XPCOM.
How is it different from COM?
XPCOM is Mozilla's own, cross-platform (hence the XP bit) version of COM.
What makes it cross platform?
It is implemented in a library that has been ported to many platforms by contributors to the Mozilla open-source project. You can build it or download a binary for any platform that you wish and, in the extremely remote possibility that you want to use it on a platform that is not already supported, it should be straightforward to port it yourself.
Also, does Component Object Model
means every functionality is
implemented in component so we can use
it without knowing the detail
implementation?
Yes, spot on. The idea is for a language-independent framework that enables different components to communicate and interact, without requiring any special knowledge of the language that any particular component is implemented in. So javascript code can call C++ code, for instance.
This is achieved by components publishing well-defined interfaces, using a language called IDL (or, in XPCOM's case, XPIDL). These interfaces make use of well-defined types with mappings in each of the supporting languages. Every interface inherits from a common base interface, which provides standard methods for reference-counting and type-inference (called IUnknown in COM and nsISupports in XPCOM).
Can you someone help me understand
this please?
In terms of online resources, there are dedicated areas on both the MSDN (for COM) and the MDC (for XPCOM). If you want to really understand the motivation for COM and why it is the way it is, I recommend picking up Don Box's Essential COM. And of course, if you have any specific questions that need answering, you can always come here to ask them. :)
We are in the process of creating active-x controls used within our application.
Since Microsoft stopped supporting classic Visual Basic, is it wise to use Visual Basic to develop the Active X control or the latest VC++/ATL/MFC libraries provide more feature where we can create controls faster by leaving Visual Basic flexibility?
We will not be able to use .NET/VB.NET/C# since the application is supposed to work inside containers and containers may not support latest .NET runtime.
Any other language is best fit for Active X control development other than VB and VC++?
I, personally, would recommend using Delphi for this. It is still actively developed, and has the control you get with C++, but a rapid development environment more like VB.NET.
#nobugz: If you are really interested what is ActiveX in Delphi, look at docwiki. Normally it is 100% source code (yours + VCL, VCL is also available as sources) with autogenerated COM wrappers. So all potential security problems are also in source code. If you find a security problem in VCL, please send a bug report to Quality Central.
Here is a good example on how to create ActiveX Controls with C# .NET
http://www.codeproject.com/KB/cs/CreateActiveXDotNet.aspx
By all means VB6 is the best language. After reading your question I feel that you are a VB6 developer. If you know VB6 and use it then why hesitate using it for producing ActiveX controls.
I program in Delphi as well as VB6 along with VB.NET and C# but creating ActiveX controls is the easiest in VB6 compares to all other development tools.
If you are hell bent on not using VB and if you are looking for an alternative then try out PowerBasic (commercial - very costly) or PureBasic (commercial but affordable) Get it from here or better still MinGW (a GNU C++ compiler).
I have to say that VB6 with a good book like Developing COM/ActiveX Components with VB6: A Guide to the Perplexed you will be up and running faster.