All your COM belong to us...

Started by
5 comments, last by wazoo69 22 years, 10 months ago
Okay, I agree the joke''s been chewed more times than a pack of juicyfruit in a 10-kid family.. Anyways, I''m working on a small 2d game engine in C++ that uses pure virtual base classes for the rendering devices (so that I can have either an OpenGL or Direct3D DLL link in during runtime).. Now just because I love learning new ways of doing things, I''m trying to implement the same thing in COM objects.. Now I understand a few BASICS of COM but this only leads me to ask more questions such as: CAN my base COM interface class rest in my static game engine library, or do I have to create a seperate DLL for that? -AND- Can anyone recommend some GOOD COM books (intro - intermediate level) which can get me started WITHOUT using MFC.. or even some tutorials.. thanks in advance! Wazoo
Learn about game programming!Games Programming in C++: Start to Finish
Advertisement
You certainly don''t need to use MFC, but I''d STRONGLY encourge you to use the ATL.

The M$ book, COM: Base Services is decent (the one I have). It covers all the COM groundwork and how to build COM objects in C++. There''s scant tutorials in the MSDN docs as well - they show you how to make COM objects from scratch.

If you really want to make COMpliant objects you''re in for a world of hurt. The COM binary spec lets you define (nearly) whatever you want for the object methods - but if you want to use them in VB/Java/VBScript/IE there''s a ton of non-compiler enforced specifications you need to meet. The ATL does make it alot easier to meet though.

There''s no such thing as an interface class (it''s a redundant oxymoron). It''s either an interface defition or a class defition. To make a com object, you first define one or more interfaces it will support (IUnknown must be one of them). Then you define a class that inherits from each of those interfaces (don''t do the encapulated classes per interface idea, that''s for non-MI systems), and implement each of the given methods


Magmai Kai Holmlor
- The disgruntled & disillusioned
- The trade-off between price and quality does not exist in Japan. Rather, the idea that high quality brings on cost reduction is widely accepted.-- Tajima & Matsubara
COM does not have to be in a DLL ... they can be implemented many ways ... they just assume that because most things that must be COM compliant are ActiveX ... AND are meant to be shared by seperate apps. COM objects have to be implemented in DLLs IF you want to use the built in services to load your components - DirectX does NOT do this ... you use DirectX specific calls to get the initial interface ... then use COM from there ... it''s up to you. COM compliance does however tie your hands in certain other details .. but they are actually fairly easy to meet.

THE book to get is "Inside COM" by MS press ... pure C++ ... no MFC BS ... covers the ideas, and implementation .. goes in proper order too ... teaches you how to make COM-like stuff (interface driven components) before tying you to all the rules about return values and registry entries ... etc etc ...

Best of luck to you.
Actually THE book to get (and yes I own "Inside COM") is:

"Developer's Workshop: COM and ATL 3.0" by Andrew W. Troelsen (it is an orangish-red book) ISBN: 1-55622-704-3.

That book is nothing short of amazing. He shows you how to implement COM using raw C++ and then shows you how ATL makes it much easier (and it does). The author covers IDL, DCOM, in-proc/out-of-proc servers, the various threading apartment models, enumerators, collections, event sinks, error handling, component registration (registry stuff), ActiveX controls and does so in raw C++ and ATL. No topic is skimmed over - this author knows what he is talking about. I've been developing C++ COM components for about 3 years now and I only discovered this book last year. Since I bought the book and devoured it my knowledge of all things COM has really expanded. I'm a much more effective COM developer because of this book.

Buy this book if you want to learn about raw C++ COM and COM via ATL , I promise you won't regret it. "Inside COM" is good but it is getting old and doesn't deal with ATL. ATL is something you are going to want to use for anything other than the most trivial COM components.



Dire Wolf
www.digitalfiends.com

Edited by - Dire.Wolf on June 5, 2001 7:50:30 PM
[email=direwolf@digitalfiends.com]Dire Wolf[/email]
www.digitalfiends.com
quote:
COM objects have to be implemented in DLLs IF you want to use the built in services to load your components - DirectX does NOT do this ... you use DirectX specific calls to get the initial interface ... then use COM from there

I think it''s the other way around - you make the COM::CoCreate call first (albeit through Direct3DCreate8 or whatnot), then you use non-COM factories to instance other objects (like IDirect3DSruface8''s coclass).


Dire.Wolf
How much success have you had actually building COM objects that can be used in various langauges? I''ve had... ''issues'' with all but the most trivial interfaces.

Magmai Kai Holmlor
- The disgruntled & disillusioned
- The trade-off between price and quality does not exist in Japan. Rather, the idea that high quality brings on cost reduction is widely accepted.-- Tajima & Matsubara
Wow! Thanks for the responses guys..

Yeah I did some checking around at some COM book sites and they
recommend the same thing..."Inside COM" first then the "Developer''s Workshop" one....though "Inside" seems good, it was suggested to get "Developer''s" as well to provide insight on ATL 3.0...

Yeah...sigh...I think the phrase "world of hurt" and "microsoft" go hand and hand these days..

I''ve found some small COM tutorials while waiting for the delivery of "Developer''s", and I''m just doing the gruntwork of making my RenderFactory produce either the OpenGL or Direct3D objects through the appropriate interfaces..

btw. Thanks for answering my first question though (about the sticking of my COM idl definitions into my static library),
it gave me some things to think about during the "slight" cough re-design..

Wazoo
Learn about game programming!Games Programming in C++: Start to Finish
Magmai,

I've developed fairly complex, multithreaded (free threading model) inproc and out-of-proc components/servers in C++/ATL. Most of my components have been used by internal developers at my company and mainly in VB and VBScript. I believe one guy at my company used Visual J++ and didn't have any problems with my inproc server.

I don't know what problems you are having so I can't suggest anything. If you have any questions, feel free to email me.



Dire Wolf
www.digitalfiends.com

Edited by - Dire.Wolf on June 19, 2001 10:37:10 AM
[email=direwolf@digitalfiends.com]Dire Wolf[/email]
www.digitalfiends.com

This topic is closed to new replies.

Advertisement