Re: COM ON!!! ... OLE!!! AYE CARRAMBA!!
Go to http://www.pbq.com.au/home/hutch/masm.htm
download the latest MASM32 there are code docs
to interface to COM thru assembler and if you know assembler
I presume you'll get it going.....
Euman
----- Original Message -----
From: "Matthew Lewis" <matthewwalkerlewis at YAHOO.COM>
To: "EUforum" <EUforum at topica.com>
Sent: Tuesday, March 20, 2001 13:23
Subject: RE: COM ON!!! ... OLE!!! AYE CARRAMBA!!
|
|
|
|
| > -----Original Message-----
| > From: Mike The Spike [mailto:mtsreborn at yahoo.com]
|
| <snip>
|
| > 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?
|
| I think you're being a bit over dramatic [again]. If you know the layout
of
| the interface, it's easy. You'd have to know this to use C++ to work with
| COM. You have to know this in _any_ language to work with COM. So what's
| the big deal?
|
| I've done some more poking around, and I think it's definitely possible.
| Even if you don't have the docs on the layout of an interface, using
| IDispatch, it should be possible to get the info that's needed. In fact,
it
| should be able to spit out a bare bones wrapper for a COM object.
|
| As far as I can tell, there's no real need to use an actual pointer table
in
| memory. We could simply use sequences to keep track of things, the same
way
| we already use them to deal with routine_id's.
|
| I've looked a little harder at asm.e, and it's not quite as hard as I
| thought (I think :). I need to add support for CALL FAR, but that looks
| pretty straightforward. I should have Eu working with COM pretty shortly
| given that.
|
| > In conclusion, your compiler should support by-name
| > refferncing of structure/class/interface members for
| > COM to work.
|
| Maybe so, but that just means a little extra work if you want to support
| COM. Certainly doesn't make anything _impossible_, as you say. Here's
what
| I envision use of my wrappers might look like:
|
| -- file: com.ew
| global constant
| iid_iunknown = "00000000-0000-0000-C000-000000000046"
| -- end com.ew
|
| constant
| myobj = new_com_object( clsid ),
| myobj_queryinterface = define_com_func( clsid, iid_iunknown,
| "QueryInterface")
|
| object ok
|
| ok = com_func( myobj, myobj_queryinterface, {} )
|
| Basically, I want to make it operate as close to Eu's c_proc/c_func as
| possible, although it will handle string conversions automatically, since
| all COM strings need to be unicode. Then it makes sense to write wrappers
| for individual COM objects using the COM wrappers.
|
| > 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.
|
| Yeah, I have. But I don't understand what you're talking about. The
issue
| of GUID's is there no matter what language you use. It's not _that_
| difficult to use them. Here's a proc for converting a GUID from a string
to
| a proper GUID structure:
|
| procedure poke_guid( sequence guid, atom ptr )
| object ok
|
| -- struct GUID
| -- DWORD Data1
| -- WORD Data2
| -- WORD Data3
| -- BYTE Data4[8]
|
| ok = value( "#" & guid[1..8] )
| ok = ok[2]
| poke4( ptr, ok )
| ptr += 4
|
| guid = guid[10..length(guid)]
|
| for i = 1 to 2 do
| ok = value( "#" & guid[1..4] )
| ok = ok[2]
| poke4(ptr, ok)
| ptr += 2
| guid = guid[6..length(guid)]
| end for
|
| for i = 1 to 2 do
| ok = value( "#" & guid[1..2] )
| ok = ok[2]
| poke(ptr,ok)
| ptr += 1
| guid = guid[3..length(guid)]
| end for
|
| guid = guid[2..length(guid)]
|
| for i = 1 to 6 do
| ok = value( "#" & guid[1..2] )
| ok = ok[2]
| poke(ptr,ok)
| ptr += 1
| guid = guid[3..length(guid)]
| end for
|
| end procedure
|
| There. That wasn't so hard, was it?
|
| Matt Lewis
|
|
|
|
|
Not Categorized, Please Help
|
|
