just came not long ago to COM stuff, pointed by Ernie and read Sean stuff too. had tried with ATL too . then i was wonder what apps that heavily using COM. hmm... i said, maybe MSIE, MSOffice, MSOutlook, ... please correct me if i'm wrong in those thing.

but it been pretty long time enough knowing those apps were "infamous" slow bloated apps , especially when i had to run on old 386 machine. actually i run on those machines when i post threads in this forum. i usually using outlook to check mails. u can imagine how darn slooooooowwwww it is to load up. and IE just darn same . well, time is money, so i had to somehow manage that. geee! who want to play inet for half hour just to check and replying mails, except dumb victim like me :((

then i thought about COM. is it that COM who made this things slooowwww? remembered in my mind that i saw "registering components" and "type library" string when installing office. neva check how the registry size got bloated in size after installing ;p
if it is, is it worth for me to muck in COM stuph? i know, maybe for jobs requiring that, i'll learn of course. but, i really want to know if i had wrong concept here. could anyone share his/her opinion out, please?

regards
Posted on 2003-01-10 00:27:56 by dion
what I think about:

yes COM makes things slow - all the dlls that are loaded, the very heavy registry access, mainly cause of the
CLSID searching, too much usage of strings instead of DWORDs, bloated VC++ stuff, etc.

but yes, its worth to deal with - simply because otherwise you are one day out of know-how. Actually the basic
windows API is always accessable, but one day it will be gone. Then you only have SHELL / GDI+ and other sh**
for accessing Windows functions.

but no, maybe its not worth. There are a lot of technologies from Microsoft, that passed by without any importance,
like ActiveMovie, DDE, ActiveX, WinG, etc. If .NET will be the up-to-date technologie, maybe COM goes to MS:\RECYCLER...
Posted on 2003-01-10 06:59:54 by beaster
uhm... thanks beaster, so it bottleneck the registry, eh?
Posted on 2003-01-10 21:12:01 by dion
COM is the underpinning of interapplication comunications. Most of all, its a communication protocol so one blob of code can talk to another blob of code, with either blob written in any language.

So VB talks to VC talks to Java talks to... I've even seen COM done in Fortran. Since COM specs the binary protocol, its a natural for assembly work.

Microsoft leans heavily on COM to reuse functionality. For example, the main window of the MSIE web browser is packaged inside a dll, any app wanting internet access can borrow it, and instantly get all the web browsing functionality of MSIE. I believe that Outlook uses it to display email (which is why hypertext and hyperlinks in letters work).

Now since Microsoft long ago learned people buy software based on its feature list, and not on its speed, they bloat up their apps to make them do lots of obscure tasks no one ever would use. These take execution time.

So does the whole OOP way of resusing existing classes and class libraries. Just compare the speed of a decent C/C++ program verses one done in MFC.

So on top of the real bloat, MS adds in COM. COM isn't the bloated part, but casual users/coders oft confuce the two.

So is it worth knowing? That of course depends on what your needs are. My reason to explore it was to give Basic back the ability to simply run the occasional long task in assembly, something that was once the norm in PC programming (back when 64K of RAM was concidered great, and the CPU couldn't support any more any way).

I'm less thrilled about going the other way, adding existing blobs to an assembly app. The blob is bound to be slower then anything you could do yourself. I'd write my own blt transfers for custom button shapes long before I'd add a client site and re-use something like thread.dll.

If one is using VC it is definately worth learing, now you're adding components with comporable speed to the rest of your app. It's actually less usefull to know if you're working in VB, as VB hides the details of COM from you.
Posted on 2003-01-11 08:21:33 by Ernie
Apart from MS apps, there is one place where I've really seen COM used Extensively and that's in the Metrowerks IDE plugin architecture.

It not only allows you to extend it to the point of providing your own Text Editor in the place of their defualt, but you can actually hook the compiler and precompiler and alter the output, but only with COM. Adobe Photoshop also uses COM (since about version 5.5) for it's Environment and Plugs also. Beyond the MS Camp, I think COM is used to the extent of writing Plugins rather than allowing automated access to the apps. Beyond MS, I don't know if other developers truly understand it in that mannor or if companies just don't care about providing such a polished product. Visio, made heavy use of COM before MS acquired them. I think any product that supports VBA must be automatable else VBA is pointless (Visio, AutoCAD, Etc. supoprt it).

In the End, COM is just a binary interface definition (not really executable on it's own accord) that provides for a standard way to communicate so DLL's or applications of other languages can communicate. For exampe, a program written in C or Pascal or C++ or Fortran or SmallTalk or Delphi cannot automatically call each others functions or methods but with COM defining a standard interface, they can very easily reuse each others functionality.

I think the overhead of COM is negligeable. If it's heavily bloated or noticably slow, it's because the source code behind it is not efficient (in whatever language they programmed it in). If you used Office on a 386 and it's slow, keep in mind that the early Office apps had to statically link every DLL and load them all before you can run the application. Since about Office 97 or moreso 2000, they employed a technique in their compiler called "DelayLoad" where the app would run immediately and only if a DLL was needed would it be loaded and used and if the DLL was never needed, it was never loaded. As well, if you're using a newer Office on a 386, of course it's slow... it's requirements are very different from Office 95--. But don't blame COM for that.

Thanks,
Shawn
Posted on 2003-01-11 12:28:20 by _Shawn
thanks you all, sorry, but i had to reading offline now, cant concentrate if online ...
Posted on 2003-01-12 20:30:56 by dion
uhm... i think i got better understanding right now, thanks all ;)
Posted on 2003-01-13 06:24:04 by dion