OSDev.org

Hi ,i am curretly working on my GUI and have decided to make my EditBoxes etc. work use c++ classes, but am having great problems in finding info on how to link/setup the COM object.

I was hoping that someone would be able to point me to some useful info.

I am using ELF objects (not executable format), and am linking at runtime.

Any help would be appriciated.
pkd.

to use COM objects residing in a shared library, you need to (how its done under Win)
-code the actual object, implement the interface as a virtual table, implement AddRef, Release, QueryInterface, and any methods in your custom interface.
-code the ClassFactory object that instantiates an object
-code the DllGetClassObject function, that instantiates a ClassFactory object for export it from the library
-compile these together into a shared library
-register the library in the COM registry

now, assuming u're not on Win, you will have to create at least a rudimentary registry database and COM runtime to handle loading shared libraries. shouldnt be that hard.
(i admit that, given that i work under linux, i have a need for such runtime myself, but i so far i've put it off and been content with static linking for the time being. i will though.)

i am doing everything COM-style, and i find it a Very Good Idea.
so i say, go for it!
i may be able to give some help.

a useful guide from the source:
msdn library

p.s. the proper name is "Component Object Model", not "Common"

Ok I think i was getting a bit ahead of myself again

I was actually just trying to implement classes and after writing null functions for _ZdlPv (i think is delete object) and _Unwind_Resume (which appears to be error Handling?)., I compiled and ran just to see what the code was doing, But I found that the code is working as is.

g++ must handle the setup, (I assumed I had to setup the memory and copy the functions as well as create the Function Table).

So Tonight i am looking through the disassembled code to try to understand whats going on.

Thanks for the help

ps. I thouht all classes were refered to as COM, my mistake.

bye
pkd

pkd wrote: Ok I think i was getting a bit ahead of myself again

I was actually just trying to implement classes and after writing null functions for _ZdlPv (i think is delete object) and _Unwind_Resume (which appears to be error Handling?).

_Z -> standard prefix without an additional _ which Microsoft-using people add

dl -> delete

Pv -> pointer to void

This is delete(void *) in C++ name mangling.

_Unwind_Resume is an OS function (or it should be...) for exception handling, and longjmp/setjmp handling. They both unwind, and in most ABI's they're recommended to be handled together.

ps. I thouht all classes were refered to as COM, my mistake.

There are lots of people turning around in their beds when they read that... (no, the inventors of for instance smalltalk, java and c++ aren't dead, they're not in a grave). COM is the Microsoft-abomination that pretends to be the only good thing, and even pretends to be an original one at that.

COM is the Microsoft-abomination that pretends to be the only good thing, and even pretends to be an original one at that.

care to justify this claim (rather questionable in many ways), give some alternatives and in which ways they do better to address the same issues?

I would suggest any other way of doing OO programming without factories, the C++ examples that include factories, or the numerous Java examples that do? I don't have a physical example ready, I'm not in to using them so I don't see the reason to. The only things I'm trying to point out & emphasize, they are not the only way, they are not perfect, they are not even the ones thinking it up. For the record, they never have thought up any original ideas, except for the worst kind of patches for holes in their own versions of software based on stolen unpatented ideas.

This of course refers to Joliet (which patched the 8.3 limit in ISO9660, which was put in for Microsoft compatibility), Long File Names in FAT (because of their own limit, the same again), patch after patch for "technologies" that completely open up your computer, so they still open up your computer but prohibit that specific program from harming you, stuff like that... The normal versions of these would be either Rock Ridge or UDF, just plain longer names such as... well... pretty much EVERY file system there is, except for FAT, and using things like Java instead of ActiveX.

BTW, found a second site using ActiveX. It sucks too. (school email system, which has had nothing but complaints).

as i expected you've been somewhat misinformed about COM.

what COM is?
is a technique for component and interface-based programming with relatively simple principles but powerful implications. it does not prescribe any particular language for implementation. it facilitates reliable functionality discovery, upgradeability, interoperability, incapsulation, black-box reuse of binary components, (potentially) use of out-of-process and remote components, transparent run-time linkage and what else did i miss.
(what a list of buzzwords, ugh. but then again, when properly applied, all of it can be achieved)

what COM is NOT?
-not the same as M$'s runtime and its extensions.
-not confined to M$'s platforms.
-ActiveX is just an application of COM, and a different story
-not the same as OO or C++.
-not dead. pro-M$ people claim it has been replaced by .NET or whatever the latest buzz seems to be; open-source folks loathe it as M$'s creation (tohether with the usual optimizato-mania which prohibits anything less efficient than plain C).

i believe that COM is the ideal way to do open-source.
it lets you to finally stop reinventing the bicycle.
it has great potential, sadly few people understand and appreciate it.

implementation of COM objects in C++ is rather awkward, and C++ is to blame for that. M$'s solutions like ATL and MFC are ugly (what's with all the macros and dirty hacks?). what is really needed is a language similar in concept to C++ but with more control, proper macro capabilities (not awkward templates and scope-ignorant preprocessor), etc. something that is really a high-level assembler.

