I figured this would be a good question to ask...

I know only a little COM and I was wondering how it related/it's use in programming today...

I tried to run some of Ernie's com examples from his site (however it ran -- just not what it was supposed to do -- It was an active program -- just didn't create a splitter window...

The question is... why do this?

Can't you write these programs without using COM?

I know it tends to be helpful in circumstances such as Directx (when you have many programmers accessing set functions)

but as for a single programmer, does it really help very much?

As for the com examples... I have windows98 second edition -- don't know why it won't work

Sliver
Posted on 2002-01-23 14:28:06 by Sliver
First off, oops, thanks for the bug report. Could you please tell me which example didn't work so I can take a look see?

Thanks mucho.

Nextly, the splitter is NOT com stuff, it's straight procedural code.

So, what about COM?

First of all, COM is a COMMUNICATIONS standard, so different blobs of code can talk to other blobs of code, no matter what language the individual blobs are written in. This way, C can talk to C++ can talk to VB can talk to Java can talk to...

WHY go to that trouble? Because code blobs are expensive, and there exist some really really nice ones already complete, debugged, at an affordable price. So why not re use them?

Custom control reuse becomes easier thru an (admitable appaulingly complex) set of COM interfaces, so yu can see things like a basically function web browser in under 100K bytes (it reuses a MSIE dll to make the browser window), or a 5K scriptable app (that reuses the MS script engine to do the hard work).

And the last reason may well be that Microsoft isn't the biggest fish in the pond, it's the pond itself, and Microsoft is 100% behind COM, and when you're a little fish in a big pond you try to swim with the current.
Posted on 2002-01-23 21:54:37 by Ernie
And lastly, its not normal!.

COM is different in a wierd way that plays with your mind, much like trying see how anyone can choke on a pretzil :grin:

... dont get me wrong, I enjoy practicing COM, but my reason is mainly because it can be a challenge to understand sometimes. (Its not just looking up another API in the MSDN).

... as well, there is things you can do in COM that you just can't with an API. Like apps Ernie gives reference to, usually the more attractive projects have a COM in is somewhere ( M$ Agent Speach software for example )

