I knew here is a link which discussed a bit about the difference between COM and XPCOM.
What is XPCOM? XPCOM vs COM?
however, I want to know this topic in more detail way.
For example, for reference counting and type inference, COM inherited from IUnknown, XPCOM inherited from nsISupport. What's the difference between IUnkown and nsISupoort except naming?
Further, Do these two different components support different threading management or memory management? Topics like this are really interested to me.
Please reply this post if you know any.
Thanks
What's the difference between IUnkown and nsISupoort except naming?
None, really. nsISupoort was specifically designed to be binary-compatible with IUnknown, to make it easier for FireFox to host ActiveX controls, and to be itself exposed as an ActiveX control.
Do these two different components support different threading management or memory management?
Yes. XPCOM uses its own memory allocator (nsMemory::Alloc et al), completely independent of COM allocator (CoTaskMemAlloc et al). COM provides an extensive set of threading models as well as marshaling support. XPCOM barely deals with threads at all (see nsIProxyObjectManager), and has no notion of marshaling.
Warning: this information may very well be obsolete. My familiarity with the state of Mozilla development is current as of 2010 or so.
Related
I am having a tough time figuring out when I should use COM. I have done some reading but I simply cannot find a solid use-case for using it...I have browsed the internet trying to figure out when and why I should use it but the concept is simply too abstract and I don't understand it.
I get how using COM is interesting when it comes to writing code which can be consumed from various programming languages that support COM (What is the Component Object Model (COM)? Is it language-dependent?). But I would love to get a few solid examples of when COM was used and why it couldn't have been done realisticaly in another way.
Could someone list a few solid / real-world examples where using COM makes more sense that writing a DLL
which exports functionality through traditional functions if you put aside the multi-language aspect of COM ?
I know for instance that COM is used heavily in development which gravitates around Microsoft Office products...Why is this ?
I have been poking around some websites, and discovered WebAssembly, and was intrigued by the fact that, to be implemented, a virtual machine is created, along with instruction sets.
Is it theoretically possible to make a WebAssembly implementation in hardware? Does the vm lack any capabilities that could not be solved by external functions?
Theoretically yes, and someone started to develop an initial implementation for an FPGA called WASM Metal but I believe has since been abandoned. Notably, folks like Brendan Eich are skeptical of the utility of it.
Wasm was designed for just-in-time compilation, so there are some minor complications that make direct execution slightly more involved (e.g., the way branch targets are addressed). Some future extensions, such as garbage collection support, might also be less straightforward, though an implementation will be allowed to not provide those.
But yes, in principle it should be possible (and useful!) to implement Wasm in hardware. I am aware of some people/projects looking into this idea, but none of them have announced anything publicly yet.
I just started playing with COM. Like my fellow C/C++ programmers I found COM ugly for many practical reasons, until the moment I've read this and this. If COM is all about interoperability, it makes sense that COM should remain at the border-edge of any implementation. I think this would be a good practice.
However, I discussed with a the guy how implemented a piece of code I'm working on (to investigate a heap corruption issue). And he didn't seem to approve the concept of putting COM on the edge. He still enumerates the benefits of providing COM interfaces for all and any. So,
Is it really a bad design to put COM everywhere in an implementation?
PS: In the implementation I'm working on, every thing is COM server. There are: ComNode, ComProperty, ComString, and even ComReal and ComInteger.
I don't know well Smalltalk, but I know some Objective-C. And I'm interested a lot in Smalltalk.
Their syntax are a lot different, but essential runtime structures (that means features) are very similar. And runtime features are supported by runtime.
I thought two languages are very similar in that meaning, but there are many features on Smalltalk that absent on Objective-C runtime. For an example, thisContext that manipulates call-stack. Or non-local return that unwinds block execution. The blocks. It was only on Smalltalk, anyway now it's implemented on Objective-C too.
Because I'm not expert on Smalltalk, I don't know that sort of features. Especially for advanced users. What features that only available in Smalltalk? Essentially, I want to know the advanced features in Smalltalk. So it's OK the features already implemented on Objective-C like block.
While I'm reasonably experienced within Objective-C, I'm not as deeply versed in Smalltalk as many, but I've done a bit of it.
It would be difficult to really enumerate a list of which language has which features for a couple of reasons.
First, what is a "language feature" at all? In Objective-C, even blocks are really built in conjunction with the Foundation APIs and things like the for(... in ...) syntax requires conformance to relatively high level protocol. Can you really talk about a language any more without also considering features of the most important API(s)? Same goes for Smalltalk.
Secondly, the two are very similar in terms of how messaging works and how inheritance is implemented, but they are also very different in how code goes from a thought in your head to running on your machine. Conceptually different to the point that it makes a feature-by-feature comparisons between the two difficult.
The key difference between the two really comes down to the foundation upon which they are built. Objective-C is built on top of C and, thus, inherits all the strengths (speed, portability, flexibility, etc..) and weaknesses (effectively a macro assembler, goofy call ABI, lack of any kind of safety net) of C & compiled-to-the-metal languages. While Objective-C layers on a bunch of relatively high level OO features, both compile time and runtime, there are limits because of the nature of C.
Smalltalk, on the other hand, takes a much more top-to-bottom-pure-OO model; everything, down to the representation of a bit, is an object. Even the call stack, exceptions, the interfaces, ...everything... is an object. And Smalltalk runs on a virtual machine which is typically, in and of itself, a relatively small native byte code interpreter that consumes a stream of smalltalk byte code that implements the higher level functionality. In smalltalk, it is much less about creating a standalone application and much more about configuring the virtual machine with a set of state and functionality that renders the features you need (wherein that configuration can effectively be snapshotted and distributed like an app).
All of this means that you always -- outside of locked down modes -- have a very high level shell to interact with the virtual machine. That shell is really also typically your IDE. Instead of edit-compile-fix-compile-run, you are generally writing code in an environment where the code is immediately live once it is syntactically sound. The lines between debugger, editor, runtime, and program are blurred.
Not a language feature, but the nil-eating behaviour of most Objective-C frameworks gives a very different developing experience than the pop-up-a-debugger, fix and continue of smalltalk.
Even though Objective-C now supports blocks, the extremely ugly syntax is unlikely to lead to much use. In Smalltalk blocks are used a lot.
Objective-C 2.0 supports blocks.
It also has non-local returns in the form of return, but perhaps you particularly meant non-local returns within blocks passed as parameters to other functions.
thisContext isn't universally supported, as far as I'm aware. Certainly there are Smalltalks that don't permit the use of continuations, for instance. That's something provided by the VM anyway, so I can conceive of an Objective-C runtime providing such a facility.
One thing Objective-C doesn't have is become: (which atomically swaps two object pointers). Again, that's something that's provided by the VM.
Otherwise I'd have to say that, like bbum points out, the major difference is probably (a) the tooling/environment and hence (b) the rapid feedback you get from the REPL-like environment. It really does feel very different, working in a Smalltalk environment and working in, say, Xcode. (I've done both.)
Lately I'm hearing much about COM at my work. I also learnt that COM is old. COM is deprecated. There is no future for COM. Are these true too?
I want to learn COM because I want to know what is the big fuss about it, but I'm unable to convince myself that this is a solid reason for spending so much time and learning it.
So, Can any one tell me:
Why should I learn COM?
Once I learn COM what can I do using it? I mean its applications.
I just don't see COM going away any time soon. If you want to be a windows expert, you must understand how it works.
Learning COM (or at least being au fait with its concepts) means you can integrate with thousands of existing components, including Microsoft Word and Excel.
I work largely in the Java domain, but having a little knowledge of COM means I can interface effectively to Word and Excel (in particular) to programatically create/read documents. I don't have an in depth knowledge, but I have a little, and having that increases my productivity substantially.
You should learn enough about COM to know that you don't want to learn any more.
The details of COM - particularly from a multithreaded or C++ application - are excruciatingly irritating, and I would not wish them on anyone (I don't know them myself, but I know enough to know this).
Therefore if you do need to call a COM library, you should learn enough COM to be able to do so, then stop. Ideally, use a language such as C# or Delphi where some (or hopefully most) of the details are handled for you relatively transparently.
There are a lot of COM libraries around, but if you feel you want to use one, you should look at its specific documentation for how to do this - it probably has a reasonable example that you can simply adapt for your own use without too much effort. If it does not, then it clearly isn't very good and shouldn't be used.
COM is definitely worth learning to at least some level if you are a Windows developer. Another common case for its use, in addition to the others already mentioned, is in the implementation of binary behaviors and BHOs for Internet Explorer. They are both implemented using COM interfaces between IE and your code.
I'd also like to recommend a couple of resources for learning about COM:
Don Box's Essential COM. It is an excellent description of why COM is the way it is and really helps you get a deeper understanding of what is going on. If you take the time to read this book, then you will have a fundamental understanding of COM internals that will serve you very well.
These two articles: { 1, 2 } ...are a very good discussion of the particular subject of COM apartments, alluded to as "excruciatingly irritating" (unfairly, imho) in MarkR's answer.