as for various sins of M$, well i am definitely not advocating M$ or their ways in general.

IMnsHO

Edit: This posting is a bit more aggressive than I intended it to be. Sorry; I shouldn't post before breakfast.

zloba wrote: as i expected you've been somewhat misinformed about COM.

what COM is?

...

it facilitates reliable functionality discovery, upgradeability, interoperability, incapsulation, black-box reuse of binary components, (potentially) use of out-of-process and remote components, transparent run-time linkage and what else did i miss.

Just like CORBA and SOAP, and take that as a starting point to venture into the wide scope of component technologies out there.

As usual, Microsoft managed to corner the market with something that does it all, is good at nothing, a ***** to use, and generally percieved by the majority as the best invention since sliced bread because it's from Microsoft.

i believe that COM is the ideal way to do open-source.

Because it makes things even more complex, and harder to understand?

it lets you to finally stop reinventing the bicycle.

It's a classic attempt at "one size fits all", which - as all such attempts - has its uses, but falls much short of keeping the promise. Look at Java for another such attempt.

Use COM for things it is good at. It is certainly not good in kernel space.

it has great potential, sadly few people understand and appreciate it.

The problem with COM is that it complicates things significantly, and in most cases, needlessly.

You will know when you need e.g. a remote procedure call technology in your software. Then look up the alternatives, and chose the one best suited to your needs. I just hate it when people fall for those "miracle cures", be they named COM, Java, XML or whatever.

Use things for what they're best at.

implementation of COM objects in C++ is rather awkward, and C++ is to blame for that.

As usual, C++ is blamed whenever some interfacing technology fails to be adaptable to the versatility of that language. Huh?

Are you proficient in C++? I ask because most claims of C++ being awkward comes from people who only touched C++ on the surface.

Funny that one of the best books on COM goes into great detail on how COM and C++ can work hand-in-hand...

what is really needed is a language similar in concept to C++ but with more control...

I can hardly picture a language giving me more control than C++, except perhaps Assembly. That's what makes C++ the litmus test for cross-language technologies in the first place: It allows you to do things few other languages allow for.

proper macro capabilities (not awkward templates and scope-ignorant preprocessor)...

OK, forget my question as to your C++ proficiency. Asking for macros instead of templates answers the question alright.

...something that is really a high-level assembler.

Try C...

*gg*

nice argument 's going on here.

COM - as Solar has stated - is a ***** to use. No, don't blame c++ on that, gosh. c++ is ok. I 'm not proficient with this language for I use other languages far more - like C, which is kinda smooth in kernel land.

COM technology adds a layer of complexity to simple things like importing a dll or remotely managing an application - althou' I have to say, in enterprise level, if you are in urgent need of some office application remotely controlled by some c++ *.exe, you can get relatively quick relatively useable examples - which, upon a closer look, seem like *very* ugly hacks.

Look: what is a VARIANT good for if you only want to pass an ordinary String to a Component? Isnt BSTR somename=System.AllocString(L"irgendwas") sufficient? No, you have to use VARIANT datatype, as if it were good for anything but added complexity and - getting into the programmers way.

No, COM is definitely not the egg-laying woolmilkswine.

@solar: Posting after having some coffee and a cake is definitely better.

And before another language flame war breaks out: I happily agree that C++ is about the ugliest of the "living" languages around. Such is the cost of versatility and C-compatibility.

Not to forget latin:

quid quid agis prutender agas et respice finem

nice sentence, but to my modern ears: *uugly*



You see, Uglyness is a very individual thing.

BI lazy wrote: quid quid agis prutender agas et respice finem

nice sentence, but to my modern ears: *uugly*

I only found out that it should be "Quidquid Abis", but I have no idea what that means... (4 years of Latin at school, what a waste of time...)

This posting is a bit more aggressive than I intended it to be. Sorry; I shouldn't post before breakfast.

oh, thank you, i find your posting to be quite good, if somewhat disagreeable.

Just like CORBA and SOAP, and take that as a starting point to venture into the wide scope of component technologies out there.

i will. (when i get serious about remote interaction)

Because it makes things even more complex, and harder to understand?