:alright:
NaN
Posted on 2002-01-23 23:16:23 by NaN
Ernie and NaN did not answer your question most properly.
COM is used in big applications, where you have to manage many data structures of different types. So, not to be confused, you set each structure to have its own set of management procedures (the "methods"). If the objects procedures are defined in the current module (.exe or .dll), you can use regular programming (and you should), but if you have a plugin (you have to manage structures, whose management procedures are defined in another .exe or .dll), then it is impossible without OOP. That is because you and the compiler do not know the address of each function given (when the .dll is dynamically loaded, not linked with a .lib file). Here OOP comes to help- the structures have defined the address of the functions, used to manage them.
COM and OLE use these basics to make easier to create and manage such structures. Bear in mind that all this OOP stuff has purpose only when the objects(structures) will be used by another module, dynamically linked with the current module!! If these objects are gonna be used in this module, too, then for speed's sake do not use the addresses of functions, defined in the structures-> use the straight approach to call the management functions to save cpu.
My opinion might be very different from the other coders' , but I think this is the best explanation of oop and com.
I am very disappointed with the way MS made OLE object creation- too complex, unnecessarily complex. Could have been done with a function to register the GUID window classname (to load the dll, where this class of window's functions are), and then to use CreateWindowEx, with the GWL_USERDATA of the window set with the address of the object. Am I wrong? Please correct me if I'm wrong, but this approach of mine makes thousands, millions of lines unnecessary, and makes everything more intuitive. MS made Windows very flexible and enough welcome for this approach. I think they on purpose created things so complex in order to defend themselves against being accused of doing nothing much.
I use my concepts with 100% success, and I have made out a lot of optimizations of OOP, still nowhere posted.
Posted on 2002-10-20 00:29:48 by Ultrano
Ultrano,

Sorry to say, I disagree with several of your points (but thats why we have horse races, right?)

First off, COM is OLE is ActiveX is DCOM is COM+ is.... new coats of paint from the Microsoft marketing department concerning incremental innovations on the same framework. (Minor point: since OLE 2.0, OLE doesn't stand for anything anymore. Object Linking and Embedding died with O.L.E. 1.0)

Thats a minor point altogether, except terminology IS importaint. Unfortunately, COM uses new words for alot of concepts you already know.

Next said, COM is NOT OOP. The confusion is natural, since the best COM sources all talk about how C++ abstract classes serve as the basis of the COM vtable interface is implimented. But thats a minor point of the low level implementation of COM itself, not of C++. Microsoft's implimentation went that way since their C++ compiler, Borlands, GNU's, and most of the major C++ compilers of the day HAPPENED to compile code to an identical binary standard (which was nowhere defined in the ANSI standard they were written to, it was just a "natural" way to do things).

If COM was about OOP, then explain why Visual Basic since version 4 has its foudation built on COM? VB is most dfinately not OOP. Instead, is is 'object based.' So is COM.

Again I make the point: the binary standard of COM defines how one code blob interacts with another (possibly seperately written and compiled) blob. That makes it a comminications standard, though I can't remember seing it discussed explicitely as such in any literature (it how MY mind wraps around it), though of course there are discussions of how VC can talk to VB can talk to Jave can talk to (sheesh, I've even seen COM in Fortran!).

Good communications standards means seperate blobs can communicate. And since a DLL is a handy way to package a run time loadable blob of code, that is one way to package a COM class (coclass). COM needs hooks into the operating system to convert a coclass GUID (CLSID) (in windows via the registry to a qualified file path name ) to the executable holding the code.

Could have been done with a function to register the GUID window classname (to load the dll, where this class of window's functions are), and then to use CreateWindowEx, with the GWL_USERDATA of the window set with the address of the object.


Good point, let me expand in it. <grin>

Many Window items act as OBJECTS. A Window is one. You define a Window CLASS, and create from it Window OBJECTS. Hey! Sounds like something OOPish to me.

BUT... one window cannot 'inherate' from another.... sure, you can subclass, superclass, ect, but that hardly looks like C++ classes, does it? Toss away OOP, think Object Based. You get objects to play with, not code to inherate.

Yet they ARE objects. And assosciating an individual object with one another is as natural as remembering your best friends phone number. Especially in low level assembler work, it is quite natural (simple and effieient too) to use GWL_USERDATA to hold special references.

If you check some of my procedural work (such as the splitter app) you'll see how each splitter window instance holds reference to its own array of window handles so it knows which windows to arrange atround itself. \

Yes, it works. Yes, it is simple. But it is NOT OOP, it is not COM.

(sorry... not gonna proof this, flame me later lol)
Posted on 2002-10-24 20:48:48 by Ernie
Ernie, I totally agree with you. The only Object Based work I've ever had was with MFC and VB. And I do not intend to use it anymore. As always, I'll continue doing all things my way. I know COM != OOP, but thought they are tightly related, forgetting my previous experience.
Posted on 2002-10-24 22:00:22 by Ultrano
From an asm point of view, is it better to study the online library or get "Inside COM"? I know they won't discuss it from asm, but which would be better to help understand it?
Posted on 2002-10-25 17:05:21 by drhowarddrfine
There is no better explanation of the low level binary interface contract available then "Inside COM"

A copy of that book was open on my lap the whole time I was writing the orgional CoLib library and samples.

Be patient with this book, read it chapter by chapter, and let him build the framework.
Posted on 2002-10-29 20:25:48 by Ernie
I'm reading about COM from MSDN but you might help me get a jump on something.

From the tutorial, Step 2: Initializing Direct3D, in DirectX, you need to call Direct3DCreate8 in order to get an interface to a Direct3D object. But if I know the clsid, can't I just use that and skip the create8? Just use clsid and go directly to GetAdapterDisplayMode?

I guess I'm confused, so far, about clsid. I wrote a little dx8 test program that worked. I understand why I need to get the interface (so I can get the vtable). I just don't see a need for Direct3DCreate8 for writing my own program.

Also, correct me if I'm wrong, I could go directly to the dll and load that couldn't I? The only disadvantage is if the dll is already in use by some other program? I also noticed that some dlls don't expose their methods so I guess I'm answering my own question right now.
Posted on 2002-11-03 10:26:19 by drhowarddrfine
Am I continuing to answer my own questions? Is IDirect3DCreate8 only a header check? That I can use the clsid to fetch the vtable? (Do I really have to call IDirect3DCreate8?)
Posted on 2002-11-03 10:39:09 by drhowarddrfine
KNowing nothing concerning DirectX, I'm going to give a simple answer. You call IDirect3DCreate8 becasue thats the rule.

All you may want it to do is return your interface pointer, but the routine may be doing other initialization functions you are not aware of.


Best to at least TRY how Microsoft documents doing something first.
Posted on 2002-11-03 22:59:21 by Ernie
I'm going to experiment some time today. Yes, it works just fine calling the that, but after doing some reading, I think I can call the clsid. Will let you know.
Posted on 2002-11-04 12:36:40 by drhowarddrfine