RE: COM ON!!! ... OLE!!! AYE CARRAMBA!!

new topic     » goto parent     » topic index » view thread      » older message » newer message

> Well, I don't know about that.  But first, let me
> ask you, have you used COM
> in any other language?  I pulled down the COM specs:
> 
> http://www.microsoft.com/com/resources/comdocs.asp

I have several Object & Embedding degrees...
I was 15 when I got my first, so yeah, I know what I'm
talking about...
I coded DX in C exclusively for two years back in 98',
untill last year, so yep, I know my COM ...

> and took a look at them.  It's certainly not _easy_,
> but I doubt it's
> impossible.  There are a few hurdles to be overcome,
> of course.  I haven't
> gotten my hands on any COM object with the docs for
> it (to get the GUID's,
> interface details, etc), but that would be the first
> step, I think.  The
> only real hurdle would be figuring out how to call
> the interfaces.  Building
> the pointer table would be easy.
> 
> (To explain, to call the functions in a COM object,
> you have to build a
> virtual function pointer table, which turns out to
> be what C++ does for
> object methods.  But it's a binary standard, so any
> language that supports
> calling functions by pointer can theoretically
> interface with COM.)
> 
> In theory, you could use call() to call the
> interfaces, but that wouldn't
> handle the arguments.  It should be fairly easy for
> someone to write a
> little ASM routine that pushed the arguments on the
> stack and called the
> routine, right?  I don't really know ASM, so that
> probably won't be me any
> time too soon, but here's how I suspect it would
> work.
> 
> You could have a memory location that holds a
> pointer to the arguments in
> memory, and another that tells you how many there
> are.  The ASM looks at
> that and pushes them on the stack.  Then there's
> also a pointer stored in
> memory that tells the ASM where to jmp to. 
> Depending on the calling
> convention (stdcall/cdecl--COM defaults to stdcall,
> but it's legal to have
> cdecl routines), you might also need to clean the
> stack.
> 
> Then in Eu you write the code to wrap that stuff,
> and an app calls those
> routines.
> 
> After that, it's all figuring out the COM API, which
> you'd pretty much have
> to do with any other language interfacing with COM. 
> How far did you get?
> Can you post what you did?  Maybe we can figure out
> how to wrap COM so it's
> easy to use with Eu.
> 
> Matt Lewis

I thought it was as easy as that too man, but the
problem is simple.
You need to be able to use COM, to use routines that
allow you to use COM.
Your compiler should support COM, otherwise, you're
stuck at doing it like this;

push(args)
call(offset + 4)

Now what is offset+4?
Is it IID_IDirect3DRM->CreateViewport?
You should do a lot of work figuring out at wich
offset members are, in theory it's all possible, but
for practical uses, it's not.
Just like it's theoretically possible to travel
through time, it don't mean we can go for a trip to
the middle ages for 29.95 pluss tax?

In computing, everything is possible, but equally
impossible at the same time.

In conclusion, your compiler should support by-name
refferncing of structure/class/interface members for
COM to work.
Besides, you talk about GUIDs, look up how you have to
work with GUIDs, and you'll see that it's by using
some COM interfaces. It's the whole chicken-and-egg
thing.

Mike The Spike

new topic     » goto parent     » topic index » view thread      » older message » newer message

Search



Quick Links

User menu

Not signed in.

Misc Menu