quite the opposite. when used properly, it helps manage complexity, by breaking up funcitonality into components.

The problem with COM is that it complicates things significantly, and in most cases, needlessly.

what i said. if it complicates things, then you're doing it wrong.

my experience has been, when things start to get messy, i sit back, review what's going on, draw up a good ol' pencil-and-paper design, refactor and reuse some things, define interfaces and order is restored. achieving a lot of in-project and inter-project black-box reuse and problem isolation.

Look at Java for another such attempt.

been there, done that. not quite the same thing.

Use COM for things it is good at. It is certainly not good in kernel space.

i agree, kernel is a different story (kinda obvious). but i find it to be quite good for pretty much anything else i can think of

...something that is really a high-level assembler.
>Try C...

i shoulda clarified, a "_full-featured_ high-level assembler". i do want to keep the same OO, but have more control over it and other things. and "macros" refer to the concept in general, not excluding templates, but making them more flexible and replacing the preprocessor business with something more flexible and scope-aware.

Funny that one of the best books on COM...

interesting, what is the title/author?

.. goes into great detail on how COM and C++ can work hand-in-hand...

oh, they very much can. don't get me wrong - i can do everything i need to implement COM objects in C++. its just all the extra typing that i find awkward. mo' typing, mo' typos, mo' time wasted, less gets done.

Are you proficient in C++?

dunno what you call proficient, but it gets the job done.

As usual, C++ is blamed whenever some interfacing technology fails to be adaptable to the versatility of that language. Huh?

or maybe there isn't enough versatility? it does not fail per se (gets the job done), but it could do better. i talked to a few people having skills similar to mine, and they agreed that C++ could use improvement. and those are not the kind of people who just got off qbasic and read "C++ for dummies" or such.

I can hardly picture a language giving me more control than C++, except perhaps Assembly.

well, i can. not only that, i intend to implement one. and yes, i know what that means.

BI lazy wrote: quid quid agis prutender agas et respice finem

Ok, 'fess up, what do you think that means?

Latin was too many moons ago for me to struggle translating it, and I wasn't that good even back when poor old Father Gabriel was trying to teach me.

zloba wrote: is a technique for component and interface-based programming with relatively simple principles but powerful implications. it does not prescribe any particular language for implementation. it facilitates reliable functionality discovery, upgradeability, interoperability, incapsulation, black-box reuse of binary components, (potentially) use of out-of-process and remote components, transparent run-time linkage and what else did i miss.

Component and interface based programming: easy with c++ too
Upgradability: c++ can do... child classes?
interoperability: say something an ABI already defines?
encapsulation: I'll keep that private... or should I keep it protected? Yes, c++ already can do
black-box reuse: something like list<vector<char *>> ?
black-box reuse of binary components: something like the default class stuff, like a class library
remote components: 1. why? there's about no reason to do that 2. there are ENOUGH different methods, think Java's RMI
Transparent runtime linkage: something like dynamic libraries?
Reliable functionality discovery? Care to elaborate?

(what a list of buzzwords, ugh. but then again, when properly applied, all of it can be achieved)

Now... same with all the other techs that have been around for some decades...

what COM is NOT?
-not the same as M$'s runtime and its extensions.
-not confined to M$'s platforms.
-ActiveX is just an application of COM, and a different story
-not the same as OO or C++.
-not dead. pro-M$ people claim it has been replaced by .NET or whatever the latest buzz seems to be; open-source folks loathe it as M$'s creation (tohether with the usual optimizato-mania which prohibits anything less efficient than plain C).

ActiveX is an application of COM? are you trying to get me to use it or loathe it?

i believe that COM is the ideal way to do open-source.
it lets you to finally stop reinventing the bicycle.
it has great potential, sadly few people understand and appreciate it.

We're not trying to reinvent the bicycle, we're reinventing the world. What if the bicycle isn't fit for my world?

what is really needed is a language similar in concept to C++ but with more control, proper macro capabilities (not awkward templates and scope-ignorant preprocessor), etc. something that is really a high-level assembler.

You care to imply you need macros instead of const ints, inline functions and similar constructions? They all obey scope, up to any wished limit you desire, plus namespaces. Highlevel assembler? that's a reserved keyword of Randall Hyde, you should know. For the function, C was designed. An OO extension to C is, well, c++?

as for various sins of M$, well i am definitely not advocating M$ or their ways in general.

like the microsoft-haters that make a website against bill using frontpage, put it online with IE, make it work only with that browser (implicit...), run their server on IIS and then wonder why they're being called hypocritical. And/or why their server is being hacked